Android learning 2 activity (1)

The last article was incomplete because it was written at night.

Today, I will record my learning process and experience, hoping to help my friends who are interested in reading this article. I am very poor at the level. I hope you can advise me.

First, check the Code:

package com.zph;import android.app.Activity;import android.os.Bundle;public class FirstActivity extends Activity {    /** Called when the activity is first created. */    @Override    public void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.main);            }}

To create an activity, you must override the oncreate () method. In Android programming, I found that the first line of code in the method body must be super. XXX (). You must first call the corresponding methods in the parent class to do the necessary work, and then write other code as needed.

Row 2: setcontentview (R. layout. Main );

Where can I find the layout? Open the view on the left of Eclipse:

There is a main. xml file in the layout folder under the res directory.

R. Java

In R. java has a value public static final int main = 0x7f030000 corresponding to main. XML file, in setcontentview (R. layout. main) found main. XML, and then read the layout Configuration

This program will not be demonstrated

Let's get down to the truth. What is activity?

I didn't translate here. Google translated activities, but it didn't feel very good. I didn't even know who translated him.

You can open the android development documentation in either of the following ways: 1. The androidinstaller has a docfolder under it and find index.html.

Http://developer.android.com/index.html 2

I suggest you use the downloaded document to enable it faster.

Let's take a rough look:

We mainly use Dev guide and reference.

Reference is an API

Dev guide is the development wizard. Open

FindActivities,First sentence:

An Activity is an application component that provides a screen with which users can interact in order to do something, such as dial the phone, take a photo, send an email, or view a map. 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.

Simply put, an activity is a screen that allows users to click and touch. An application may have more than one activity. The activity size is not necessarily the same as that of the mobile phone screen, but may be smaller. A simple example: When we were using a mobile phone, we suddenly made a call. The activity that showed the call did not cover the screen.

Next, let's look:

Creating an ActivityTo create an activity, you must create a subclass of Activity (or an existing subclass of it). In your subclass, you need to implement callback methods that the system calls when the activity transitions between various states of its lifecycle, such as when the activity is being created, stopped, resumed, or destroyed. The two most important callback methods are:onCreate()You must implement this method. 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.onPause()The system calls this method as the first indication that the user is leaving your activity (though it does not always mean the activity is being destroyed). This is usually where you should commit any changes that should be persisted beyond the current user session (because the user might not come back).There are several other lifecycle callback methods that you should use in order to provide a fluid user experience between activities and handle unexpected interuptions that cause your activity to be stopped and even destroyed. All of the lifecycle callback methods are discussed later, in the section about Managing the Activity Lifecycle.

This section describes how to create an activity first, extends inherits the activity, and the system callback method must be implemented in the subclass. Each method represents each State. For example, the previous oncreate () method indicates the method at creation, onstart () indicates the method at start, onpause () indicates the method at pause, onstop () indicates the method at stop, and so on, the document will be detailed later. In the method body, we can do some things as needed. For example, in the onpause () method, we need to save some important data to prevent loss. In the next onresume () or onstart () is recoverable.
In the previous example, we only wrote the oncreate () method and can add other methods. However, oncreate () is required. Otherwise, it cannot be created.
Next:

Implementing a user interfaceThe user interface for an activity is provided by a hierarchy of views—objects derived from the View class. Each view controls a particular rectangular space within the activity's window and can respond to user interaction. For example, a view might be a button that initiates an action when the user touches it.Android provides a number of ready-made views that you can use to design and organize your layout. "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, or relative layout. You can also subclass the View and ViewGroup classes (or existing subclasses) to create your own widgets and layouts and apply them to your activity layout.The most common way to define a layout using views is with an XML layout file saved in your application resources. This way, you can maintain the design of your user interface 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 code and build a view hierarchy by inserting new Views into a ViewGroup, then use that layout by passing the root ViewGroup to setContentView().

There are many user interfaces for displaying user interfaces, which are called widgets in the Document. Google translates them as "parts", such as buttons, text boxes, check boxes, and drop-down menus. Open the main. xml file, which contains configurations. Our widgets are all configured in the file, and then let Android parse the configuration to display it. The benefits of doing so are self-evident. The simplified MVC model (personal understanding ).
After all, these la S and controls will be written to the configuration file, and several la s will be written for several activities.
Next, you need to open androidmanifest. xml
Reading XML files should be a layer-by-layer read,

<?xml version="1.0" encoding="utf-8"?>

This xml header is ignored.

The following is taken directly from the document:

<manifest ... >  <application ... >      <activity android:name=".ExampleActivity" />      ...  </application ... >  ...</manifest >

This is his basic structure, and some of the following elements can be inserted in it, for example:

<intent-filter>

Add it to the activity Tag:

<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon">    <intent-filter>        <action android:name="android.intent.action.MAIN" />        <category android:name="android.intent.category.LAUNCHER" />    </intent-filter></activity>

