Android in Pictures

On approaching a new framework or technology (or indeed system) it is the poor engineer who eschews the documentation; it is the good engineer who studies it diligently; and it is the manager who ... just looks at the pictures.  For as the old adage goes: a diagrammatic abstraction using graphical notation is worth a thousand words.  Or something like that.  And cliche though it may be, true it nonetheless is.

Being the simpleton that I am (is there a design pattern for that? - see I'm getting confused again), I've always been a strong advocate of pretty pictures.  And here I don't necessarily mean the use of formal notation for detailed design, but something at a much higher level.  When I first get involved in a project, it may take me a while to get my little brain around all the big concepts involved, and nothing cements the process better than getting it all down in a good doodle.  Done well, this doodle can become something else.  It can become the first port-of-call for anyone joining the team - a way-in diagram. It serves to set the scene - capturing, as it does, some grand context or high level view of a system (or a fundamental component therefore).

There is no magic formula for arriving at such a masterpiece.  But when you have one you'll know.  It will chime with everyone on the team, and thereafter copies of it will be seen strewn about on people's desks for months to come, with notes and annotations scrawled upon it.  It will often be the focal point of discussion or the starting point of meetings.  It will become familiar to everyone.  People will grow comfortable with it and be put at ease when it fades in as the opener to an otherwise daunting PowerPoint presentation.

Such a diagram need not conform to any formal notation, like UML.  Dare I say, it should not conform.  It must be a renegade.  To get your message across at this level it needs to employ a lexicon that is accessible to everyone, from hardcore coder to programme manager.  And the diagram needs to be as visually stimulating as possible without detracting from the content.  As such, there is no notation that supports its genesis, any more than there is a notation for creating a still-life or a seascape.  Every situation will warrant a different style and there is no substitute for being creative, dare I say artistic.  Yes, even the paintbrush is a valuable tool in the software manager's armoury.

But enough of the pretext.  I have recently be exploring the Android architecture to evaluate its applicability to larger industry.  Being the 'good engineer' that I am, I actually read the documentation, which, on the whole is very good.  But, as is often the case, I felt that the way-in diagram was missing.  And is indeed not to be found anywhere on the web.  There are an awful lot of references to the Android OS architecture diagram, as shown here.  This is, no question, useful, but what would have been even moreso was a diagram depicting the architecture of an application.  So, in its absence, I thought I'd cobble one together.  It's not much and there is probably much room for improvement, but it's a start.

Android Application Architecture

Note, that most of the coupling has been omitted to save it becoming a tangled mess.  I won't put many words to it.  Read the Android Application Fundamentals documentation and it should all make sense.

Okay, if you really haven't got time, here's a very rushed precis.  An Activity is effectively the logic running a single screen in an Android application.  The featured application has two Activities and therefore two screens.  Screens are defined in XML.  The XML schema for defining screen layouts contain elements for all the widgets you'd expect to find in a UI toolkit.  Layouts for Dialogs (which are shown in front of screens) can also be defined in XML. Activities can create and show Dialogs dynamically. Thematic elements (such as fonts and colours) can be separated from layout by defining them in separate XML files, as hierarchical styles analogous to CSS.

Capability that needs to run when no screen is being displayed is achieved using a Service.  An Activity can register for updates from a Service via a Broadcast Receiver.

Transitory packets of data can be passed between Activies and Services as Intents (not shown). For data that needs to be shared throughout the lifetime of an application, one solution is via a singleton class which exposes public accessors to static data.  Similarly, common logic can be encapsulated in singleton classes and accessed statically.

Persistence is provided by ContentProviders which wrap up access to either the file system, an SQLite database or the web.

So there we go, my trivial contribution to the Android movement.