6 Gründe für native Android-Entwicklung

Auch 2016 war wieder ein Wachstumsjahr für den Bereich der mobilen Geräte. Die Betriebssysteme Android und iOS erreichen zusammen eine 99,3-prozentige Abdeckung im Markt.

Es klingt daher vernünftig, Apps plattformübergreifend zu entwickeln und gewisse Bestandteile der Anwendung wiederzuverwenden. In diesem Post folgen anhand der Erfahrungen mit der Plattform Xamarin.Android ein paar Gründe, warum das möglicherweise nicht so eine gute Idee ist.

Über Xamarin.Android

Der Ansatz der Xamarin.Android-Plattform ist erst einmal vielversprechend. Die Kombination einer Sprache wie C# mit einer plattformübergreifenden Managed Runtime (Mono) verspricht, dass sich Entwickler mehr darauf konzentrieren können, Features zu produzieren, anstatt den Code einer getrennten Android- und iOS-Implementierung zu pflegen.

Einerseits ist es die Programmiersprache, die einige Besonderheiten von Java bzw. Android über Sprachkonstrukte abbilden kann (z.B. Manifest-Generierung über Annotationen, implizite Casts über generische Methoden, Hintergrund-Threads über das async-Keyword). Andererseits besteht die Möglichkeit, plattformunabhängigen Code zu produzieren und diesen in nativen Apps für Android, iOS und Windows Phone wiederzuverwenden.

Leider hat der Ansatz auch ein paar Nachteile, die mich dazu bewegt haben, meine Versuche in diese Richtung wieder aufzugeben und zu reiner Java-Entwicklung für Android zurückzukehren. Dieser Blog-Beitrag ist daher also nicht mit einem Rant gegen Hybrid-Entwicklung zu verwechseln, sondern mit einem Plädoyer für Vanilla Android.

Grund 1: Das umfangreiche Ökosystem nativer Libraries

Es gibt mittlerweile ein riesiges Angebot an Libraries für Android, sowohl neue als auch etablierte Libraries, die um Android-Unterstützung ergänzt wurden. Leider nur ein kleiner Teil davon wird auch nach C# portiert bzw. in NuGet-Packages für die Xamarin Plattform konvertiert.

Grund 2: Der direkte Support durch Google

Die Community und der Herstellersupport um Android ist natürlich ungleich umfangreicher als bei Xamarin. Bugs zu Android können über den Bugtracker (https://source.android.com/source/life-of-a-bug.html) eingestellt und diskutiert werden.
Neueste Android SDK-Versionen sind sofort verfügbar und müssen nicht portiert werden, wie es bei Xamarin.Android der Fall ist.

Bei Fehlern mit Xamarin.Android erübrigt sich das altbekannte Ping-Pong-Spiel, ob jetzt die Mono-Runtime oder Android verantwortlich ist.

Grund 3: Stackoverflow AKA developer love

Stackoverflow ist *die* Quelle für Problemlösungen in der IT. Aktuell (Stand 27.12.2016) gibt es 931,615 Fragen, die mit Android getaggt wurden, dagegen nur 18,590 Xamarin-Fragen.

Grund 4: Android Studio

Seit Google auf die IntelliJ-Plattform gewechselt ist und Android Studio anbietet, hat diese Entwicklungsumgebung stark an Qualität gewonnen. Obwohl ich normalerweise Intellij IDEA nutze und es auch dafür das Android-Plugin gibt,
nutze ich Android Studio separat, weil es so gut für den Usecase Android-Entwicklung abgestimmt ist.

Meine Lieblingsfeatures sind:

• der ausgesprochen gute Layout-Designer
• umfangreiche Lint-Regeln für Code- und Layout-Optimierung
• Instant Run

Grund 5: Werkzeuge

Die Werkzeuge rund um das Android SDK sind sehr gut in Android Studio integriert, außerdem wird das einheitliche, transparent beschriebene, erweiterbare Buildsystem Gradle mit Unterstützung der äußerst umfangreichen Maven-Repositories verwendet.
Die Produktivität als Entwickler ist sehr gut, da alles in die IDE integriert ist und gut miteinander harmoniert.

Außerdem: Android Studio gibt es für Windows und macOS. Bisher musste Xamarin.Android unter macOS mit Xamarin Studio, unter Windows mit Visual Studio entwickelt werden. Das soll sich aber bald ändern: https://www.visualstudio.com/vs/visual-studio-mac/

Grund 6: Start-Zeit und Größe der App

Xamarin.Android-Apps benötigen eine Mono-Runtime, um den in C# geschriebenen Code ausführbar zu machen. Diese Runtime wird aber im Gegensatz zur JVM unter Android erst hochgefahren, wenn die Xamarin.Android-App gestartet wird. Dies verursacht gerade während der Entwicklung im Gegensatz zu Android Studios Instant Run immer etwas längere Wartezeiten.

Da die Mono-Runtime und Teile von Mono.Android in der App gebündelt wird, ist die App auch immer größer , als eine reine Android-App.

Zum Ende

Einige der hier aufgeführten Gründe sind natürlich persönlicher Geschmack. Ich glaube aber, dass native App-Entwicklung auf lange Sicht weniger Kosten verursacht, als allgemein angenommen wird. Welche Erfahrungen habt ihr mit Xamarin und Android gemacht? Hinterlasst gerne einen Kommentar!