Some notes about Android Context

Context is an interface to global information about an application environment. It's an abstract class whose implementation is provided by the Android system.

Context allows access to application-specific resources and classes, as well as calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.

All the widgets receive a Context parameter in their constructor. In a regular Android application, you usually have two kinds of Context, Activity and Application. It's usually an Activity Context that the developer passes to classes and methods that need a Context.

Basically the Application context is associated with the Application and will always be the same throughout the life cycle of your app, where as the Activity context is associated with the activity and could possible be destroyed many times as the activity is destroyed during screen orientation changes and such.

In particular you should be careful when dealing with anything that deals with the GUI that requires a Context. For example, if you pass the application Context into the LayoutInflator you will get an Exception. It's good practice to use an Activity's Context within that Activity, and the Application Context when passing a context beyond the scope of an Activity to avoid memory leaks.

Here's a quick snippet showing how you can find both the Activity Context and the Application Context:


public class MyActivity extends Activity {
public void aMethod() {
Context actContext = this; /*returns the Activity Context since Activity extends Context.*/

Context appContext = getApplicationContext(); /*returns the context of the single, global Application object of the current process. */

Button btnGoToFirstAct = (Button) findViewById(R.id.btnGoToAct1);
Context vwContext = btnGoToFirstAct.getContext(); /*returns the context of the View. */



When run in the debugger, you can see the results of this:

 Notice that the vwContext in this case also returns the Activity Context.



Hope that helps answer some questions. Drop me a message in the comments if you have anything to add.

Android applications: Components and Structure

Android extends the standard views/data model, providing a new model that is suitable for equipment activated at all times.

The structure of an Android application is defined as follows:

The file AndroidManifest.xml

This defines the components of the application and their relationships. It gives the permissions to application as to what it can do with users. It can also give permission to components of the application.

The views (Class android.view.View)

The interface of a program for Android is a tree of views.

Activity (android.app.Activity class)
This is something that the user can do, translated into program. It corresponds to a screen, but can have multiple views.

Intent (android.content.Intent class)
Describes an action which must be performed.

Service (android.app.Service )
Program that operates in background.

Content Provider (android.content.ContentProvider class)
Encapsulates data and provides them commonly to several programs.

Notification (android.app.NotificationManager and android.app.Notification classes)
Class which informs the user about what is happening.

Besides components, there are also resources that can be XML files, image files as jpeg, etc. These use the android.content.Resources interface and are stored in the res directory.

Components of an Android application

Each component is included in a list stored in the manifest file AndroidManifest.xml of each application.

Activity

An activity corresponds to a screen. If an application is composed of several screens, it has an activity for each screen. Each activity is a class that extends the base class Activity. It has a graphical user interface made of views, and it responds to events. When you change screen, a new activity is launched.
It can return a value. For example, if an activity can choose something, text, image, it returns what is chosen.

The graphical interface of an activity is described by a Layout:
- Full screen.
- Float: dialogue or alert.
- None. In this case it works in background and is invisible. It is maked visible by giving it a layout.

Note that the graphical user interface is described in XML as XUL and XAML.

Intent

The intents are the goals of applications and are made effective by a new screen. An intent is made up of an action and data that are URI.

Examples of actions: MAIN, VIEW, EDIT, PICK.
If one wants to see a card about a person, an intent is defined. The action is VIEW and the data is the URI which enables access to this card.

IntentFilters describes how the action should apply.

IntentReceiver is an object that responds to external events. It can operate in the application or it can start an application.

Example of intent, view a webpage: VIEW for action and for data http://www.linkToStuff.org.

Service

A service is designed to operate independently of the screen, thus of activities. The best example is the music player that can works while moving from one screen to another.

Content Provider

Data stored by a computer program, in the form of files or SQLite databases are private and may not be used by other applications.
But Content Provider may be used to share data among several applications. The interface ContentResolver is the interface that provides data to other objects.

Notification

The class android.app.Notification defines how an event must be notified to user: displaying an icon, changing state of a led, vibration, or others. While the class android.app.NotificationManager sends the message in the form so defined.

Android Activities

An activity presents a visual user interface for one focused endeavor the user can undertake.

For example, an activity might present a list of menu items users can choose from or it might display photographs along with their captions. A text messaging application might have one activity that shows a list of contacts to send messages to, a second activity to write the message to the chosen contact, and other activities to review old messages or change settings.

Though they work together to form a cohesive user interface, each activity is independent of the others. Each one is implemented as a subclass of the Activity base class.

An application might consist of just one activity or, like the text messaging application just mentioned, it may contain several. What the activities are, and how many there are depends, of course, on the application and its design.

Typically, one of the activities is marked as the first one that should be presented to the user when the application is launched. Moving from one activity to another is accomplished by having the current activity start the next one.

Each activity is given a default window to draw in. Typically, the window fills the screen, but it might be smaller than the screen and float on top of other windows.

An activity can also make use of additional windows — for example, a pop-up dialog that calls for a user response in the midst of the activity, or a window that presents users with vital information when they select a particular item on-screen.

The visual content of the window is provided by a hierarchy of views — objects derived from the base View class. Each view controls a particular rectangular space within the window. Parent views contain and organize the layout of their children. Leaf views (those at the bottom of the hierarchy) draw in the rectangles they control and respond to user actions directed at that space. Views are, therefore, where the activity's interaction with the user takes place.

For example, a view might display a small image and initiate an action when the user taps that image. Android has a number of ready-made views that you can use — including buttons, text fields, scroll bars, menu items, check boxes, and more.

A view hierarchy is placed within an activity's window by the Activity.setContentView() method. The content view is the View object at the root of the hierarchy.

Activity Lifecycle

Activities in the system are managed as an activity stack.
When a new activity is started, it is placed on the top of the stack and becomes the running activity -- the previous activity always remains below it in the stack, and will not come to the foreground again until the new activity exits.

An activity has essentially four states:

If an activity in the foreground of the screen (at the top of the stack), it is active or running.

If an activity has lost focus but is still visible (that is, a new non-full-sized or transparent activity has focus on top of your activity), it is paused.

A paused activity is completely alive (it maintains all state and member information and remains attached to the window manager), but can be killed by the system in extreme low memory situations.

If an activity is completely obscured by another activity, it is stopped.

It still retains all state and member information, however, it is no longer visible to the user so its window is hidden and it will often be killed by the system when memory is needed elsewhere.

If an activity is paused or stopped, the system can drop the activity from memory by either asking it to finish, or simply killing its process. When it is displayed again to the user, it must be completely restarted and restored to its previous state.

There are three key loops you may be interested in monitoring within your activity:

The entire lifetime of an activity happens between the first call to onCreate(Bundle) through to a single final call to onDestroy().

An activity will do all setup of "global" state in onCreate(), and release all remaining resources in onDestroy(). For example, if it has a thread running in the background to download data from the network, it may create that thread in onCreate() and then stop the thread in onDestroy().

The visible lifetime of an activity happens between a call to onStart() until a corresponding call to onStop(). During this time the user can see the activity on-screen, though it may not be in the foreground and interacting with the user. Between these two methods you can maintain resources that are needed to show the activity to the user.

For example, you can register an IntentReceiver in onStart() to monitor for changes that impact your UI, and unregister it in onStop() when the user an no longer see what you are displaying. The onStart() and onStop() methods can be called multiple times, as the activity becomes visible and hidden to the user.

The foreground lifetime of an activity happens between a call to onResume() until a corresponding call to onPause(). During this time the activity is in front of all other activities and interacting with the user.

An activity can frequently go between the resumed and paused states -- for example when the device goes to sleep, when an activity result is delivered, when a new intent is delivered -- so the code in these methods should be fairly lightweight.

The entire lifecycle of an activity is defined by the following Activity methods. All of these are hooks that you can override to do appropriate work when the activity changes state. All activities will implement onCreate(Bundle) to do their initial setup; many will also implement onPause() to commit changes to data and otherwise prepare to stop interacting with the user.

You should always call up to your superclass when implementing these methods.

protected void onCreate(Bundle icicle);

Called when the activity is first created. This is where you should do all of your normal static set up: create views, bind data to lists, etc. This method also provides you with a Bundle containing the activity's previously frozen state, if there was one.

Always followed by ..




protected void onStart();

Called when the activity is becoming visible to the user.

Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden.

protected void onRestart();

Called after your activity has been stopped, prior to it being started again. Always followed by onStart()

protected void onResume();
Called when the activity will start interacting with the user. At this point your activity is at the top of the activity stack, with user input going to it.

Always followed by onPause().

protected void onPause();
Called when the system is about to start resuming a previous activity. This is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU, etc. Implementations of this method must be very quick because the next activity will not be resumed until this method returns.

Followed by either onResume() if the activity returns back to the front, or onStop() if it becomes invisible to the user.

protected void onStop();
Called when the activity is no longer visible to the user, because another activity has been resumed and is covering this one. This may happen either because a new activity is being started, an existing one is being brought in front of this one, or this one is being destroyed.

Followed by either onRestart() if this activity is coming back to interact with the user, or onDestroy() if this activity is going away.

protected void onDestroy();
The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method.