Moderne Apps

Entwerfen einer plattformübergreifenden modernen App-Architektur

Rachel Appel

Beim Entwurf eines neuen Projekts und beim Ändern vorhandener Lösungen ist es gleichermaßen wichtig, die Landschaft moderner Apps zu kennen. Das heißt, Sie müssen unterscheiden können, welche Geräte, Betriebssysteme und Browser vorhanden und relevant sind. Und mit "Geräte" sind nicht nur Smartphones gemeint, sondern auch Tablets, PC und große Desktop-Bildschirme. Allerdings werden immer noch mehr Smartphones verkauft als Geräte anderen Typs. Einige Entwickler müssen u. U. sogar in die Kleidung integrierte Geräte in ihre plattformübergreifende Architektur einbeziehen.

Im Endeffekt geht es darum, dass bei der Programmierung von Software heutzutage verschiedene Geräte berücksichtigt werden müssen. Das Hauptziel besteht darin, möglichst viel für die verschiedenen Plattformen geeigneten Code zu schreiben, um möglichst wenig Code schreiben zu müssen. Auf diese Weise können Sie das Produkt oder die App schneller auf den Markt bringen. Zudem ist der Code dann nicht so anfällig für Fehler, die sich einschleichen können, wenn dieselbe Logik in verschiedenen Sprachen formuliert werden muss.

Plattformübergreifende Geräteentwicklung

Wie Sie die plattformübergreifende Entwicklung angehen, hängt von dem Typ von Software ab, die bereits vorhanden ist. Wenn Sie eine Website haben, deren Inhalte freigegeben und gemeinsam genutzt werden sollen, dann ist möglicherweise eine Hybridlösung die beste Wahl. Wenn es sich um eine reife Website handelt, können Sie ein responsives Design und Unterstützung für mobile Geräte hinzufügen. Sie könnten auf die mobile Website ganz verzichten und einfach eine Website und separate native Begleit-Apps bereitstellen. Desweiteren ist zu überlegen, ob die App nur eine andere Methode zur Darstellung der Inhalte der Website ist oder ob sie als eigenständige Idee bestehen kann.

Erstellen Sie zuerst Ihre mobile Website und dann die nativen Apps. Während der Entwicklung nativer Apps kann die mobile Website als App fungieren, bis Sie alle Plattformen abgedeckt haben. Diejenigen, die bereits Websites in Betrieb haben, müssen diesen Inhalt unter Umständen für die einzelnen Plattformen und Geräte anpassen. Auf diese Weise können Sie Ihren Kundenstamm mobiler Benutzer während der Entwicklung mobiler Apps weiter ausbauen. Wenn Sie mit dem Schreiben native Apps beginnen können, brauchen Sie unter Umständen Hilfe bei der Wahl der geeigneten Sprache. Lesen Sie daher unbedingt meinen Artikel vom September 2013 mit dem Titel „Richtiges Auswählen von Sprachen zum Entwickeln moderner Apps‟ (msdn.microsoft.com/magazine/dn385713).

Es ist zwar gängige Praxis, zuerst Apps für die größte Plattform bzw. die Plattform mit den meisten Geräteverkäufen zu entwickeln, manchmal ist es jedoch vom geschäftlichen Standpunkt her klüger, mit der Plattform zu beginnen, die über Features verfügt, die sich mit Ihren Anforderungen decken. Beispielsweise kann es für eine Fitness-App, die zur Protokollierung von Mahlzeiten und Trainingseinheiten dient, erforderlich sein, eine Zusammenfassung Ihrer Mahlzeiten und Aktivitäten anzuzeigen. MyFitnessPal ist ein gutes Beispiel dafür auf Windows Phone. Diese Art von Daten eignen sich perfekt für eine Live-Kachel, die nur auf der Windows-Plattform verfügbar ist.

