Cross-platform mobile developement

Alex TheedomNovember 3rd, 2015Last Updated: November 2nd, 2015

3 42 4 minutes read

So what problems does cross-platform development actually solve. well they are two-fold.

To have the capability of complete (or near complete) mobile platform coverage by developing the application once to run on multiple platforms. To kill two (or multiple birds) with one stone.

And secondly to reduce language selection to a subset of the languages normally used to develop mobile applications and ideally to just one.

The financial implication of successful cross-platform development are obvious in terms of human resources and clearly make this kind of development very attractive to businesses and their clients.

Two Approaches

There are two broad approaches to developing for multiple platforms. The Hybrid approach, used by the GWT, where the code is developed in one language only (in the case of gwit it is Java) and then translated to HTML5, CSS and javascript. These apps run the same code on every platform and render views in the webview of the native device. Access to device features such as the camera and contacts leverage JSNI (JavaScript native interface), perhaps using Cordova.

The alternative approach is to cross-compile your code base to the native code of the target device by translating to the native language. Weather that be Swift/Objective-c for iOS or Java on Anroid or C# on windows phone.

We are gong to look at three frameworks that levarage these methods but in quite unique ways.

Tabris

Tabris falls into the Hybrid category of cross-platform development. Like GWT it uses Java to describe the views and widgets available to the application and Java EE technology to create an application on the server. However unlike gwit it does not translate the UI into HTML5 and JavaScript but rather into JSON representations of the UI element. The native client effectively acts as a player for the applications UI. It access the application by calling a URL that provides the JSON representation of the UI element. Then the client will render the UI from the JSON message using native components. For iOS those components are Cocoa Touch widgets and Java based widgets for Andriod.

On the server side a war file is deployed to a web server where it registers a servlet that becomes the entry point of the application. The JSON UI messages are then served to the client.

You require a commercial license to use their framework.

OK so lets see how this works from a code perspective. The Tabris UI framework is responsible for creating the Page and

Action objects which are added to the UI Configuration object. in this example two configurations will be created and added to the UIConfiguration. The first is a PageConfiguration which defines a top level page with id ‘all-dvds’ .This page will have a title and an image. The second configuration is an ActionConfiguration that defines a search action. This is then rendered with the native look and feel.

Codename One

Now lets have a look at a framework that compiles java code to the native language of the target device. Codename one comes as a plug-in for eclipse, netbeans and intillij. Using their API you build your app’s UI and code its business logic. The interesting part comes when you want to compile and deploy the app code.

For apps written to directly target an Android, J2ME & Blackberry device the standard Java code is executed as is. While apps coded in Java 5 are translated to JDK 1.3 cldc subset for execution on J2ME and Blackberry. For target iOS devices the java code is translated to C code and for the Windows phone it is translated to c#.

Now the really interesting part here is that to compile to native code you select the target device from the plugin menu, this bundles the app and sends the code off to thier remote build servers where it uses a virtual mac or pc to perform the necessary actions to compile the code.

This removes the need to own a mac and pc machine. When the app is compiled and is ready you are presented on screen with a QR code that when scanned by your device will download and install the app.

Now lets see some code. For those of you who know Swing or even GWT, for that matter, this code will be immediately understandable. Page components are created and action listeners are attached as anonymous classes. In the example we create a button and add it as a component to the form. Then we add an action listener to the button.

When the button is click a dialog box pops up showing the message.

They published a blog article a few months ago saying that they are working on java 8 for the next plugin release. So we should see code like this in the future.

You require a commercial license to use their framework.

Oracle mobile application Framework

And finally lets take a look at Oracle’s offering. They have taken a very different approach to the other two. You write your business logic and the code that reacts to user interactions and accesses backend functions. This code is then deployed on a lightweight native JVM on each device. The JVM is bound to the webview and device features.

The UI components are defined in XML, HTML 5 or can be served as HTML webpages. Devices
feature’s interactions leverage Apache cordova and are rendered in the native webview.

However you must use either Eclipse or JDeveloper.

Lets look at how a MAF app is developed. The flow between pages is defined with the help of a GUI that visually represents the pages and their inter-relationships, here showGraph specifies the transition type, you then must write the actual logic for each page.

The device’s features are accessed via an instance of the DeviceManager. Here we create a new contact and added it to the contacts via the devicemanager. Your app is deployed as a platform specific deployment.

And a commercial license is required to use the framework.

The slides to the complete JavaOne presentation that I did with Murat can be downloaded from slide share: Mobile Java with GWT: Still “Write Once, Run Everywhere”

Reference:

Cross-platform mobile developement from our JCG partner Alex Theedom at the alex.theedom blog.