Teil 2: Mobile-Apps sind weiter auf dem Vormarsch

Mobile-Apps auf dem Vormarsch: Die richtige (Aus)Wahl
Keine Kommentare

Auf den Smartphones und Tablets dieser Welt sind Android und iOS installiert. Meist muss eine App für beide Systeme erstellt werden. Android und iOS unterscheiden sich jedoch aus Anwender- und aus Entwicklersicht stark. Plattformübergreifende Programmierung bietet einen Ausweg. Hier gibt es inzwischen mehrere Optionen für Entwickler.

Die Nutzung mobiler Devices ist seit Jahren auf den Vormarsch. Weltweit werden zunehmend mobile Geräte statt Desktopsysteme eingesetzt. Dieser Trend gilt sowohl im Bereich der Endverbraucher (Consumer) als auch für Unternehmenszwecke (Enterprise). Aus technischer Sicht gilt es zu differenzieren, d. h. man muss zwischen unterschiedlichen Arten von Apps unterscheiden. Konkret unterscheidet man

  • native Apps
  • Web-Apps und
  • hybride Apps.

Der Vorteil von nativen Apps liegt darin, dass diese für das jeweilige Betriebssystem optimiert sind. Die Benutzeroberfläche fügt sich vollständig in die Vorgaben der Plattform ein und die Benutzerführung ist mit der Systemumgebung kompatibel. Ein weiterer wichtiger Vorteil besteht darin, dass native Apps keine Einschränkungen beim Zugriff auf spezifische Gerätehardware des Smartphones oder Tablets aufweisen. Alle Sensoren dieser Geräte können über die APIs des Systems direkt angesprochen werden. Das Deployment von nativen Apps erfolgt üblicherweise über die App-Stores. Ist eine native App installiert, kann diese im Offlinemodus auch ohne Internetzugriff ausgeführt werden.

Artikelserie

Dem gegenüber stehen Web-Apps. Das sind spezielle Webapplikationen, die für die Nutzung auf mobilen Geräten angepasst werden. Der Zugriff auf die Systemhardware ist jedoch beschränkt. Einfache Funktionen wie der Ortungsdienst sind nutzbar. Die Darstellung erfolgt im Browser des Systems und kann die Besonderheiten der einzelnen Plattform nur bedingt berücksichtigen. Web-Apps können nicht über App-Stores bereitgestellt werden. Sie laufen auf dem Server und benötigen daher eine konstante Internetverbindung. Mit Progressive Web Apps (PWA) ist auch eine Offlinenutzung möglich. Zwischen Web-App und nativer App agieren hybride Apps. Sie laufen in einem WebView-Container, d. h. gewissermaßen in einem internen Browser. Damit wirken sie für das Betriebssystem wie eine native App. Das User Interface (UI) muss generisch sein, um mit allen Systemen zurechtzukommen. Ein Vorteil von hybriden Apps ist es, dass man sie über die App-Stores verteilen kann. Wie die drei Arten von Apps grundsätzlich funktionieren, ist in Abbildung 1 dargestellt.

Abb. 1: Native vs. hybride vs. Web-App

Abb. 1: Native vs. hybride vs. Web-App

Wir wollen uns ansehen, wie man Apps entwickelt, die sowohl unter Android als auch unter iOS ausgeführt werden. Dabei geht es uns um native Apps, d. h. die Applikationen sollten möglichst performant ausgeführt werden können und sich bestmöglich in das Betriebssystem eingliedern.

IT Security Camp

Freiberuflicher Whitehat Hacker, Trainer und Security-Coach

Christian Schneider (Schneider IT-Security)

IoT Conference 2020

All Inclusive

Katrin Rabow

Entwicklung für mobile Systeme

