Android MVC – Forward and Backward Navigation

This weekend’s changes to the Android MVC project include the following:

  • Reorganization of the Command classes. AbstractBaseCommand has been created for simple get/set. All methods except “execute” have been implemented. This class now forms the base for IdentityCommand as well as AbstractCommand.
  • Controller now has full support for forward as well as backward navigation.
  • Controller can now record the activity navigation. Uses ActivityStackInfo.
  • Controller now support forward navigation with few more options:
    1. Can optionally mark the command to not be recorded
    2. Can optionally reset the activity stack
  • Controller now has back method for backward navigation.
  • Controller, during forward navigation, manipulates the activity stack appropriately.
    • Missing part is handling failure scenario when receiving a response. When processing the response, if it is in “error” state, IMHO, the response must be handled by the same activity rather than launching a new one.
    • More so, the command must be removed from the top of the stack if there was an error.
  • The support for IMemento, IInitializable has been removed. Not required.
  • The initialize method, henceforth, has been removed from BaseActivity.
  • BaseActivity now has two methods preProcessData and processData called before onBeforeCreate and before onCreateContent respectively.
  • BaseActivity now handles the back button (using the v2.0 function onBackPressed) by calling the back method for navigation.
    • Developers using v1.6 can override the method onKeyPressed and look for the KeyEvent.KEYCODE_BACK and call the method back.

Sample case study (showcase) now comprises of the following:

  • SplashActivity that happens to be the main launcher activity.
  • Erstwhile MainActivity has been renamed to LoginActivity to reflect its purpose.
  • HomeActivitiy continues to be the same.
  • SplashActivity launches LoginActivity using IdentityCommand and sharing some data (using Tag)
  • LoginActivity launches HomeActivity upon successful login (sharing some data using Tag and passing some piece of data to LoginCommand using Data).

The code is, as usual, available on Sourceforge at;a=tree. Additionally, I’ve also pushed the codebase on Github at

Android MVC – Stable Release and Case Study

Yes! The code has moving quite fast… now from Beta– to Beta- as I see it ;).

And soon, the Android MVC project should move up to real Beta.

The Http-Commands have been made more robust with better error handling. Controller has been enhanced to provide support for registering activities dynamically.

What still remains pending is activity-stack management by the Controller – which otherwise is done by the Android OS. The stack management is not a trivial task, however for an application it will provide some interesting bits. Firstly, it’d be great for a single-Activity-at-a-time application without too many overheads. Secondly, the Controller will some enhancements to ensure that forward-and-back work without too many duplicates in the UI as what happens in several applications as of now.

As usual… the code can be browsed at:

And Oh Yes… to login, use these credentials – username: “gvaish”, password: “password” (without quotes).

Android MVC Project Updates

The latest code can be browsed at A couple of critical changes have gone into the structure:

  • Removed the logic for progress or error activity from the Controller. The effect is – the fields progressActivity, errorActivity have been removed and also the code pieces that referenced them have been deleted.
  • Progress activity has been replaced by a simple, easy to use, ProgressDialog. This dialog is initialized in and launched from BaseActivity, as opposed to earlier structure where the progress activity was launched from Controller
  • Overloaded “go” methods have been added in BaseActivity. This gives ease and peace of mind to the BaseActivity-inherited classes to never be bothered about the Controller.

Pending items include:

  • Appropriate response handling in case of error from the incoming response in Controller.
  • Ensuring that if an error occurs and the same activity is shown, pressing the “back” button should not execute the “errorsome” command again (deviation from normal browsing a MVC-designed website).
  • Creating a robust case study to test out a few scenarios:
    Main (Splash) => Login => Successful => Home => Back (should exit);
    Splash => Login => Failed => Relogin (may be same activity or different) => Back (should exit);
    Splash => Login => Cancel (back button) => Should just cancel the login request.

Keep watching for more updates!

Model View Controller (MVC) for Android

Finally, I have been able to find time to push the intial code for “Model View Controller” implementation on Android.

Quite a few people told me that MVC is inbuilt in Android, with the View being represented by the Activity but I failed to visualize or tangelize the Controller. Well, the Model can always be the backend data – the business entities.

The code is hosted on Sourceforge –

If are you interested in the code, you can get it using Git at git://

Or if you just want to browse the code before downloading it on your machine, you can visit

The code, by any means, is not yet ready for production use since I know various pitfalls, specially for the scenarios when the “Command” fetches the data from the network or database or from anywhere that takes long time.

In these cases, the best practice would be to hive-off the execution in a separate thread (read: Non-UI Thread). When the response is ready, you would pass it to the main thread (read: UI Thread) using a Handler. This part is implemented in the Controller, however, there can be race conditions in the scenarios where in multiple commands get issued – specially in very interactive application. Well, the bigger question there can always be – should MVC be used in that specific scenario?

Additionally, since, currently, the progress is presented using another Activity, there is an extra house keeping that is being done and I know (by use of this approach in my application), it is bound to fail in near-extreme scenarios.

The fixes are available with me… and I should soon find time to push them. Besides, I also need to a create more powerful case-study! 😀

So… keep watching!

And yes… if you feel that the code has done any good to you, please do spread the word and “Share the Love” :)

Here are initial screenshots of a trivial case-study (scenario) of initial implementation…

[showtime bgcolor=’#fcd77f’ width=’480′ height=’640′]

On becoming “Double Chachu”

And finally, the d-day has come. My friend and business colleague, Umakant, has been blessed with a daughter – Goddess Laksmi for the second time in his family! Sooo lucky :)

The name is Yana, meaning “Precious to God”. See Yana andIoannes.
Here are some photos…

[showtime bgcolor=’#fcd77f’ width=’480′ height=’640′]

Model View Controller (MVC) Framework for Android

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:

  1. Everything happens on the client side – there’s no browser that will take care of the “Back” and “Forward”
  2. Cannot rely on the OS default handling of the launching of the new activities and the hardware back button
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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.

Well, this posting is just a primer for MVC for Android in terms of what are some of items to be taken care of.

I will create a project on SourceForge, publish the code there… and write the updates here.

Keep watching…

Facebook targeting Orkut!

Have you noticed?

I noticed this …

Orkut Ad on Facebook

Asks you to export and download (as CSV file) the friend-list from Orkut and upload it on Facebook.

Facebook to Orkut Import

Google Web Toolkit 2.0 (GWT 2.0)

Google Web Toolkit 2.0 has finally been released! And it’s exciting. There are quite a few updates. Do have a look at

Few things that I personally like:

  • Development mode as opposed to hosted mode. So, now I can ask my colleague in Stanford to test application that I host here or vice-versa –we don’t need to exchange Eclipse environment. Selenium Remote Control (Selenium RC) integration just rocks!
  • Speed Tracer is a great thing to have for Google Chrome. For starters, it’s like Firebug for Firefox.
  • Code Splitting is finally here. It was always in my wish-list, coming a Dojo background 😉
  • UiBinder – using templates to create the interface. Although, the Dojo template engine is 100x better
  • And finally… unit testing that I never made use of the way GWT originally provided has support for headless browser – HtmlUnit. HtmlUnit is something indispensable for web application developers and testers.

XMPP and Openfire

This is a great surprise for us!

Openfire 3.6.5 will be released under Apache Public License (APL) v2.0 :)

Have a look at

I could not find any update on any of the mailing lists to this effect. Version 3.6.4 was release a couple of months back, under GNU General Public License (GPL). However, when I looked at the latest code that I checkout a few days back but noticed only today (while doing a diff) in the headers of one of the core files.

Great going Ignite Realtime :)