© tlorna, Fotolia.com

Ein Großteil mobiler Smartphones lässt selbst programmierte Anwendungen ablaufen und liefert dazu auch die notwendigen Werkzeuge mit. Je nach Plattform unterscheiden sich Lernkurve, Tools und Grad des Zugriffs auf die mobile Hardware. Eine Bestandsaufnahme.

Die Menge mobiler Applikationen entscheidet die Vorherrschaft im Smartphone-Markt mit. Hersteller tun also gut daran, Entwicklern ihre Plattform schmackhaft zu machen. Um einen Eindruck der Werkzeugunterstützung zu bekommen, haben die Linux-Magazin-Tester eine Telefonapplikation für Maemo, Android und Web OS entwickelt. Der Kasten “Für Symbian entwickeln” beschreibt die Situation für das bisher auf Nokia & Co. vorherrschende Mobil-OS.

? Android

Google orientiert sich wie schon bei früheren Projekten, etwa dem Google Web Toolkit, an Java. Deren Entwickler haben daher keine Schwierigkeiten, sich für Android fit zu machen. Grob gliedert sich die Android-Bibliothek in zwei Teile: Zum einen existieren umfangreiche Klassen und Module, um GUI-Elemente oder Telefonie-Funktionen zu nutzen. Google orientierte sich bei diesen Widgets jedoch nicht an bekannten Toolkits wie Swing oder AWT, sondern entwickelte sie selbst. Zum anderen liefert Android eine Java-Standardbibliothek mit, die sich an Java SE 5 anlehnt, dem API jedoch nicht vollständig entspricht.

SDK, IDE und Emulator

Um die Hürde für Applikationsentwickler gering zu halten, bietet Google außer dem Android Software Development Kit (SDK) zusätzlich ein Eclipse-Plugin an. Es vereint die Entwicklungswerkzeuge mit einem minimalen GUI-Designer und einem Mobiltelefon-Emulator, der auf Qemu basiert (Abbildung 1).

Abbildung 1: Der auf Qemu basierende Emulator lässt auch Entwickler ohne konkrete Hardware-Applikationen für Android entwerfen. Programmierer dürfen sich dazu sogar die konkrete Android-Version aussuchen.

Das unter einer speziellen Android-SDK-Lizenz herunterladbare Kit [1] besteht seit der Version 2.0 aus einem minimalen Programm, das alle benötigten Dateien aus dem Netz nachlädt. Hat der Admin es ausgepackt, startet er es mit »tools/android update sdk«. Ein seit Version 2.0 bestehender Bug verhindert, per SSL auf das voreingestellte Repository zuzugreifen. Der Eintrag »sdkman.force.http=true« in »~/.android/androidtool.cfg« heilt das Problem. Wenn der Entwickler per »Accept all« alle vom Managementtool gezeigten Pakete auswählt, installiert es sie automatisch.

Das Eclipse-Plugin nimmt dem Entwickler viel Handarbeiten ab, führt die Anwendung aus und hilft beim Paketieren. Im Managementprogramm trägt er dazu die Eclipse-Update-Seite [2] im Menü »Help | Software Updates« ein und installiert aus ihr alle Android-Pakete. Sie vereinfachen die Arbeit des Entwicklers, da sie viele Dateien automatisch oder mittels Wizard anlegen, beispielsweise minimale Activities und ihre nötigen Beschreibungsdateien. Um loszulegen, konfiguriert der Entwickler unter »Window | Preferences | Android« des Eclipse-Plugins den Pfad zum vorher ausgepackten SDK.

In dem Menü »Window« findet sich auch der Eintrag »Android AVD Manager«. Dort legt der Programmierer ein neues Android-Virtual-Device (AVD) an, um später seine Applikation auf einzelnen Android-Varianten zu testen. Jedes AVD simuliert abwärtskompatibel bis zur gewählten Version.

Eigene Begrifflichkeiten

Android benennt die Komponenten seiner Applikation auf eigene Weise: Zentral ist die Activity. Sie beschreibt jeweils ein Fenster auf dem Gerät und nimmt den gesamten Bildschirm ein. Sollen sich weitere Fenster öffnen, benötigt der Programmierer neben der Haupt-Activity noch weitere. Den Entwurf der grafischen Oberfläche einer Activity legt der Programmierer deklarativ in einem XML-Dokument fest. Das ist zwar eine Härte für den Entwickler, aber eine kleinere Zumutung, als das Layout der Oberfläche komplett in Java zu spezifizieren. Der notwendige Code ist dadurch leserlicher als in Swing.

