FileSystem API was introduced in AppEngine last year. A great feature. I tried using it more than a couple of times and ended up with one problem or the other. Some of the notable issues include:
After a bunch of experiments, I concluded that it is best to use BlobKey.
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).
So, we have been working on this application… web based, data driven, to be used in “social context”. I think today there’s nothing sexier than using the word social.
We designed this application nicely, fantastic by many ways. We were sure of putting this up on a public cloud, just that we were not sure of which one: EC2 or GAE. One of the most riskiest questions to keep open… but really, we were not sure. The only thing we were sure of was Java + jQuery + HTML5 (as much as possible).
EC2 gives you IaaS but then you must manage all the servers, load balancing, failovers. Even if you happen to choose BeanStalk, a lot of work has to be done, specifically database. Thankfully, we now have ElastiCache (launched around August 2011, IIRC) otherwise managing a cluster of Memcache was yet another task for the admins.
GAE provides you PaaS, so you don’t need to worry about doing all the stuff in previous paragraph yourself. Except that you have strong restrictions… a very small subset of Java SE library – specifically, not threads or direct sockets, no JDBC and Datastore, though amazing, is not an easy meat to digest for those not used to. And above all, the server side execution must complete in 30 seconds (now on what are known are front-end servers).
So, we designed our own data-access abstraction so that we can switch EC2 <=> GAE without any hassles. It took a while, but it’s a great thing that we have.
After writing core entities and business logic layer, it was time to start pushing it all up to the user interface. The dashboard – the landing page after login – has to get updates from various “components” in the system. All components worked great, except that the dashboard took somewhere around 1200ms to load for the first time. Note that most of the public resources (images, JavaScript, CSS) were loaded from GAE CDNs.
Just not acceptable!
I have always wanted to a start a series on Android, noting that I have now spent over 3yrs working on Android, mainly at the application level (what you touch and play with on the device) and at times at the middleware level (drivers and codecs, that runs without your knowledge in the background).
So, I finally I have a go… as and when I get time, I will be writing articles on various application development aspects relating to Android. And no, I am definitely not planning to write another “Hello World” tutorial. You can search on Google for several such tutorials on the web.
I will be writing the stuff on the aspects “Beyond Hello World”.
I had been hunting for a good web based code editor when I came across CodeMirror at http://www.codemirror.net.
Great project and a lot of hard and smart work indeed.
I am a great fan of GWT and try to move anything and everything that comes my way to GWT 
The result is gCodeMirror project at Google Code and GitHub.
If you are interested in directly jumping to a demo, browse to this test URL.
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 git://android-mvc.git.sourceforge.net/gitroot/android-mvc/android-mvc.
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′]