Four major Android Components

 

Android Components

On the ridge side, the distance is different. -- Question Xilin Wall

Component is an important thing when talking about the so-called architecture and reuse. In many cases, component-based software architecture refers to the process that is expected to be Lego-like. There are a bunch of interface standards to encapsulate complete components and place them together, the entire program is built.

At the beginning, we mentioned that Android is a platform built for componentization. It introduces the so-called Mash-Up concept, which makes you at the top of the application, it is very difficult to do anything without componentization (bottom-layer logic, Well, it cannot be managed ...). Specifically, Android has four main components: Activity, Service, Broadcast explorer, and Content Provider.

Activity

It is really difficult to build a complete Android program and don't want to use Activity, unless you want to be crazy. Because Activity is a window for interaction between Android apps and users, in my opinion, from this perspective, Android Activity is a webpage of a website.

First of all, if a website does not have a page, it is a wonderful thing. A page usually has an independent topic and function, such as logon page, registration page, and management page.

In each page, some links are put, and feature points are connected in series. Some links are clicked and brushed to another page on the same site. Some links are clicked, closed, it may jump to the pages of other websites. There are links. Well ..., this time I did not run, but the current page may have changed. These models are similar to Activity, but their implementation strategies are different. After all, the core idea of the Android architecture comes from the concept of Mash-Up on the Web, it is regarded as a client of the page, and it cannot be tasted.

Activity is undoubtedly the most complex among the four main components. During the past few years, a hook between something and the interface cannot be simplified. Think about it, you can figure out how much time it takes to create an independent application on the interface. In terms of visual effects, an Activity occupies the current window, responds to all window events, and has interface elements such as controls and menus. From the internal logic point of view, the Activity needs to do a lot of persistent things to maintain the status of each interface. It also needs to properly manage the lifecycle and some switch logic. For developers, they need to derive a subclass of the Activity, and then work hard to do the above. For more details about the Activity, see reference/android/app/Activity.html. In the future, we will provide a more detailed analysis.

Service

Service, in the most straightforward view, is to strip the Activity of the interface. They are very similar in many Android concepts and are encapsulated with a complete functional logic implementation, however, the Service is not exposed, but it is a solid backing silently.

But in fact, from another perspective, the services in Android are similar to the Windows Services and Web Background services that we usually call. These services are usually used for long running of the background and accept upper-layer commands, the module that completes related transactions. In running mode, Activity jumps from one to the other ..., this is a bit like a modal dialog box (or a web page ...), give an input (or no ...), then, regardless of whether you want it to run, the output (same as or without...) is returned when it leaves ...).

The Service is not, it is waiting, waiting for the upper layer to connect to it, and then generate a persistent and lingering communication, which is like an Ajax page, watching nothing changed, sneaky and Service, I don't know how many times it went.

However, unlike general services, the process model of Android services is configurable like all four components, both the caller and the producer can choose whether to run the component in the same process or in different processes. This sentence can be engraved into your mind, which highlights the running characteristics of Android. If a Service is expected to run in different processes of the caller, you need to use the RPC mechanism provided by Android to deploy a set of inter-process communication policies for it.

 

Shows the RPC implementation of Android, as shown in (well, it also comes from the SDK ...), nothing unusual. Based on an implementation of the proxy mode, a proxy class is generated on both the caller and the server side for serialization and deserialization, this allows both the caller and server to use the RPC interface just like calling a local interface.

The class used for data serialization in Android is Parcel. For details, see/reference/android/OS/Parcel.html. This class encapsulates the serialization details and provides an access interface that is sufficiently object-oriented, android is said to be very efficient.

There is also the Android Interface Definition Language (AIDL), an Interface-defined Language, and the RPC Interface of the service, which can be described by AIDL, the ADT can help you automatically generate a complete set of classes required for the proxy mode, which is the kind of kind that is hard to write. For more information, see guide/developing/tools/aidl.html. If you are interested, you can find other PRC implementation materials lou.

For more information about the Service implementation, see the RemoteService implementation in the API Demos Sample. It fully demonstrates what a Service needs to do: defines the Intent to be accepted, provides synchronous or asynchronous interfaces, and binds it to the upper layer, through these interfaces (usually RPC ...) communication. The data and callback interface objects used in the RPC interface. If they are not implemented by a standard system (the system can be serialized), you need to customize aidl, everything, in this Sample, there are expressions and strong recommendations.