Der vom Eclipse-Plugin mitgelieferte Designer hilft dem Entwickler zwar, eine grobe Vorgabe des GUI zu entwerfen, letztlich verfeinert er diese dann im XML aber doch von Hand. Projekte wie Droid Draw haben dagegen einen etwas größeren Funktionsumfang [3].

Zum Leben erweckt

Mit Eclipse legt der Programmierer im Menü »File | New Project« schnell ein neues Android-Projekt an, das neben der ersten Mini-Activity auch die Meta-Informationsdateien enthält. In Abbildung 2 wählt der Entwickler »HelloLM« als Projektname und den API-Level. Das ist minimal die benötigte Android-Version für die Anwendung. Version 1.6 reicht oft aus, da die meisten Geräte sie zurzeit unterstützen. Als Paketname erwartet das Plugin einen Standard-Java-Paketnamen, etwa »de.linuxmagazin.hellolm«. Zum Schluss gibt der Programmierer »MainActivity« als Activity an, die das Hauptfenster realisiert.

Abbildung 2: Bei einem neuen Projekt legt der Entwickler den Namen, API-Level, Java-Paketnamen sowie die Version des Android-API fest. Auf diese Weise testet er, ob seine App auf den verschiedenen Geräten am Markt korrekt läuft.

Die generierte Datei »AndroidManifest.xml« des Projekts enthält ihren Paketnamen, Anwendungsnamen, Berechtigungen und Ähnliches. Das GUI des Hauptfensters beschreibt »res/layout/main.xml« und in »gen/« liegen die von der Toolchain automatisch generierten Klassen, die eine Brücke zwischen deklarativem GUI und Java-Code bilden.

Um sein Hauptfenster zu gestalten, editiert der Entwickler dessen XML-Beschreibung oder nutzt den grafischen GUI-Editor in Eclipse. Tags in XML entsprechen jeweils einem Widget. In Listing 1 stehen zwei »TextEdit«-Elemente über einem »Button«. Das Attribut »text« bestimmt, was auf den Widgets zu lesen ist. Über das Attribut »id« spricht der Programmierer sie im Java-Code an.

01 <?xml version="1.0" encoding="utf-8"?>
02 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
03   android:orientation="vertical"
04   android:layout_width="fill_parent" android:layout_height="fill_parent">
05 <EditText android:text="Vorname" android:id="@+id/vorname"
06           android:layout_width="fill_parent"
07           android:layout_height="wrap_content"></EditText>
08 <EditText android:text="Nachname" android:id="@+id/nachname"
09           android:layout_width="fill_parent"
10           android:layout_height="wrap_content"></EditText>
11 <Button android:text="Kontakt anlegen" android:id="@+id/kontaktanlegen"
12         android:layout_width="fill_parent"
13         android:layout_height="wrap_content"></Button>
14 </LinearLayout>

Google hilft Androiden

Listing 2 implementiert die Klasse »MainActivity«. Ab Zeile 4 baut die Methode »onCreate()« das GUI auf. Die Methode »findViewById()« sucht ab Zeile 8 per Argument »id« die so bezeichneten Widgets aus dem XML-Layout. Die dazu verwendete Klasse »R« hat die Toolchain automatisch generiert. Sie enthält durch das Attribut »id« alle Oberflächenelemente, die der Entwickler in seinem Layout deklariert hat. Klickt ein Anwender auf den Knopf »Kontakt anlegen«, löst Zeile 11 ein Ereignis in einem Listener aus. Die Hilfsmethode »createContact()« deutet an, wie Android mit Daten umgeht. Das Betriebssystem setzt Datenabstraktion über so genannte Content-Provider um. Möchte der Entwickler Daten verarbeiten, bedient er sich am entsprechenden Content-Provider, hier bei demjenigen für Kontakte.