Um herauszufinden, ob Ihre Anforderungen zur Plattform passen, können Sie alle wichtigen App-Funktionen auflisten. Überprüfen Sie jeweils, ob die Anforderung auf den verschiedenen Plattformen unterstützt wird und, wenn möglich, in welchem Umfang sie unterstützt wird. Abweichungen werden Sie bei hardwarespezifischen Funktionen, z. B. Kamera, oder Betriebssystemfunktionen, wie Kacheln oder Spracherkennung, feststellen. Sehr allgemein betrachtet, stehen Ihnen Architekturoptionen zur Auswahl, mit denen Sie eine dieser drei Richtungen einschlagen: native Apps, Hybrid-Apps oder mobe HTML5-Web-Apps.

Nativ Das bedeutet, dass Sie für jede Plattform eine eigene App erstellen müssen. Bei den Plattformen handelt es sich wahrscheinlich um Windows Phone 8, iOS und Android. Für einige sind andere Plattformen wie BlackBerry noch interessant. Jede App nutzt in vollem Umfang alle speziellen Features, die jeweils die betreffende Plattform zur Verfügung stellt. Die Leistung nativer Apps ist großartig, aber Sie müssen natürlich soliden und sauberen Code schreiben, da die Leistung schnell beeinträchtigt wird, wenn Sie nicht gewissenhaft sind. Sie müssen für jede Plattform mindestens eine Benutzeroberfläche für die native App erstellen. Die Kosten pro Plattform steigen also und sind hier im Vergleich zu den anderen Optionen am höchsten.

Hybrid Irgendwo im grauen Bereich zwischen nativer App und Web-App ist die Hybrid-App angesiedelt. Bei Hybrid-Apps werden in der Regel Inhalte aus einer vorhandenen Website in eine App integriert, um sie nativ verpacken und bereitstellen zu können. Dies ist insbesondere hilfreich, um sich schnell einen Platz in den App-Stores zu sichern und dort präsent zu sein, vielleicht während eine vollständig native App für die betreffende Plattform entwickelt wird. Die Leistung ist offenkundig langsamer als bei nativen Apps und Web-Apps, da zur Erstellung von Hybrid-Apps im Allgemeinen vorhandener HTML-Code in einen Container gepackt wird. Unter Windows Phone ist dies beispielsweise ein WebBrowser-Steuerelement. Immer wenn eine zusätzliche Ebene vorhanden ist, gibt es potenzielle Leistungsverluste.

Ausgeglichen wird dies jedoch durch die schnelle Bereitstellung auf der nativen Plattform. Zur Erstellung von Hybrid-Apps müssen Sie eines der folgenden Tools verwenden:

• Apache Cordova/PhoneGap
• Visual Studio-Projektvorlage für Windows Phone-HTML5-Apps
• Telerik AppBuilder (vormals Icenium)
• Xamarin Studio

Aufgrund ihrer Beschaffenheit, packen Hybrid-Apps Web-Inhalte in das WebBrowser-Steuerelement (um beim Beispiel für Windows Phone zu bleiben), das ein XAML-Element ist:

<phone:WebBrowser x:Name="Browser"
HorizontalAlignment="Stretch"
VerticalAlignment="Stretch"
Loaded="Browser_Loaded"
NavigationFailed="Browser_NavigationFailed" />

Mehr brauchen Sie nicht, um mit der Erstellung einer Hybrid-App zu beginnen. Auf anderen Plattformen wird das gleiche Konzept verwendet, aber die Steuerelemente sind möglicherweise anders. Seien Sie bei der Erstellung Hybrid-Apps vorsichtig, da sie möglicherweise nicht die gleichen Zugriffsrechte oder Berechtigungen zum Ausführen von Aktionen wie native Apps haben. Der Grund hierfür sind Vorsichtsmaßnahmen, um die Ausführung von böswilligen Skripts aus dem Web auf dem Client zu verhindern. Aus diesem Grund gelten auch für HTML-Apps ähnliche Beschränkungen.

Zum Erstellen von Hybrid-Apps können Sie Telerik AppBuilder oder Apache Cordova statt Visual Studio-Projekten verwenden. Diese Drittanbietertools schließen die Lücken zwischen dem Hybrid-Web-Eindruck und dem nativen Erscheinungsbild Ihrer App.