Sehen wir uns an, welche technischen Ansätze es gibt, eine App für die mobilen Systeme zu erstellen. Berücksichtigt ist eine Auswahl aus verschiedenen Technologiebereichen. Natürlich gibt es weitere Möglichkeiten, eine App für Android und iOS zu programmieren. Zum Beispiel kann man auch Low-Code-Tools einsetzen und dabei hauptsächlich mit Hilfe grafischer Designer arbeiten. Erfreulicherweise gibt es eine beachtliche Vielfalt von Vorgehensweisen. Das hat den Vorteil, dass man sich die passende Variante für sein Projekt gewissermaßen herauspicken kann. Neben den technischen Zielen stehen dabei auch andere Gründe für die Auswahl im Fokus, zum Beispiel:

  • Kenntnis von Programmiersprachen und Technologien: Wenn Sie nur gelegentlich eine Mobile-Apps programmieren, ist es hilfreich, wenn Sie dazu einen vertrauten Ansatz wählen können, um den Lernaufwand zu minimieren.
  • Kosten für Lizenzen: Entwicklungsumgebungen und zu nutzende Frameworks müssen teilweise auch lizenziert werden. Für eine nicht oder nur begrenzt kommerzielle Lösung stehen die Werkzeuge meist kostenfrei zur Verfügung. Bei einer weitergehenden Nutzung müssen i. d. R. Lizenzgebühren entrichtet werden.
  • Erfahrungen: Bestehen bereits positive oder negative Erfahrungen mit einem Ansatz? Das können Gründe sein, eine bekannte Technologie zu wechseln oder beizubehalten.

Ebenso ist zu beachten, dass nicht alle Vorhaben mit jedem Ansatz realisierbar sind. Das Ziel der hier dargestellten Vorgehensweisen ist zwar eine native App, dennoch gibt es immer noch Unterschiede, wenn man mit Java (Android) oder Swift (iOS) und den direkten APIs der jeweiligen Plattform arbeitet. Das kann sich zum Beispiel darin äußern, dass man ausgewählte Hardware nicht ansprechen oder dass man eine spezifische Designvorgabe aus technischen Gründen nicht realisieren kann. In diesem Fall bleibt tatsächlich nur der direkte Weg, den die Hersteller der Betriebssysteme Google und Apple vorgesehen haben. Je ausgereifter die Vorgehensweisen sind, desto seltener sollten diese massiven Probleme jedoch auftreten.

Mit mobilen Apps sind solche für Android und iOS gemeint. Cross-Plattform-Ansätze, die sich auf diese beiden Systeme konzentrieren, sind meist spezialisierter als Vorgehensweisen, die gleichzeitig auch das Erstellen von Apps für Desktopsysteme ermöglichen. Das liegt primär daran, dass die Hardwarevoraussetzungen auf einem mobilen Gerät (Touch, kleiner Bildschirm usw.) vollständig anders sind als auf einem Desktoprechner.

Los geht es mit Xamarin als Weg zur App für iOS und Android.

Xamarin

Mit Hilfe von Xamarin ist es möglich, Apps für alle Plattformen simultan zu erstellen. Dabei erzeugt man native Applikationen. Grundsätzlich stehen zwei Wege zur Verfügung (Abb. 2):

Abb. 2: Xamarin.Forms vs. Xamarin traditionell

Abb. 2: Xamarin.Forms vs. Xamarin traditionell

  1. Traditionell (nativ): Das User Interface wird mit der spezifischen Technologie der Plattform erstellt und die Businesslogik wird aus einer gemeinsamen Codebasis in C# programmiert.
  2. Xamarin.Forms: Zusätzlich zur ersten Variante kann das User Interface mit Hilfe von Xamarin.Forms deklarativ in einem XAML-Dialekt erstellt werden. Xamarin übersetzt diese generische UI-Beschreibung in das konkrete plattformspezifische Aussehen.

Bei beiden Optionen werden die Benutzeroberfläche und die Businesslogik in Visual Studio unter Windows oder alternativ in Xamarin Studio unter macOS programmiert. Um die finalen App-Packages für iOS zu erstellen, wird ein Mac inklusive Xcode als Entwicklungsumgebung benötigt.

Technologisch funktioniert Xamarin nach dem folgenden Prinzip: Damit Entwickler mit einer einheitlichen Codebasis auf allen Plattformen Apps erstellen können, wird das .NET Core Framework auf den Zielplattformen verfügbar gemacht. Auf diese Weise kann man mit Hilfe von C# und der üblichen, aus .NET bekannten Vorgehensweis die Apps programmieren. Diese Teilimplementierungen des ehemaligen .NET Frameworks gehen auf Mono zurück. Sie heißen für die Plattformen iOS bzw. Android entsprechend Xamarin.iOS und Xamarin.Android. Weiterhin stellt Xamarin so genannte Wrapper-Klassen bereit, um plattformspezifische APIs nutzen zu können. Auf diese Weise ist es auch möglich, spezielle Hardware der Systeme anzusprechen. Beispielsweise kann man mit ihrer Hilfe aus C# heraus auf die Funktionen des Fingerabdrucksensors eines iPhones zugreifen. Der Xamarin-Compiler generiert aus dem C#-Quellcode und der .NET-Core-Codebasis eigenständig die nativen Apps. Als Entwickler ist man darauf angewiesen, dass das Team von Xamarin das Tool möglichst fehlerfrei hält. Updates der Plattformen Android und iOS muss Xamarin sehr zeitnah ausführen, damit Entwickler stets auf der Höhe der Zeit sind. Im Moment scheint das sehr gut zu funktionieren und es werden in relativ kurzen Zeitabständen Updates der Xamarin-Bibliotheken zur Verfügung gestellt.

