Using Google App Engine as Backend for Android

If you’re looking for a way to create a backend for your Android application, Google App Engine looks like the perfect choice: You can use Java as you can do for Android and you don’t need to think too much about hosting, as it is all stored in the cloud.

Another benefit is that you can reuse your transfer objects on the client and on server side. But as it is often there are some problems doing this in practice. So you don’t have the same ones I had, I am glad to share my experiences with you.

So first question is what libraries are to use for the client/server communication. At start I tried Restlet 2.0. Looked like a great choice as there are special editions for App Engine and for Android available. In practice it is not very useful as the libraries are to big for Android and I also very much disliked that fully serialized java objects are transfered.

Best approach I found so far is to use Jersey 1.6: It is easy to use and implements the JAX-RS (JSR 311) standard. To set it up on the App Engine, please consult these blog posts from me: Using real POJOs (without JAXB Annotations) as transfer objects with JAX-RS and Storing large images RESTful in the cloud using Google App Engine.

Ok, so far about the server side. To keep things small and simple on the Android side, I mainly created the following wrapper class for the HttpClient to handle the HTTP requests:

This implementation is far from perfect, especially exception handling and passing parameters need to be improved, but it works so far :)

Using this class it is easy to store a file using the FileServerResource from my former blog post. Just call:

Also it is easy to store a transfer object using the doPut method. Note that is is using the ObjectMapper class from Jackson, the same JSON processor that is also used by Jersey.
Jackson is therefore the only additional library that you need on the Android side which keeps the executable small. If you use the same version of Jackson on the client side as on the server side you’re also ensured that the (un-)marshalling process of your transfer objects works flawlessly on both sides.

Hope you liked this approach – feel free to discuss here further ideas.

Using real POJOs (without JAXB Annotations) as transfer objects with JAX-RS

Are you annoyed that you have to annotate your POJOs with @XmlRootElement, so they can be used with JAX-RS? If your using Jersey as JAX-RS implementation your lucky: Just add to the <servlet> tag in your web.xml the following snippet:

After restarting your servlet, your POJOs are marshalled to JSON as a charme. Enjoy!

Openbahn-API – Bahn-Webseite als Webservice

As this is only of interest for German users – this article is in German only. It’s about a new project of mine. Sorry folks.

Ich bin gerade dabei eine Android-App zu entwickeln, mit der es möglich ist Fahrkarten für Bahn-Pendler einfacher zu buchen.
Bei der Entwicklung ist mir aufgefallen, dass die Bahn leider keine Webservices nach außen zur Verfügung stellt – die Webseite www.bahn.de ist zusammen mit der mobilen Variante m.bahn.de die einzige Schnittstelle.

Daher habe ich das Projekt Openbahn-API ins Leben gerufen: Es handelt sich um eine API, die Funktionalitäten der Bahn-Webseite als Webservices zur Verfügung stellt. Über diese Services können eigene Programme die verfügbaren Bahnhöfe oder Zugverbindungen inkl. Zeiten und Preise abrufen. Des Weiteren ist es über die Schnittstelle möglich, Zugtickets zu buchen oder Sitzplätze zu reservieren.

Die Dokumentation und URLs zu den einzelnen Services finden sich auf der Projektseite unter http://code.google.com/p/openbahn-api. Diese werden über HTTP-GET aufgerufen und liefern JSON Objekte zurück. So gibt der Aufruf von http://openbahnapi.appspot.com/rest/stations/list?contains=karlsr eine Liste von JSON-Objekten zurück, die alle Bahnhöfe enthalten, die im Namen „karlsr“ enthalten. Im Beispiel sind dies die gesamten Bahnhöfe im Stadtgebiet von Karlsruhe.

Die API kann verwendet werden, um eigene Anwendungen zu entwickeln, die Bahndaten benötigen.

Um die Qualität des Parsers zu sichern, wird der Code komplett als GPL auf Google Code unter http://code.google.com/p/openbahn-api zur Verfügung gestellt – jeder Entwickler ist herzlich dazu eingeladen Verbesserungen und Erweiterungen vorzunehmen. Das Hosting erfolgt über die Google AppEngine. Die Ergebnisse der Anfragen werden über einen Cache zwischengespeichert, so dass die Kommunikation mit der Bahn-Webseite minimiert wird und für vorhandene Ergebnisse auch funktioniert, wenn diese offline ist.

Ich bin gespannt auf eure Meinung und wünsche euch viel Spaß mit der neuen API.