Logo von Developer

Suche
preisvergleich_weiss

Recherche in 2.383.371 Produkten

Simon André Scherr, Steffen Hupp, Patrick Mennig 16

Erfahrungen aus der Cross-Plattform-Entwicklung mit Xamarin, Teil 1: Apps und Frameworks

Erfahrungen aus der Cross-Plattform-Entwicklung mit Xamarin, Teil 1: Apps und Frameworks

Die Cross-Plattform-Entwicklung verspricht hauptsächlich für mobile Betriebssysteme viel: Code nur einmal schreiben und auf verschiedenen Plattformen nutzen. Der Auftakt eines Artikeldreiteilers zu Xamarin gibt Überblick über die verschiedenen Ansätze und Entscheidungshilfen für die Auswahl eines geeigneten Frameworks.

Die Frage nach Cross-Plattform-Entwicklung für mobile Betriebssysteme ist so alt wie die verschiedenen Plattformen selbst. Der Wunsch, mit nur einer Codebasis und minimalen Änderungen mehrere Zielplattformen bedienen zu können, ist verlockend. Die Alternative ist, für jede Zielplattform eine separate Applikation in der Programmiersprache der jeweiligen Plattform zu erstellen und zu pflegen.

Xamarin ist ein Framework für die Cross-Plattform-Entwicklung. Aber was genau ist Cross-Plattform-Entwicklung überhaupt? Welche Frameworks gibt es außer Xamarin noch? Wie funktioniert die Entwicklung mit Xamarin, und welche Vor- und Nachteile hat das für Entwickler? Diese und andere Fragen beantworten drei Artikel zur Cross-Plattform-Entwicklung mit Xamarin und Xamarin.Forms.

Erfahrungen aus der Cross-Plattform-Entwicklung mit Xamarin

Das moderne App-Zeitalter

Apples iPhone hat das Zeitalter der Smartphones eingeläutet, und obwohl Android schon länger den Markt der mobilen Betriebssysteme bei Smartphones dominiert, müssen sich Entwickler weiterhin vielen Herausforderungen stellen. Nutzer erwarten von den Apps auf ihren Geräten viel. Klare, einfach zu bedienende und schicke User Interfaces (UIs) gehören bereits lange zum guten Ton.

Dabei hat jedes Betriebssystem seine eigenen Paradigmen, etwa der Zurück-Button unter Android, der auf iOS vollständig fehlt. Die Bildschirmgrößen und Pixeldichten sind so verschieden wie die verfügbaren Geräteklassen, auf denen Apps verfügbar sind (z. B. Smartphones, Phablets, Tablets, Smart-TVs, Set-Top-Boxen, TV-Sticks ...). Die Geschwindigkeit der (Grafik-)Prozessoren unterscheidet sich ebenso wie die Menge an Arbeitsspeicher. Hardwarefeatures wie Gyroskope, Kameras oder Mikrofone diversifizieren die Geräte weiter. Gleichzeitig ist es für manche Klassen von Anwendungen wie Musik- oder Videostreaming-Dienste unerlässlich, auf fast allen Geräten verfügbar zu sein.

Da ist das Versprechen der Cross-Plattform-Entwicklung, nur eine Code-Basis pflegen zu müssen und Anwendungen auf viele Plattformen bringen zu können, verlockend. Denn erfahrene Entwickler sind Mangelware und Teams notorisch unterbesetzt sowie unter Zeitdruck.

Beispiel Facebook

Schon früh in der Geschichte mobiler Betriebssysteme wurden verschiedene Ansätze der Cross-Plattform-Entwicklung präsentiert und versprachen Abhilfe. Am Beispiel der Facebook-App lässt sich viel über Cross-Plattform-Entwicklung lernen. Angefangen hat das erfolgreichste soziale Netz 2004 als Webseite für Studierende der Universität Harvard. Drei Jahre später folgte eine angepasste Version der Seite für Handys und eine weitere für das erste iPhone. Die Facebook-Webseite war das Produkt der jungen Firma und die Eigenheiten der mobilen Endgeräte wurden über eine spezifische Sicht auf die Webseite abgefangen. Als Apple 2008 den App Store für externe Entwickler freigab, veröffentlichte Facebook eine App für das damailge iPhone OS. Erstellt war sie mit dem nativen, also speziell für diese eine Plattform entwickelten iPhone OS SDK.

