Since the rise of smart phones writing phone apps is all the rage, to the extent that it almost seems we have forgotten what we used to do before there were smart phones. There are tons of desktops and laptops out there armed with browsers, but my local bus company wants me to download an app to my phone so that I can basically look at their web page. So do my local weather service. Even my phone company wants to do this.

All of the above present the same information on a web page which I can access just fine using the browser on my smart phone. So why do they go to the trouble of developing mobile applications to do the same thing? Notice I said ‘applications’, plural. They typically develop for iOS and again for Android. The two use different APIs and different development tools so this does mean double the effort. But it doesn’t stop there.  There are Blackberry, webOS, Symbian and Windows phones out there too and, assuming you think they are all worth supporting, you’ll need to rewrite your application for those as well.

And all to present the information on your web page. Really?

The reason they want to create an app is probably one or more of the following:

• The newly hired batch of geeks are getting bored
• We need to present a cool image to our customers
• We can monetize the app (ie sell it) through the various app stores.

Different app writers will have different reasons. The weather service I mentioned above wants me to pay for their app, so they’re clearly into the 3rd reason. The phone company and the bus company give their apps away so I’m thinking one of the first two reasons applies to them. Or maybe once I use their apps I will find add-on pay for features, or maybe they have advertising.

None of these reasons are bad reasons. But they do seem a little pointless when what you end up with is just the same as the web site.

And there is a better way anyway.

In the early days of desktop computing the entire program, including its UI, always ran on the desktop machine in much the same way smart phone apps do today. Many desktop applications still work like this (MS Office, for example).

But these always need you to install something locally and as the Web took off applications started to be entirely web based. This was always difficult to manage well partly because the browsers were fairly dumb and partly because there were so many different technologies to integrate (html, javascript, JSP or ASP, backend languages like Java or C, databases etc). Then you had security and failover to manage.

But we moved on to smarter techniques using AJAX that could build really slick applications that were web based but look like desktop applications. Google’s GMail and most of their other services are examples of this approach. They also published GWT, the framework they use to build their applications. There are others in this area too such as Dojo and Echo, so Google doesn’t own this space.

But the interesting thing about GWT is it means you can forget about those other technologies and just write Java. The Javascript is generated transparently (including the code to handle cross browser inconsistencies). But it doesn’t stop there.

Vaadin developed their product on top of GWT and Vaadin’s approach simplifies the GWT stuff, provides a ton of out-of-the-box widgets (which you can add to) as well as a rich framework for building heavy duty Java applications at the server side. Using Vaadin you don’t even have to worry about GWT, though you can tweak CSS stuff if you want (and you probably do want to) to add a richer look and feel. But CSS is just look and feel, not function. The CSS team can go work on their own while the application programmers work on the real stuff (oops, I just insulted all the CSS experts out there, sorry).  This separation is important. It ensures the two groups do not trip over each other.

Vaadin applications are designed for desktop browsers. How does this fit into your mobile ambitions?

The answer is Touchkit, a Vaadin add on which has widgets that look and behave like smart phone controls. The default style is iOS but you can tweak that for other environments, and you’re still using the same application.

What about monetization? Oh, yes, you still want to see your app in the app store and charge for it. Okay, you can do that by surrounding it with a webview, but it is still the same application and it is still running in a browser. There is a small gotcha there in that Apple are a bit wary of webview applications, although they are allowing some. Also I’m not sure about serving up advertising in an application in a web view, probably fine, but it might need some work to get it going.

That gets you a browser based app that is installed like a native mobile app, but you only have one copy to develop and maintain. What are the downsides?

There are a couple. First, you do have to have a server running the application somewhere. So if you were developing a stand alone Tetris game this solution is not for you. Having said that Vaadin’s Touchkit supports going offline (actually I think it is riding on GWT’s support for this) and synching subsequent changes afterwards, so you’re not quite tied to the internet. But you do need a server.

The second one is that you are still running in a browser. What the browser cannot do your app cannot do. So, location services are okay because HTML5 browsers support that. Camera access not so much. There is a work being done in this area with a product called PhoneGap which seems to understand how to drive all the mobile platforms I mentioned early on in this post. Actually they list 7. It takes HTML, Javascript and CSS and turns them into an app for the target platforms, including accessing the accellerometer, compass, camera etc. They do appear to have had some issues with Apple about whether their apps can be in the app store. But these seem to be resolved.

Vaadin applications, as far as the client is concerned, are precisely that (HTML, Javascript and CSS and the client doesn’t know about the Java back end code running on the server). More about it working with Vaadin here. There is ongoing work in this area, but we should be able to write totally portable mobile web based applications.