Android Developer's Cheat

An Android application is defined using one or more of Android's four core application components:

• Activity (<activity> declaration in AndroidManifest.xml)
• Service (<service> declaration in AndroidManifest.xml)
• BroadcastReceiver (<receiver> declaration in AndroidManifest.xml)
• ContentProvider (<provider> declaration in AndroidManifest.xml)

When an application starts, 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).

Once installed on a device, each Android application lives in its own security sandbox:

• The Android operating system is a multi-user Linux system in which each application is a different user.
• By default, the system assigns each application a unique Linux user ID. The system sets permissions for all the files in an application so that only the user ID assigned to that application can access them.
• Each process has its own VM, so an application's code runs in isolation from other applications.
• By default, every application runs in its own Linux process.

The Android system places each process into an "importance hierarchy" based on the components running in the process and the state of those components. There are five types of processes (processes with the lowest importance are eliminated first):

1. Foreground process
2. Visible process
3. Service process
4. Background process
5. Empty process (does not hold any active application components, used e.g. for caching purposes)

UI Thread

The main thread is in charge of dispatching events to the appropriate user interface widgets, including drawing events. As such, the main thread is commonly called the UI thread.

Since the Android UI toolkit is not thread-safe all manipulations to the user interface must be performed from the UI thread. Thus, there are simply two rules to Android's single thread model:

• Do not block the UI thread
• Do not access the Android UI toolkit from outside the UI thread

Activities

An activity 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. It can start other activities, including activities that live in separate applications.

• An activity is implemented as a subclass of android.app.Activity.

Services

A service typically performs long-running operations in the background without a user interface. For example, a service can handle network transactions, play music, or work with a content provider without the user being aware of the work going on.

• A service is neither a separate process nor a thread.
• A service is implemented as a subclass of android.app.Service.
• A service can be declared as private (android:exported="false" in AndroidManifest.xml), thus blocking access from other applications.
• A Service instance can be started with Context.startService() and Context.bindService().
  • A started service runs even if the component that started it is destroyed. For instance it may download or upload a file over the network and stop when the operation is done.
  • A bound service offers a client-server interface that allows components to interact with the service, and even do so across processes (using IPC). When all components unbind, the service is destroyed.
  A service can work both ways — it can be started (to run indefinitely) and also allow binding.

The most important callback methods you should override are:

• onStartCommand() is called when another component, such as an activity, requests that the service be started, by calling startService().
• onBind() is called when another component wants to bind with the service (such as to perform RPC) by calling bindService().
• onCreate() is called when the service is first created, to perform one-time setup procedures (before calling either onStartCommand() or onBind()).
• onDestroy() is called last to clean up any resources such as threads, registered listeners, receivers.

Examples: SimpleBinderExample (from "Unlocking Android" book).

Content Providers

A content provider manages a shared set of application data. Data are stored either in the file system, an SQLite database, on the web, or any other persistent storage location the application can access.

• A content provider is implemented as a subclass of android.content.ContentProvider.
• A content provider exposes a public URI for each data set it controls (URIs begin with "content://").
• Data is exposed as a simple table on a database model, where each row is a record and each column is data of a particular type and meaning.

Three informations are needed to query a content provider:

• The URI that identifies the provider
• The names of the data fields you want to receive
• The data types for those fields

A query returns a set of zero or more database records with a unique numeric ID for each record.

Acronysms