Kaum zwei Jahre gingen ins Land, bis Facebook 2010 seine Web-App auf Android und iOS veröffentlichte. Das Ziel des sozialen Netzes war es, so viel Code wie möglich zwischen iOS und Android wiederzuverwenden, um so schnelle Iterationen zu ermöglichen und eine einheitliche Nutzererfahrung auf allen Plattformen sicherzustellen. Die App war jedoch langsam, träge, stürzte häufig ab und Nutzer, die an die Designsprache ihrer jeweiligen Plattform gewöhnt waren, empfanden die Bedienung der App als mühselig.

2011 versuchte Facebook mit "Project Spartan", eine eigene Web-basierte Plattform als Gegengewicht zu den App-Stores der mobilen Betriebssysteme zu etablieren. Sie verschwand aber wieder genauso unvermittelt, wie sie gekommen war. Im gleichen Jahr veröffentlichte Facebook eine App speziell für das iPad und separate Apps für den Messenger auf iOS und Android. Die Codebasis und die Komplexität wuchsen.

2012 vollzog Facebook auf einmal eine Kehrtwende und veröffentlichte Versionen seiner App, die zu großen Teilen mit nativen, plattformspezifischen Techniken erstellt wurden. Durch die Nutzung plattformspezifischer Techniken konnte das soziale Netz 2013 mit Facebook Home sogar eine Interaktion ermöglichen, die vollständig nur unter Android funktionierte.

Das Thema Webentwicklung wurde jedoch keinesfalls vernachlässigt, denn im selben Jahr wurde das React-Framework Open Source. Zu diesem Zeitpunkt sprachen Facebook-Entwickler davon, dass sie bereits seit vier Jahren an diesem Tool arbeiteten. Weitere zwei Jahre später veröffentlichte Facebook React Native als Möglichkeit, mit JavaScript-Code native Applikationen zu erstellen. Spätestens 2016 enthielt die Facebook-App Teile, die mit React Native erstellt wurden und damit wieder auf Webtechniken basierten. Facebook selbst nennt diesen Ansatz nicht "write once, run everywhere", sondern "learn once, write everywhere", da seine Entwickler nach eigener Aussage weiterhin für große Teile der Applikationen
plattformspezifischen Code schreiben.

Unterschiedliche Arten der Cross-Plattform-Entwicklung

Das Beispiel zeigt eindrucksvoll verschiedene Facetten der Cross-Plattform-Debatte. Es ist eine Frage der User Experience und des Eingehens auf plattformspezifische Besonderheiten. Aber auch die Wiederverwendung von Code, der Entwicklungs-Workflow, kurze Releasezyklen und die Plattformabdeckung sind wichtige Aspekte. Mit welchen Mitteln lassen sich Cross-Plattform-Anwendungen jedoch umsetzen? Es gibt dafür diverse Cross-Plattform-Frameworks, die sich grob in vier Kategorien einteilen lassen: Low-Code und Generierung, Web, hybrid und nativ.

Low-Code und Generierung umfasst eine breite Klasse von Cross-Plattform-Entwicklungsumgebungen. Dahinter steckt die Idee, auch Nicht-Programmierern einen Zugang zur App-Entwicklung zu ermöglichen, indem viele Details hinter WYSIWYG-Editoren (What You See Is What You Get) versteckt bleiben. Bei Low-Code-Ansätzen können Elemente der Nutzeroberfläche einfach in einem Arbeitsbereich angeordnet und sollen dann auch genauso in der fertigen App angezeigt werden.

