Android-Entwicklung jenseits von Google

Inhaltsverzeichnis

Android-Entwickler haben sich tendenziell mit einem Duopol abgefunden: Wer nicht mit Googles Werkzeugen arbeitet, schreibt seine Apps stattdessen mit PhoneGap. Es gibt jedoch noch einige andere Tools, die App-Entwickler mit neuen Möglichkeiten versorgen.

Aus didaktischen Gründen seien die vorgestellten Werkzeuge in drei Gruppen unterteilt. Zuerst wird ein Blick auf klassische Entwicklungsumgebungen geworfen, die manchen Entwicklern vom Desktop her bekannt sein dürften. Spieleentwickler greifen schon lange auf spezielle IDEs zurück, deren Funktionsumfang auf das Realisieren von Games und Animationen optimiert ist. Diese Werkzeuge bringen diverse Erweiterungen wie eine 3D-Engine mit. Im Laufe der letzten Monate haben einige Anbieter ihr Augenmerk auf den Mobilmarkt gerichtet.

Schließlich werden IDEs berücksichtigt, die auf die Entwicklung von Applikationen für Smartphones optimiert sind. Eine damit realisierte Applikation lässt sich oft nicht ohne Weiteres auf den Desktop bringen – der schnellere Entwicklungsprozess amortisiert diesen Nachteil jedoch in vielen Fällen.

Die großen Klassiker

Einige Entwicklungsumgebungen gibt es schon seit gefühlt einer Ewigkeit. Aufgrund der zunehmend größer werdenden Popularität von Android werden sie mittlerweile Schritt für Schritt um Unterstützung für Googles Betriebssystem erweitert.

Xamarin – .NET auf Abwegen

Microsofts Marketingabteilung sah .NET anfangs als Marketingwerkzeug. Das bedeutet, dass die Spezifikation der als Basis dienenden MSIL zwar offen war – einen Interpreter samt Bibliotheken gab es indes nur für hauseigene Betriebssysteme.

Ein als Mono bezeichnetes Projekt versuchte sich erfolgreich an der Implementierung eines quelloffenen Interpreters, der in MSIL gehaltene Programme ausführte. Nach mehreren Eigentümerwechseln landete das Produkt bei Xamarin, wo es auf iOS und Android portiert wurde.

Microsoft kündigte im Dezember 2014 an, Teile des hauseigenen Interpreters zwecks Vereinheitlichung der Plattform als Open-Source-Code anzubieten. Noch ist nicht abschätzbar, wie sich diese Änderungen auf Xamarin auswirken. Eindeutiger ist, dass sich Xamarins hauseigenes Produkt mit der vor wenigen Monaten erschienenen Version 3.0 stark veränderte. Die IDE beschränkte sich bisher darauf, Entwicklern einen Wrapper für die existierenden APIs von Android und iOS anzubieten.

Als Beispiel dafür sei ein Blick auf eine aus dem Projektskelett entnommene Routine geworfen:

protected override void OnCreate (Bundle bundle) 
{ 
    base.OnCreate (bundle); 

    // Set our view from the "main" layout resource 
    SetContentView (Resource.Layout.Main); 
       // Additional setup code will go here 

   } 
   SetContentView (Resource.Layout.Main); 
} 

Android-Entwickler merken sofort, dass sie es hier mit der nativen, von Google spezifizierten API zu tun haben. Der einzige relevante Unterschied liegt darin, dass die Funktionen nun mit C# angesprochen werden.

Die dritte Version von Xamarin bietet mit Xamarin.Forms einen plattformunabhängigen GUI-Stack an, der aber keinen WYSIWYG-Editor enthält. Anwender erhalten 19 Steuerelemente, die in einer Gruppe von Layouts einbaubar sind.

Xamarin ist allerdings alles andere als preiswert. Pro Plattform und Entwickler fällt eine Lizenzgebühr von knapp 1000 US-Dollar an – beim gemeinsamen Kauf von Android und iOS gibt es oft kleine Sonderrabatte.

Qt – seit Jahren bewährt

Nokias Niedergang hatte kaum einen Einfluss auf die Geschicke des Cross-Plattform-Frameworks Qt – zu groß war die Zahl der am Weiterbestehen des Produkts interessierten Stakeholder, und schließlich gingen die Rechte an Digia. Das Framework wird als Lösung für alle Fragen im Bereich der Entwicklung von Cross-Plattform-Applikationen positioniert: Es gibt einen GUI-Stack, eine IDE und ein Build-System, die für alle Plattformen gleichermaßen zur Verfügung stehen. Eine nur auf Qt-Elementen basierende Applikation funktioniert – zumindest in der Theorie – auf allen unterstützten Betriebssystemen: In der Praxis sind manchmal minimale Änderungen erforderlich.

Bei korrekter Anwendung der Werkzeuge können Entwickler mit nativen Elementen versehene Applikationen realisieren, ohne dabei auf die IDE des Plattformanbieters zugreifen zu müssen. Das wird durch ein als qmake bezeichnetes Werkzeug realisiert. Es nimmt .pro-Dateien entgegen, die die Projektstruktur beschreiben. Ihr prinzipieller Aufbau sei durch folgendes Beispiel demonstriert:

QT       += core gui 
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets 

TARGET = GarterCarlo 
TEMPLATE = app 

SOURCES += main.cpp\ 
        mainwindow.cpp 

HEADERS  += mainwindow.h 

FORMS    += mainwindow.ui 