01 public class MainActivity extends Activity {
02    EditText vorname, nachname;
03 
04    @Override
05    public void onCreate(Bundle savedInstanceState) {
06       super.onCreate(savedInstanceState);
07       setContentView(R.layout.main);
08       vorname  = (EditText) findViewById(R.id.vorname);
09       nachname = (EditText) findViewById(R.id.nachname);
10       Button addContact = (Button) findViewById(R.id.kontaktanlegen);
11       addContact.setOnClickListener(new OnClickListener() {
12          public void onClick(View v) { createContact(); }
13         });
14     }
15 
16    protected void createContact() {
17       ContentValues personValues = new ContentValues();
18       String name = vorname.getText() + " " + nachname.getText();
19       personValues.put(Contacts.People.NAME, name);
20       personValues.put(Contacts.People.STARRED, 1);
21       Uri newPersonUri = Contacts.People.createPersonInMyContactsGroup(
22                                   getContentResolver(), personValues);
23     }
24 }

Die Applikation testet der Programmierer aus Eclipse heraus im Emulator, indem er ihn im Kontextmenü des Projektnamens »Run As | Android Application« startet (Abbildung 3). Jede Applikation trägt eine Signatur. Sie dient in der Android-Welt dazu, den Entwickler zu identifizieren und Vertrauensbeziehungen zwischen Applikationen desselben Entwicklers herzustellen. Sie dient aber nicht dazu, zu entscheiden, ob der Anwender sie überhaupt installieren darf.

Abbildung 3: Im Android-Emulator erwartet die Activity der Beispielapplikation Namen und Vornamen, um einen neuen Kontakt anzulegen.

Durch die Anlehnung an Java 5 gibt sich Google Mühe, es jenen Entwicklern leicht zu machen, die die Programmiersprache schon kennen. Gerade das Eclipse-Plugin lässt nur geringe Unterschiede zur Desktop-Entwicklung erkennen. Mit dem Emulator testen Entwickler ihre Anwendungen auch ohne Mobilgerät und dürfen dabei sogar Gimmicks wie den Versand vom SMS zwischen zwei Emulator-Instanzen nutzen.

Marktplatz der Apps

Um ihre Applikation zu vertreiben und im offiziellen Android-Markt anzubieten, investieren Entwickler 25 US-Dollar für einen Zugang. Anschließend führt der Marktplatz die Eigenentwicklung entweder umsonst oder zu einem selbst festgelegten Preis. Üblich sind Preise zwischen einem und fünf Euro. Von jedem Verkauf behalten Google und der Netzbetreiber übrigens 30 Prozent ein.

? Web OS

Web OS ist die jüngste Linux-Mobilplattform. Ungewöhnlich ist der Ansatz von Anbieter Palm, Applikationen Webseiten ähneln zu lassen. Entwickler schreiben sie in einer speziellen Form von HTML, CSS und Javascript. Palm plant auch ein Plugin-Development-Kit herauszugeben, das native Komponenten und Applikationen in C oder C++ erlaubt und Zugriff auf Features wie Open GL ES gewährt. Das dürfte Spiele-Entwickler interessieren und die Portierung bestehender Anwendungen erleichtern.

Palm bietet ein Development-Kit an für mehrere Betriebssysteme, darunter auch als Debian-Paket, und einen Emulator in einer virtualisierten Umgebung an (siehe Abbildung 4). Für sie trägt bei Debian und Ubuntu der Entwickler das zusätzliche Repository

Abbildung 4: Auch Palms Web OS bringt einen Emulator mit. Er setzt auf Virtual Box auf und lässt sich aus dem SDK starten.

deb http://download.virtualbox.org/
virtualbox/debian jaunty non-free

in seine »/etc/apt/sources.list« ein, denn das SDK benötigt die aktuelle offizielle Version ab 3.0 von Virtual Box. Anwender anderer Distributionen oder Ausgaben passen die Paketquelle entsprechend an. Anschließend laden sie per Hand die Pakete »palm-sdk-1.3.5« und »palm-novacom« von der Palm-Webseite [4] und installieren sie mit »dpkg -i«.

Palm hat auch ein Eclipse-Plugin im Angebot, das Sichten, Projekt-Wizards und eine Web-OS-Perspektive bereitstellt. Die Aptana-Webentwicklungs-Plugins installiert, wer Unterstützung bei Javascript und HTML/CSS möchte. Aptana bietet ein komplettes Entwicklungsstudio an, für Web OS benötigen Entwickler aber nur die Eclipse-Plugins [5].

Tools erzeugen Mojo

Der Entwickler legt mit »Project | New« und der Auswahl von »Mojo Application« eine neue Anwendung an, die allerdings noch keine Szenen genannten Interaktionsfenster besitzt (siehe Abbildung 5). Wechselt er auf der Kommandozeile in das Eclipse-Workspace-Verzeichnis, generiert »palm-generate -t new_scene -p “name:first” Eclipse-Projektname« die benötigten Dateien und Einträge für die Szene »first«.

