Native Cross-Platform Apps with Tabris

Tabris is the first Java toolkit for the cross-platform development of native mobile applications. It combines native user experience with tailor-made, native controls and functions.

But what exactly does native mean?

The wide range of existing platforms available poses a genuine problem when currently developing mobile applications.

These are a dream for end-users who can access a wide range of hardware and software, but a nightmare for developers.

As soon as mobile App developers have to develop an App for more than one platform, they face a wide range of challenges.

One of the most difficult challenge is fulfilling the necessary expertise. Even if we “only” consider both of the market-leading platforms, iOS and Android, this means the following:

• Being proficient in 2 programming languages: Java and Objective-C.
• Mastering two platforms with different APIs.
• Planning one (or two) application design(s) that take both platforms into consideration.

In brief, if you develop ‘natively’ separately for each platform, the effort required to develop a mobile application more or less increases with the number of platforms supported. Luckily, cross-platform toolkits provide an excellent alternative.

Currently, there are two different types of cross-platform toolkits. On one hand, the HTML-based toolkits and, on the other, toolkits based on the cross-platform compilation or interpretation of native controls and functions.

PhoneGap clearly dominates the first category and uses HTML to display the UI. The unquestionable charm of this solution is the speed with which a simple App can be developed.

However, the HTML5 trend has lost some of its appeal lately, mainly because of dissatisfied end-users and prominent failures, such as Facebook.

As far as user experience is concerned, HTML5 can easily become a burden when developing mobile Apps. Unlike Web applications, mobile applications are usually equipped with highly-sophisticated controls (widgets). Although HTML5 toolkits such as JQuery Mobile offer similar features to operating system widgets, for this purpose they require a composition of several elements for each widget. In the case of more complex user interfaces, this leads to a multitude of DOM elements and may negatively influence the App’s performance. Widget-oriented or not, most HTML-UIs do not provide a satisfactory user experience, as the application generally looks and feels unfamiliar. This lack of familiarity ranges from the look and feel of the widgets to unfamiliar navigation concepts and animations.

The second category of cross-platform toolkits uses operating system widgets, hence avoiding look&feel problems. Apps created with this kind of technology are visually much closer to the native interface than HTML-UIs. However, these solutions also pose various challenges.

To successfully develop a native App, it is not enough to display native widgets. The user navigation must also reflect the platform-specific concepts. In the case of native App development, the developer has access to the relevant platform concepts for designing the application. In the case of iOS, this is the ‘ViewController’ principle, for Android ‘Activities’ and the ‘ActionBar’. Only a few cross-platform toolkits abstract these concepts and unify them.

This is exactly where Tabris comes in. Basically, Tabris falls into the second category of cross-platform toolkits. It abstracts native controls and their functionality with a Java-API. These include simple elements, such as buttons or text fields, but also more complex elements such as a tree/list or a swipe-widget. In addition to the controls, it also provides Java-APIs for controlling the device's camera or getting geolocation information. Another fundamental feature of Tabris is the abstraction of native navigation concepts, called the Tabris UI.

The UI is kept very simple and consists of just two core components. These are the Page and Action types. The best way to explain these types is using a screenshot.

(Click on the image to enlarge it)

This image shows how the same application is displayed on an iOS and an Android device. The actual content of the application is identical. Only the integration with the platform-typical framework is different. The area marked in red represents a Page. A Page is a kind of container for controls. The area marked in green represents two Actions. Conceptually, an Action represents a possible user interaction that is in relation to the application or to a Page.

To create a complete application with these types, they have to be connected to one another. The first connection is the so-called flow. The flow describes a chain of pages that can be put together in various ways. To create this kind of a flow, a Page has to take on a role. Possible roles are top-level page and normal page. A top-level page marks the start of a flow and does exist only once. A normal page can exist once or several times within the flow, but not at the start. This is easily explained using the following diagram.

(Click on the image to enlarge it)

The above diagram shows a typical application flow. In this case, the application consists of three top-level pages and several normal pages. A user can now navigate between the individual pages, e.g by using an Action. At this stage it is important that flows can be traversed in different orders, as explained in the following example.

Let's assume that you wish to develop a “Book Shop App”. In this case, a book is the central element of the application. Hence, the user must be able to easily navigate between different books. A feature that has helped Amazon generate considerable additional revenue is collaborative filtering. i.e. “Customers that bought this book, also bought these other books”. With this functionality a user can navigate from book to book. The length of this navigation chain is thereby not restricted. However, what is required is the ability to navigate backwards, either to the previous book or back to the start page.

