"Android Interface Implementation" Starting an activity (activity life cycle pyramid model)

reprint Please specify: http://blog.csdn.net/zhaokaiqiang1992

This article is translated from http://developer.android.com/training/basics/activity-lifecycle/starting.html, you can go to see the original text.

Android is not like other programs, it is not loaded from the main () function, the Android system is done by invoking the corresponding callback method of the life cycle at different times to initialize the code. So if you want to understand the Android program, you must understand the boot sequence and destroy order.

In this lesson we will learn a very important life cycle approach and show you how to control the lifecycle of callback methods to initialize an activity instance.

Understanding the callback method of the life cycle

In the presence of an activity, the system invokes a life cycle method model of a "pyramid" shape in a certain order. Each phase of the activity's life cycle is a separate step in the pyramid model. When the system creates an instance of activity, each callback method pushes the state of the activity forward. At the top of the pyramid is the state value in which activity can always exist with the front of the window and can interact with the user.

When the user leaves the activity, the system calls other methods to push the activity state from the pyramid's spire so that the activity can be destroyed. In some cases, the activity will only move a bit down the spire and then stop at that state value, such as when the user opens another app, and when the user returns to our app again, the status value will return to the top of the spire and revert to the state before the user left.

The above diagram is the pyramid model of the activity life cycle, from which we can clearly see the change and transformation of the state value of the activity. When the program calls OnStart, the activity is visible to the user, and then the call to Onresume,activity stays in the resumed state, which should be the state in which activity can interact with the user normally. After that, if the activity is partially obscured, the activity's OnPause method is called and the activity enters the paused state, and the activity's interface is partially visible to the user. If the occlusion section leaves the interface, the activity returns to the resumed state, returning to the state before the user left. If the activity interface is completely obscured by an activity, then the activity's OnStop method will be called, the activity interface is completely invisible to the user, that is, the non-interactive state, this time into the stopped state, if the memory is not enough, Then the activity is likely to be recycled by the memory collector. However, if the user returns to the activity before being recycled, the program will go to the resumed state from the stopped state, call Onrestart, OnStart, Onresume method, and revert to the state before the user leaves.

Depending on our business needs, these life cycle callback methods are not necessarily all rewritten, however, it is important that you understand each life cycle approach and ensure that your software can run with the behavior that your users want. Implementing a life cycle approach and making your software work well is mainly in the following areas:

(1) When a user receives a phone call or chooses another app, make sure your app doesn't crash out.

(2) Do not consume valuable system resources when users are not actively using them.

(3) Do not lose the user's progress when the user leaves and then returns after a period of time

(4) When the direction of the screen changes, do not lose the user's progress or crash off

After that you will learn the transitions between different states of activity, and then, in only three states, activity can remain:

Resumed: In this state, the activity interface can interact with the user and be at the forefront of the phone's window.

Paused: When activity is partially obscured, such as when a dialog pops up, entering this state, activity in this state cannot accept user input, nor can it execute any code

Stopped: You can enter this state when the activity is completely invisible to the user. In this state, the activity and its state information, such as the member variable, are preserved, but the code cannot continue to execute.

Other states, such as created or started, are quickly converted to other states due to the life cycle callback method and cannot be persisted. Therefore, after calling OnCreate, OnStart and Onresume are called very quickly.

These are some of the more basic introductions to the activity life cycle, and below, we'll cover some of the more specific situations.

set the app's load activity

When the user clicks on the icon of our app on the desktop, the system invokes the OnCreate method we set up to start the activity, which is the user interface entry for our app.

We can define the activation activity by setting the Androidmanifest.xml file. The main activity of the program must declare a <INTENT-ILTER> with the main action and the launcher classification, as follows:

<activity android:name= ". Mainactivity "android:label=" @string/app_name ">    <intent-filter>        <action android:name=" Android.intent.action.MAIN "/>        <category android:name=" Android.intent.category.LAUNCHER "/>    < /intent-filter></activity>

Note: When we created the good one project using the development tools, the main load activity was set up.

If our app does not have a main activity, there will be no icon for our app in the list of programs in the user's home screen.

to create a new instance

Many apps have a lot of activity to do different things, whether the activity is the main activity or other activity, the completion of the activity of the initialization work is done in the OnCreate method. We have to rewrite the OnCreate method and do it in a single initialization operation, such as declaring the user interface, declaring a member variable, and so on.

TextView Mtextview; Member variable for text view in the Layout@overridepublic void OnCreate (Bundle savedinstancestate) {    super.oncreat E (savedinstancestate);    Set the user interface layout for this Activity    //The layout file was defined in the project Res/layout/main_activi Ty.xml file    setcontentview (r.layout.main_activity);        Initialize member TextView So we can manipulate it later    Mtextview = (TextView) Findviewbyid (r.id.text_message); 
   //Make sure we ' re running on honeycomb or higher to use ActionBar APIs    if (Build.VERSION.SDK_INT >= Build.versio N_codes. Honeycomb) {        //For the main activity, make sure the app icon in the Action Bar        //does not behave as a BUTTON
   actionbar ActionBar = Getactionbar ();        Actionbar.sethomebuttonenabled (false);}    }

once the OnCreate is finished, the system calls the OnStart, Onresume method immediately, and the activity will never stay in the started and created states. When the Onstrat call, the interface is now visible to the user, and then immediately call Onresume when the law, and stay in the resumed state, until there is an operation to interrupt the state, for example, a call to enter. The user navigates to other interfaces and so on.

In the rest of the course, you will understand how important the onstart and Onresume methods are for recovering from paused and stopped states during the activity lifecycle.

Destroying Activity

In the activity lifecycle, the first action is OnCreate, and the last action is ondestory, and when this method is called, it means that your activity has been completely erased from memory. Many apps do not need to implement this method because local class references are destroyed and most cleanup work should be done in the OnPause and OnStop methods. However, if you have a thread in your program that is running in the background, or if the resource references that would cause a memory leak if the shutdown is incorrect, you should kill them in the Ondestory method.

@Overridepublic void OnDestroy () {    Super.ondestroy ();  Always call the superclass        //Stop method tracing that the activity started during onCreate ()    android.os.Debug. Stopmethodtracing ();}

Note: In most cases, the system calls Ondestory after the OnPause and OnStop methods, but if you call ondestory directly in OnCreate, the system immediately calls Ondestory, Instead of invoking the callback methods in those life cycles before him.

"Android Interface Implementation" Starting an activity (activity life cycle pyramid model)