Structural Relationship between Content Resolver and Content Provider - an example of Proxy Design Pattern...

As i was digging into the source code of Content Provider and Content Resolver, i found a nice structural relationship among the two and it closely resembles the Proxy Pattern of the GoF book. We need Proxy Pattern whenever there is a need of a sophisticated reference to an object other than the simple pointer.

The class diagram of the Proxy Pattern is something similar to the following:

What it actually does is that it adds a level of indirection when accessing an object. Whenever a client needs to interact with an object of a RealSubject, it instead interacts with a Proxy of it. The proxy forwards the request to the RealSubject.

Now let us dig into the source code of Content Resolver and Content Provider to understand how it resembles the Proxy Pattern. The Content Provider offers the client of it all of the CRUD (create, read, update & delete) functionalities. Internally what it does it forwards these functionalities to the Content Provider. There is an one to one mapping between the CRUD functions of the Content Resolver with the Content Providers. A simplistic version of the structural relationship between the Content Resolver and the Content Provider can be depicted as follows.

Whenever the client calls any of the above functions on the ContentResolver, it just gets a reference to the appropriate Content Provider by the function called aquireProvider and then delegates that function to that of the ContentProvider. In each of these CRUD functions, the ContentResolver also manages the lifecycle of the ContentProvider it acquires through a function called releaseProvider.

Thus we can say that to a client, the ContentResolver works as a proxy of ContentProviders.

Implementation of a State machine for a long running background task in an Android service

Implementation of Half Sync Half Async design pattern in Android Asynctask...

Dissection of Android service internals...

How an Android bound service works...

As i was delving into how an Android bound service works from a developer's perspective i came out with the following write-up which i would like to share with you.
The following diagram depicts the whole flow nicely.

Thus in the onServiceConnected we get a reference to the proxy of the Service through which we can call the methods of the remote service as if they were the local methods. What happens in the background is described here.

If the data that are being passed while calling any of the Service methods through the proxy reference (which we have got in the onserviceConnected callback)are basic data types, then the proxy first converts them into parcelable data. If we want to pass an user defined data types (any objects of an UDT), we have to derive that class from Parcelable interface so that the proxy can write them to the IPC layer.

Then we basically call the the transact on a member variable called mRemote where we pass those parcelable in data as well as the parcelable out data as the second and the third parameter respectively. We also pass something like Stub.Transaction_add (if the function in the AIDL interface was called, say add). At this point the interprocess communication is initiated with the transact method. The parcelled data is sent to the JNI interface which then sends it to the Binder kernel driver. The Binder kernel driver will send the client process to sleep and map the data and the code from the client process to the server process. Then the parcel is sent upwards from the binder kernel to the C++ middleware and then to the JNI and on java API wrapper layer the method onTransact of the stub is called.

@Override public boolean onTransact ( int code , android . os . Par c e l  data

, android . os . Par c e l  r eply , int f l a g s ) throws android . os . RemoteException

{

switch ( code )

{

case TRANSACTION_add:

data . e n f o r c e I n t e r f a c e (DESCRIPTOR) ;

int _ar g 0 ;

_ar g 0 = data . r e adInt ( ) ;

int _ar g 1 ;

_ ar g 1 = data . r e adInt ( ) ;

int _ r e s u l t = this . add ( _arg0 , _ar g1 ) ;

13 r epl y . wr i teNoExcept ion ( ) ;

14 r epl y . wr i t e I n t ( _r e s u l t ) ;

return true ;

}

}

The code is read first due to the accurate signature and the number of arguments. Then the arguments are extracted and the business logic gets executed. The result is written to a reply parcel and which is then again routed through the Binder driver which then wakes up the client and writes the reply parcel to the proxy.  The reply is unmarshalled by the proxy and then sent to the client application.

Hope this helps the android learners....

Reference: http://www.nds.rub.de/media/attachments/files/2012/03/binder.pdf

Android boot up process and Services (both native and android services)

My tribute to Nirbhaya - a freeware android SOS app called Nirbhaya with source code

This freeware android app is my own way to pay tribute to Nirbhaya and all such women who have been badly abused by our society. Install it from Google Play.

Its not anything great but may be useful for people in distressed situations.

Although i have created this App to save people on street from rowdies and loafers, this can also be used by an ill person to notify his doctor or nurse.

And for those eager learners, the source code is available at https://github.com/sommukhopadhyay/nirbhaya