Der eben beschriebene Ansatz des Code-Sharings bezieht sich jedoch zunächst nur auf die Businesslogik einer App. Die sehr unterschiedlichen Vorgehensweisen zur Erstellung der Benutzeroberflächen bleiben zunächst außen vor und müssen daher plattformspezifisch realisiert werden. Einen Schritt weiter geht wie erwähnt Xamarin.Forms. Hier wird das UI für alle Plattformen durch die einheitliche generische Beschreibungssprache XAML definiert. Damit kann man einen weiteren Teil der App aus einer einheitlichen Codebasis erstellen. Bei Xamarin.Forms arbeitet man mit einem streng logischen Aufbau bei der Gestaltung der Oberfläche. Es gibt Layoutcontainer, Objekte aus dem XAML-Code werden mittels Data Binding an den C#-Code gebunden. Xamarin setzt für die Architektur und Projektstruktur üblicherweise auf das Model-View-ViewModel-(MVVM-)Entwurfsmuster.

Mit Xamarin.Forms gelingt es noch nicht, alle spezifischen Möglichkeiten der einzelnen Plattformen zu 100 Prozent abzudecken. Man kommt aber i. d. R. schon recht weit. Lässt sich ein bestimmtes User Interface nur auf einer Zielplattform umsetzen, kommt man auch hier nicht umhin, bestimmte Elemente spezifisch anzupassen. Muss man das zu oft machen, geht der erhoffte Vorteil wieder verloren. Plattformspezifische Anpassungen kosten Zeit und man muss sich erst in die genaue Vorgehensweise einarbeiten.

RAD Studio mit FireMonkey

Mit Hilfe der Entwicklungsumgebung RAD Studio können Apps für Android und iOS erstellt werden. Die Dokumentation von RAD Studio informiert darüber, welche spezifischen Voraussetzungen vorliegen müssen, um Apps für Android zu bauen. Möglich macht es das plattformübergreifende Grafik-Framework FireMonkey. Dabei sind die Apps für die mobilen Systeme das Ergebnis einer so genannten geräteübergreifenden Programmierung. Ebenso können neben Apps für die mobilen Systeme auch Applikationen für Windows, macOS und Linux aus einem Quellcode generiert werden. Erstellt man Apps mit RAD Studio, besteht ein wichtiger Vorteil darin, dass man das User Interface komplett im grafischen Designer erstellt (Abb. 3).

Abb. 3: RAD Studio enthält einen grafischen Designer zum Erstellen der Benutzeroberfläche

Abb. 3: RAD Studio enthält einen grafischen Designer zum Erstellen der Benutzeroberfläche

Eine Nachbearbeitung im Code ist nicht notwendig. Wichtige Eigenschaften der Steuerelemente werden ebenfalls über die Konfiguration angepasst. Noch während der Entwicklung kann man das spätere Aussehen der Screens mit Hilfe einer Vorschaufunktion abschätzen (Abb. 4).

Abb. 4: Vorschau der Benutzeroberfläche für unterschiedliche Geräte

Abb. 4: Vorschau der Benutzeroberfläche für unterschiedliche Geräte

Dieses Feature beschleunigt den Entwicklungsprozess. Ebenso hilft die Entwicklungsumgebung dabei, die plattformspezifischen Konfigurationen komfortabel über Dialogfelder vorzunehmen. Mit wenigen Einstellungen kann man die Zielplattform wechseln und das jeweilige App-Package generieren lassen. Bei plattformübergreifender Entwicklung entsteht eine funktionsgleiche App für unterschiedliche Systeme.

