Model View Controller (MVC) Framework for Android

Posted on April 7, 2010 by m10v

Recently, I have been working on a Model-View-Controller framework for Android. Have been having a crazy and interesting life since.

The infrastructure is something as follows:

An Activity act as a “View”
There’s a “Controller” – a singleton class – that keeps a track of all transactions across the “View” and the “Model”
Business Entity representing the “Model”
Then there is “Command” that represent any transaction / action triggered from the “View” to generate the “Updated Model” and result
A “Command Manager” to keep a track of all business operations so that, just in case, a command needs to be terminated and/or for general bookkeeping

There are quite a few interesting challenges that I came across while working on the same… and continue to evolve it:

Everything happens on the client side – there’s no browser that will take care of the “Back” and “Forward”
Cannot rely on the OS default handling of the launching of the new activities and the hardware back button
So as to provide a support for the Back button, because that’s the only one on the device by default, the controller has to keep its own stack of multiple items – activity, data used to launch and initialize the activity, any changes that may have happened in the state while interacting with the activity itself – the last of which I still need to do
Most of the new activity launches are triggered from data transactions over network. For example, after the login screen, I jump to the home screen and upon performing an action (like click) on some item on the home screen, I navigate to, say my messages activity. As such, the controller has provided a support for “progress” – not just on the top of the activity but as a full-screen activity
While going “Back”, the controller had to be made smart enough to ensure that the “Progress” activity is never shown but the real previous activity is launch with appropriate data for initialization
The activities talk to the controller for a business operation to be performed on a piece of data (model). As such, you can say, the controller follows the front controller pattern. For those familiar with the Struts framework, controller is something similar to ActionServlet to which *.do or /do/* is mapped or like the StrutsPrepareAndExecuteFilter in Struts2 that pre-processes all incoming requests
Most of the business operations, as what I believe and least the case is in the current application that prompted me for creating the framework, will fetch data from either database or network. And in our case, we had no caching – any and all user interface when presented to the user will always get the latest data from the server. There’s no “Refresh” button. It’s always refreshed by default. And we would not like to block the UI thread while fetching the data. So, process all business operations in a non-UI thread and do a context switch just before the data is to be processed by the activity (the UI) – all that is the responsibility of the controller
At some point in time, the “Back” button may need to be reset – saying that from the current point, no back is possible. Controller has the flexibility. Useful if the activity-stack gets larger or if the logic says, for example, on launching any activity from the options menu should reset the back-activity-stack
It has to do all data housekeeping – what was the data used to launch the activity and initialize it. When to launch a new activity or when to update an existing one. Which activity to launch. Whether or not to terminate any previous business operations pending, for example, while navigating from one activity to another, any data communication to/from server may need termination… there’s a lot of hard work to be done by controller.