Abbildung 5: Web OS kennt einen Wizard, um ein neues Projekt anzulegen. Die zusätzlich für eine Szene benötigten Dateien legt jedoch ein Tool auf der Kommandozeile an.

Die deklarative Beschreibung des GUI liegt in »views/first«, das zugehörige Javascript, das die Logik implementiert, unterhalb von »assistent/first«. Um GUI-Elemente hinzuzufügen, editiert der Programmierer »first-scene.html«. Neue GUI-Elemente fügt er durch Div-Tags hinzu, deren Attribut »x-mojo-element« das jeweilige Web-OS-Widget bestimmt. Dann wählt er für die drei Widgets in Listing 3 eindeutige IDs und Namen, um sie später aus dem Javascript-Code zu referenzieren. Die ersten beiden sind Textfelder, das dritte ein Knopf, der ihre Inhalte als neuen Kontakt speichert.

01 <div id="main" class="palm-hasheader">
02     <div class="palm-header">LM Adresscontroller
03     </div>
04     <div x-mojo-element="TextField"
05             id="editBox" name="vorname"></div>
06     <br>
07     <div x-mojo-element="TextField"
08             id="editBox" name="nachname"></div>
09 
10     <div x-mojo-element="Button"
11             id="MyButton" name="MyButton1"></div>
12 </div>

Um die Szene mit Logik zu versehen, passt der Entwickler die zum GUI gehörige Javascript-Datei »first-assistant.js« an. Er füllt die Setup-Funktion mit Initialisierungen, richtet mittels »setupWidget()« die Oberflächenelemente ein und fängt mittels »Mojo.Event.listen()« den Knopfdruck ab (siehe Listing 4).

01 FirstAssistant.prototype.setup = function() {
02    this.buttonAttributes = {};
03    this.buttonModel = { "disabled" : false,
04       "label" : "Erstelle Kontakt",
05       "buttonClass" : "" };
06    this.controller.setupWidget("MyButton",
07      this.buttonAttributes, this.buttonModel);
08    Mojo.Event.listen(this.controller
09      .get("MyButton"), Mojo.Event.tap,
10      this.handleButtonPress.bind(this));
11    this.controller.setupWidget("vorname",
12       this.attributes = {
13          hintText: $L('Vorname'),
14             multiline: false,
15             enterSubmits: false, focus: true
16       }, this.vornameModel = {
17             value: "", disabled: false
18    });
19    this.controller.setupWidget("nachname",
20       this.attributes = {
21         hintText: $L('Nachname'),
22         multiline: false,
23         enterSubmits: false, focus: true
24       }, this.nachnameModel = {
25              value: "", disabled: false
26     });
27     Mojo.Event.listen(this.controller
28       .get("MyButton"), Mojo.Event.tap,
29       this.handleButtonPress.bind(this));
30 }

Plattform mit Service

Der Code in Listing 5 fügt dem Telefon einen Kontakt hinzu und orientiert sich dabei am Service-Konzept von Web OS. Auf die vorgestellte Weise ruft der Entwickler Funktionen wie Telefonie und Kontakte auf, die das Web-OS-Framework bereitstellt. Der Code verwendet ab Zeile 6 den Service von Web OS, um einen neuen Kontakt anzulegen. Der Aufruf öffnet eine von der Plattform bereitgestellte neue Szene, die die Eingaben hinzufügt. Sie lassen sich nicht unmittelbar speichern, die Szene ist aber schon mit Vor- und Nachnamen befüllt. Bevor der Anwender im Eclipse-GUI das Projekt simuliert, startet er »palm-emulator« auf der Kommandozeile. Dann wählt er »Run As | Mojo Application« im Kontextmenü des Projektnamens (Abbildung 6).

Abbildung 6: Im Emulator von Web OS leitet die in HTML und Javascript verfasste Anwendung Eingaben per Service-Request an den Kontaktmanager.

01 FirstAssistant.prototype.handleButtonPress = function(event) {
02      var contact = {
03          firstName: this.vornameModel.value,
04          lastName: this.nachnameMod  el.value,
05      }
06      this.controller.serviceRequest("palm://com.palm.applicationManager", {
07          method: "open", parameters: {
08              id: "com.palm.app.contacts", params: {
09                  contact: contact, launchType: "newContact"
10              }
11         }
12 });}

