Running on any platform using Java with GWT

Do you still remember that big Java promise: “Write once, run everywhere”? This is even true when it comes to mobile, you just need to go and use clever tools to do so. If you look at today's software development you will notice that many people are writing software not once, but instead write it three times: for the web, for android and for iOS.

Being involved with GWT, mgwt and Phonegap for quite a while, I think there is another way of doing this. I already shared this idea on several conference talks, but finally got around to writing it down:

Mobile is not that different than desktop

If you compare a mobile device to a desktop computer there are only two real differences:

A different screen size (kind of obvious) and a different way of interacting with the device. Since our fingers do have a certain width, we are not as accurate while using touch compared to using a mouse. This means that we do have a different information density per screen on a mobile device, but is this enough to redevelop software? Surely its not!

It is a matter of structure

If you understand the fundamental difference of those devices, you can start to arrange your applications to accommodate the fact. In general we do have more information per screen on desktop, but have fewer screens, while having less information per screen on a mobile phone and therefore more screens.

Let’s say this is how your product might look like on desktop:

And this is how the same software would look like on a phone:

You can clearly see that this application displays the same information across different screens. If there was only a way to separate the screen from the rest of the code that actually drives it.

MVP

MVP stands for Model, View, Presenter. It separates your UI code into those 3 categories. In the GWT world the use of MVP is quite common and there are several good frameworks out there.

Every UI has to do four basic things:

• maintain a presentation state, the data to be displayed and the state of the UI
• render the presentation state into the display
• draw things on the screen (aka the display)
• contain the UI event handling logic (“what do we need to do if this button is clicked?”)

MVP cuts these responsibilities like this:

The main idea is to have as few code as possible in the display to help testing, but this also helps our cause for building cross platform and cross device applications. The view does not contain any logic, it only contains the widgets with its positions. Therefore it could actually be build by a designer instead of a software engineer. Using MVP it is easy to swap out the view since we already do this for testing. The view only tends to be around 20% of your code, that does not contain any logic and is easy to write. By swapping out the view, we can reuse the presenter and the model for the desktop, tablet and a phone. This means reusing the major parts of your application on every platform it runs on.

So how do I build an app

The first thing you are going to do is to write a solid Java application, should also include mock views for testing purposes. In the second step you will use GWT to write a view implementation for the web. The third step involves using mgwt for writing a good mobile UI. Remember these are only about 20% of the actual code.

If your application requires native features that a browser can not offer, you will start to use gwt-phonegap and deploy your applications to the app store or Google Play using Phonegap.

There is also an easy way of making your code run natively on android and iOS, but I will be covering this in another post.

This means you can cover the web (desktop and mobile), android and iOS directly from Java thanks to the GWT compiler and mgwt / gwt-phonegap.

Conclusion

I think we can do better in business software development than rewriting our software per platform. By understand the fundamental difference between desktop and mobile we can choose an architecture that allows to only rewrite the small part that we actually want different per platform (the view), while sharing the same logic across all those clients.

This means that we can ship features faster, only need to fix bugs once, while letting compilers do the hard work for us.