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: http://bit.ly/cLHzbW.

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

The latest code can be browsed at http://bit.ly/cLHzbW. 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!

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…

Google Web Toolkit 2.0 has finally been released! And it’s exciting. There are quite a few updates. Do have a look at http://code.google.com/webtoolkit/doc/latest/ReleaseNotes.html

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.

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 http://svn.igniterealtime.org/svn/repos/openfire/trunk/documentation/dist/

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