A weekend project with Android and GWT

For a long time, I thought of getting my hands dirty with Android and GWT (Google Web Toolkit) but never had a chance (part because I was lazy, I guess). Finally this weekend I took the entire two days to build an application. This post is about my experience with Android and GWT.

GWT
There is no specific reason to choose GWT apart from the fact that I have little to no knowledge in HTML, CSS and Java Script. If I were to use any other web frameworks out there for Java, like JSF, Spring MVC, etc I need to handle the web UI quirks separately. Where as in GWT it’s all handled by the framework itself. Yes I had to deal with some CSS, but got all my CSS from the sample applications that came with GWT.

This post is not about GWT, if you need more information check out here. However let me list out the benefits that I had by using GWT

• It’s a component based model and hence you develop your entire UI in Java. Need not have to create a single piece of HTML code, apart from the home page.
• The GWT compiler converts your UI code (which is written in Java as said above) into a high performance java script code. This will be used by the browser to render the UI you have built. If I were to create the UI with just HTML and Java Script I would have spent days on it (again this might not be the case for a HTML and CSS guru).
• It comes with a great eclipse plugin, so you could just stay within eclipse to do all the GWT stuff. It comes with an integrated development server (based on Jetty) which you could use for quick testing.
• GWT has it’s own RPC mechanism, under the hoods it’s all based on servlets just like any other web framework. However the key architecture difference here is that, GWT promotes the use of AJAX. The server communication is all based on AJAX. So you would only send and receive data rather than receiving the entire HTML page from the server.
• Above all it has a great integration with Google API’s. I was using Google Map’s API and it was a breeze to get a Map displayed on the UI. Just two to three lines of code.

Android OS
I don’t have to talk much about what Android is as you might already know it, if not check out here. I was intrigued by the news earlier this week that Google now ships 60,000 android handsets per day (check here), so thought let me check out what it takes to build an application in Android.

The most obvious thing you would note about Android while reading about it, is that it’s a loosely coupled architecture and highly promotes reusability between components and for that matter between applications as well. I was not able to stop my self to compare it with Service Oriented / Messaging Architecture, will write more about it later. In Android one could build four types of components

• Activities - for the UI
• Services - does not require a UI, it runs in the background. Example a music player
• Broadcast Receivers - these receive and react to system and other application broadcasts. Similar to messaging systems.
• Content Providers - components that provide access to content in the phone, e.g. contacts data, media data, etc

My use case for this application is a very simple one, Whenever the phone boots up I need to start a back ground service which listens for requests from external source. External source being, in this case a web application running in an external server. Once a request is received the back ground service will send the current location data to the caller. The web application will then display it on a Google Maps mashup.

For the above use case to work I need only to concentrate on Broadcast Receivers and Services. My broad cast receiver will listen for system boot completed broadcast in Android OS. Once it receives the information that the phone is switched on, it starts the background service. My background Service starts a Server Socket and listens for client invocation. When it gets a client invocation, it uses the Location Manager API in Android and sends the current location data back to the caller.

All along in my career (which is just about 10 years), I worked in J2EE based applications and never had to deal with multi threading as the application server takes care of it. In Android, one has to deal with multi threading if the application does a lot of background processes. Overall I learnt a lot in the process of building the above application. I also made so many mistakes that every beginner makes though there are good documentation at the developer site. In the days to come, I will post about these beginner mistakes and the lessons that I have learnt in detail.

Wholesale Applications Community - Yet Another Platform For Mobile Application Developers

Today 24 mobile network operators joined together and announced their plans to create a Wholesale Applications Community (WAC), an unified platform that promises developers to write their application once and run anywhere, meaning across any handsets and any operating systems. The announcement was made in the 2010 Mobile World Conference. Sounds familiar?? this exactly what Sun did with Java for the desktop applications development and what J2ME did for the mobile application development, will come to this later. Go to the WAC website to understand more about the goals and it’s supporters. Anyway I think this is a huge effort and may not be that easy and they might be setting themselves up for failure, here are my reasons.

Write once and run anywhere mantra was proved wrong already - at least for the mobile application development. One of the goal of WAC is to allow developers to write once and run in any mobile operating system. This exactly what J2SE (Java) promised for desktop application development and what J2ME did for mobile application development, but what happened to those ambitious goals, seems like we went nowhere. While Java is great for server side application, it’s not widely adopted for the desktop and especially not for the mobile application development. WAC might be following J2ME’s failure by repeating what J2ME tried to do a decade back (J2ME was first released in 1999).

Issues in dealing with different Operating Systems. On a higher level the mobile eco system consists of three major players the operating system, the network operators and the handsets. WAC promises to create a single programming interface that will work in multiple mobile operating systems (e.g. Symbian, Android, Windows, etc). This might create a huge issue for application developers, if the different operating systems support different versions of the API’s. For e.g. say a new version of the API is released and Symbian supports it but RIM does not support it, developers now have to manage different versions of their application for different operating systems. This completely defeats the goal of WAC.

How about the network operators? Even if the operating system is updated to support the latest versions of the API, one has to rely on the network operators to push the updates to the individual hand sets. Most of them do not update their operating system in their handsets unless it is pushed by the network operators. And this causes a lot of variation in the market each using different versions of operating system and each operating system supporting different versions of the so called one uniform API from WAC. This ultimately increases the cost of maintaining and releasing a mobile application. Speaking of the network operators, they are notoriously famous for controlling access, for e.g. each network operator might have their own customized application store making the developers to go past their red tape. And you know what this what happens for the android market place as well, some network operators even block the market place access and provide their own customized version of it.

Got to deal with different devices with different capabilities. Say there is no issues with OS and even with network operators even then developers have to deal with multiple handsets. Developers have to deal with hundreds of devices with different capabilities. They will have to consider display resolutions, input options, does it support gestures?, processing power, does it have GPS?, does it have a camera? and so on.

All the above issues creates a lot of confusion for developers and will certainly increase the time and cost to the market for application developers. Not only that, think about average consumers they have to understand what kind of application will work in their devices, this will certainly scare the heck out of them and there by reducing the potential of them buying an application from the store. All these factors will prohibit the adoption of the ecosystem by the developers and hence WAC might be an eventual failure.

On the other hand Apple iPhone and it’s application store is a great success as the device (hardware) and the software is tightly controlled by Apple and hence developers or consumers need not have to deal with the mess listed above.

On a different note, Why do we need another platform that works across all the handsets and isn’t that Android is all about? The key difference is WAC is trying to create one API for various operating systems where as Android is just one operating system. And as techcrunch pointed out, there is already a platform that works on every smartphone which is HTML 5. Great example of this is HTML 5 based Google Voice application which works in iPhone, Palm Pre, and any smart phone that supports HTML5.