In this section we go through some basic Android concepts which readers should take note of. Most of the information have been taken from http://developer.android.com/develop/index.html and condensed where possible to suit the needs of this user guide. For a more in depth view the reader should refer to the source.

An Activity is an application component that provides a screen with which users can interact in order to do something, such as dial the phone, take a photo, send an email, or view a map. Each activity is given a window in which to draw its user interface. The window typically fills the screen, but may be smaller than the screen and float on top of other windows.

The Android system attempts to keep application process around for as long as possible, but eventually will need to remove old processes when memory runs low. As described in Activity Lifecycle, the decision about which process to remove is intimately tied to the state of the user's interaction with it. In general, there are four states a process can be in based on the activities running in it, listed here in order of importance. The system will kill less important processes (the last ones) before it resorts to killing more important processes (the first ones).

The foreground activity (the activity at the top of the screen that the user is currently interacting with) is considered the most important. Its process will only be killed as a last resort, if it uses more memory than is available on the device. Generally at this point the device has reached a memory paging state, so this is required in order to keep the user interface responsive.

A visible activity (an activity that is visible to the user but not in the foreground, such as one sitting behind a foreground dialog) is considered extremely important and will not be killed unless that is required to keep the foreground activity running.

A background activity (an activity that is not visible to the user and has been paused) is no longer critical, so the system may safely kill its process to reclaim memory for other foreground or visible processes. If its process needs to be killed, when the user navigates back to the activity (making it visible on the screen again), its onCreate(Bundle) method will be called with the savedInstanceState it had previously supplied in onSaveInstanceState(Bundle) so that it can restart itself in the same state as the user last left it.

An empty process is one hosting no activities or other application components (such as Service or BroadcastReceiver classes). These are killed very quickly by the system as memory becomes low. For this reason, any background operation you do outside of an activity must be executed in the context of an activity BroadcastReceiver or Service to ensure that the system knows it needs to keep your process around.

Figure 13: Activity Lifecycle

Figure 13 shows the lifecycle of an activity. From the flowchart it can be seen that an Application process can be killed when apps with higher priority need memory. Sometimes an Activity may need to do a long-running operation that exists independently of the activity lifecycle itself. An example is when you are logging data from a Shimmer device. As logging can take a long time, the application should allow the user to leave the application while it is executing. To accomplish this, your Activity should start a Service in which logging takes place. This allows the system to properly prioritize your process (considering it to be more important than other non-visible applications) for the duration of the upload, independent of whether the original activity is paused, stopped, or finished.

A Serviceis an application component that can perform long-running operations in the background and does not provide a user interface.

It is important to understand when to use a service when designing an Android application.

Note that services too have a priority lifecycle. Users should note the difference between a foreground service and a background service. A foreground service is defined as:

• A started service can use the startForeground(int, Notification) API to put the service in a foreground state, where the system considers it to be something the user is actively aware of and thus not a candidate for killing when low on memory. (It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.)

See the Service Example for more information on how to use the ShimmerService class in an application.

When a process is created for your application, its main thread is dedicated to running a message queue that takes care of managing the top-level application objects (activities, broadcast receivers, etc.) and any windows they create. You can create your own threads, and communicate back with the main application thread through a Handler. This is done by calling the post or sendMessage methods, from your new thread.

Please refer to one of the available examples like the Bluetooth Manager Example for a demonstration on how to use the Handler.

Readers should note that while it is safer to use a static handler, for the sake of simplicity many of the examples don't.