HTML5 Der Vorteil dieses Ansatzes besteht in der unmittelbaren breiten Verfügbarkeit, welche die HTML5-Spezifikation mit sich bringt. Mobile Websites haben eine große Reichweite, aber nicht das native Erscheinungsbild, das die Benutzer mögen und normalerweise von nativen Apps erwarten. Zudem ist eine HTML5-App möglicherweise nicht in der Lage, auf einige hardwarespezifische Funktionen der Zielplattformen zuzugreifen, z. B. Webcam oder Beschleunigungsmesser.

HTML5 ist mit den geringsten Kosten pro Plattform verbunden, da Sie den einmal erstellten Code in den meisten Webbrowsern ausführen können sollten. Einige mobile Webbrowser unterstützen allerdings nicht alle aktuellen Standards. Das kann ein großes Problem bei der Entwicklung von HTML5-Apps sein. Wenn native Funktionen für Ihr Projekt wichtig sind, dann kann mangelnder Zugriff in diesem Bereich Sie dazu zwingen, native Apps zu entwickeln.

Obwohl HTML5 mit der breiten Verfügbarkeit lockt, sollten Sie daran denken, dass die Entwicklung für das Web in gewisser Weise der Entwicklung nativer Apps ähnelt. Sie müssen sich mit der Unterstützung einer Reihe von Webbrowsers befassen. Wie bei der Geräteentwicklung, priorisieren die Webentwickler diejenigen Browser mit den meisten Benutzern, also Internet Explorer, Chrome, FireFox und Opera.

Sie möchten für verschiedene Geräte schöne Benutzeroberflächen auf der Clientseite entwerfen, können diesen spezifischen Gerätecode aber nicht wiederverwenden. Die folgenden nativen Funktionen zeigen auf den verschiedenen Plattformen wahrscheinlich nicht dasselbe Verhalten bzw. sind nicht auf allen Plattformen verfügbar:

• Pushbenachrichtigungen
• Wallet
• NFC (Near Field Communication)
• Multitasking/Multithreading
• Sprache
• Navigationschemata
• Dialogfelder

Hybrid-Apps oder HTML5-Client-Apps stützen sich nicht auf den Zugriff auf diese plattformspezifischen Attribute. Wenn Funktionen wie diese Teil der App-Anforderungen sind, müssen Sie native Apps erstellen.

Konstruktion plattformübergreifender Lösungen

Die Festlegung, welche Plattformen unterstützt werden sollen, ist nur eine Entscheidung in der App-Landschaft. Sie müssen die Lösung auch entwerfen und Dinge berücksichtigen, wie die Produkteinführungszeit und die Priorisierung der Plattformen. Auch die gemeinsame Nutzung möglichst großer Codeteile zwischen Apps ist eine wichtige Überlegung.

Die Back-End-Webdienste und APIs funktionieren in plattformübergreifenden Szenarien gut, weil jede Plattform HTTP unterstützt. Die Verwendung von Dienstebenen im Back-End bedeutet, dass Sie für diese Dienste nur einmal Code schreiben müssen.

Bei der Erweiterung der Architektur im Hinblick auf den Client sollten Sie möglichst viel Code gemeinsam nutzen. Sie können mit PCLs (Portable Class Libraries) mühelos Code unter Windows 8 und Windows Phone programmieren, aber dann bleiben andere Plattformen wie Android und iOS außen vor. Sie können Code unter Windows 8, Windows Phone, Android und iOS gemeinsam nutzen, wenn Sie den Code in C# schreiben und die Xamarin-Tools zum Compilieren verwenden.

Der Vorteil nativer Apps besteht darin, dass die Benutzer das Erscheinungsbid der nativen Plattform erhalten. Sie können zwar beim Einsatz von Tools wie Xamarin einigen Code auf der Benutzeroberflächeebenen gemeinsam verwenden, erzielen jedoch die besten Ergebnisse, wenn Sie jede Benutzeroberfläche getrennt von Hand anfertigen. In der Regel müssen Sie dazu den von Xamarin generierten Code abändern. Dies ist ein guter Zeitpunkt zum Hinzufügen plattformspezifischer Funktionen, um die Erfahrung für die Benutzer jeder Plattform anzupassen.