.pro-Dateien dienen als eine Art "Index", der alle im Projekt enthaltenen Quelldateien samt eventuell notwendigen plattformspezifischen Einstellungen auflistet. qmake nimmt die Datei entgegen und wandelt sie in für das native Kompilierwerkzeug verständliche Makefiles um. Diese erledigen die eigentliche Kompilierung danach im Alleingang. Da qmake die Quellcode-Dateien nicht verändert, lässt sich nativer Code in durch den Präprozessor abgesicherte "Codeinseln" verpacken. Als Beispiel dafür sei die folgende Passage herangezogen, die die Nutzung der Symbian-Sound-APIs illustriert:

QtBallZ::QtBallZ(QWidget *parent) 
    : QMainWindow(parent) 
{ 
        ui.setupUi(this); 
     
    // lock orientation ? S60 code 
    CAknAppUi* appUi = dynamic_cast<CAknAppUi*>(CEikonEnv::Static()
          ->AppUi()); 
    if(appUi){ 
        QT_TRAP_THROWING(appUi ->SetOrientationL( 
          CAknAppUi::EAppUiOrientationLandscape)); 
    } 

// some more Qt code 

    ApplicationPrefs::initPrefs(); 
    this->showFullScreen(); 
     
        myTimerID=startTimer(75); 
} 

Als Argument gegen Qt ist die Fragmentierung der Plattform anzuführen. Entwickler können ihre Applikationen mit drei verschiedenen GUI-Stacks realisieren. Die seit jeher verfügbaren Widgets (ehemals QtGUI) werden mit einem leistungsfähigen WYSIWYG-Designer ausgeliefert und sind zur Darstellung großer Datenmengen geeignet. Das neuere QML ist eine Art "JavaScript für GUIs", das seine Stärken bei Animationen ausspielen kann. Widgets und QML lassen sich miteinander mischen: Es ist problemlos möglich, ein QML-Skript in ein per Widgets realisiertes Formular einzubinden.

Für BlackBerry steht mit Cascades zudem ein dritter und mit nichts anderem kompatibler GUI-Stack zur Verfügung. Seine Nutzung verbietet das Verwenden von QML oder Widgets, da er einen komplett anderen Rendering-Pfad voraussetzt.

Die Qt-Varianten für Mobilgeräte sind teilweise nur im Rahmen einer kommerziellen Lizenz erhältlich. Die Preise beginnen hier bei rund 20 Euro im Monat.

Interpreter-Ansatz mit NS Basic

Bei NS Basic (NS = Nice and Simple) handelt es sich um eine vage an Visual Basic angelehnte Programmiersprache, mit der sich durch einen Interpreter auszuführende Applikationen realisieren lassen. Der Intepreter wurde anfangs für Palm OS, Windows CE und den Desktop angeboten. Im Laufe der Zeit ersetzte der Hersteller die Laufzeitumgebung durch ein auf diversen Webstandards aufgebautes System. Die im folgenden Snippet illustrierte Syntax wird vor der Ausführung in JavaScript umgewandelt und mit den im WYSIWYG-GUI-Designer zusammengestellten Formularen kombiniert:

Sub cmdAdd_onclick() 
  Dim FirstNumber 
  Dim SecondNumber 
  Dim Total 

  FirstNumber  = CSng(txtFirstNo.value) 
  SecondNumber = CSng(txtSecondNo.value) 
  Total = FirstNumber + SecondNumber 

  txtTotal.value = Total 
End Sub 

Das Intermediärkompilat basiert auf verbreiteten Bibliotheken wie PhoneGap und diversen jQuery-Derivaten. Dank ihrer breiten Kompatibilität sind die resultierenden Applikationen auf so gut wie jedem Computersystem lauffähig – es muss "nur" Webapps ausführen können.

NS Basic ist eine der preiswertesten IDEs in dieser Untersuchung. Die Einzellizenz bekommen Entwickler normalerweise für weniger als 200 US-Dollar; Supportverträge haben vergleichsweise "humane" Preise.

Delphi – es orakelt weiter

Die von Borland initiierte IDE Delphi wird nach wie vor weiterentwickelt – seit einigen Jahren unter den Fittichen von Embarcadero. Wie schon früher dürfen Entwickler immer noch auf einen WYSIWYG-Editor zurückgreifen, der die Realisierung der Benutzerschnittstelle ohne aufwendige Codierung ermöglicht. Eine als FireDAC bezeichnete Datenabstraktionsschicht sorgt dafür, dass Zugriffe auf Datenbanken verschiedener Hersteller über ein einheitliches Interface erfolgen.

Die Nutzung von Delphi ist dabei gar nicht verpflichtend. Embarcadero unterstützt C++ seit Jahren mit dem C++Builder; die derzeitige Version sorgte für "Sprachparität" zwischen Android und iOS. Die Angebote von Embarcadero lohnen sich insbesondere dann, wenn man bereits mit den Entwicklungsumgebungen des Herstellers aufgewachsen ist. Die Cross-Plattformunterstützung ist mit dem anderer Anbieter gebotenen vergleichbar; der Einsatz von FireDAC spart mitunter viel Zeit.

Wer existierenden Code weiterverwenden möchte, muss ihn an das LLVM-Backend anpassen. Der Grad der notwendigen Änderungen ist von der inneren Architektur einer Applikation abhängig. Strings sind die häufigste Ursache für Fehler, da etliche Klassen (WideString, AnsiString, ShortString, AnsiChar, PansiChar, PwideChar und OpenString) mittlerweile abgekündigt wurden. Portierungswillige Entwickler finden im Embarcadero-Wiki weitere Informationen zum Thema.

Embarcaderos RAD Studio, in dem Delphi und C++Builder konfektioniert sind, ist alles andere als preiswert. Die Version mit dem geringsten Funktionsumfang kostet ohne FireDAC rund 2500 Euro pro Entwickler, Upgrades werden mit 1350 Euro verrechnet. Die Nutzung der hier angebotenen Recharge-Option mag bei der Kostenreduzierung hilfreich sein.