Webentwickler finden sich schnell in Palms Welt zurecht. Der Anbieter betreibt ebenfalls einen Dienst, über den Entwickler ihre Applikationen anbieten dürfen, sodass sich ein Ökosystem um Palms Web OS entwickeln kann. Dies ist für eine begrenzte Zeit noch kostenlos, nach Ablauf der Frist will Palm einen jährlicher Beitrag von run 100 US-Dollar fordern. Open-Source-Projekte erhalten jedoch einen kostenlosen Zugang.

? Maemo 5

Maemo ist Nokias Entwicklungsplattform für die eigene N800- und N900-Reihe. Es basiert auf Linux, ähnelt Desktop-Linux-Distributionen und nutzt sogar die Debian-Paketverwaltung mittels »dpkg« und »ipkg« [6]. Damit gleicht die Entwicklung einer Telefonapplikation der auf dem Desktop. Bislang war GTK+ das Standardframework, um Widgets darzustellen, neuerdings ist zusätzlich Qt erlaubt [7]. Nokia, der neue Besitzer von Qt-Entwickler Trolltech, treibt aber die Migration auf Qt für die Zukunft voran (siehe Abbildung 7).

Abbildung 7: Für die Maemo-5-Oberfläche dürfen Entwickler sowohl mit GTK+ als auch mit Qt programmieren.

Maemo bietet mit Hildon ein eigenes Anwendungsframework, um die grafische Benutzeroberfläche zu nutzen oder um Anwendungen in den Maemo-Desktop zu integrieren. Das Betriebssystem greift weder auf Virtualisierung noch auf Laufzeitumgebungen zurück: Die Applikationen sind daher nativ, sodass die Entwickler Applikationen für jedes Gerät cross-kompilieren müssen.

SDK installieren

Das SDK bringt einen grafischen Installer mit, der die Crosscompiling-Umgebung Scratchbox installiert und Abhängigkeiten auflöst. Voraussetzung dafür ist ein Debian-Paketmanager, da die Installation auf Apt aufsetzt [8]. Der Anwender muss das Skript als Root ausführen, da das SDK nicht unterhalb des Home-Ordners installiert wird, sondern brutal nach »/scratchbox« – unschön. Die Entwicklungsumgebung nutzt den Nested-X-Server Xephyr, um Anwendungen und Maemo-5-Oberfläche darzustellen. Erst startet der Anwender den X-Server und loggt sich danach in die Scratchbox ein:

Xephyr :2 -host-cursor -screen 800x480x16
 -dpi 96 -ac -kb & /scratchbox/login

Die Maemo-5-Oberfläche startet auf dem Xephyer-X-Server mit den Kommandos:

export DISPLAY=:2; af-sb-init.sh start

Um die Anwendung für ein echtes Gerät zu übersetzen, stellt der Programmierer die Scratchbox-Umgebung auf ein anderes Target um, zum Beispiel auf »ARMEL« wie in Abbildung 8. Dann verwendet Scratchbox statt des Compilers für den Host einen für die Zielplattform passenden Crosscompiler. Scratchbox ist ein mächtiges Werkzeug und vereinfacht diesen Vorgang enorm.

Abbildung 8: Die Maemo-Entwicklungsumgebung Scratchbox lässt ihre Anwender unter mehreren Zielplattformen auswählen, für die sie dann cross-kompiliert.

Ein erstes Maemo-Projekt

Auch Maemo präsentiert dem Entwickler ein Adressbuch-API, um auf Kontakte zuzugreifen. Die Freiheitsgrade dieses API sind wie bei den anderen Plattformen groß. Zusätzlich sorgen die Plattform-Entwickler vor und bieten fertige Widgets an. Sie erleichtern die Arbeit mit Kontakten, zeigen Listen an und erfassen oder löschen Einträge per Dialog.

Neue Projekte erfordern zunächst einige Handarbeit: Das Werkzeug Autoconf steuert den Buildprozess für das Übersetzen von C oder C++. Zusätzlich legt der Entwickler eine Debian-konforme Dateistruktur an, um die Anwendung später zur Distribution zu paketieren. Ein Maemo-Tutorial erklärt alle diese Schritte [9] im Einzelnen.

