Hanging on the telephone

JBoss goes mobile: Mobile applications with Aerogear


Spotlight on a project which puts the focus firmly on mobile development, with a library and other utilities for Android, iOS and JavaScript.

Aerogear is a JBoss Community project which puts the emphasis on mobile development, providing a library and various utilities for Android, iOS and JavaScript. We’re going to take a whistle stop preview tour in this article (originally published in JAX Magazine).

The development of mobile applications does not necessarily need to be over-complicated. A common hurdle faced is the deployment of an application on different platforms. For Java developers, Android still seems to be the most common platform choice. At the same time, developers can expect several issues that are completely different to those of Swing or even Enterprise Java applications. New or additional languages, such as JavaScript or Objective-C, can also cause problems.

Different frameworks

Dealing with the completely different frameworks that exist for their respective platforms is a considerably bigger problem than working with various languages. The central aim of a mobile application is to implement business requirements, but this means putting it into source code. To access a HTTP interface in Android, the “HttpURLConnection” API is frequently used – however, in iOS applications,  the AFNetworking Framework [1] or the native NSURLConnection class [2] is most commonly utilised. For mobile web applications, jQuery or the XmlHttpRequest object is used. These frameworks have completely different APIs, and not only because they were created in different programming languages. These differences serve to make it easier to program a business requirement for different mobile platforms.

Aerogear: Uniform API

The Aerogear project [3] provides a unified API for Android, iOS, and JavaScript. The concepts of the library are platform specific and therefore easy to transfer to other platforms. In practice, this means that the API provides the same functionality, but honors the realities of the programming language. For example, in Java a callback is expressed by an interface, and in Objective-C, a so-called block is used (comparable with a closure). The current focus of Aerogear lies in HTTP communication, offline storage, and various security issues such as OTP [4] or authentication.


For access to RESTful web services, Aerogear offers the pipe interface. It abstracts the actual HTTP access to an HTTP resource, and is essentially CRUD – functionality. All pipe objects are created by the pipeline class, which also takes over the management of the individual pipes. Let us pretend there is a REST service,, that works with the corresponding CRUD functionality, as described in [5]. Get the code for the Aerogear Android platform [6] here:

//set up the baseURL and the Pipeline „Factory“:

URL baseURL = new URL(„“);

Pipeline pipeline = new Pipeline(baseURL);

// create Connection to „“

Pipe carsPipe = pipeline.pipe(Car.class);

In the first three rows, the pipe object for the URL is created. Then data can be read from the REST service or transmitted to it (Listing 1).

Listing 1

// create “business object”

Care someCar = new Car(.........);

// save, via HTTP POST:, new Callback<Car>() {

