A while back I wrote something about delivering web apps as mobile apps and I have at last got around to building something to show it working. Most of what I have done is just picking up other people’s work and implementing it, and documenting how I got on in this blog. I also wanted to show that it all works with my Madura software.

The good news is that it does, and very nicely. A key goal of Madura is to make it easy to implement serious back end logic independent of the User Interface, and yet have that UI cooperate with the back end logic intimately. In its first test of this, switching from a conventional browser environment to one designed for a mobile phone I really did only have to change the UI, not the underlying logic. In fact my sample application has both UIs embedded in it, and it picks the right one depending on your browser. Both of them talk to the same business rules and business objects. So no redevelopment of the underlying layers, just the UI.

And when I say the UI, well, there isn’t much to it. The Vaadin support code I already wrote happily ties in validation, dynamic field adjustments etc which propagate from the business logic. So the UI is fairly bare. Code to enable buttons to enable or disable at the right time, for example, doesn’t need to be written, it just happens.

Let’s see what it looks like. The Mobile UI shows a configurable pizza where you pick the base, size and topping. There are a couple of test fields at the bottom and an amount.

You can only pick some combinations of size and topping and once you pick a topping the list of options for the size will change, or vice versa if you pick size first. It only ever shows you valid choices.

The size determines the amount so once you pick a size the amount will change. This is done by rules not by some embedded logic in the UI.

The two buttons at the bottom are interesting too, although the Save doesn’t do anything. If there is a required field that has no value the Save will be disabled. You only see a required field if Size is set to Medium, then a new field appears and it is required, and  empty, and Save is disabled.

Again, none of this is done in the UI logic. It is all handled in the back end rules. The other UI does similar things and it is driven by the same rules, not a slightly adjusted copy of them, the exact same rules.

All of the UI here is using Vaadin, which is just brilliant. It also uses an add-on to the standard Vaadin called the TouchKit, also developed by Vaadin. That handles the Mobile specifics like touch screen etc.

So this is a web app that looks like a phone app. But shouldn’t it be a proper phone app that you can put into the app store where people can find it? Maybe you can charge for it and deliver ads through it. I’m not sure about the ads, but you can package this as a phone app and it is very easy. The steps are well documented using a product called PhoneGap which takes some combination of html and javascript and turns it into an app. Not only does it deliver Android apps, it delivers them for iOS and Windows phone and all the other mobile platforms you didn’t know you could write apps for. The process is trivial to do and seems to work just fine for Vaadin apps.

My code for all of this is here with an online demo here. The demo will show you the non-mobile UI if you use a non-webkit browser like FireFox. If you use Chrome it will show you the mobile UI. Of course if you browse there from a phone you’ll see the mobile as well. I’ve only tried it on Android so far.

The project also makes an apk file which can be side loaded as an application to an Android device. The main difference between running from the app is that you don’t see the URL box from the browser, it just looks like an ordinary native app.

I didn’t need to take things this far but Vaadin’s demos include getting the location (GPS) information and there seems to be mechanisms to get at the camera and other phone hardware too. For now, all I wanted to prove was that Madura could run in this environment.