Four key points of Android applications

An Android application consists of four key construction blocks: Activity, Intent Receiver er, Service, and Content Provider.

However, not every Android application requires these four construction blocks. This is not necessary. In some cases, we only need to combine these four types into our applications.

When we have clarified which construction blocks are required for our application, we need to register the list of these construction blocks in AndroidManifest. xml. This is an XML configuration file that defines the components, functions, and necessary conditions of our application. This configuration file is required by every Android application. For the Schema of AndroidMainfest. xml, we will describe the four construction blocks:

1. Activity

Activity is the most basic type of Android block construction. In an application, an activity is usually a separate screen. Every activity is implemented as an independent class and inherits from the base class of Activity. This activity class will display the user interfaces composed of several Views controls and respond to the events. Most applications contain multiple screens. For example, a short message application will have a screen for displaying the contact list, a second screen for writing short messages, and a screen for browsing old short messages and system settings. Every screen like this is an activity. It's easy to navigate from one screen to another. In some applications, a screen may even return a value to the previous screen.

When a new screen is opened, the previous screen is paused and saved in the history stack. You can return to the previous screen in the history stack. When the screen is no longer used, it can also be deleted from the history stack. By default, Android retains the running screen from the main screen to each application.

Android uses the Intent special class to move between the screen and the screen. The Intent class is used to describe what an application will do. In the description structure of Intent, there are two most important parts: the data corresponding to the action and action. Typical action types include: MAINactivity portal), VIEW, PICK, and EDIT. The data corresponding to the action is represented in URI format. For example, to VIEW the contact information of a person, you need to create an intent with the action type of VIEW and a URI that represents the person.

An associated class is IntentFilter. Compared with intent, an intent filter is used to describe the Intent that an activity or intent Receiver can operate on. To display the contact information of a person, an IntentFilter must be declared for an activity. The IntentFilter must know how to handle the VIEW action and represent a person's URI. IntentFilter must be defined in AndroidManifest. xml.

By parsing various intents, it is easy to navigate from one screen to another. When you navigate forward, activity calls the startActivity (Intent myIntent) method. Then, the system finds the activity that best matches the Intent of myIntent in the IntentFilter defined in all installed applications. The new activity starts to run after it receives a notification from myIntent. When the startActivity method is called, myIntent Parsing is triggered. This mechanism provides two key advantages:

◆ Activities can reuse a request generated in Intent form from other components;

◆ Activities can be replaced by a new Activity with the same IntentFilter at any time.

2. Intent Receiver

When you want your application to respond to an external event, such as a call, a data network, or an evening event, you can use an Intent Receiver. Although Intent Receiver uses icationicationmanager to notify users of events of interest, it cannot generate a UI. Intent consumer er is registered in AndroidManifest. xml, but you can also use Context. registerReceiver () in the Code for registration. When an intent consumer er is triggered, your application does not need to call the intent consumer ER for the request. The system starts your application as needed. Various Applications can also broadcast their own intent Referer to other applications by using Context. broadcastIntent.

3. Service

A Service has a long life cycle and has no user interface. A better example is a media player that is playing a song from the playlist. In a media player application, there should be multiple activities that allow users to select and play songs. However, the music replay function does not have a corresponding activity, because the user will certainly think that the music should still be played when navigation to other screens. In this example, the activity of the Media Player uses Context. startService () to start a service, so that the music can be played in the background. At the same time, the system will keep the service running until the service stops running. In addition, we can also connect to a service by using the Context. bindService () method. if the service is not running, it will be started ). After connecting to a service, we can also communicate with the interface provided by the service. In the media player example, we can also pause, replay, and other operations.

4. Content Provider

Applications can save their data to files, SQL databases, or even any valid device. Content Provider is useful when you want to share your application data with other applications. A Content Provider class implements a set of standard methods, so that other applications can save or read various data types processed by this Content Provider.