Android Basic Training Course: Activity lifecycle

    As you know, most of these devices are Android phones. So there will be a number of important Activity than others - for example: to make a call is more important than playing Sudoku. And, because it is a phone, it has less RAM than a desktop or notebook.
    Since the RAM limitation of the phone, your Activity will sometimes be killed by other Activity is occurring and the system will recover memory that your applications are occupying. We may see the OS (Android) is like a lifecycle - your Activity is destroyed whereby the other Activity may live, and keep up. You can not guarantee its Activity will run until you think it has been completed, or even be the case users think similarly. This is for example - is the most important hope of how the lifecycle of Activity that affect the logic in your application.
    This chapter will talk to many of the state and different callback methods has created a cycle of Activity, and how do you use them in a reasonable manner.

Activity States

    One Activity, will generally lie 1 of 4 states below at any time:
- Active: Activity has been started by the user, running, and appear right on your home screen. That's what you used to think about how it works for your Activity.
- Paused: Activity has been started by the user, running, and hidden away, but an announcement or some something is concealed part of the screen. During this time, users can see your Activity but can not interact with it. For example, if there is an incoming call, the user will have the opportunity to receive the call or ignore it.
- Stopped: Activity has been started by the user, is running, but is hidden by the user to run or switch to another Activity. Your application will not be able to indicate anything meaningful to the user directly, but can still communicate via the notification mechanism.
- Dead: Either the Activity never boot (e.g: after rebooting device) or is terminated - maybe due to lack of memory.

onCreate() and onDestroy()

    We used to execute the method onCreate() in all subclasses of Activity in the previous example. This method will be called in three cases:
- When at the first running (for example: after the system restart), onCreate() will be called with the parameters is null.
- If the Activity has ever run, then destroyed, the onCreate() will be called with the object method Bundle from onSaveInstancesState() as a parameter (to be discussed later).
- If the Activity has ever run, and you set your Activity with the different resources according to the state of the device (for example: horizontal/vertical rotating), your Activity will be recreated and will call on the mode onCreate(). Working with resources that will be addressed in chapter 22.
    This is where you create your user interface and set up anything that needs to be done once, no matter how user Activity.
    Moreover, when at end of Activity life, methods onDestroy() will be called when the Activity is off, regardless of the Activity by calling the method finish() (will "finish" Activity) or because Android needs RAM and finish it early. Note that the method onDestroy() may not be called if the need to use RAM is too urgent (for example: there is an incoming call), but Activity is still disabled. Therefore, methods onDestroy() mostly devoted to freeing clean resources that you have taken in the onCreate().

onStart(), onRestart() and onStop()

    An Activity can appear up front screen when it is run or the first time or is it to be brought back interactive display after being hidden (for example by a different Activity or by a call come). Method onStart() is invoked in such cases.
    Method onRestart() called in case the Activity was stopped and now are restarting.
    In contrast to above, the methods onStop() is called when the Activity is stopped.

onPause() and onResume()

    Method onResume() is called right before your Activity appear on the screen interaction, either after being run for the first time, after being restarted from the stopped state, or after a pop-up dialog (for example: an incoming call) is deleted. This is a great place to refresh the user interface based on things that can happen since the user can see your last Activity. For example, if you tuck a service available to change certain information (e.g: the new position for a read data), methods onResume() is a good time for both the current and refresh view if appropriate, may be referred to a background thread to update the view (e.g, via a Handler).
    Conversely, anything that pulls the user out of your applications - basically enabling a different Activity - would make the method onPause() is called. Here, you should destroy any of what you've done in method onResume(), such as a request to stop the thread running underground, freeing resources separate access which you have requested (e.g: camera) and t the same ones.
    Once method onPause() is called, Android will have the right to destroy your application any time. Therefore, you should not believe to be able to get one event followed another.

Saving Activity instance state

    Primarily, the described methods used to deal with things at common applications (e.g: calling the components of the user interface in the onCreate() or off the background thread in methods onPause()).
    However, the vast majority of Android goal is to have something seamless. The Activity can come and go as designated by the memory requirements, but ideally, users do not know that this is happening. For example, a user who uses a computer program, then stay to lunch, and then back to the computer program that, he was seen by any public figure that I had worked before the break, unless he perform some action to shut the computer program down(for example: press the back button to exit the application).
    To do all of them active, the Activity must have the ability to save the state of the application object, as well as implementing it quickly. Since the Activity can be destroyed at any time, the Activity should save our state more often than what you might expect. Then, when the Activity restarts, the Activity will get it's old state, so it can restore the Activity the way it appeared earlier. It's like setting a bookmark pages when users return to bookmarks, you can restore the application to the same state that it was there when the user exits it.
    Saving the state of the object to be processed by the methods onSaveInstanceState(). It provides an object Bundle, the Activity can dump whatever data we need into it (for example, the number displayed on the computer screen). Methods of implementation need to quickly, so do not try to do too special, just put your data in the Bundle and get rid of this method.
    The status of the application is provided to you again in two places: in the onCreate() and methods onRestoreInstanceState(). It's your choice if you want to retrieve the data on its Activity status.
The implementation of methods available onSaveInstanceState() will save the state can change from a subset of the widget. For example, it will save the text content in EditText, but it will not save the state of a button is enabled or disabled. It works as long as the widget is uniquely identified via thier android:id attribute.
    Thus, if you execute the method onSaveInstanceState(), you can choose to reuse and improved methods inherited from the parent class or not, and override this implementation is inherited. Similarly, some may not need onSaveInstanceState() executed because they considered the available enforcement methods have done everything that we need.


Previous post
« Prev Post
Next post
Next Post »