From the perspective of Service implementation, the most special is the implementation of these RPC, and other content will be close to some implementations of Activity, and may not be detailed in detail.

Broadcast Receiver er

In practical applications, we often need to wait and wait for the system or other applications to issue a command to give a clear light to our applications. This kind of waiting will have to pay a large price on many platforms.

For example, in Symbian, if you want to wait for a call message to display a home location or something like that, you must enable your application to start from the system, hide the hidden icon, hide task items, and lurk in the background, monitors related events and waits for a transient opportunity. This is a very embarrassing thing. It not only consumes system resources in vain, but also leaves a name for rogue software. This is really a positive example of hard work and thankfulness.

In Android, a wide range of such requirements are fully taken into account, so a component such as Broadcast Receiver is available. Each Broadcast Receiver can receive one or more intents as a trigger event (if you do not know the Intent, you will know it later ...), when such an event occurs, the system will wake up or send messages to the Broadcast Receiver for disposal. Prior to and later, whether or not the Broadcast Receiver is running has become less important and green.

This implementation mechanism is obviously based on a registration method. Broadcast aggreger describes its features and registers them in the system. Based on the registration time, it can be divided into two types, I named it cold hot swapping. The so-called Cold plugging means that information about the Broadcast Receiver is written in the configuration file (for details about the configuration file? The system will promptly notify the Broadcast Receiver when related events occur. This mode is suitable for such scenarios. Event method-> notification Broadcast-> Start related applications. For example, listening for incoming calls, emails, text messages, and so on all belong to this mode. Hot swapping, as its name implies, is handled by the application itself. Generally, it is registered in the OnResume event through registerReceiver and is not registered in OnPause events, in this way, you can keep an eye on related events during running. For example, an excellent dictionary software (such as youdao dictionary ...), you may need to pay attention to the changing network conditions during running so that you can use the network query vocabulary preferentially when there is a cheap network. In other cases, you can first use the local dictionary to query words, in this way, both pockets and experiences can be taken into consideration ...). For such a listener, you only need to keep it in its working status. When it is not running, it is a great change in the network. What do you do with me. The mode can be summarized as: start the application-> listen to events-> process when an event occurs.

In addition to receiving messages, the sender also has an important choice. Generally, there are two types of message sending: one is the system itself, which is called the system Broadcast message. In reference/android/content/Intent.html's Standard Broadcast Actions, you can obtain the details of related messages. In addition to the system, custom applications can release Broadcast messages. The interfaces used can be Context. sendBroadcast or Context. sendOrderedBroadcast. The former is called Normal broadcast, and all the referers that follow the message have the opportunity to obtain and process the message. The latter is called Ordered broadcasts. As the name suggests, the Receiver needs to rank by resource, the backend users can only eat the first and the rest. The former users are in a bad mood and the latter can only drink the northwest wind.

When Broadcast receivers receive related messages, they usually do some simple processing, and then convert them into a Notification, one-time ringing, one-time vibration, or start an Activity for further interaction and processing. Therefore, although the entire Broadcast logic is not complex, it is useful and easy to use. It unifies the event Broadcast model of Android, so that many platforms Are outputted. For more information, see/reference/android/content/BroadcastReceiver.html.

Content Provider

Content Provider, which is related to data. That's right. This is the third-party Application Data Access solution provided by Android. In Android, data protection is very strict. Apart from the data stored on the SD card, the databases, files, and other contents held by an application are not allowed for direct access, however, sometimes communication is necessary, not only for third parties, but also for applications.

For example, an application managed by a contact. If a third-party application is not allowed to add, delete, and query its contact database, the whole application will lose scalability and will be discarded by other applications. Then, a new portal will be created for you.

Andorid certainly does not make every application an isolated island. It provides a window for all applications. This is the Content Provider. The data to be provided by an application can be encapsulated into a Content Provider by deriving the ContentProvider class. Each Content Provider uses a uri as an independent identifier, such as content: // com. xxxxx. Everything looks like REST, but in fact it is more flexible than REST. Similar to REST, uri can be of two types: id-based and column-based.

Table, but the implementer does not need to follow this mode. You can also return data of the list type for the uri of your id. As long as the caller understands it, it is fine. You do not need to require the so-called REST.

In addition, Content providers are not only available in Uris like REST, and can also accept Projection, Selection, OrderBy, and other parameters. In this way, you can perform Projection, Selection, and sorting like databases. The query results are returned in the form of Cursor (see reference/android/database/Cursor.html). The caller can move the Cursor to access the data of each column.

