Application Fundamentals 2.

All Android applications contain zero or more of the following components:

1. Activity – a single piece of user interface (UI). In a system it runs independently from other elements although users have a smooth experience of different activities appearing on the screen in a sequence. Activities usually contain some graphical elements (customised or taken from a pre-defined set) and constitute a specific action that users can perform like writing an email or selecting contact from a list.

2. Service – a separate part of the application without a graphical representation (running in a background). Service itself does not start a separate thread because it runs in context of the activity or the broadcast receiver which has started it. However, it usually should use a working thread to perform some complex computation or lengthy I/O operations.

3. Content Provider – a mechanism that allows applications to share data between each other or to simply persistently save some information. It is basically an interface which provides standard methods to access data like query, insert, update, delete. No specific type of data structure is imposed by the system, it can be a single file or an SQLite database. Content provider is uniquely identified by its authority and can contain many types of data objects (many tables in a database). The most common method of accessing an object is to query Content Provider with a specific content uri which has a generic form of: content://<authority>/..<type path>../<id>/Broadcast Receiver – a part of the application which responds to actions broadcasted by the system itself (dimming the screen, capturing a new photo) or by other parts of the application (the same one or not).

4. Broadcast Receiver does not have its own graphical representation but it can initiate certain actions to keep users informed about its work. This could be done for instance by creating a notification in a status bar or updating a desktop widget.

Android is an event-driven system. 

These events are called Intents. 

Intent API is a very powerful mechanism that manages interactions between application components across the whole system. 

Developers do not have to write any additional lines of code in order to integrate their application with other ones as long as they know their set of supported Intents.

Moreover, it does not make any difference whether you send an Intent to a separate application or another part of the same one – the mechanism is exactly the same.

A good example is the Map application which supports Intents that contain a request to display specific geo location. 

Developers can simply broadcast this Intent whenever they want to show a map with a specific location. Additionally, should users have installed a different app which masks the functionality of the Map application (by filtering Intents), this new application would be used automatically instead.

The Intent mechanism allows developers to easily reuse different system components across the platform. They can focus on really innovative and unique functionality and simply add (’attach’) new components like maps or navigation to their applications which makes them even more compelling and useful.

Very often Android has to deal with situations of memory shortage. The system has to reclaim resources in order to allow new processes to run.

In such situations Android ranks all active processes according to the following order:

1. Foreground process – the process which hosts a foreground activity or a service that is bound to a foreground activity. It basically means the part of the system that the user is currently interacting with, so at any given time there are only few such processes. These processes are killed only in absolute critical situations as not terminating them will most likely cause lack of responsiveness (or even displaying error messages to the user).

2. Visible process – a process that does not have any active components, but still is visible to the user. A good example is a process which hosts an activity that launched another not-full-screen activity. Visible processes are considered important and will only get killed if the system cannot find enough memory for foreground processes.

3. Service process – a process which basically hosts a service and at the moment it is neither a foreground nor a visible process. Those processes however may be doing some important tasks for the, user like playing music in a background, or downloading some data from the Internet.

4. Background process – a process which handles an activity that is currently not visible. These processes are likely to get killed at any given time so activities should be prepared for that.

5. Empty process – a process without any of the application’s components. The only reason why the system holds these processes alive is for caching purposes.