Auch die Anbindung an Datenquellen wie an eine Datenbank oder ein CRM-System sind, je nach Produkt, möglich. Des Öfteren sind diese speziell an ein Produkt wie Salesforce gebunden. Die Möglichkeiten, ausgefeilte Apps zu erstellen, sind dabei gering, und Entwickler werden sich von Low-Code-Ansätzen schnell eingeschränkt fühlen. Bestimmte Eigenheiten der Plattformen werden nicht berücksichtigt und Fehler sind teilweise nur schwer nachvollziehbar oder lösbar.

Mithilfe von Web-Frameworks wiederum können Entwickler Webseiten so erstellen, dass sie Apps täuschend ähnlich sehen und sich ebenso verhalten. Die Codebasis bilden Webtechniken, also HTML, CSS und JavaScript. Die Arbeit mit modernen Frameworks wie Angular, React, Ionic oder Sencha Touch hat wenig mit der Entwicklung klassischer Webseiten gemein. Das Tooling ist reifer. Automatisiertes Testen ist ebenso möglich wie Continuous Integration. Dennoch bleibt die Ausführungsumgebung des Codes der Browser-Stack, selbst wenn er sich hinter einem App-Icon verbirgt. Funktionen wie das Aufnehmen von Bildern werden über die APIs der Browser aufgerufen und nur die Funktionen, die von den Browsern der Systeme angeboten werden, lassen sich nutzen. Einen guten Überblick dazu liefert die Webseite "Can I Use".

In eine ähnliche Richtung wie Web-Frameworks gehen hybride Ansätze. Das UI der Anwendung wird mit Webtechniken erstellt, aber über spezielle APIs der Frameworks lässt sich plattformspezifischer (sog. nativer) Code aufrufen. Entwickler können so Teile der Applikationen (hauptsächlich UI und Business-Logik) wiederverwenden. Für Anwendungsfälle, die nativen Code benötigen, können sie aber auch plattformspezifischen Code ergänzen. Bekannte Vertreter dieser Gattung sind beispielsweise PhoneGap oder Appcelerator Titanum.

Die vierte Kategorie der Cross-Plattform-Frameworks sind native Frameworks. Dazu zählt auch Xamarin. Dort schreiben Entwickler Code in einer Sprache (z. B. C++), der dann auf die jeweiligen Zielplattformen kompiliert wird oder sich dort nativ ausführen lässt. So entstehen Anwendungen, die plattformspezifischen Code enthalten, ohne dass Entwickler für jede Plattform den Code separat schreiben müssen.

Dieser Ansatz ist insofern komplex, als dass verschiedene Plattformen Ausführungsumgebungen für unterschiedliche Sprachen bieten. Beispielsweise können sowohl Android als auch iOS C- oder C++-Code ausführen, obwohl Java beziehungsweise Swift (früher Objective-C) die eigentlichen nativen Sprachen der Betriebssysteme sind. Manche Frameworks setzen dabei darauf, sämtlichen Code auf verschiedenen Plattformen gleich zu kompilieren, während andere native UI-Elemente erzeugen und den ursprünglichen Code anderer Code-Teile erhalten. Beispiele hierfür sind Unity oder eben Xamarin.

Welches Framework für wen?

Bei all der Vielfalt der Framework-Arten sowie deren konkreten Umsetzungen stellt sich in einem Entwicklungsprojekt früh die Frage: "Welches Framework nehme ich denn jetzt?" Die Antwort ist leider dieselbe wie immer in der Softwareentwicklung: "Es kommt ganz darauf an." Aufgrund der großen Unterschiede in den Anforderungen der Apps und des Funktionsumfangs der Frameworks ist es weder einfach noch hilfreich, einen Sieger in einem Vergleich zu küren. Die Schnelllebigkeit der mobilen Welt erschwert es, eine absolute Aussage zu treffen. Stattdessen ist es wichtiger, sich über Kriterien Gedanken zu machen, die beim Finden einer Cross-Plattform-Technik für die jeweilige Anwendung oder Anwendungsdomäne helfen können. All diese Frameworks haben ihre Stärken und Schwächen; entscheidend ist jedoch, wie die Kombination aus Stärken und Schwächen mit dem zu entwickelnden Produkt(-portfolio) zusammenpasst.

