Unlike announced in my previous post this one is neither soon nor on a surprise topic. It is about a general aspect of Android that is, to my opinion, very powerful but often under utilized.
Android apps are not monolithic but rather a collection of components of different kinds. I suspect android took inspiration from the concept of midlet suites in j2me and believe it expanded on that quite well.
These components (except for provider) can be exposed through intent filters in the package’s manifest and can be used by other components in different packages. This allows apps to accomplish tasks together which a single app could never do.
The most important type of component is the Activity and it can be used in several ways:
- Leaf: view data specified or referred to in the extras of the calling intent.
- Put: a pre-filled form with data from the extras. performs an action then stops or returns.
- Pick: select data from a source owned by another app and return it (or a reference to it) to the calling activity.
As activities might start other activities in other tasks, care must be taken to maintain a consistent activity back stack.
Image Shortcut and Send Text demonstrate usage of these intents (but an abnormal use of content provider)
The type of component most suitable for increasing synergy is perhaps the Content Provider.
A Content Provider is accessed through a content resolver and can be used to search, read and update data belonging to a different package. A component can also register to the Content Provider to be notified of changes to its data set.
To send a message to a different package, a Broadcast Receiver is used.
The system also sends a number of messages which apps can listen to.
Sending a broadcast intent can be done asynchronously or synchronously so you can get a result for each matching receiver and have them called in order of priority.
In either case a Broadcast Receiver is not the place to do a lot of processing. Usually either a service is started to handle any data or a notification is raised so the user can take action.
The final type of component is a Service. As the name suggests it runs in the background, and comes in the varieties “run once and die” and “create once then run as demanded”. A service can be bound to through a Binder and communicates through aidl.
I think that, apart from selfishness, fear of abuse is a factor holding back synergy.
Although you can create permissions and set those on your components so other apps need to request those permissions before they can use your components, some users might not review the requested permissions when installing a potentially malicious app.
I am currently developing an Android app at a bank which has a component (currently not exposed) that allows a user to transfer money from his account.
If the activity was exposed it could be used as part of the payment process in any shopping app. The transfer activity would receive the amount and the destination account pre-filled through intent extras set by the shopping app. The transfer activity could return a cookie to the shopping app (similar to pick) which it can verify against the bank’s server independently.
Of course the shopping app shouldn’t have to scan the phone for each banking app so there needs to be defined a common profile of supported component interactions for each type of task. This would allow the shopping app to show an iDeal button calling an intent that matches the filter of any installed banking app’s transfer component in drive-through mode.
‘The whole is greater than the sum of its parts’ Aristotle, Metaphysica
