Instructor: Mazhar Hussain Android Services, Broadcast receiver, application resources and process Instructor: Mazhar Hussain

Services  A Service is an application component that can perform long-running operations in the background and does not provide a user interface. Another application component can start a service and it will continue to run in the background even if the user switches to another application. Additionally, a component can bind to a service to interact with it and even perform interprocess communication (IPC). For example, a service might handle network transactions, play music, perform file I/O, or interact with a content provider, all from the background.

Services Started Bound A service is "started" when an application component (such as an activity) starts it by calling startService(). Once started, a service can run in the background indefinitely, even if the component that started it is destroyed. Usually, a started service performs a single operation and does not return a result to the caller. For example, it might download or upload a file over the network. When the operation is done, the service should stop itself. Bound A service is "bound" when an application component binds to it by calling bindService(). A bound service offers a client-server interface that allows components to interact with the service, send requests, get results, and even do so across processes with interprocess communication (IPC). A bound service runs only as long as another application component is bound to it. Multiple components can bind to the service at once, but when all of them unbind, the service is destroyed.

Services >A first-class component in Android that must be declared in the the manifest >Has no graphical user-interface >Used for long-running background tasks; typically networking, I/O, interaction with content providers, multimedia >There are two classes of Services; Service Started (local) Bound (remote) Across apps Used within the same app

Services To create a service, you must create a subclass of Service (or one of its existing subclasses). In your implementation, you need to override some callback methods that handle key aspects of the service lifecycle and provide a mechanism for components to bind to the service, if appropriate. The most important callback methods you should override are: onStartCommand() The system calls this method when another component, such as an activity, requests that the service be started, by calling  startService() Once this method executes, the service is started and can run in the background indefinitely. If you implement this, it is your responsibility to stop the service when its work is done, by callingstopSelf() or stopService(). (If you only want to provide binding, you don't need to implement this method.)

Services onBind()The system calls this method when another component wants to bind with the service (such as to perform RPC), by calling bindService(). In your implementation of this method, you must provide an interface that clients use to communicate with the service, by returning an IBinder. You must always implement this method, but if you don't want to allow binding, then you should return null. onCreate()The system calls this method when the service is first created, to perform one-time setup procedures (before it calls either onStartCommand() or onBind()). If the service is already running, this method is not called. onDestroy()The system calls this method when the service is no longer used and is being destroyed. Your service should implement this to clean up any resources such as threads, registered listeners, receivers, etc. This is the last call the service receives.

Services If a component starts the service by calling startService() (which results in a call to onStartCommand()), then the service remains running until it stops itself with stopSelf() or another component stops it by callingstopService(). If a component calls bindService() to create the service (and onStartCommand() is not called), then the service runs only as long as the component is bound to it. Once the service is unbound from all clients, the system destroys it.

Broadcast Receivers  are meant to respond to an intent (usually one sent by a service or a system event), do something, and be done. An example here might be the user touches an Near Field Communication (NFC)-enabled phone to a tag, the system creates an intent for it, and a registered receiver handles it to change some settings (change volume, turn on bluetooth, etc). When an intent is broadcast via sendBroadcast, it will be sent to all receivers that have matching intent filters. *NFC, short for Near Field Communication, is a short range wireless RFID technology that makes use of interacting electromagnetic radio fields instead of the typical direct radio transmissions used by technologies such as Bluetooth.

Example : You want to perform some data analysis to find some patterns in your data Background Thread  If all processing should happen while the user is in the same application and on the same Activity, a background thread (or an AsyncTask that manages a background thread) would be a good approach. Service  If you want to allow the user to exit the application while the processing is being performed (and notify them of the results later), or allow them to progress through multiple activities in the same application while the processing is being performed, a Service would be a better approach.

Android App Resources

Applications Resource It takes more than just code to build a great app. Resources are the additional files and static content that your code uses, such as bitmaps, layout definitions, user interface strings, animation instructions, and more. You should always externalize resources such as images and strings from your application code, so that you can maintain them independently. Externalizing your resources also allows you to provide alternative resources that support specific device configurations such as different languages or screen sizes, which becomes increasingly important as more Android-powered devices become available with different configurations. In order to provide compatibility with different configurations, you must organize resources in your project's res/ directory, using various sub-directories that group resources by type and configuration.

For any type of resource, you can specify default and multiple alternative resources for your application: Default resources are those that should be used regardless of the device configuration or when there are no alternative resources that match the current configuration. Alternative resources are those that you've designed for use with a specific configuration. To specify that a group of resources are for a specific configuration, append an appropriate configuration qualifier to the directory name.

Providing Resources You should always externalize application resources such as images and strings from your code, so that you can maintain them independently. You should also provide alternative resources for specific device configurations, by grouping them in specially-named resource directories. At runtime, Android uses the appropriate resource based on the current configuration. For example, you might want to provide a different UI layout depending on the screen size or different strings depending on the language setting.

Grouping Resource Types

Grouping Resource Types

Accessing Resources Animation Resources Define pre-determined animations. Tween animations are saved in res/anim/ and accessed from the R.anim class. Frame animations are saved in res/drawable/ and accessed from the R.drawable class. Color State List Resource Define a color resources that changes based on the View state. Saved in res/color/ and accessed from the R.color class. Drawable Resources Define various graphics with bitmaps or XML. Saved in res/drawable/ and accessed from the R.drawable class. Layout Resource Define the layout for your application UI. Saved in res/layout/ and accessed from the R.layout class. Menu Rsource Define the contents of your application menus. Saved in res/menu/ and accessed from the R.menu class.

Accessing Resources String Resources Define strings, string arrays, and plurals (and include string formatting and styling). Saved in res/values/ and accessed from the R.string, R.array, and R.plurals classes. Style Resource Define the look and format for UI elements. Saved in res/values/ and accessed from the R.style class. More Resource Types Define values such as booleans, integers, dimensions, colors, and other arrays. Saved in res/values/ but each accessed from unique R sub-classes (such as R.bool, R.integer,R.dimen, etc.).

Android Processes

When an application component starts and the application does not have any other components running, the Android system starts a new Linux process for the application with a single thread of execution. By default, all components of the same application run in the same process and thread (called the "main" thread). If an application component starts and there already exists a process for that application (because another component from the application exists), then the component is started within that process and uses the same thread of execution. However, you can arrange for different components in your application to run in separate processes, and you can create additional threads for any process.

Process lifecycle The Android system tries to maintain an application process for as long as possible, but eventually needs to remove old processes to reclaim memory for new or more important processes. To determine which processes to keep and which to kill, the system places each process into an "importance hierarchy" based on the components running in the process and the state of those components. Processes with the lowest importance are eliminated first, then those with the next lowest importance, and so on, as necessary to recover system resources. There are five levels in the importance hierarchy. The following list presents the different types of processes in order of importance (the first process is most important and is killed last):

References 1. http://developer.android.com/guide

Questions/Comments?