Erwähnenswert ist zum Beispiel das so genannte LiveBinding. Damit ist es möglich Eigenschaften der visuellen Komponenten an Datenstrukturen oder Eigenschaften anderer Komponenten zu binden. Auf diese Weise können Datenflüsse zum User Interface auf dem Wege der Konfiguration umgesetzt werden, d. h., es ist nicht notwendig, dafür Programmcode zu schreiben. Mit Hilfe des Bindings-Experten kann man Quelle und Ziel einer solchen visuellen Datenverbindung schnell auswählen und entsprechend konfigurieren. Der Quellcodeumfang schrumpft damit erheblich. Die in der Palette standardmäßig verfügbaren Komponenten dürften in den meisten Fällen genügen, um die Anforderungen an Benutzeroberflächen umzusetzen. Trotzdem gibt es die Möglichkeit, zusätzlich externe Komponenten zu installieren und zu verwenden. Erste Anlaufstelle ist der interne Package-Manager GetIt in der Entwicklungsumgebung.

Über vordefinierte Styles kann man das Aussehen der Applikation auf der Basis von FireMonkey schnell an das gewünschte Design anpassen. Auch bei diesem Ansatz benötigt man für das Erstellen von iOS-Apps einen Mac mit Xcode. RAD Studio selbst ist eine Windows-Anwendung, die man aber auch in einer virtuellen Maschine unter macOS ausführen kann, um nur einen Rechner für die Entwicklung zu verwenden.

NativeScript

Eine weitere Vorgehensweise basiert auf NativeScript. NativeScript ist ein Open-Source-Framework von Progress Telerik. Die Entwicklung erfolgt in JavaScript, alternativ in TypeScript. Ergänzend kann man die Frameworks Angular oder Vue.js einbinden. Die Benutzeroberfläche wird wie bei Web-Apps oder hybriden Apps mit HTML und CSS gestaltet. Der Unterschied besteht jedoch darin, dass kein Browser bzw. keine WebView für die Ausführung der App benötigt wird. NativeScript führt zwar auch JavaScript aus, es werden jedoch zur Laufzeit die Widgets der nativen Plattform, also von Android oder iOS, erzeugt. Das User Interface wird auf der Basis von JSX (JavaScript Syntax Extension) beschrieben. Spezifische Funktionen von Android und iOS können über JavaScript angesprochen werden. Während des Zusammenbauens der App wird der nichtplattformspezifische Code für die jeweilige Zielplattform übersetzt. Abbildung 5 zeigt die Architektur einer App, die auf NativeScript beruht.

Dazu sind die folgenden Anmerkungen angebracht:

  • Application Code: Hiermit ist der Code für die Anwendung gemeint. Dabei handelt es sich um die Geschäftslogik der App.
  • Application Framework: Der Anwendungscode kann entweder direkt in JavaScript geschrieben werden oder bei Verwendung von TypeScript mittels eines Transpilers direkt in JavaScript übersetzt werden. Alternativ kann man die bekannten Anwendungsframeworks Angular und Vue.js einsetzen.
  • Native Script Core Modules: Diese Module stellen die Abstraktionen bereit, die für den Zugriff auf die nativen Plattformen erforderlich sind, zum Beispiel das Gestenmodul. Es definiert eine gemeinsame JavaScript-API, die den TypeScript-/JavaScript-Code der Anwendung in native Gesten-API-Aufrufe übersetzt. Ein weiteres Element der Kernmodule ist eine grundlegende XML-basierte Methode zum Definieren der Benutzeroberfläche, der Datenbindung und der Navigation.
  • Runtimes: Mit den NativeScript Runtimes werden die APIs von Android- und iOS mit Hilfe von JavaScript-Code aufgerufen. Dazu verwendet man die auf JavaScript basierende virtuelle Maschine von Google (Android) und die JavaScriptCore-Implementierung von WebKit, die mit iOS 7.0 und höher ausgeliefert wird. Umfassendere Beschreibungen findet man online in der Dokumentation von NativeScript für Android und iOS.
  • NativeScript CLI: Dabei handelt es sich um das Command Line Interface, mit dessen Hilfe man eine neue App erzeugt, erstellt und ausführt.

Mit Hilfe eines Online-Playgrounds, der u. a. einen Editor beinhaltet (Abb. 6) und der NativeScript-Playground-App für Android bzw. iOS kann man direkt im Browser mit ersten Experimenten starten. Dazu kann man den Code online im Browser editieren und sich das voraussichtliche Ergebnis direkt in der App auf dem mobilen Gerät anzeigen lassen.

