Embed Size (px)
DESCRIPTION
This document describes the structural relationship between Content Resolver and Content Provider and explains how it resembles the Proxy Design Pattern described by the GoF.
Citation preview
Structural Relationship between Content Resolverand Content Provider of Android - an example ofProxy Design Pattern
by
Somenath Mukhopadhyay
As i was digging into the source code of Content Provider and Content Resolver, i found a nicestructural relationship among the two and it closely resembles the Proxy Pattern of the GoFbook. We need Proxy Pattern whenever there is a need of a sophisticated reference to an objectother 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 aclient needs to interact with an object of a RealSubject, it instead interacts with a Proxy of it. Theproxy forwards the request to the RealSubject.
Now let us dig into the source code of Content Resolver and Content Provider to understandhow 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 thesefunctionalities to the Content Provider. There is an one to one mapping between the CRUDfunctions of the Content Resolver with the Content Providers. A simplistic version of thestructural relationship between the Content Resolver and the Content Provider can be depictedas follows.
Whenever the client calls any of the above functions on the ContentResolver, it just gets areference to the appropriate Content Provider by the function called aquireProvider and thendelegates that function to that of the ContentProvider. In each of these CRUD functions, theContentResolver also manages the lifecycle of the ContentProvider it acquires through afunction called releaseProvider.Thus we can say that to a client, the ContentResolver works as a proxy of ContentProviders.
