How Does Mobile App Communicate With Server

16 Apr 2012

Serving mobile devices with server-side apps

You may have read the title of this post and are asking yourself, "what the heck is a server-side app?". Let me try to explain. When an app works with sensitive data there is always a security risk in storing the data on the device. If the device is lost or stolen the sensitive data is lost or worse, no longer confidential. A server-side app can prevent this. Data is stored on the server and the client displays and manipulates it, but no data is stored locally. I think you've got it: server-side apps are nothing more than a thin client approach adopted to the mobile/app sector.

When you're confronted with this problem, you've probably either started by designing the server application or are porting an existing server application to be accessible by mobile devices. So, your next step will be to plan how to visualize the server-side app on the clients. The most common approach is to build an App for iOS, Android and so on and render the data in a more or less generic UI. You'll invest a lot of effort in creating and securing the communication between server and client to get your server-side app ready. And, you'll have joined the club of developers, including me, who have reinvented the wheel once more.

This is the problem we are solving with Tabris (previously RAP Mobile). Tabris consists of a server and generic clients, with the server based on standard servlet technology and a kick-ass OSGi integration. The server's open source and hosted within the Eclipse RAP project. The generic clients currently exist for iOS and Android, and in both cases, all the clients do is talk to the server and display a UI. But, every other server-side app does this too. What's special here?

With usual server-side apps you have to couple the client to the server. The data and message contents are defined and the client needs to understand them, resulting in a more or less a tight coupling between these two all created by yourself. With Tabris, the work on communication is done by the framework for you. The server produces JSON based messages that the Tabris clients can understand. The messages contain information like "Create a Window, create a Button, set the text of the button to …", (I think you get it). When you sketch this out it looks like this:

This approach allows us and you (because the server's open source) to come up with any client as long as it understands JSON. I think the major benefit Tabris brings is that you can concentrate on the server-side and your domain requirements, instead of programming a generic UI for every platform.

When you've read this far you might now be asking yourself, "When everything is on the server side and I don't have to write a native UI for the mobile devices, eg. in Objective-C, how does the native UI get created?" And now the Eclipse open source project comes into the game with Eclipse RAP. RAP provides a widget toolkit which is based on SWT, which means that you write your UI completely in Java. When RAP was created the goal was to enable a developer to create a desktop and a web application with the same code base. As a result, the RAP developers solved problems like multi-user awareness, clustering support, styling and many many more. In the meantime, we've gone even further and extended this idea to the mobile space. (And, we're making good progress, because on the server side we're working with a mature technology.) In short, it means that when you write a Tabris app for iOS, Android and so on, you don't have to worry about the native client, but you can write your UI in plain Java and run it in the server.

If you're hungry for more ;), visit the Tabris website, watch the demo videos, clone the examples and run your own app. ~~To join the developer preview, you'll need to complete a short form, but in a few months we will move into an open beta.~~

You can download the latest Tabris available right now!

I hope you will have fun with this as much as I do. Any feedback is welcome.