Für die Evaluierung von Cross-Plattform-Frameworks bieten sich grundsätzlich die Bereiche Funktionalität, Ausführungsgeschwindigkeit, Entwicklungsprozess, Rentabilität sowie Community und Support an.

Beleuchtet man die Funktionalität näher, gilt es herauszufinden, inwieweit ein Framework vertraute UI-Elemente nativer Apps abbilden kann oder das Erstellen wiederverwendbarer Komponenten unterstützt. Je nach intendierter Anwendung ist auch die Frage nach der Integration in Betriebssystem- und Hardwarefunktionen wichtig. Wie gut kann eine Technik gegebenenfalls auf zugrunde liegende Betriebssystemfunktionen zugreifen? Wie leicht lässt sich eine Anwendung erstellen, die auch als Dienst agieren und Aufgaben ausführen kann, wenn sie gar nicht oder allenfalls im Hintergrund geöffnet ist?

Abschließend fällt in diesen Diskussionsbereich die Betrachtung der Hardwareanbindung: Ist eine direkte 3D-Unterstützung gegeben oder nicht? Wie sieht es mit der Integration von Sensoren wie dem Gyroskop aus? Kriterien aus dem Bereich der Funktionalität sind meist entscheidend für ein Produkt. Insbesondere bei den Möglichkeiten zur UI-Gestaltung ist häufig ein Fokus festzulegen. Der Fokus auf Hardwarenähe wiederum spielt nur für bestimmte Anwendungen eine Rolle.

Ähnlich gestaltet es sich mit der Ausführungsgeschwindigkeit. Eine Anwendung, die sich träge anfühlt, werden Nutzer kaum akzeptieren. Inwieweit allerdings eine besonders hohe Ausführungsgeschwindigkeit benötigt wird, hängt wiederum stark vom Produkt ab. Vielen Apps gemein ist, dass sie häufig nur für kurze Zeit benutzt werden und in dieser Zeit auf den Nutzer reagieren müssen. Daher sind Startzeiten und Reaktionsgeschwindigkeit wichtige Aspekte bei der Auswahl des Frameworks. Wie gut komplexe Inhalte oder Animationen verarbeitet werden oder nicht, spielt wiederum nur für bestimmte Anwendungen eine Rolle. Hinzu kommt, dass Cross-Platform-Frameworks eine gute Ausführungsgeschwindigkeit auf allen
Zielplattformen bieten sollten.

Schnelligkeit und Rentabilität

Verschiebt man den Fokus von der Benutzung hin zur Entwicklungszeit, gibt es dort ebenfalls zahlreiche Möglichkeiten, sich einen Überblick zu verschaffen. Beispielsweise sollte die vom gewählten Framework verwendete Programmiersprache zu den Fähigkeiten des Teams passen. Auch die Frage nach dem Reifegrad der Werkzeuge zur Entwicklung ist von essenzieller Bedeutung. Wie gut unterstützen etablierte Entwicklungsumgebungen ein Framework? Wie gut lässt sich eine CI-Pipeline realisieren? Ist Debugging und Profiling schlecht umgesetzt oder gibt es ausgefeilte Tools? Wie reif sind die verfügbaren Frameworks zur Testautomatisierung? Insbesondere bei den beiden letzten Fragen spielt aufgrund der Fragmentierung der mobilen Gerätewelt auch die Frage nach Cloud-basiertem Testen eine Rolle.

Bei der Betrachtung der Rentabilität sind vor allem Untersuchungen wie die Frage nach der Langlebigkeit der Techniken wichtig. Hier spielt vor allem der Reifegrad eine Rolle. Ist ein Framework noch so neu, dass es sich potenziell im Wochenrhythmus stark ändert, ist ein langlebiges Projekt kaum realisierbar. Hingegen ist die Frage nach der Unterstützung von Funktionen neuerer Betriebssystemversionen wieder nur für bestimmte Anwendungen relevant.

