Go deep into Android [3] -- getting started with components

Android Components

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

Component ( Component ), It is an important thing to talk about the so-called architecture and reuse. In most cases, component-based software architecture refers to the expectation Program Like Lego, there are a bunch of Interface Standard encapsulated complete components where to put them. When you want to use them with a few matches, the whole 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 is a complete Android program and does not want to use it. It is really difficult, unless you want to be crazy. Because activity is the window for interaction between Android apps and users, in my opinion, from this perspective, Android activity is a special website Page . First of all, if a website does not have a page, it is a wonderful thing. A page usually has Independent themes and functions Such as the 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, in the most straightforward view, is to strip the activity of the interface. They are very close to each other in terms of many Android concepts. Complete functional logic implementation , But the service does not show its head, but is a solid backing silently. But in fact, from another perspective, the services in Android are similar to Windows Services and Web Background services, which are usually The backend is a module that runs for a long time and accepts upper-level commands to complete 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, Android services are the same as all four components. All process models can be configured. Both the caller and the producer can choose whether to run this 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 must use RPC To deploy a set of inter-process communication policies.

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 classes used for data serialization in Android are: Parcel , See: /Reference/Android/OS/parcel.html It encapsulates the serialization details and provides sufficient object-oriented access interfaces. Android claims that the implementation is very efficient. There is Aidl (Android Interface Definition Language) A language defined by an interface. The Service RPC interface can be described using aidl. In this way, ADT can help you automatically generate a complete set of classes required for proxy mode, it's the kind of hard work that I think. For more information, see: Guide/developing/tools/aidl.html If you are interested, you can find some other PRC implementation information Lou. For more information about service implementation, see API demos In this sample Remoteservice . It fully demonstrates what a service needs to do: Define the intent to be accepted and provide Synchronous or asynchronous Interfaces After it is bound to the upper layer, communication is performed through these interfaces (RPC in many cases. 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. 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. Broadcast receiver er Such a component. 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 Register In this way, the broadcast receiver describes its features and registers them in the system. Based on the registration time, it can be divided into two types, named Cold hot swapping . The so-called Cold plugging That is, information about the broadcast receiver is written in 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 application processing . For example, listening for incoming calls, emails, text messages, and so on all belong to this mode. While Hot swapping As the name suggests, plugging is handled by the application itself, usually in the onresume event Registerreceiver 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: Start the application-> listen for events-> process when an application 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. Reference/Android/content/intent.html Of Standard broadcast actions For details about the message. In addition to the system, custom applications can release broadcast messages. The interface used can be Context. sendbroadcast , Or Context. sendorderedbroadcast . The former is called Normal Broadcast All the referers that follow the message have the opportunity to obtain and process the message. Ordered broadcasts As the name suggests, the recipients need to sort their peers based on their resources. The people behind the group can only eat the first and the rest. The former is 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 about broadcast receiver, see: /Reference/Android/content/broadcastreceiver.html . Content providercontent provider, which is related to data, is a 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. Content Provider . The data that the application wants to provide externally can be encapsulated into a content provider by deriving the contentprovider class. Each content provider uses one Uri As an independent identifier, such: Content: // com. XXXXX . Everything looks like rest, but in fact it is more flexible than rest. Similar to rest, Uri can also be of two types, one with ID and the other with list, but the implementers do not need to follow this pattern, you can also return the list type data for the URI of your ID. As long as the caller understands it, there is no need to demand the so-called rest. In addition, content provider and rest are only available in Uri and can accept Projection , Selection , Orderby In this way, you can perform projection, selection, and sorting like a database. The query results are as follows: 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. The content provider is usually implemented by databases. Android provides powerful SQLite Yes, but you can also encapsulate files or other mixed data. In Android, Contentresolver Is used to initiate content provider positioning 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 Asyncqueryhandler (See: Reference/Android/content/asyncqueryhandler.html ) To help asynchronously access the content provider. Among the major components, both service and content provider require continuous access. If a service is time-consuming Asynchronous access Content provider provides the agreed interface regardless of the efficiency. Synchronous access Interface. What I want to follow is Scenario-oriented design Because content provider only provides data access, it cannot be sure how the specific use scenario will use its data. In contrast, the logic contained in the service is more complex and complete. You can choose the scenario where an interface is used most of the time to determine whether the most appropriate interface is synchronous or asynchronous, which simplifies the logic of upper-layer calls. After the four components are configured, the heroes behind the four components should also be displayed, that is, each application will have a configuration file named Androidmanifest. xml In 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 reflect some meanings. In In others Here 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. Important: in the lower part of the image, the description is Android . In Android, Application Boundary At the component level, it is extremely vague. No process or application can be perceived. For example, app 1 implements the components A and B, and app 2 implements the component C. If both components A and C want to use the component B, then they are used in the following way: Completely consistent You must use the system's core component identification and communication mechanisms to find and use component B. 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, Identification of all components and message passing Logic All must rely on the underlying core (communication can be conducted without the involvement of the underlying core, for example, once the service is found, it can produce 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 inserts the component into the underlying core. Plug . 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: How to recognize . 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 Running Problems . 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, this is the end.