Die App-Codeebene entspricht dem Controller oder ViewModel-Tielen der Model-View-Controller (MVC)- bzw. Model-View-ViewModel (MVVM)-Muster. Die Benutzeroberflächenebene entspricht der Ansicht (View) in MVC und MVVM. Das Modell ist selbstverständlich die Datendarstellung. Es kann sich dabei um JavaScript-Klassen handeln, die Datenbankobjekten im lokalen Speicher zugeordnet werden, oder die Zuordnung kann zu einem entfernten Schema in der Datenbank erfolgen. Lokale Daten werden normalerweise von Geräten gemeinsam genutzt, da sie oft gerätespezifische Informationen enthalten.

Beim Erstellen einer Lösung besteht der Weg des geringsten Widerstandes darin, zunächst mit den Back-End-Ebenen zu beginnen, dann die Website und schließlich die Apps zu erstellen. Auf diese Weise können Sie für einem möglichst großen Kundenkreis etwas bereitstellen. Auf der App-Seite müssen Sie bestimmen, was Sie zuerst erstellen möchten und ob Sie eine Plattform als primäre Plattform wählen.

Ich persönlich mag die Plattform Windows 8/Windows RT/Windows Phone und denke, dass sie (insbesondere Windows Phone) die beste Benutzerschnittstelle für alle verfügbaren Geräte hat. Das ist nicht nur so, weil ich einmal Mitarbeiter bei Microsoft war. Ich bin auch der Meinung, dass das iPhone eine gute Benutzerschnittstelle hat. Funktionen wie Kacheln und die hervorragenden Nokia-Kameras sind überzeugende Gründe, Windows Phone als primäre Plattform zu wählen, wenn diese Funktionen in einer App benötigt werden. Zudem kann Windows Phone mit den integrierten cloud-basierten Apps für Kontakte und Kalender reibungslos Kontakte, Kalender und andere wichtigen Daten auf verschiedenen Windows Phone-basierten Geräten verwalten und zusammenführen.

Zusammenfassung

Mit dem Aufkommen der BYOD- (Bring your own device)-Bewegung am Arbeitsplatz wurde die Entwicklung nativer Apps gängige Praxis. Wie Sie sehen, gibt es viele Variablen und Faktoren, die bei der Erstellung von Apps zu berücksichtigen sind und sich auf Ihren Erfolg auswirken. Sofern Sie nicht in einem Unternehmen tätig sind, das einen Standarddesktopclient erfordert, dann rate ich davon ab. Endergebnis ist, dass es nicht die erste App auf dieser Plattform ist.

Wenn Sie über genügend Budget und Personal verfügen plus einen längeren Zeitraum zum Erstellen der Lösung, dann können Sie eine Website mit einer mobilen Version und einen kompletten Satz an nativen Apps erstellen. Das bedeutet, dass Sie alle Möglichkeiten zum Zugriff auf Ihre Dienste und Daten bereitstellen. Dieser Weg ist natürlich der arbeitsaufwendigste und kostspieligste.

Rachel Appel ist Beraterin, Autorin, Mentorin und frühere Microsoft-Mitarbeiterin mit über zwanzigjähriger Erfahrung in der IT-Branche. Sie nimmt an wichtigen Branchenkonferenzen wie Visual Studio Live!, DevConnections und MIX als Rednerin teil. Ihr Fachbereich ist die Entwicklung von Lösungen, bei denen geschäftliche und technologische Aspekte in Einklang gebracht werden und in denen führende Microsoft- und offene Webtechnologien zum Einsatz kommen. Besuchen Sie Rachel Appel auf ihrer Website unter rachelappel.com.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Frank La Vigne (Microsoft) und Wally McClure (Scalable Development)