Abb. 6: Online-Playground von NativeScript

Abb. 6: Online-Playground von NativeScript

Flutter

Flutter stammt aus dem Hause Google und verspricht eine neue Herangehensweise fürs Erstellen von nativen Apps für iOS und Android. Flutter verwendet nicht die nativen User-Interface-Komponenten der Zielplattformen, sondern zum Zeichnen der Komponenten wird eine eigene Rendering-Engine namens Skia benutzt. Die Elemente des User Interface wurden darin nachgebaut. Das User Interface erstellt man auch hier direkt im Code, einen grafischen Editor gibt es nicht. Flutter basiert auf Googles Programmiersprache Dart. Die Syntax von Dart ist an die Syntax von C angelehnt. Dart ist streng typisiert und objektorientiert. Für die Entwicklung benötigt man das Flutter-SDK. Als Entwicklungsumgebung kann man zum Beispiel Android Studio oder IntelliJ IDEA einsetzen. Auch die Verwendung von Visual Studio Code ist möglich. Ein Überblick über die Architektur einer Flutter-App ist in Abbildung 7 dargestellt. Die Performance der Apps wird als sehr gut beschrieben. Das Material Design der Benutzeroberfläche ist an Android ausgerichtet und kann sehr leicht angepasst werden. Damit wird das Erstellen von Apps erleichtert, die man zum Beispiel an Vorgaben eines bestehenden Corporate Designs ausrichten möchte.

Qt

Wenn Sie überrascht sind, auch diese beiden Buchstaben hier zu finden, dann wundert es uns nicht. Einstiegspunkt ist die Dokumentation für die mobile Entwicklung mit Qt, wie sie im Netz auf den Seiten von Qt zu finden ist. Basis sind die Qt Quick Controls. Entwickelt wird in der Programmiersprache C++. Streng genommen sollten wir sogar sagen, dass damit die Businesslogik erstellt wird. Das User Interface wird mit QML gestaltet. QML (Qt Meta-Object Language) ist eine deklarative Programmiersprache. Um eine App für ein mobiles Gerät zu erstellen und auszuführen, müssen Sie die Entwicklungsumgebung für die Geräteplattform einrichten und eine Verbindung zwischen dem Qt Creator und dem mobilen Gerät konfigurieren. Um Apps für Android-Geräte zu entwickeln, müssen Sie die neuesten Android NDK- und SDK-Tools herunterladen und installieren. Anschließend können Sie die für die Entwicklung erforderlichen Tools und Pakete aktualisieren oder installieren. Außerdem benötigen Sie das Java SE Development Kit (JDK). Nachdem Sie alle diese Tools installiert haben, müssen Sie die Pfade zum Qt Creator angeben. Für die Entwicklung von iOS-Apps installieren Sie Xcode und verwenden es zum Konfigurieren Ihres Geräts.

Qt kann dann ein gangbarer Weg sein, wenn Sie sich bereits mit diesem plattformübergreifenden Framework auskennen und zum Beispiel Applikationen für Desktopsysteme damit erstellen. Wird dann noch eine Mobile-App benötigt, kann man gegebenenfalls schon vorhandenen Quellcode wiederverwenden.

Entwicklungs- und Systemumgebung

Anders als bei der Entwicklung von klassischen Applikationen ist im Bereich der Entwicklung von Apps für die mobilen Systeme etwas mehr Aufwand hinsichtlich der System- und Entwicklungsumgebung notwendig. Android basiert auf einem Linux-Kernel und gibt sich grundsätzlich als offenes System, d. h. eine Entwicklung ist auf den Desktopbetriebssystemen Windows, Linux und macOS möglich. Emulatoren stehen ebenso für alle Betriebssysteme zur Verfügung. Anders sieht es bei iOS aus. Hier ist zum Erstellen der finalen App-Packages für das Deployment ein Mac mit Xcode und iOS notwendig. Auch der iOS-Simulator kann nur unter macOS ausgeführt werden. Zum Testen der Apps kann man in einem ersten Schritt auf einen Emulator/Simulator setzen. Jedoch muss man berücksichtigen, dass folgende technische Aspekte in einem Emulator/Simulator so gut wie gar nicht abgebildet werden:

  • Darstellung des Akkuverbrauchs
  • Funktionsweise der Kamera des Mobilgeräts
  • Unterbrechungen durch eingehende Anrufe und SMS
  • Auswirkungen einer intensiven Speicherverwendung