Um ein Projekt anzulegen, loggt sich der Entwickler mittels »/scratchbox/login« in Scratchbox ein und wählt das x86-Target. Die Voreinstellung erkennt er am Kommandoprompt von Scratchbox. Das GTK+-Programm in Listing 6 greift auf das von Maemo bereitgestellte Kontakte-API Abook zurück. Es ist Teil der Libosso, die Dbus-Funktionsaufrufe kapselt und gewisse Persinstenzfunktionen für sie nutzende Anwendungen anbietet. Das Libosso-Abook enthält nicht nur Funktionen, um mit Kontakten zu arbeiten, sondern zusätzlich vorgefertigte Widgets, die der Beispielcode verwendet [10]. Die Contact View ab Zeile 12 zeigt eine Liste vorhandener Kontakte an. Die Zeile 18 öffnet einen Dialog, der einen neuen Eintrag anlegt.

01 #include <libosso-abook/osso-abook.h>
02 
03 int main(int argc, char** argv) {
04       osso_context_t *osso_cxt;
05       OssoABookContactModel *default_model;
06       GtkWidget *view, *window;
07 
08       osso_cxt = osso_initialize(argv[0], "1.0", FALSE, NULL);
09       osso_abook_init(&argc, &argv, osso_cxt);
10       window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
11       default_model = osso_abook_contact_model_get_default();
12       view = osso_abook_contact_view_new_basic(HILDON_UI_MODE_NORMAL,
13                                                default_model);
14 
15       gtk_container_add(GTK_CONTAINER (window), view);
16       gtk_widget_show(view);
17       gtk_widget_show(window);
18       osso_abook_add_contact_dialog_run(GTK_WINDOW(window));
19       gtk_main();
20 }

Maemo-Entwickler nutzen die GCC, um ihre Apps zu kompilieren. Das Werkzeug »pkg-config« steuert dabei die Liste der benötigten Bibliotheken und Compiler-Flags bei:

gcc -o abook_list $(pkg-config --cflags
 --libs libosso-abook-1.0) abook_list.c

Um das Beispiel auszuführen, kopiert der Entwickler die Desktop- und Dbus-Dateien von Hand nach »/usr/share/applications/hildon« beziehungsweise »/usr/share/dbus-1/services«. Die ausführbare Datei gehört nach »/usr/bin«. Wer für komplexere Applikationen Autoconf verwendet, darf auf diese Schritte verzichten und stattdessen auf »make« und »make install« zurückgreifen. Die Anwendung startet aus dem Menü in der linken oberen Ecke heraus (siehe Abbildung 9).

Abbildung 9: Das Maemo-Programmierbeispiel läuft im Nested-X-Server Xephyr.

Maemo belohnt viel Mühe

Maemo 5 bietet dem Entwickler den höchsten Freiheitsgrad, aber auch die höchsten Einarbeitshürden. Applikationen dürfen aktuell GTK oder Qt als Toolkit verwenden. Als Programmiersprachen sind C, C++ und Python einsetzbar. Für alle gibt es Bindings für die Oberflächengestaltung und zu APIs weiterer Komponenten. Wer sich darum selbst kümmert, dem ist es theoretisch möglich, beliebige Programmiersprachen zu verwenden. Maemo ähnelt einem Desktop-Linux mehr als seine beiden Konkurrenten Android und Web OS – mit allen Vor- und Nachteilen. Um die Werkzeuge produktiv einzusetzen, bedarf es schon einer gehörigen Portion Einarbeitung und Kenntnissen beim Crosscompiling.

Für Symbian entwickeln