There is a way to define the label. In eclipse, there is a code prompt function (shortcut: Alt +/), and you will be prompted by clicking the shortcut key at the corresponding position, this shortcut is also a shortcut for Automatic Code completion. There is also a way to read the document and write it in the document.
The following content involves some concepts. Here we will talk about intent and intent first. The concept of intention is simply to tell the program what I want to do. Intention can be divided into: explicit intent and implicit intent. Let's look at the Code directly:

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

This is an explicit intent call.
Here, we first create an intent. The parameter is this: caller, singinactivity. Class: The activity class to be started, and then call startactivity (intent) to start the call.
The explicit intention is simply that I know exactly who the activity is!
Naturally, the implicit call does not know which activity I want to start. Check the Code:

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

Obviously, the implicit intent only needs to tell Android what I want to do. Here I want to tell android that I want to send an email. Of course there are many other intents, such as phone calls, text messages, and Web searches.
After writing intent briefly, I will be dizzy and forget that today I am studying activity. Let's look at the code above. We created an intent,
Then execute the task. The call method is startactivity (intent). You can see the name and start an activity, which means that our activity can be created like this.
The method to end an activity is finish (), but the document clearly states that, unless necessary, do not call the finish () method by yourself. What is this necessary:

 Calling these methods could adversely affect the expected user experience and should only be used when you absolutely do not want the user to return to this instance of the activity.

In most cases, we do not need to close the activity. The system will end some activities as needed.
I think there is something messy here. The previous things are complicated. Let's pull it here. However, after reading the lifecycle of an activity, I believe that many of the previous things can be understood or understood more deeply.

Activity Lifecycle

Don't worry about this. drinking a cup of water is important.
When an activity starts, it first calls the oncreate () method. In this method, we need to prepare the program well, such as creating a view and binding data, this method is used to pass in a bundle object, which contains the previous status of the activity (provided that the status is captured ).
Onstart () starts after oncreate (). The onstart () method is not described too much in this document:

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.

In my opinion, this activity is directly started, and the activity is visible to users at this time.
If the activity is not hidden, the called method is onresume (). This method is called when the user can capture the focus and the activity is at the top of the stack.
If this activity is hidden, it may be started by a program with a higher priority. In short, it is hidden. At this time, onstop () is called (). However, I think the time between onstart () and onresume () methods should be very short. In most cases, onstart () is followed by onresume.
Onresume () is onpause ()
Onpause (), as its name implies, is paused because the system wants to restore or start another activity. The execution time of this method is as short as possible so that another activity can be started as soon as possible, but this method is very important. As mentioned above, in this method, we need to save some important data and stop the animation. This method will occupy the CPU (because we have to do a lot of work ), however, the other started activity does not cover all the screens. That is to say, the user can still see our paused screen.
You can see that onpause () has three destinations:
1. It was killed by the system. That is why we need to save data and why is it killed by the system? It may be that this activity is too resource-consuming, resulting in insufficient resources.
2. Return to onstart () and start the activity again. The activity can be displayed on the screen.
3. onstop (): Stop because the activity is invisible and invisible in general. The screen is overwritten by another activity. This is what is said in the document:

Called when the activity is no longer visible to the user. 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.

Onstop () also has three places:
1. Killed by the System
2. onrestart () is restarted because the activity is visible.
3. Why will the ondestory () method be destroyed? The reason is that the activity has completed its work. It is about to end, and the entire activity lifecycle is about to end.
The entire activity lifecycle is like this.
Here is another note: In the onpause () method, we previously said that we want to save some data, not all of which need to be manually saved, A large part is saved by the system. In this document, we say:

However, even if you do nothing and do not implement onSaveInstanceState(), some of the activity state is restored by the Activity class's default implementation of onSaveInstanceState(). Specifically, the default implementation calls onSaveInstanceState() for every View in the layout, which allows each view to provide information about itself that should be saved. Almost every widget in the Android framework implements this method as appropriate, such that any visible changes to the UI are automatically saved and restored when your activity is recreated. For example, the EditText widget saves any text entered by the user and the CheckBox widget saves whether it's checked or not. 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 it cannot save its state.

Simply put, all saved items have IDs. This also indicates that when writing these la S and controls, add the ID whenever possible.
There are two images in the document:

The figure on the right shows the process of restoring the activity status clearly, provided that there is an onsaveinstancestate () method. Sometimes you need to override the onsaveinstancestate () method by yourself, I personally think that no matter whether the parent class is overwritten or not, the subclass should be overwritten. In addition, the document emphasizes that persistent data should not be stored in the onsaveinstancestate () method. This method is suitable for storing the status information of the UI. persistent data should be stored in onpause () method:

Note: Because onSaveInstanceState() is not guaranteed to be called, you should use it only to record the transient state of the activity (the state of the UI)—you should never use it to store persistent data. Instead, you should use onPause() to store persistent data (such as data that should be saved to a database) when the user leaves the activity.

References: http://developer.android.com/guide/topics/fundamentals/activities.html