Vor allem in der Einstiegsphase und bei komplexeren Projekten ist die Verfügbarkeit einer starken Community sowie eines guten Technik-Supports wichtig. Wie einfach sind Entwickler für dieses Framework zu finden? Wie leicht lassen sich Schulungen für die Entwickler organisieren? Wie viele Informationen finden sich für die Techniken im Internet? Gerade für Letzteres hilfreich sind Seiten wie Stack Overflow, die sehr gut das Interesse der Entwicklerwelt an einer Technik verdeutlichen.

All diese Fragen sind lediglich Denkanstöße für das eigene Produkt, die man näher untersuchen muss. Das Entwicklerteam sollte so früh wie möglich in die Entscheidungsfindung eingebunden sein. Hierbei fällt dem Requirements Engineering die besondere Rolle zu, zwischen der langfristigen Vision des Unternehmens, den Zielen des Produktmanagements und den Anforderungen der Entwickler zu vermitteln. Erst wenn eine klare Vorstellung des zu entwickelnden Produkts (der App) herausgearbeitet und die Bedürfnisse der Nutzer erörtert wurden, kann eine Analyse der Cross-Plattform-Frameworks in den oben genannten Bereichen erfolgen. Dann kann das Team gemeinsam eine fundierte Entscheidung treffen und gegebenenfalls um weitere Mitglieder ergänzt werden, um die Entwicklung zu starten.

Fazit

Die Cross-Plattform-Entwicklung bietet viele Vorteile. Selbst große Anbieter wie Facebook sind jedoch bei der Entwicklung ihrer Produkte zwischen plattformspezifischer und plattformübergreifender Entwicklung hin und her gependelt. Das zeigt ganz klar die Bewegung in diesem Thema.

Ein Vertreter der Cross-Plattform-Welt, der in letzter Zeit ganz besonders im Fokus steht, ist Xamarin von Microsoft. Die Autoren haben für die Entwicklung verschiedener Apps, die das Leben in ländlichen Regionen Deutschlands lebenswerter gestalten sollen, Xamarin als Cross-Plattform-Framework ausgewählt. Dabei haben sie immer wieder Rückschläge erlebt und mussten lernen, mit den Stolperfallen der Cross-Plattform-Entwicklung umzugehen.

In den nächsten beiden Teilen dieser Artikelserie wird Xamarin näher betrachtet. Es geht dann um seinen Aufbau und seine Funktionsweise, außerdem werden die Autoren Einblicke in den Entwicklungsablauf geben. (ane)

Simon André Scherr
ist seit über sechs Jahren im Bereich mobile Software Engineering mit Fokus auf User Experience unterwegs. Neben der Organisation von Entwicklungsprojekten im mobilen Bereich ist sein derzeitiger Schwerpunkt die Einbezugnahme des Nutzers in die schnelllebige Produktentwicklung.

Steffen Hupp
arbeitet seit 2015 als Mobile Software Engineer im Fraunhofer IESE in Kaiserslautern. Im Projekt Digitale Dörfer liegen seine Aufgaben in der technischen Konzeption und Umsetzung im Kontext der Cross-Plattform-Entwicklung sowie die Automatisierung von Vorgängen in der Entwicklung.

Patrick Mennig
ist Wirtschaftsinformatiker mit dem Schwerpunkt Anforderungserhebung und Innovation für Informationssysteme. Sein Schwerpunkt liegt auf Kreativworkshops und -techniken für softwarebasierte Innovationen. Dafür entwickelt er immer wieder Prototypen und Anwendungen mit Web-Technologien, insbesondere React. Seit 2017 arbeitet er am Fraunhofer IESE in verschiedenen Forschungs- und Innovationsprojekten.

16 Kommentare