Der EPOC-Nachfahre Symbian läuft auf einer ganzen Reihe von Smartphones. Viele davon stammen vom finnischen Telefongiganten Nokia, dem die Rechte am mobilen Betriebssystemkern heute gehören. Darauf setzen mehrere UI-Bibliotheken auf, heute dominiert von S60. Im Zuge der Freigabe von Symbian als Open Source Anfang Februar 2010 [11] ist Qt zwar ebenfalls im Gespräch, zurzeit müssten Entwickler jedoch die kompletten Bibliotheken selbst paketieren und ihren Anwendungen mitliefern. Keine der UI-Bibliotheken gibt unmittelbaren Zugriff auf die Plattform selbst, sodass sich Entwickler in jedem Fall auch mit den Symbian-APIs beschäftigen müssen. Auch vor der Freigabe des Code war es so möglich, spezifische Geräteeigenschaften zu nutzen, aber Entwickler erhoffen sich von der neuen Situation vor allem mehr Einblick in die Implementierung von APIs, für die bislang Dokumentation fehlte. Dazu schreiben Programmierer Code in C++. Frühere Symbian-Versionen erforderten einen Dialekt der Sprache, der Speicherzugriffe und Fehlerbehandlung anders notiert. Das rührt noch aus Zeiten, in denen C++ Ausnahmen noch nicht einheitlich implementiert hatte. Heute lösen plattformspezifische Makros dieses Problem, die Entwickler nutzen sollten, wollen sie konform zu den Symbian-APIs bleiben. Alternativ bietet Symbian Java ME als Plattform an, das viel weniger Eigenarten als das spezielle C++ aufweist und auch auf vielen weiteren Geräten läuft, auch auf den weniger leistungsfähigen Feature Phones. Das erkaufen sich vornehmlich Spiele-Entwickler durch etwas weniger Leistung und sehr generische APIs, die große Komitees verabschieden. Neuere Symbian-Modelle enthalten Flash-Lite-Laufzeitumgebungen, auch Python-Bindings sind in einem Zusatzpaket zu haben – praktisch für das Rapid Prototyping, aber für den Produktionseinsatz oft ungeeignet. Linux-Patches fürs offizielle SDK Wer nativ für Symbian entwickeln möchte, sieht sich SDKs, IDEs und Emulatoren gegenüber, deren Hersteller primär für Windows entwarfen. Martin Storsjö (siehe Abbildung 10), der für das Unternehmen Bambuser Live-Videostreaming-Software entwirft, betreut jedoch die Linux-Tools Gnupoc. “Sie bestehen aus einem Satz Patches für die offiziellen Symbian-SDKs, da uns ihre Lizenz bislang Änderungen und das Weiterverteilen verbot”, erläutert der Maintainer. Abbildung 10: Martin Storsjö programmiert für das finnische Unternehmen Bambuser Live-Videostreams für Mobiltelefone. Er betreut Linux-Tools für die Symbian-Entwicklung. Entwickler, die sich mit den Symbian-Spezialitäten bereits auskennen, erhalten mit Gnupoc Kommandozeilenwerkzeuge, mit denen sie ihren Code übersetzen können und die auch – anders als andere Linux-Ansätze – Projektdateien von Windows ohne Modifikationen verarbeiten [12]. “Anfangs liefen viele Tools unter Wine, mittlerweile haben wir sie neu geschrieben oder greifen auf alte Open-Source-Versionen zurück”, berichtet der Mobil-Entwickler. Native Tools, Emulator per Wine Gnupoc enthält keinen Emulator, ältere Windows-Versionen laufen jedoch unter Wine. Meist prüfen Symbian-Entwickler aber ihren Code direkt auf dem Gerät. “Die Werkzeuge bieten nicht den gleichen Komfort wie ihre Windows-Pendants”, gibt Storsjö zu, weist aber auf erfahrene Programmierer als Zielgruppe hin, die froh um eine Kommandozeilenversion sind. Die Website des Projekts enthält knappe, aber vollständige Installationsanweisungen und Links auf alle benötigten Dateien in Abhängigkeit vom Ziel-SDK. Wer die Skripte zum Übersetzen der Build-Tools und zum Extrahieren und Patchen des SDK ausführt, kann damit fast jedes Symbian-Projekt übersetzen, sofern es keine kleineren Probleme mit der Groß- und Kleinschreibung gibt. Auf diese Weise lässt sich beispielsweise das Hallo-Welt-Beispiel übersetzen und ausführen. (Nils Magnus)

Die vorgestellten Mobilplattformen könnten aus Entwicklersicht unterschiedlicher nicht sein. Während Maemo die Entwicklung von nativen Applikationen vorsieht, führt Android in seiner Dalvik genannten optimierten Java-VM alle Applikationen virtualisiert aus (eine Ausnahme ist JNI). Palm macht es den Webentwicklern so angenehm wie nur möglich und lässt sie Applikationen in HTML, CSS und Javascript entwickeln. Alle Plattformen haben aber eins gemein, dass es nie einfacher war, Applikationen für Mobilgeräte zu entwickeln.

Gerade Android und Web OS stecken voller Details, um dem Entwickler die Möglichkeit zu geben, auf Telefonie-Funktionen sowie PIM-Daten und Gerätehardware wie Location-Services zuzugreifen. Auf konkrete Endgeräte kann der interessierte Entwickler sogar verzichten, da ausreichend Emulationssoftware zur Verfügung steht. (mg)