Android application architecture. Part IV - integration level
In this article we will talk about the different mechanisms through which parts of Android applications interact. We agree to call all these mechanisms "interaction level" (as far as I know, there is no special term in the Android documentation for this).
As shown earlier, the Android framework implements several interaction patterns:
Obviously, this is the first interaction mechanism that a developer encounters when starting programming under Android. It is used to start the activation or service . Mechanism is implemented using three methods of the Context class (which was discussed in one of the previous articles ) and one method of the Activity class:
')
In both cases, the Intent class serves as the message being transmitted.
How does Android know which activation or service the message is addressed to? There are two ways to do this:
Keep in mind that in the case of sending a message (an instance of the Intent class), the interaction mechanism will deliver it to only one component, or not deliver it at all.
The publisher / subscriber interaction mechanism uses the same Intent class as the message and the same filters as the target component detection mechanism, but it works a little differently. The intents used in this case are called “broadcasting”. These intents can only be delivered by BroadcastReceiver.
Unlike the intents used for sending messages, one broadcast intent can be delivered to several components.
In fact, Android implements two different publisher / subscriber mechanisms, each of which has two versions (regular and sticky, sticky):
I haven't confused you yet, right?
The normal broadcasting mechanism delivers the intent to all suitable broadcast receivers asynchronously, and they respond to them independently. That is, some Broadcast receiver cannot influence how the other Broadcast receiver reacts to the intensity, or how the intensity is delivered to another Broadcast receiver. This is a regular publisher / subscriber template.
An ordered broadcasting mechanism delivers intents to all suitable Broadcast receivers consistently, that is, only one at a time. Therefore, each Broadcast receiver can potentially:
Components that have initialized streamlined broadcasting are able to receive the result of processing the intensity from the entire chain of broadcasters.
Orderly broadcasting is the implementation of the chain of duty pattern .
Sticky broadcasting is a form of regular broadcasting. The difference is that the intent is available until it is explicitly removed by the context class removeStickyBroadcast () method. Remember that this type of broadcasting should be used with caution, as not removed “sticky” intents result in a memory leak.
All the interaction mechanisms described use the Intent class as the message. Note that most of the methods presented are implemented by the Context class, which means that theoretically they can be used by all its subclasses.
From this we can conclude that all Android interaction mechanisms use the Intent class. But it is not so.
In most cases, the ContentProvider class is used as a wrapper around a SQLite database. Although, theoretically, it can be used for other data storage / retrieval mechanisms. You can read about using this class here .
There are many ways to use content-sharing. Some include getting objects that work as a proxy on a content porter (usually an instance or a subclass of ContentProviderClient that implements the proxy pattern ). Others return an instance of the Cursor class, which allows you to iterate over the set of data returned by the provider. In any case, a specific ContentProvider must be identified by a URI (for more details, see here ).
In any case, this is a typical late binding pattern.
If you think that the interaction mechanisms are over, then you are mistaken.
Apart from the ContentProvider class, there is the Service class, which serves as a model in the MVVM architecture. In the previous article, we discussed the hypothetical reasons why Android has two different classes that perform the same role.
It is a bit confusing that the same service can be used both as local and remote; the difference is in where the components that invoke the service are located (in the same process or in another).
Here and here you can read more about the use of services.
Previous articles:
From the translator. This is the last of Vlad Nevzorov ’s four articles on the architecture of Android applications. I would like to express my gratitude to my beloved wife Gale for help and for not distracting me from the computer for several evenings, as well as for habrayusers Monnoroch , Semp , PomanoB , ssidelnikov , So1 , Manul , pravic and szKarlen for their useful comments and observations.
As shown earlier, the Android framework implements several interaction patterns:
- Messaging with the Intent class
- Observer using the Intent and BroadcastReceiver classes
- Later binding with a subsequent method call is used to access content providers ( ContentProviders ) and local (intra-process) services ( Services )
- Late binding and interprocess communication ( Inter-process Procedure Communication , IPC) for service call (AIDL)
Message exchange
Obviously, this is the first interaction mechanism that a developer encounters when starting programming under Android. It is used to start the activation or service . Mechanism is implemented using three methods of the Context class (which was discussed in one of the previous articles ) and one method of the Activity class:
')
- startActivity () of class Context launches activity
- startActivityForResult () of class Activity launches activit
- startService () or bindService () of the Context class starts the service, if necessary, and communicates with it (there is some difference between these two methods)
In both cases, the Intent class serves as the message being transmitted.
How does Android know which activation or service the message is addressed to? There are two ways to do this:
- Intent can explicitly indicate the name of the component. Such intents are called explicit (“explicitIntents”). The target component is defined by the setComponent () and setClass () methods. This type of intent-oriented interaction mechanism does not implement the late binding pattern, unlike all others.
- The target component is determined by a very unusual decision-making mechanism based on intent filters .
Keep in mind that in the case of sending a message (an instance of the Intent class), the interaction mechanism will deliver it to only one component, or not deliver it at all.
Publisher / Subscriber
The publisher / subscriber interaction mechanism uses the same Intent class as the message and the same filters as the target component detection mechanism, but it works a little differently. The intents used in this case are called “broadcasting”. These intents can only be delivered by BroadcastReceiver.
Unlike the intents used for sending messages, one broadcast intent can be delivered to several components.
In fact, Android implements two different publisher / subscriber mechanisms, each of which has two versions (regular and sticky, sticky):
- Normal broadcasting is implemented by the sendBroadcast () and sendStickyBroadcast () methods of the Context class.
- Ordered broadcasting is implemented by the sendOrderedBroadcast () and sendStickyOrderedBroadcast () methods.
I haven't confused you yet, right?
The normal broadcasting mechanism delivers the intent to all suitable broadcast receivers asynchronously, and they respond to them independently. That is, some Broadcast receiver cannot influence how the other Broadcast receiver reacts to the intensity, or how the intensity is delivered to another Broadcast receiver. This is a regular publisher / subscriber template.
An ordered broadcasting mechanism delivers intents to all suitable Broadcast receivers consistently, that is, only one at a time. Therefore, each Broadcast receiver can potentially:
- Use the results of the previous Broadcast receiver, which worked on the same intent.
- If necessary, interrupt further processing.
Components that have initialized streamlined broadcasting are able to receive the result of processing the intensity from the entire chain of broadcasters.
Orderly broadcasting is the implementation of the chain of duty pattern .
Sticky broadcasting is a form of regular broadcasting. The difference is that the intent is available until it is explicitly removed by the context class removeStickyBroadcast () method. Remember that this type of broadcasting should be used with caution, as not removed “sticky” intents result in a memory leak.
Conclusions on the orientation-oriented interaction mechanism
All the interaction mechanisms described use the Intent class as the message. Note that most of the methods presented are implemented by the Context class, which means that theoretically they can be used by all its subclasses.
From this we can conclude that all Android interaction mechanisms use the Intent class. But it is not so.
Late binding of ContentProviders
In most cases, the ContentProvider class is used as a wrapper around a SQLite database. Although, theoretically, it can be used for other data storage / retrieval mechanisms. You can read about using this class here .
There are many ways to use content-sharing. Some include getting objects that work as a proxy on a content porter (usually an instance or a subclass of ContentProviderClient that implements the proxy pattern ). Others return an instance of the Cursor class, which allows you to iterate over the set of data returned by the provider. In any case, a specific ContentProvider must be identified by a URI (for more details, see here ).
In any case, this is a typical late binding pattern.
Late binding and interprocess communication (IPC)
If you think that the interaction mechanisms are over, then you are mistaken.
Apart from the ContentProvider class, there is the Service class, which serves as a model in the MVVM architecture. In the previous article, we discussed the hypothetical reasons why Android has two different classes that perform the same role.
- The local service is started in the same process where it is called. Architecturally, it is similar to a content provider, except that the former has its own life cycle and there is no obligatory looking at the database. A kind of late binding is used to access the local service.
- Remote service works in a different process, and not in the one from which it was called. Communication with this service occurs through a type of IPC called AIDL (Android Interface Definition Language).
It is a bit confusing that the same service can be used both as local and remote; the difference is in where the components that invoke the service are located (in the same process or in another).
Here and here you can read more about the use of services.
Previous articles:
- Android application architecture. Part I - the origins
- Android application architecture. Part II - architectural styles and patterns
- Android application architecture. Part III - the main parts of the application
From the translator. This is the last of Vlad Nevzorov ’s four articles on the architecture of Android applications. I would like to express my gratitude to my beloved wife Gale for help and for not distracting me from the computer for several evenings, as well as for habrayusers Monnoroch , Semp , PomanoB , ssidelnikov , So1 , Manul , pravic and szKarlen for their useful comments and observations.
Source: https://habr.com/ru/post/141504/
All Articles