Aus dieser Zusammenstellung ergibt sich bereits, dass zu einem fortgeschrittenen Zeitpunkt der Entwicklung ein umfassendes Testen auf Echtgeräten notwendig ist. In der Praxis verfügt ein Entwickler aber nur über einen eingeschränkten Gerätepark. Gerade für Android gibt es unzählige Gerätetypen, Leistungsklassen und Betriebssystemversionen. Die Heterogenität hat jedoch auch bei iOS beträchtlich zugenommen. Mit Hilfe von Cloudlösungen kann man seine App auf einer Vielzahl von Geräten testen. Ein Beispiel ist das Visual Studio App Center. Hierüber hat man Zugriff auf unzählige Mobilgeräte für Android und iOS. In fortgeschrittenen Projektphasen ist das eine gute Ergänzung, um der ausufernden Gerätevielfalt etwas entgegenzusetzen. Auch die Ausgestaltung der Systemumgebung kann je nach Ansatz variieren. Bewährt hat sich nach Erfahrungen des Autors der Einsatz eines Macs. Hier hat man einen iOS-Simulator und die Entwicklungsumgebung Xcode für die Entwicklung von Apps für iOS direkt an Bord.

Ist für die eigentliche Entwicklungsumgebung ein Windows-System notwendig (Visual Studio, RAD Studio), kann man das in einer virtuellen Maschine (VM) auf dem Mac ausführen. Parallels ist die VM der Wahl. Wird jedoch für die Entwicklung lediglich ein beliebiger Editor benötigt, kann man die Entwicklungsplattform – zumindest bis zum Erstellen des App-Packages für iOS – frei wählen.

Einschätzung

Aus den Darstellungen hier ergibt sich, dass plattformübergreifende Ansätze aus technischer Sicht und aus Perspektive der Wirtschaftlichkeit ein gutes Kosten-Nutzen-Verhältnis bieten. Doch welcher Ansatz ist nun der richtige?

Das kann man so pauschal nicht beantworten. Die jeweilige Herangehensweise, die eingesetzte Programmiersprache, der Weg zum User Interface und der Entwicklungszyklus sind von Fall zu Fall sehr unterschiedlich. Gezielte Einarbeitung ist bei allen Ansätzen notwendig. Ebenso wird man bei allen Vorgehensweisen früher oder später an die Grenzen der gewählten Methode stoßen. Das ist aber für die Cross-Plattform-Programmierung insgesamt typisch, denn wir wollen in diesem Fall sowohl Android als auch iOS aus einem gemeinsamen Quellcode bedienen. Daraus kann man schlussfolgern: Sind besondere Anforderungen an das Design oder an die Hardware (wie Gerätetypen und Sensoren) zu erfüllen, dann muss man die Machbarkeit in vorgelagerten Experimenten prüfen. Sonst läuft man Gefahr, erst bei fortgeschrittenem Projektstand festzustellen, dass der gewählte Weg doch zu steinig ist oder sogar in eine Sackgasse führt. Ebenso ist kritisch anzumerken, dass es im Moment nur zwei mobile Plattformen mit Relevanz gibt. Mit anderen Worten: Bevor man sich mit einem speziellen Tool oder Framework zu sehr abmüht, ist man vielleicht mit zwei getrennt entwickelten Apps gar nicht viel langsamer. Es gilt also, im Vorfeld sorgfältig abzuwägen und Entscheidungen zu treffen.

Fazit und Ausblick

Wir haben uns jetzt angesehen, welche Optionen es gibt, eine native App für die mobilen Systeme zu erstellen. Die erfreuliche Nachricht: Das Spektrum an Möglichkeiten ist breit. Man muss sich allerdings auch entscheiden. Das gelingt nur dann, wenn man zunächst experimentiert. Wie weit komme ich mit einem Ansatz? Was geht gut, und was hakt? In der kommenden Ausgabe wollen wir das praktisch ausprobieren, d. h., eine native App für iOS und Android aus einer Codebasis erstellen und uns dabei zwei Ansätze im Vergleich ansehen. Bis dahin ist noch etwas Zeit, die eine oder andere – bisher unbekannte – Vorgehensweise mit einem „Hello World“ auszuprobieren.

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. Außerdem ist der Windows Developer weiterhin als Print-Magazin im Abonnement erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -