APP Activities

http://developer.android.com/guide/components/activities.html

1. Activities

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.

Tipycally, one activity in an application is specified as the "main" activity, which is presented to the user when launching the application for the

first time.

Each time a new activity starts, the previous activity is stopped. But the system preserves the activity in a stack (the "back stack").

2. Creating an activity

Two most important callback methods are :

(1) onCreate()

The system calls this when creating your activity.

Within your implementation, you should initialize the essential components of your activity.

Most importantly, this is where you must call setContentView() to define the layout for the activity's user interface.

(2) onPause()

The system calls this as the first indication that the user is leaving your activity (thougn it does not always mean the activity is being

destroyed).

3. Implementing a user interface

The user interface for an activity is provided by a hierarchy of views - objects derived from view class. Each view controls a particular rectangular

space within the activity's window, and can respond to user interaction. (A view might be a button that initiates an action when the user

touches it).

"Widgets" are views that provide a visual (and interactive) elements for the screen, such as a button, text field, checkbox, or just an image.

"Layouts" are views derived from ViewGroup that provide a unique layout model for its child views such as a linear layout, a grid layout....

The most common way to define a layout using views is with an XML file saved in your application resources. In this way,

you can maintain the design of your userinterface separately from the source code that defines the activity's behavior.

You can set the layout as the UI for your activity with setContentView(), passing the resource ID for the layout.

However, you can also create new views in your activity and build a view hierarchy by inserting new Views into a new group then use that

by passing the root ViewGroup to setContentView().

4. Declaring the activity in the manifest

The android:name attribute is the only required attribute - it specifies the class name of the activity.

5. Using intent filters

<activity> element - <intent - filter> declare how other application components may activate it.

</intent - filter>

The <action> element specifies that this is the "main" entry point to the application.

The <category> element specifies this activity should be listed in the system's application launcher (to allow users

to launch this activity).

If you want your activity to respond to implicit intents that are delivered from other application ( and your own), then you must

define additional intent filters for your activity . For each type of intent you want respond, you must include an <intent-filter>

that includes an <action> element, and optionally, a <category> element and a <data>.

6. Starting an Activity

acivity is activated by an intent. An intent can also carry small amounts of data to be used by the activity that is started.

Intent intent =newIntent(this,SignInActivity.class);
startActivity(intent);

    Intent intent =newIntent(Intent.ACTION_SEND);
    intent.putExtra(Intent.EXTRA_EMAIL, recipientArray);
    startActivity(intent);

7. Starting an activity for a result

For example, perhaps you want the user to pick one of their contacts, so your activity can do something with the information in that contact.

Here's how you can create such an intent and handle the result:

privatevoid pickContact(){
// Create an intent to "pick" a contact, as defined by the content provider URI
Intent intent =newIntent(Intent.ACTION_PICK,Contacts.CONTENT_URI);
startActivityForResult(intent, PICK_CONTACT_REQUEST);
}

@Override
protectedvoid onActivityResult(int requestCode,int resultCode,Intent data){
// If the request went well (OK) and the request was PICK_CONTACT_REQUEST
if(resultCode ==Activity.RESULT_OK && requestCode == PICK_CONTACT_REQUEST){
// Perform a query to the contact's content provider for the contact's name
Cursor cursor = getContentResolver().query(data.getData(),
newString[]{Contacts.DISPLAY_NAME},null,null,null);
if(cursor.moveToFirst()){// True if the cursor is not empty
int columnIndex = cursor.getColumnIndex(Contacts.DISPLAY_NAME);
String name = cursor.getString(columnIndex);
// Do something with the selected contact's name...
}
}
}

startActivityResult()

onActivityResult( int requestCode, int resultCode, int data)

What happens is, a ContentResolver performs a query against a content provider, which returns a Cursor that allows the queried data to be read. For more information, see the Content Providers document.

8. Shutting Down an Activity

finish();

finishAcitivity();

9. Managing the Acitivity Lifecycle

three states

(1) Resumed , activity is foreground of the screen and has user focus

(2) Paused, another activity is in the foreground and has focus , but this one is still visible. That is that activity is partially transparent or

does'nt cover the entire screen (Activity object is retained in memory, maitains all state and member information, remains

attatched to the window manager).

(3) Stopped, the activity is completely obscured by another activity, and is also alive (Activity object is retained in memory, maitains all state

and member information, but not attatched to the window manager).

10. Implementing the lifecycle callbacks

publicclassExampleActivityextendsActivity{

@Override
publicvoidonCreate(Bundle savedInstanceState){
super.onCreate(savedInstanceState);
// The activity is being created.
}

@Override
protectedvoidonStart(){
super.onStart();
// The activity is about to become visible.for example, onPause() is called when the device goes to sleep or when a dialog appears. Because this state can transition often, the code in these two methods should be fairly lightweight in order to avoid slow transitions that make the user wait.
}

@Override
protectedvoidonResume(){
super.onResume();
// The activity has become visible (it is now "resumed").
}

@Override
protectedvoidonPause(){
super.onPause();
// Another activity is taking focus (this activity is about to be "paused").
}

@Override
protectedvoidonStop(){
super.onStop();
// The activity is no longer visible (it is now "stopped")
}

@Override
protectedvoidonDestroy(){
super.onDestroy();
// The activity is about to be destroyed.
}
}

The entire lifetime happens between the call to onCreate() and the call to onDestroy().

The visible lifetime happens between the call to onStart() and the call to onStop(). For example, you can register a

BroadcastReceiver in onStart() to monitor changes that impact your UI, and unregister it in onStop() when

the user can no longer see what you are displaying. The system might call onStart() and onStop() multiple times

during the entire lifetime of the activity, as the activity alternates between being visible and hidden to the user.

The foreground lifetime of an activity happens between the call to onResume() and the call to onPause().

for example, onPause() is called when the device goes to sleep or when a dialog appears. Because this state can

transition often, the code in these two methods should be fairly lightweight in order to avoid slow transitions

that make the user wait.

onCreate()

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,

and so on. This method is passed a Bundle object containing the activity's previous state, if that state was captured

(see Saving Activity State later).

onPause(): Called when the system is about to start resuming another activity.

onCalled() Called when the activity is no longer visible to the user.

12. Saving activity state

The system calls onSaveInstanceState() before making the activity vulnerable to destruction.

The system passes this method a Bundle in which you can save state information about the activity as name-value pairs, using

methods such as putString() and putInt(). Then, if the system kills your application process and the user navigates back to your

activity, the system recreates the activity and passes the Bundle to both onCreate() and onRestoreInstanceState().

If there is no state information to restore, then the Bundle passed to you is null (which is the case when the activity is

created for the first time).

The only work required by you is to provide a unique ID (with the android:id attribute) for each widget you want

to save its state. If a widget does not have an ID, then the system cannot save its state.

13. Handling configuration changes

Some device configurations can change during runtime (such as screen orientation, keyboard availability, and language). When

such a change occurs, Android recreates the running activity (the system calls onDestroy(), then immediately calls onCreate()).

This behavior is designed to help your application adapt to new configurations by automatically reloading your application with

alternative resources that you've provided (such as different layouts for different screen orientations and sizes).

The best way to handle such a restart is to save and restore the state of your activity using onSaveInstanceState()

and onRestoreInstanceState() (or onCreate()), as discussed in the previous section.

14. Coordinating activities