Content Provider shields the storage details of internal data and provides the preceding unified interface model. This abstraction layer greatly simplifies the writing of upper-layer applications, it also provides a more convenient way for data integration. Content Provider is usually implemented in databases. Android provides powerful Sqlite support, but in many cases, you can also encapsulate files or other mixed data.

In Android, ContentResolver is used to initiate Content Provider locating and access. However, it only provides the Content Provider interface for Synchronous access. However, generally, Content providers may need to access large data sources such as databases, which is less efficient than enough, resulting in congestion of calling threads. Therefore, Android provides an AsyncQueryHandler (see reference/android/content/AsyncQueryHandler.html) to help users access Content providers asynchronously.

Among the major components, both Service and Content Provider require continuous access. If a Service is time-consuming, asynchronous access interfaces are often provided. Content providers provide agreed synchronous access interfaces regardless of the efficiency. I think this follows the scenario-oriented design principle. Because Content Provider only provides data access, it cannot be sure how the specific use scenario is and how the data will be used; in contrast, the Service contains more complex and complete logic. You can choose the scenario where a certain interface is used most of the time to determine whether the most appropriate interface is synchronous or asynchronous, simplifies the upper-layer calling logic.

Configuration

After the four components are finished, the heroes behind the four components should also be displayed, that is, each application will have a configuration file named AndroidManifest. xml, which is under the root directory of the project. This configuration file not only describes application-related information, but also contains information about all components of an application. If you derive an Activity or Service to implement a related class, this is only the first step of componentization. You need to write the relevant information of this class to the configuration file, it will be applied as a component, otherwise it will only survive the rest of its life in obscurity.

 

I made a picture. This is not a stolen image. It is an original image, so it is ugly without an accident, but it can basically show some meanings. In Others, this is a model of communication and interaction between platform applications. Each application has a strong application boundary (often manifested as a process boundary ...), app 1 is still App 2, which is clearly identified. Each application has its own logic to split functional components. Such splitting usually has no standards, but is more efficient. The interaction logic between applications is also scattered. When App 1 interacts with App 2, it is often necessary to clearly know the specific information of the other application, such as the process ID and process name, this makes the connection between the application and the application very stiff. However, the communication between upper-layer applications and system applications often involves many specific modes. This mode may not be directly applied between common applications. In other words, system applications have some special characteristics.

Focus: the lower part of the figure describes the application of Android. In Android, the application boundary is extremely vague at the component level. No process or application can be perceived. For example, App 1 implements the components A and B, and App 2 implements the component C. Both A and C want to use the B component, so they are used in the same way. They need to identify and use the component B through the core components of the system and the communication mechanism. A. Although B and B are coming out of the family, I am very sorry. There is no special backend or shortcut, but we still need to use it in A proper way. A Harmonious Society is born.

In Android, the identification and message passing logic of all components must depend on the underlying core (communication can be performed without the involvement of the underlying core, for example, once the Service is found, it can generate persistent communication with it ...), there is no bridge between the underlying core and no two components can be connected. For example, if an Activity jumps to another Activity, it must initiate an Intent to the underlying core. After underlying parsing and approval, another Activity will be found and relevant messages and data will be sent to it. To use the data in Content Provider, an Activity must parse the relevant uri through the underlying core, locate the Content Provider, pass the parameter to it, and return the Cursor required by the Activity. This design ensures the absolute control and cognitive right of all components at the underlying core, making development like building blocks possible.

In order to make the core system fully grasp the information of each component, the configuration file is required. The configuration file is the plug that inserts the component into the underlying core. Only by inserting this plug in the underlying core of the socket (do not think about it, not 18 banned...), the component can shine heat, shine.

In my opinion, the configuration information of components mainly includes two aspects: one is to describe how to recognize them. For example, Activity, Service, and Broadcast referers all have name information, and Intent information that you want to grasp (let's look at as a message...). Content Provider has a uri describing its identity. When other components use such a name or Intent, they can be found.

The other part is the running information. This component is expected to run in a separate process, a process with the caller, or other related components in the same process, it can be determined at the time of configuration (the caller has a further choice within the scope of this constraint ...). For more configuration items, see guide/topics/manifest/manifest-intro.html.

Through the previous content, you may be able to have a preliminary understanding of the Android components. However, all these understandings are still at the static level, and the program is a dynamic concept. How are the components associated with each other and how can they work hand in hand to complete a function, that's the end.