The flow of the Tabris UI enables this kind of navigation. A flow can have any, non-fixed depth. A forward navigation is possible at any time. However, this means that the start of a flow has to have a fixed definition. In our book sample, that would be, for example, a list of bestseller books.

The second concept, the Action, is also connected to the pages. Typically, an action encapsulates application functionality. In the book example, this could be adding a book to the shopping basket or a search. These two activities also directly describe the possible action scope: an Action has either Page or global scope. It is also connected with a Page or with the whole application. A search is an example of a global action as it should be accessible from everywhere in the application. Unlike that, it should only be possible to add a book to the shopping basket when the user is on a book page.

A complete application-flow for a book shop could look like this:

(Click on the imge to enlarge it)

The screenshots show the same application both for Android and iOS. The App consists of three top-level pages: “All Books, Popular and Favorites”. Each of these top-level pages shows a list of books. Upon selection, one of the books is shown in the detailed view. From there, the end-user can either access further books or a sneak preview. The code of this application is available on GitHub. To see this application in action you can also take a look at this video.

After we have discussed the navigation concepts of the Tabris UI, we want to also discuss the widgets that make up the intrinsic part of the application. In the process, Tabris makes use of the API of the established cross-platform widget-toolkit SWT (Standard Widget Toolkit). SWT is lightweight, widespread, open source and uses JFace to provide a powerful MVC framework. The list view of the bookstore shown above can, for example, be implemented with just a few lines of code.

public class BooksListPage extends AbstractPage {

 public void createContent( Composite parent ) {

   TreeViewer viewer = new TreeViewer( parent, SWT.V_SCROLL );
   viewer.setContentProvider( new BooksContentProvider() );
   viewer.setLabelProvider( new BooksLabelProvider() );
   addBookSelectionListener( viewer );
   ...

public class BooksContentProvider implements ITreeContentProvider {

 public Object[] getElements( Object inputElement ) {
   return books.toArray();
 }
 ...

public class BooksLabelProvider implements ITableLabelProvider {

 public String getColumnText( Object element, int columnIndex ) {
   String result = null;
   if( columnIndex == 0 ) {
     if( element instanceof Book ) {
       result = ( ( Book )element ).getTitle();
 ...

As well as the conciseness of the API, further advantages of using the SWT are the availability of documentation, examples and support in the Eclipse Community. The handling of big data, the modular design of the application with OSGi and the integration of model-based user interfaces are all part of Tabris’s standard repertoire.

The underlying architecture enables the simple integration with established Java technologies. The thin-client architecture of Tabris can certainly be compared with a Web server and a Web browser, with the Web application logic being executed on the server side. The accompanying UI is delivered in HTML and rendered in the browser. In the case of Tabris, the application logic is also executed on a server, e.g on a JEE application server. A native client, for example, a tablet is connected to the server and receives the representation of the UI in the form of JSON. But instead of an HTML-based UI, the Tabris clients render native widgets and hence create a platform-specific user experience.

Like Web applications, mobile clients always need to be connected to the server. For some applications this is an unacceptable restriction, but for others this can be a real advantage. Data is only transferred in order to create the interface. The clients do not execute any application logic at all, they merely serve to display the UI. What’s more, this means that no sensitive application data or algorithms are saved on the mobile end devices, protecting these implicitly from theft or other kinds of loss.

An additional interesting advantage of the architecture and the underlying open communication protocol ¹, is the simple addition of different clients. For example, in addition to the mobile clients there are also open source Web and Desktop clients. Some clients, for example, based on Windows CE or for limited embedded devices such as cash registers can be implemented simply with a reduced widget set, therefore enabling new application and migration paths.

Version 1.0 of Tabris has been available since April, 2013. The server components, plus the Web and Desktop client are covered by the Eclipse Public License and can be freely used in commercial products. Only the mobile clients are covered by a commercial license. To personally test and evaluate the wide range of possibilities for Tabris, mobile clients are available for download from the project's website ².

¹RAP/Protocol

²Tabris

About the Authors

Jochen Krause is a member of the Board of Directors of the Eclipse Foundation. He is CEO of EclipseSource, a recognized leader in Eclipse distribution and OSGi runtime technologies. Jochen has had a leadership role in the Eclipse community since its inception in 2002, and has served in many roles from project lead to member of the architecture council and PMC lead.

Holger Staudacher works as a software developer and consultant at EclipseSource in Karlsruhe, Germany. He is responsible for Tabris and one of the core team of committers on the Eclipse Remote Application Platform (RAP) project. Holger also authored the popular restfuse framework for testing REST APIs. He is interested in anything to do with Agile, clean code and distributed systems.