In Part 3, we now explode the box #1 – “Browser or Custom App”. We look at various consumption channels and how they affect the implementation and technology choices.
Part 1 of the series on “Architecture for Multi-Device Applications” focussed on the bare-bore design.
In Part 2, we look at high-level implementation structure – a slightly more detailed version of the design discussed in Part 1, before we start opening the individual boxes.
One of the key aspects that we discussed in Part 1 was the separation between the “Application Server” and “Web Server” layer and argued that most of the applications that we come across in real world, daily life, don’t really separate them… or rather we find them difficult to separate because of the choices that we have or we are “taught” in our life.
One of the questions that keeps coming to me over and over again is – what is an ideal architecture for multi-device applications or rather applications that cater to multiple devices like desktop, mobiles, tablets, internet-TVs and what not?
This is quite interesting and exciting as more and more frameworks get developed. We started the multi-device world with native apps and soon realized that the model doesn’t scale. There came HTML apps (or what people naively refer to as HTML5). I won’t call them as really HTML5 (HTML5 only) apps… since you can live with HTML4 and CSS2 for most of the purposes unless you want features specific to HTML5 – most common being using audio/video since Flash is unavailable on iOS (iPhone, iPad etc).
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
IdentityCommandas well as
Controllernow has full support for forward as well as backward navigation.
Controllercan now record the activity navigation. Uses
Controllernow support forward navigation with few more options:
- Can optionally mark the command to not be recorded
- Can optionally reset the activity stack
backmethod 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
IInitializablehas been removed. Not required.
- The initialize method, henceforth, has been removed from
BaseActivitynow has two methods
BaseActivitynow 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
onKeyPressedand look for the
KeyEvent.KEYCODE_BACKand call the method
- Developers using v1.6 can override the method
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 http://android-mvc.git.sourceforge.net/git/gitweb.cgi?p=android-mvc/android-mvc;a=tree. Additionally, I’ve also pushed the codebase on Github at http://github.com/gvaish/Android-MVC.
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 – https://sourceforge.net/projects/android-mvc/
If are you interested in the code, you can get it using Git at
Or if you just want to browse the code before downloading it on your machine, you can visit http://android-mvc.git.sourceforge.net/.
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′]