@Override Public void onSuccess (Car serverData) {

// work with the Data...


@Override Public void onFailure (Exception E) {

show error...




A simple POJO object is sent using the save method to the server. The fact that internal HTTP POST is used is completely transparent. In addition to the actual object, an anonymous implementation of the callback interface is passed. In case of a successful saving (eg HTTP 201 (created)), the onSuccess () method is called. Various errors are signaled within onFailure ().

If this code is loaded from an Android activity or a fragment, you should make sure to pay attention to the properties of the Android Activity Lifecycle [7].When a call is transferred, the application in the background, and (via HTTP) read data can be lost, or even cause an error if the callback of the UI wants to change the background located ligand Android Activity. The same happens with a “change in configuration”, as for example, turning on the phone. The latest Android Activity is destroyed, and the operating system creates new data. The data of the anonymous callback implementation is also lost. Again, Aerogear offers assistance in the form of special abstract helper implementations of the callback interface [8].

In addition to the CRUD features we have also tackled the issue of hypermedia: AeroGear‘s pipe supports various types for scrolling through large amounts of data (“pagination”). Among other things, the Web Linking RFC is implemented [9] (see Listing 2).

Listing 2


ReadFilter readFilter = new ReadFilter();

readFilter.setLimit(2);max.two cars per response

//HTTP GET for two cars new Callback<List<Car>>(){


Public void onSuccess (List<Car>) response;

PagedList<Car>pagedCars = (PagedList<Car>)response;

// performs HTTP-GET for next items;


public void onFailure (Exception e) {

//show error




For the pagination, the read()-method is supplied with the usual callback as well as a Read Filter object [10]. In addition to these parameters, additional fine-tuning for the production of the can with the pipe object class PageConfig [11] are specified, such as the information which Linking variant to be used (for example, RFC 5988, or within the response).

If the server responds to the (HTTP) request from the Android application, the onSuccess() method is loaded, as expected. Here the list result is made on a type-cast to a PagedList object. The call to next () intends to send another request to the server. In this example, the next two cars will be loaded from the server.

Apple iOS

The above described Pipe-/Pipeline-API is also for the iOS platform before [12]. Here, too, the pipe object known read or save functions, but adapted to the “peculiarities” of Objective-C (Listing 3).

Listing 3

//set up the baseURL and the Pipeline “Factory”:

NSURL *baseURL = [NSURL URLWithString:@”};

AGPipeline *pipeline = [AGPipeline pipelineWithBaseURL:baseURL];

// create Connection to “”

id<AGPipe> carsPipe = [pipeline pipe:^(id<AGPipeConfig) {

[config setName:@”cars”]’



Within a few lines of the pipe object for the requested URL is created. As in the Android version, the pipeline “Factory” features a pipe method. Here is a so-called block (similar to Java Closures (JDK8)). This block gets passed exactly to determine the configuration (eg EndpointName or authentication modules) an object. Then data can be read from the REST service or transferred to it.

Similar to the Android Version of a “Car”, an object is sent to the server. Instead of a separate class, a map is used, which represents the car. The success and failure callbacks are also implemented using block. Both blocks have exactly one argument.

Xcode template

The starting new projects is often idle. In Aerogear there is therefore an Xcode template[13], shown in Figure 1

Figure 1: Xcode template

This template creates a simple example based on the Aerogear iOS library. After the project is created, we‘re just missing a small step: The dependencies must be installed with CocoaPods [14].CocoaPods is broadly comparable to Apache Maven:

pod install

With this call, the dependencies are loaded and a so-called workspace is created. After this workspace, open the application can be run directly on your own phone.

In addition to Android and iOS, JavaScript is also available for mobile web applications. Again, the API meets the previously introduced concepts. JavaScript functions are used here for callbacks, however:

Offline storage

Various client platforms offer different ways to store data:

  •  Android: Memory, SQLite

  •  iOS: Memory, PList

  •  JavaScript: Memory, Session Storage, Local Storage

Again, the Store API provides cross-platform concepts, in turn, adapted to the specificities of the programming language used, as here in the case of JavaScript:

In addition to an ordinary login modules Aerogear provides support for One Time Password (OTP), see [15] . With the 2-phase authentication, the actual login, expanded by an additional protection mechanism. Besides the password, the user selected a generated OTP token is required. Aerogear in the TOTP (Time-based One-Time-Password) variant isimplemented [16] . The Java library can be both client side (Android) and are also used on the server side. The server generates a secret and sends it to the client:

The client must now based on the received mystery, for example, via SMS, the token for the second step of the registration form (Android):

The client sends this token to the server now, so this – after successful validation – the login attempt are free:

Figure 2 shows the process based on the iOS client demos [17]. A JavaScript version is currently in progress.

Figure 2: iOS client demo


The current version 1.0 provides the basis for future Aerogear features. Currently, the developers are working on new features such as “Data-Sync”, “Offline” (eg Core Data for iOS or content provider stores for Android) as well as cross-platform push notifications which for APNs [18], GCM [19] or Simple Push [ 20]. The Aerogear Unified Push Server provides a single HTTP interface (and Java API) to a push notification to be sent to different devices (Fig. 3) [21].

Figure 3: Push notification

A special feature here is the development of a JavaScript API for Simple Push, which is available outside the FirefoxOS. In addition to the JavaScript library, the project provides an implementation of the Simple push protocol.

Matthias Wessendorf works as Principal Software Engineer at Red Hat, where he is focused on mobile and HTML5. In the past he was the PMC Chair of the Apache MyFaces project. Matthias is a regular conference speaker. He maintains a blog ( and tweets (@mwessendorf).



All Posts by MatthiasWessendorf

Inline Feedbacks
View all comments