Android Chapter03 Life Cycle
Android Chapter03 Life Cycle
Android Chapter03 Life Cycle
Android Applications
An application consists of one or more components that are defined in the application's manifest file. A component can be one of the following: 1. 2. 3. 4. An Activity A Service A broadcast receiver A content provider
Android Applications
1. Activity
An activity usually presents a single visual user interface from which a number of actions could be performed. Altough activities work together to form a cohesive user interface, each activity is independent of the others. 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 through so called intents.
Android Applications
2. Service
A service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time. It's possible to connect to (bind to) an ongoing service (and start the service if it's not already running). While connected, you can communicate with the service through an interface that the service exposes.
Android Applications
3. Broadcast receiver
A broadcast receiver is a component that does nothing but receive and react to broadcast announcements.
Many broadcasts originate in system code (eg. you got mail) but any other applications can also initiate broadcasts.
Broadcast receivers do not display a user interface. However, they may start an activity in response to the information they receive, or - as services do - they may use the notification manager to alert the user.
Android Applications
4. Content provider
A content provider makes a specific set of the application's data available to other applications. The data usually is stored in the file system, or in an SQLite database. The content provider implements a standard set of methods that enable other applications to retrieve and store data of the type it controls. However, applications do not call these methods directly. Rather they use a content resolver object and call its methods instead. A content resolver can talk to any content provider; it cooperates with the provider to manage any interprocess communication that's involved.
6
Android Applications
A Linux process encapsulating an Android application is created for the application when some of its code needs to be run, and will remain running until 1. it is no longer needed, OR 2. the system needs to reclaim its memory for use by other applications.
An unusual and fundamental feature of Android is that an application process's lifetime is not directly controlled by the application itself.
Instead, it is determined by the system through a combination of 1. the parts of the application that the system knows are running, 2. how important these things are to the user, and 3. how much overall memory is available in the system.
Component Lifecycles
Application components have a lifecycle 1. A beginning when Android instantiates them to respond to intents 2. An end when the instances are destroyed. 3. In between, they may sometimes be active or inactive, or -in the case of activities- visible to the user or invisible.
Start
End
10
Activty Stack
11
Activity Stack
Running Activity Back button pushed or running activity closed Last Running Activity Activity n-1
Activity Stack
Previous Activities
...
Figure 1.
12
Figure 2.
13
1.
It is active or running when it is in the foreground of the screen (at the top of the activity stack for the current task). This is the activity that is the focus for the user's actions.
14
2.
It is paused if it has lost focus but is still visible to the user. That is, another activity lies on top of it and that new activity either is transparent or doesn't cover the full screen. 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.
15
3.
It is stopped if it is completely obscured by another activity. 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.
16
Figure 3.
17
1. Write an Android app. (PuraVida) to show the different cycles followed by an application. 2. The main.xml layout should include a Button (text: Finish, id: btnFinish) and an EditText container (txt: and id txtMsg). 3. Use the onCreate method to connect the button and textbox to the program. Add the following line of code:
Toast.makeText(this, "onCreate", 1).show();
4. The click method has only one command: finish(); called to terminate the application. Add a Toast-command (as the one above) to each of the remaining six main events. To simplify your job use the Eclipses top menu: Source > Override/Implement Methods 5. On the option window check mark each of the following events: onStart, onResume, onPause, onStop, onDestry, onRestart (notice how many onEvent methods are there!!!) 6. Save your code.
18
7. Compile and execute application. 8. Write down the sequence of messages displayed by the Toast-commands. 9. Press the FINISH button. Observe the sequence of states. 10. Re-execute the application 11. Press emulators HOME button. What happens? 12. Click on launch pad, look for icon and return to the PuraVida app. What sequence of messages is displayed? 13. Click on the emulators CALL (Green phone). Is the app paused or stopped? 14. Click on the BACK button to return to the application. 15. Long-tap on the emulators HANG-UP button. What happens?
19
7. Run a second emulator. 1. Make a voice-call to the first emulator that is still showing our app. What happens on this case? (real-time synchronous request) 2. Send a text-message to first emulator (asynchronous attention request) 8. Write a phrase in the EditText box (these are the best moments of my life.). 9. Re-execute the app. What happened to the text?
20
19. What happens now with the data previously entered in the text box?
21
22
All of these methods are hooks that you can override to do appropriate work when the state changes. (MUST) All activities must implement onCreate() to do the initial setup when the object is first instantiated. (Highly Recommended) Many activities will also implement onPause() to commit data changes and otherwise prepare to stop interacting with the user.
23
Applications Lifetime
Entire Lifetime
The seven transition methods (Figure 3) define the entire lifecycle of an activity. The entire lifetime of an activity happens between the first call to onCreate() through to a single final call to onDestroy(). An activity does all its initial setup of "global" state in onCreate(), and releases all remaining resources in onDestroy().
24
Visible Lifetime
Visible Lifetime
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. The onStart() and onStop() methods can be called multiple times, as the activity alternates between being visible and hidden to the user. Between these two methods, you can maintain resources that are needed to show the activity to the user.
25
Foreground Lifetime
Foreground Lifetime
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 on screen and is interacting with the user. An activity can frequently transition between the resumed and paused states for example, onPause() is called when the device goes to sleep or when a new activity is started, onResume() is called when an activity result or a new intent is delivered.
26
Method:
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. Always followed by onStart()
27
Method:
onRestart()
Called after the activity has been stopped, just prior to it being started again. Always followed by onStart() onStart()
Method:
Called just before the activity becomes visible to the user. Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden.
28
Method:
onResume()
1. Called just before the activity starts interacting with the user. 2. At this point the activity is at the top of the activity stack, with user input going to it. 3. Always followed by onPause().
29
Method:
onPause()
1. Called when the system is about to start resuming another activity. 2. This method is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU, and so on. 3. It should do whatever it does very quickly, because the next activity will not be resumed until it returns. 4. Followed either by onResume() if the activity returns back to the front, or by onStop() if it becomes invisible to the user. 5. The activity in this state is killable by the system.
30
Method:
onStop()
1. Called when the activity is no longer visible to the user. 2. This may happen because it is being destroyed, or because another activity (either an existing one or a new one) has been resumed and is covering it. 3. Followed either by onRestart() if the activity is coming back to interact with the user, or by onDestroy() if this activity is going away. 4. The activity in this state is killable by the system.
31
Method:
onDestroy()
1. Called before the activity is destroyed. 2. This is the final call that the activity will receive. 3. It could be called 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. 4. You can distinguish between these two scenarios with the isFinishing() method. 5. The activity in this state is killable by the system.
32
Killable States
Activities on killable states can be terminated by the system at any time after the method returns, without executing another line of the activity's code. Three methods (onPause(), onStop(), and onDestroy()) are killable. onPause() is the only one that is guaranteed to be called before the process is killed onStop() and onDestroy() may not be. Therefore, you should use onPause() to write any persistent data (such as user edits) to storage.
33
Android Preferences
Preferences is a lightweight mechanism to store and retrieve key-value pairs of primitive data types. It is typically used to store application preferences, such as a default greeting or a text font to be loaded whenever the application is started. Call Context.getSharedPreferences() to read and write values. Assign a name to your set of preferences if you want to share them with other components in the same application, or use Activity.getPreferences() with no name to keep them private to the calling activity. You cannot share preferences across applications (except by using a content provider).
34
LAYOUT
3. Android Application's Life Cycle
<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:id="@+id/myScreen" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent" android:background="#ff000000" > <TextView android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="@string/hello" /> <EditText android:id="@+id/txtColorSelect" android:hint="Background color (red, green, blue)" android:layout_width="wrap_content" android:layout_height="wrap_content"> </EditText> <TextView android:id="@+id/txtToDo" android:layout_width="fill_parent" android:layout_height="wrap_content" android:background="#00000000"> <!-- transparent --> </TextView> <Button android:text=" Finish " android:id="@+id/btnFinish" android:layout_width="wrap_content" android:layout_height="wrap_content"> </Button> </LinearLayout>
35
//GOAL: show the following life-cycle events in action //protected //protected //protected //protected //protected //protected //protected void void void void void void void onCreate(Bundle savedInstanceState); onStart(); onRestart(); onResume(); onPause(); onStop(); onDestroy();
36
\n \n \n \n \n \n \n \n \n \n
" " " " " " " " " ";
37
38
Code: Life Cycle Demo. Part 3 @Override protected void onPause() { super.onPause(); saveDataFromCurrentState(); Toast.makeText(this, "onPause", 1).show(); }
@Override protected void onRestart() { super.onRestart(); Toast.makeText(this, "onRestart", 1).show(); } @Override protected void onResume() { super.onResume(); Toast.makeText(this, "onResume", 1).show(); }
39
40
41
42
43
44
45
onCreate
46
onPause
47
Preserving State Information 1. 2. 3. 4. 5. 6. 7. Enter data: Hasta la vista! Click Home button onSavedInstance > onPause > onStop Read your SMS Execute an instance of the application onRestart > onStart > onResume You see the data entered in step 1
End of Example
48
Questions ?
49
Appendix
Saving State
@Override public void onCreate(Bundle savedInstanceState) { ... somevalue = savedInstanceState.getString(SOME_KEY); ... } ... @Override protected void onSaveInstanceState(Bundle outState) { super.onSaveInstanceState(outState); outState.putString(SOME_KEY, "blah blah blah"); }
50