Abb. 1: Der App-Entwicklungszyklus in Meilensteinen

Der gestiegene Bedarf an Apps für die mobilen Systeme führt auch dazu, dass die dafür verfügbare Zeit zur Entwicklung sehr oft knapp bemessen ist. In einigen Fällen ist es sogar so, dass wir eine App für einen bestimmten und sehr begrenzten Zeitraum benötigen und danach kein Bedarf mehr an der App besteht („Wegwerf-App“). Beispiele sind die App für eine (einmalige) Veranstaltung oder eine bestimmte Marketingaktion. Welche Beweggründe auch immer bestehen, eine App zu erstellen, es stellt sich dabei immer die Frage nach der passenden Vorgehensweise.

Obwohl wir es lediglich mit zwei aktiven Systemen, Android und iOS, zu tun haben, gibt es in der Zwischenzeit eine Reihe von sehr unterschiedlichen Vorgehensweisen, um das Ziel, eine auf dem Smartphone lauffähigen App zu erstellen, zu erreichen. Diese Tatsache muss etwas näher betrachtet werden. Die Hersteller der Betriebssysteme Android und iOS haben selbstverständlich einen eigenen Weg vorgesehen, der zu einer App für ihr jeweiliges System führt. Das Ergebnis ist eine sogenannte native App und ermöglicht, alle Optionen der jeweiligen Plattform zu nutzen. Die Gründe, nach alternativen Vorgehensweisen zu suchen, bzw. warum sehr viele unterschiedliche Ansätze angeboten werden, sind nach meiner Einschätzung die folgenden:

• Apps für beide Systeme aus einer Quellcodebasis: Beide Systeme unterscheiden sich technisch erheblich. Soll eine App für beide Systeme angeboten werden, wie es in der Regel die übliche Anforderung ist, muss man nahezu den kompletten Entwicklungszyklus doppelt durchlaufen. Ggf. können die Phasen Konzeption und Prototyping verkürzt ausfallen, da man von wechselseitigen Synergien profitieren kann. Neben dem nahezu doppelten Aufwand braucht man auch zwei Teams. Die notwendigen Fähigkeiten sind ebenfalls sehr unterschiedlich.
• Zeitfaktor (Time to Market): Die plattformspezifischen Ansätze sind nicht dafür bekannt, dass sie einen schnellen Entwicklungszyklus unterstützen. Der Vorteil, alle Möglichkeiten eines Systems auszuschöpfen, führt teilweise auch dazu, dass umfangreicher Quellcode zu schreiben ist. Ein typisches Beispiel ist die Prüfung von Berechtigungen auf der Android-Plattform. Aus oben genannten Gründen kann es erforderlich sein, sehr schnell zu ersten Ergebnissen mit einer lauffähigen App zu kommen. Gefragt sind daher insbesondere Ansätze, die den Aufwand reduzieren. Im Mittelpunkt steht dabei die Gestaltung der Benutzeroberfläche und die Umsetzung von Standardanforderungen wie der Prüfung von Berechtigungen.
• Kenntnisse in den Programmiersprachen: Für die native Entwicklung muss man die Programmiersprachen anwenden, die die Hersteller der Systeme dafür vorschlagen. Programmiert man nur gelegentlich eine App bzw. ist man in einem grundsätzlich anderen Technologiestack zu Hause, kann das eine große Hürde darstellen.
• Vorhandener Quellcode: Ist bereits Quellcode aus anderen Projekten – zum Beispiel zur Businesslogik oder zur Anbindung eines Backends – vorhanden, kann es ggf. gelingen, bestimmte Bestandteile dieses Codes wiederzuverwenden und auf diese Weise wertvolle Ressourcen zu sparen.

Sie sehen, es gibt unterschiedliche Gründe, nach alternativen Vorgehensweisen zur App-Entwicklung gegenüber den von Apple und Google angebotenen systemeigenen Entwicklungswerkzeugen, Sprachen und Frameworks Ausschau zu halten. Je nach angewendeter Technologie kommen wir dabei zu unterschiedlichen Ergebnissen. Diese sind Gegenstand des kommenden Abschnitts.

Nativ, Web, Hybrid, Cross-Plattform

Aus enger technischer Perspektive kann man bekanntermaßen folgende Arten von Apps unterscheiden:

• native Apps
• Web-Apps
• hybride Apps

Native Apps werden exklusiv für das Zielsystem, d. h. Android oder iOS, erstellt. Man nutzt direkt das API der Systeme. Die Benutzeroberfläche fügt sich exakt in die Vorgaben der Plattform ein und auch die Benutzerführung ist mit der Systemumgebung kompatibel. Nutzer müssen sich also nicht erst länger orientieren, d. h. sie sind mit den üblichen Vorgängen, wie der Auswahl bzw. dem Löschen von Elementen oder dem Wechseln zwischen den Screens einer Anwendung, sofort vertraut. Ein weiterer wichtiger Vorteil besteht darin, dass native Apps keine Einschränkungen beim Zugriff auf mögliche spezifische Gerätehardware des Smartphones oder Tablets aufweisen. Alle Sensoren dieser Geräte können direkt angesprochen werden. Auch werden die Funktionen von neuen Geräten vollständig unterstützt und können damit in der eigenen App verwendet werden. Das Deployment erfolgt über die App-Stores. Ist eine native App installiert, kann diese – sofern sinnvoll – auch ohne Internetzugriff ausgeführt werden, d. h., dass ein Offlinebetrieb möglich ist. Eine notwendige Datensynchronisation kann beim Herstellen der nächsten Onlineverbindung des mobilen Gerätes automatisch stattfinden. Web-Apps sind dagegen auf die mobilen Devices ausgerichtete Webapplikationen (Mobile First). Das betrifft primär die Gestaltung des User Interface. Der Zugriff auf die Systemhardware ist eingeschränkt. Einige Basisfunktionen, wie zum Beispiel die Ortung via GPS, sind jedoch möglich. Eine Bereitstellung über die Stores ist nicht möglich. Die Apps laufen auf dem Server und benötigen daher eine stetige Internetverbindung. Jedoch kann man ein Icon auf dem Home Screen einrichten, so dass die Nutzer keine Hürden beim Start der App haben. Web-Apps können aus Kundensicht immer dann eine Alternative sein, wenn man dem Nutzer eine Installation nicht zumuten möchte (zusätzlicher Aufwand) bzw. eine Version der Applikation für größere Devices (Desktop) besteht und diese an die mobilen Geräte angepasst werden soll. Ein Beispiel ist der Einsatz einer App für Zwecke des Marketings am Point of Sale. Ein QR-Code für den korrekten Link zur Internetadresse ist schneller gescannt als den Umweg der Installation über den App-Store zu gehen. Das gilt gerade dann, wenn die Kunden die App voraussichtlich nur für eine sehr kurze Zeit nutzen werden. Die fehlende Offlinefähigkeit kann durch den Ansatz der Progressive Web App (PWA) teilweise beseitigt werden. Eine PWA ist eine Symbiose aus einer Webseite und einer App. Mittels eines Service Workers kann eine Caching-Funktion umgesetzt werden. Dieser Service Worker ist zwischen den Webserver und der App auf dem mobilen Gerät geschaltet.

Und hybride Apps? Der Name ist hier tatsächlich Programm. Diese Apps basieren intern auf Webtechnologien. Die Web-App wird in einer Art eingebettetem Webbrowser ausgeführt. Sie läuft in einem Sandkasten, worüber Plattformunabhängigkeit erreicht wird. Über Plug-ins gelingt es, aus dem Sandkasten „auszubrechen“ und auf die notwendigen Systemfunktionen der jeweiligen Plattform zuzugreifen. Das System glaubt daher, eine native App vor sich zu haben (interner Browser), und die eigentliche App wird als Webapplikation ausgeführt.

An dieser Stelle können wir bereits zusammenfassen, dass sowohl Web-Apps als auch hybride Apps auf beide Systeme simultan abzielen. Sie weisen jedoch einige Nachteile gegenüber den nativen Apps auf. Daher versucht man seit Langem, die Vorteile miteinander zu verknüpfen. Das führt uns zu den Cross-Plattform-Ansätzen. Das Ziel von Cross-Plattform ist stets, dem nativen Vorbild möglichst nahe zu kommen, beispielsweise mit Blick auf die Performance der App. Alle Ansätze versuchen dabei aus einer gemeinsamen Quellcodebasis ein möglichst generisches Anwendungsgerüst, nach Möglichkeit über alle Ebenen der App zu verwenden, vom User Interface bis hin zur Datenhaltung. Die Umsetzung als App für das Zielsystem passiert dann weitgehend automatisch. Wir werden unten konkrete Ansätze aus diesem Segment vorstellen. Sie unterscheiden sich vielfältig, beispielsweise in der Art und Weise der Programmierung, der verwendeten Programmiersprache und dem Build-Prozess. Auch der Einsatz der Werkzeuge ist sehr unterschiedlich.

Die Vor- und Nachteile der einzelnen App-Arten sind in Abbildung 2 zusammengefasst. Die Cross-Plattform-App haben wir hier nicht erwähnt, da Cross-Plattform eher eine Vorgehensweise statt einer Technologie im Sinne einer App-Art ist.

Abb. 2: Vor- und Nachteile der einzelnen App-Arten; Idee nach [1]

Der Möglichkeiten viele

In diesem Abschnitt wollen wir die Möglichkeiten der App-Entwicklung etwas sortieren und sie gemäß den eben beschrieben App-Arten (nativ, Web, hybrid) zuordnen. Ein eigener Abschnitt untersucht plattformübergreifende Vorgehensmodelle. Beginnen wir mit der nativen App-Entwicklung für iOS. Die findet bekanntermaßen in der Entwicklungsumgebung Xcode mit der Programmiersprache Swift unter macOS statt (Kasten: „Kein iOS ohne macOS und Xcode“). Das User Interface wurde sehr lange Zeit im Interface Builder mit Hilfe von Storyboards erstellt. Nunmehr wird auch ein deklaratorischer Ansatz verwendet. Über SwiftUI erfolgt die Definition im Quellcode. Die Vorgehensweise ist mit der Arbeitsweise auf anderen Systemen vergleichbar. Statt einem XML-Code bleibt man jedoch auch bei der User-Interface-Definition bei Swift. Der Einsatz von SwiftUI vereinfacht im Übrigen die Entwicklung von Apps für das gesamte Ökosystem aus dem Hause Apple. Auf diese Weise kann man die grafische Benutzerschnittstelle generisch für die unterschiedlichsten Devices erstellen, zum Beispiel für einen Mac, und den Quellcode ohne größere Anpassungen auf anderen Geräten, beispielsweise auf einem iPad oder iPhone, wiederverwenden. Die Anpassungen an das Zielsystem werden vom System automatisch erledigt. Zusammenfassend kann man sagen, dass SwiftUI das Erstellen der Oberflächen vereinfacht. Die Entwicklergemeinde begrüßt daher dieses Feature.

Kein iOS ohne macOS und Xcode

iOS ist ein geschlossenes System, d. h., für das Erstellen der App-Packages und die Verteilung auf den mobilen Devices wird Xcode und damit ein Mac mit macOS benötigt. Ebenso lässt sich der iOS-Simulator nur mit macOS betreiben. Beim Erstellen hybrider Apps oder der Wahl eines plattformübergreifenden Ansatzes kann die Entwicklung zwar grundsätzlich auch auf einem Microsoft-Windows- oder Linux-Betriebssystem erfolgen, jedoch wird eine Verbindung zu einem Mac benötigt. Ebenso lässt sich macOS aus lizenzrechtlichen Gründen nicht auf einer virtuellen Maschine auf einem anderen Gastbetriebssystem betreiben.

Neben dem eigenen physischen Mac im lokalen Netzwerk kann auch auf einen Cloud-Service zurückgegriffen werden. Für die Entwicklung gibt es die Option, einen in der Cloud gehosteten Mac mit allen notwendigen Entwicklungswerkzeugen zu verwenden und diesen über eine Remoteverbindung zu steuern. Ein solches Angebot bietet der Dienst MacinCloud [2]. Der Bildschirm wird dann auf den eigenen Entwicklungsrechner übertragen. Das löst das Problem, das App-Package zu erstellen und den iOS-Simulator während der Programmierung verwenden zu können. Zum Einsatz kommen solche Remotelösungen insbesondere dann, wenn man mit hybriden oder plattformübergreifenden Technologien unter Windows oder Linux programmiert. Ein physisches Device kann man natürlich über die Cloud nicht nutzen.

Alternativ kann man das App-Package auch über einen Online-Build erstellen lassen. Diese Variante nutzt das Framework Tabris.js. Hier kann unmittelbar aus einem Online-Repository ein solches App-Paket erstellt werden.

Kommen wir zur Entwicklung von nativen Apps für Android. Das System aus dem Hause Google gibt sich hier in Bezug auf die Entwicklung deutlich flexibler. Die integrierte Entwicklungsumgebung Android Studio kann unter Windows, macOS oder Linux ausgeführt werden. Ebenso stehen für alle Systeme Emulatoren zum Testen der App während der Entwicklung zur Verfügung. Für die Programmierung kann man alternativ die Sprachen Java oder Kotlin einsetzen. Google empfiehlt inzwischen den Einsatz der moderneren Sprache Kotlin. Entwickler, die mit dieser Sprache bisher nicht in Berührung gekommen sind, finden unter [3] eine einführende Dokumentation. Auch bezüglich der IDE kann man Alternativen einsetzen, zum Beispiel IntelliJ IDEA von JetBrains. Das User Interface wird mit Hilfe eines XML-Dialektes deklariert. Zur Unterstützung bieten die IDEs Interface Builder (Abb. 3).

Abb. 3: Interface Builder in IntelliJ IDEA [4]

An dieser Stelle kommen wir bereits zu alternativen Ansätzen der App-Entwicklung. Diese lassen sich nicht immer ganz genau nach dem o. g. Raster den App-Arten zuordnen, dennoch werden wir hier eine Systematisierung versuchen.

Beginnen wir mit dem Einsatz von Webtechnologien. Um eine Webapplikation für die mobilen Systeme zu erstellen, steht Ihnen die gesamte Bandbreite der Webtechnologien zur Auswahl. Insbesondere die gängigen Bibliotheken und Frameworks können verwendet werden. Eine Webapplikation läuft komplett auf dem Server und ist für den Fall der Ausführung auf einem Smartphone/Tablet insbesondere hinsichtlich der Darstellung des User Interface angepasst. Viele moderne User-Interface-Bibliotheken sind unmittelbar auf eine responsive Darstellung ausgerichtet, d. h., sie passen diese direkt an die Größe und Platzverhältnisse des Zielgerätes an. Ein typisches Beispiel ist die häufig und gern eingesetzte UI-Bibliothek Bootstrap [5]. Diese bietet Layoutcontainer und Controls, u. a. eine Navigation, die sich automatisch an die Bildschirmgröße des Endgerätes anpasst. Webtechnologien basieren final immer auf den Elementen HTML (Struktur), CSS (Design) und JavaScript (Interaktion, Logik). Andere Technologien, zum Beispiel TypeScript statt JavaScript, können wir natürlich ersetzend bzw. zusätzlich anwenden, letztendlich wird die App jedoch durch den Browser auf dem Smartphone ausgeführt und dieser verarbeitet nun einmal lediglich diese Sprachen. Weitere Frameworks, um Webapplikationen für (primär) mobile Devices zu erstellen sind u. a. Framework7 [6], Ionic Framework [7], Onsen UI [8] und Tizen [9]. Die Liste ließe sich noch eine ganze Weile fortsetzen, ohne dabei den Anspruch zu erheben, vollständig zu sein. Hier kommt es u. a. auch darauf an, mit welchen weiteren Tools und Frameworks man die App bauen möchte. Die UI Frameworks können weitgehend miteinander kombiniert werden, sodass dem Entwickler maximale Entscheidungsfreiheit, aber auch die Qual der Wahl bleibt.

Kommen wir jetzt zu den hybriden Technologien. Auch hier ist der Entwickler bei der Auswahl nicht auf ein System festgelegt. Für die Entwicklung stehen mehrere Frameworks zur Verfügung, zum Beispiel Cordova der Apache Software Foundation oder Appcelerator Titanium Mobile. Das Prinzip ist stets ähnlich: Die App öffnet beim Starten ein Browserfenster im Vollbildmodus, sodass der Browser als solcher nicht identifizierbar ist. Die Webadresse kann nicht geändert werden. In dieser WebView wird die mit HTML, CSS und JavaScript erstellte Web-App angezeigt. Die Web-App kann weitere Bibliotheken und Frameworks einsetzen, beispielsweise für eine vereinfachte Gestaltung des User Interface. Wir haben hier die gleiche Auswahl an Werkzeugen wie bei einer Webapplikation. Über das Framework, zum Beispiel Cordova, bekommt die App Zugriff auf Systemfunktionen wie die Kamera oder das Adressbuch. Das geschieht mit Hilfe von Plug-ins. Das hybride App-Framework bietet damit den Rahmen für die App und simuliert für das Betriebssystem die Funktionsweise einer nativen App. Exemplarisch zeigt Abbildung 4 den Systemaufbau auf der Basis von Apache Cordova.

Abb. 4: Architektur einer hybriden App am Beispiel von Apache Cordova [10]

Sehen wir uns das etwas genauer an: Links oben haben wir den Kasten Web-App. Dieser stellt die eigentliche Applikation in Form einer interaktiven Webseite, d. h. einer Webapplikation dar. Statt in einem externen Browser läuft diese App nun aber in der WebView, also dem von Cordova bereitgestellten internen Browser. Genutzt werden herkömmliche HTML APIs und spezifische APIs von Cordova. Für Systemzugriffe (Sensoren, Dienste, Daten usw.) werden eigens von Cordova angebotene Plug-ins verwendet (rechter Kasten oben). Die Verfügbarkeit und Leistungsfähigkeit dieser Plug-ins bestimmt also den möglichen Funktionsumfang einer hybriden App. Ebenso kapseln die Plug-ins die Unterschiede in den Zielsystemen (Android und iOS). In der Folge nutzt der Entwickler nur das generische Cordova API und das System sorgt für die korrekte Umsetzung auf dem Zielsystem. Das mobile Betriebssystem stellt auch hier die Funktionen über APIs bereit (blauer Kasten unten).

Nach den nativen, webbasierten und hybriden Apps kommen wir nun zum Cross-Plattform-Vorgehen. Es gibt inzwischen eine große Anzahl von Cross-Plattform-Ansätzen, die in der Herangehensweise sehr unterschiedlich sind. In Tabelle 1 sind aktuell verfügbare Methoden mit ihren wichtigsten Eigenschaften zusammengetragen.

Tab. 1: Plattformübergreifende Ansätze zur App-Programmierung für Android und iOS

Ein „ideales“ Vorgehen gibt es nicht. Jeder dieser Ansätze bietet Vor- und Nachteile. Dabei können wir feststellen, dass eine Reihe von Ansätzen aus den Werkzeugen, Programmiersprachen und Ressourcen, d. h. Bibliotheken und Frameworks, der Webentwicklung stammen. Dazu zählen zum Beispiel NativeScript und React Native. Andere Ansätze, zum Beispiel Xamarin, sind eher an die Vorgehensweise der Entwicklung von klassischen Desktopapplikationen angelehnt. Hier hat der Entwickler die Wahl.

Im kommenden Abschnitt sehen wir uns mögliche Hürden an, die es vor der Auswahl einer Technologie unbedingt zu berücksichtigen gilt.

Stolpersteine

Verwenden wir alternative Technologien, um eine App für Android und iOS zu erstellen, dann geht es in der Regel darum, beide Systeme gleichermaßen gut bedienbar zu machen. Folgende Stolpersteine müssen dabei in Betracht gezogen werden:

• User Interface: Viele Elemente sind auf beiden Systemen grundsätzlich gleich, ähnlich oder unterscheiden sich nur in der Art der Darstellung. Dennoch gibt es auch maßgebliche Unterschiede bei der Gestaltung. Wird das UI generisch über eine Abstraktionsschicht gestaltet, muss es sich dabei stets um einen Kompromiss handeln. Einige Elemente können dabei vom jeweiligen Framework sehr gut auf die nativen Elemente der Zielplattform umgesetzt werden. Das gilt dann, wenn das betreffende Element grundsätzlich vorhanden ist, zum Beispiel ein Tabbed Interface (Registerkarten). Diese werden unter iOS am unteren und unter Android am oberen Bildschirmrand angezeigt. Spezifika einer Plattform müssen jedoch außen vor bleiben. Wird von einem Ansatz ein eigenes Rendering der Benutzeroberfläche verwendet, dann können die Apps zwar auf beiden Systemen identisch aussehen, aber auf einem System wirkt das meist etwas befremdlich.
• Hardwareinteraktion (Sensoren): Dabei kommt es darauf an, welche tiefgehende Nutzung von Hardware auf den mobilen Geräten gefordert ist. Eine Nutzung der „Standardsensoren“, wie Geolocation, Kamera usw., ist mit nahezu jedem Framework möglich. Auch aus Webapplikationen kann man bereits über die neuen HTML APIs auf bestimmte Gerätesensoren zugreifen. Bei hybriden Apps und bei einer geräteübergreifenden Vorgehensweise nutzt man in der Regel Plug-ins u. Ä., um eine Abstraktion aus Sicht des Entwicklers zu erreichen. Sehr neue und gerätespezifische Hardware, zum Beispiel die neusten Hardwarefeatures eines iPhone oder eines Premium-Devices mit Android-Betriebssystem, kann man nicht über diese Abstraktionsschicht ansprechen. Hier muss man die herstellerspezifischen SDKs einsetzen (Kasten: „Technologie bei der Corona-Warn-App“).
• Abhängigkeit vom Framework: Die Unabhängigkeit von den APIs der Zielsysteme erkauft man sich durch eine Abhängigkeit vom System. Sehr lange laufende Projekte sind dann auf die regelmäßige Aktualisierung der Module und Bibliotheken des Vorgehensmodells angewiesen. Das kann bei der Auswahl der projektindividuellen Vorgehensweise ein ausschlaggebender Grund sein.
• Deployment über den Store: Die App muss zu einem Package verpackt werden, damit man das Deployment über die Stores von Apple und Google nutzen kann. Webapplikationen ermöglichen das nicht. Mit hybriden Apps und plattformübergreifenden Ansätzen dürfte es in der Regel keine Probleme mit dieser Art des Deployments geben.

Technologie bei der Corona-Warn-App

Auf GitHub kann man die fortlaufende Entwicklung dieser App verfolgen [11]. Zum Zeitpunkt der Erstellung des Artikels (Mitte Juni 2020) befand sie sich gerade in der finalen Phase der Entwicklung. Wenn Sie dieses Heft lesen, ist die App bereits im aktiven Einsatz. Uns interessiert ein Blick auf die Repositories der iOS- und Android-Apps. Beide Apps sind mit nativen Technologien programmiert, d. h. Android mit Kotlin und iOS mit Swift. Eine andere Option wird auch nicht bestanden haben, denn man musste für die Feststellung der Abstände die Technik Bluetooth Low Energy (BLE), ausgeführt in einem Hintergrunddienst, verwenden. Dazu war es notwendig, tiefgehend auf die Gerätehardware zuzugreifen. Nach vorliegenden Informationen hat Apple eine entsprechende Schnittstelle eingebaut. Diese Programmierschnittstelle ist zum aktuellen Zeitpunkt noch in keinem Framework zur plattformübergreifenden Programmierung gekapselt, sodass in der Tat nur eine aufwendige native Entwicklung für jede Plattform übrigblieb.

In der Praxis stellt sich dabei immer wieder die Frage nach der „Tauglichkeit“ eines Vorgehens im konkreten Projektfall. Wie soll man vorgehen, um nicht den falschen Ansatz zu wählen, aber gleichzeitig auch das Feld der Technologien nicht sofort zu stark einzuschränken? Es hat sich bewährt, nach den kritischen Stellen in einem App-Projekt zu suchen. Typische Beispiele für die kritischen funktionalen Aspekte können sein:

• besondere Anforderungen bei der Nutzung von Sensoren
• Nutzung von plattformspezifischen UI-Elementen
• Notwendigkeit einer sehr hohen Performance

Haben Sie derartige Anforderungen in Ihrem App-Projekt, kann das ein Hinweis sein, dass man tatsächlich nur mit einer nativen App zum Ziel kommt. Sofern man mit einer möglicherweise anderen Technologie keine Erfahrungen in den identifizierten Bereichen hat, kann ein schneller Prototyp (Rapid Prototyping) darüber Auskunft geben. Geeignet sind dabei vertikale Prototypen. Im Gegensatz zu horizontalen Prototypen, zum Beispiel der Oberfläche, sind diese ein Querschnitt durch die gesamte App für eine bestimmte Funktion. Wir können damit zum Beispiel das Funktionieren einer bestimmten Anforderung über alle Schichten der App (User Interface, Logik, Daten, Backend) zeigen. Dabei kommt es nicht auf Details an. Es muss lediglich verifiziert werden, dass das Vorgehen grundsätzlich funktioniert und die Methode geeignet ist.

Fazit und Ausblick

In diesem Artikel haben wir einen Überblick über die inzwischen sehr vielfältigen Optionen zur App-Programmierung für die mobilen Geräte gegeben. Dabei wird es Ihnen höchstwahrscheinlich so gehen, dass Sie von der Vielfalt der Möglichkeiten fast überfordert sind. Die Frage nach der besten Vorgehensweise kann man nicht seriös beantworten. Alle vorgestellten Technologien gelten als ausgereift und funktionieren. Die meisten App-Ideen (Anforderungen) wird man damit umsetzen können. Stolpersteine wird es in jedem Projekt geben, denn der „Teufel steckt bekanntermaßen im Detail“. Native Applikationen sind immer dann das Mittel der Wahl, wenn die App funktional sehr umfassend ist, intensive Hardwareinteraktion gefragt ist und das Projekt eine sehr lange Laufzeit hat. Zeit, Budget und Kenntnisse (Teams) zu beiden Plattformen werden jedoch vorausgesetzt.

Weitere Informationen zu diesen und anderen IT-Themen finden Sie unter http://larinet.com.

Links & Literatur__________________________________________________________________________________________________________________________________

[1] https://clearbridgemobile.com/mobile-app-development-native-vs-web-vs-hybrid/

[2] https://www.macincloud.com

[3] https://kotlinlang.org/docs/reference/

[4] https://www.jetbrains.com/help/idea/designer-tool-window.html

[5] https://getbootstrap.com

[6] https://framework7.io

[7] https://ionicframework.com

[8] https://onsen.io

[9] https://developer.tizen.org

[10] https://cordova.apache.org/docs/en/latest/guide/overview/

[11] https://github.com/corona-warn-app

The post Zwei Systeme und unendliche Möglichkeiten appeared first on MobileTechCon.

Wer traditionelle IDEs wie IntelliJ startet, kennt das: man muss erst einmal eine Weile warten, bis diese lahmen Dinger endlich bereit sind. Programmiersprachen wie Java erlauben zwar
langlaufende Operationen im Hintergrund zu starten, aber der Programmierer muss das immer explizit machen, und um ehrlich zu sein, so richtig elegant ist das nicht in den APIs verankert. Und wenn etwas nicht einfach ist, bzw. man nicht dazu gezwungen wird, macht man es auch eher nicht. Dart löst das anders. Operationen, die potenziell langsam sein können, wie File-Operationen oder Netzwerkzugriff, sind immer asynchron. Das heißt, man kann sie gar nicht explizit synchron aufrufen.

Zurück in die Future

Rufe ich in Dart eine Operation auf, die potenziell langsam sein könnte, bekomme ich nie direkt ein Objekt zurück, sondern immer ein Future, getypt mit dem eigentlich Objekttyp. Dieses Future hat zwei Stati, uncompleted und completed. Das Future führt die langlaufende Operation also aus und ist zunächst im Status uncompleted. Irgendwann ist die langlaufende Operation fertig und das Future ist completed. Dart bietet Code, der nicht auch asynchron ist, keine Möglichkeit, synchron auf das eigentliche Objekt zuzugreifen. Was eventuell hier noch wie Bevormundung der Entwicklergemeinschaft klingt, verhindert, dass man es sich als Programmierer leichtmachen kann und doch mal eben schnell auf das Objekt zugreift. „Wird schon nicht so lange laufen“-Denken wird hier gar nicht erst zugelassen.
Damit man aber noch etwas mit dem Future anfangen kann, kann man einen Callback registrieren, der von Dart aufgerufen wird, wenn das Future fertig ist. Damit haben wir in Dart das „Hollywood Design“-Prinzip für langsame Operationen: Versuchen Sie nicht, uns anzurufen, wir rufen Sie an. Sobald Dart das Future angeführt hat, wird der Clientcode aufgerufen, im neuen IT-Slang auch reaktives Programmieren genannt und zurzeit mit den reactive Extensions von Microsoft sehr populär. Klingt kompliziert? Ist es aber gar nicht: Listing 1 zeigt eine Dart-Methode, die einen langsamen Zugriff simuliert. Es wird mit drei Sekunden Verzug die Zahl 77 als Future berechnet.

Listing 1: Zugriffszahl in Dart Future

                                                                                                                     
Future getUserId() {
// simuliert eine langlaufende Operation
return Future.delayed(Duration(seconds: 3), () => 77);

Wer immer diese Methode aufruft, bekommt sofort das Future zurück, d. h. die Berechnung des Callers kann weiterlaufen. Über den Callback kann man auf das Ergebnis reagieren, wenn das Future completed ist (Listing 2).

Listing 2: Callback ins Future

                                                                                                                                      </strong></code>
void main() {
var userIdFuture = getUserId();
// hier registieren wir unseren Callback
userIdFuture.then((userId) =&gt; print(userId));

// Hello wird vor 77 ausgegeben, 77 wird erst nach 3 Sekunden ausgegeben
print('Hello');
}

Warte mal!
So weit, so gut. Manchmal kann das Registrieren von Callbacks, insbesondere dann, wenn man mehrere asynchrone Calls verschachteln will, doch recht komplex werden. Und Dart soll einfach bleiben, oder? Stimmt. Und deshalb kann man doch synchron auf das Ergebnis eines asynchronen Calls zugreifen, wenn man auch asynchron läuft. Asynchroner Code darf also synchron auf asynchrone Ergebnisse zugreifen. So darf eine Methode, die asynchron ist, einen REST-Call synchron absetzen und dann mit dem Ergebnis noch einmal einen Netzwerk-Call durchführen und das Ergebnis am Ende wieder als Future zurückgeben.
Eine Methode markiert sich in Dart mit dem async-Keyword als asynchron. Um den Wert eines Futures in einer solchen Methode synchron zu bekommen, wird await verwendet. Wahrscheinlich erklärt das ein Codebeispiel besser. Wir nutzen hier unsere alte getUserId()-Methode, die im synchronen Fall ein Future zurückgibt mit dem await, um auf das Ergebnis zu warten. Das geht wie gesagt nur, weil unsere Methode mit async markiert ist (Listing 3).

Listing 3: async/await

                                                                                                                                              </strong></code>
Future getUserName() async {
var userId = await getUserId();
return Future.delayed(Duration(seconds: 1), () =&gt; "Username $userId");
}

Bisher war das alles Dart-Code. Damit wir dem Titel des Artikels noch gerecht werden, kommen wir nun zu Flutter.
Die Futures in Flutter
In Flutter sind alles Widgets. Wie spielt Flutter mit Futures zusammen? Man könnte natürlich einen Callback auf dem Flutter registrieren und in diesem Callback dann den State in einem StatefulWidget updaten und diesen State zum Bauen der Widget Hierarchy verwenden. Also in Pseudologik: Wenn ich noch keine Daten habe, dann zeige einen Platzhalter. Wenn die Daten kommen, baue mein UI neu mit den neuen Daten. Das würde gehen, wäre aber nicht so elegant, weil Dart ja sehr häufig Futures nutzt. Von daher hat Flutter das FutureBuilder-Widget. Dieses erlaubt es, effizient mit Futures zu arbeiten. Für das Beispiel erzeugt man eine Flutter-App wie im letzten Teil oder unter [2] beschrieben. Dann muss man in sein pubspec yaml noch http: ^0.12.0+4 als Dependency hinzufügen (Listing 4).

Listing 4: Dependency in Flutter

  
dependencies:
flutter:
sdk: flutter
http: ^0.12.0+4

Dann kann man sein Datenmodell schreiben und es im Internet mit JSON füllen (Listing 5). Das Ganze ist asynchron.

Listing 5: Datenmodell schreiben

  
class Todo {
int userId;
String title;
bool completed;

Todo._internal({this.userId, this.completed, this.title});
factory Todo(Map<String, dynamic> map) {
var userId = map['userId'];
bool completed = map['completed'];
var title = map['title'];

return Todo._internal(userId: userId, completed: completed, title: title);
}
}

Future<List> _getTodos() async {
List todos = List();
http.Response response =
await http.get("https://jsonplaceholder.typicode.com/todos");
if (response.statusCode == 200) {
String body = response.body;
var json = jsonDecode(body);
for (Map<String, dynamic> map in json) {
todos.add(Todo(map));
}
}
return todos;
}

Dieses Future kann man dann mit dem FutureBuilder verwenden. In Listing 6 ist ein Widget zu sehen, das es nutzt. Das muss man nur noch in seiner App einbauen, wie im letzten Teil oder in [2] beschrieben.

Listing 6: FutureBuilder

  
import 'package:flutter/material.dart';
import 'package:http/http.dart' as http;
import 'dart:convert';

class TodoListWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Container(
child: FutureBuilder(
builder: (context, AsyncSnapshot<List> snapshot) {
if (snapshot.hasData) {
return ListView.builder(
padding: EdgeInsets.all(16),
itemCount: snapshot.data.length,
itemBuilder: (context, number) {
return Container(
decoration: BoxDecoration(
border: Border.all(color: Colors.grey),
borderRadius: BorderRadius.circular(5.0),
),
child: ListTile(
title: Text("${snapshot.data[number].title}"),
subtitle: Text("${snapshot.data[number].completed}"),
),
);
},
);
} else {
return Center(child: CircularProgressIndicator());
}
},
future: _getTodos(),
),
);
}
}

Das Ganze sieht dann so aus wie in Abbildung 1. Wir haben also eine Liste erzeugt, die wir asynchron mit geparstem JSON befüllt haben. Und das alles in ca. 70 Zeilen Code. Ganz schön beeindruckend, finde ich.

Links & Literatur
[1] Entwickler Magazin 1.20: Flutter-haft. Mobiles Entwicklen mit dem Flutter SDK. Lars Vogel, Jonas Hungershausen.
[2] https://www.vogella.com/tutorials/Flutter/article.html

The post Flutter – Einblick in die Future appeared first on MobileTechCon.

Technischer Unterbau
Wenn man mit dem Flutter SDK mobile Applikationen schreibt, nutzt man die Programmiersprache Dart, eine ehemalige JavaScript-Alternative aus dem Hause Google. Dart existiert schon länger und wurde der Welt bereits öfter feilgeboten, fand bisher aber kaum Akzeptanz. Inzwischen hat Google wohl sein AdWords Frontend auf Dart umgeschrieben und positioniert Dart mit Flutter wieder neu.
Dart ist eine effiziente, Java- bzw. C#-nahe Sprache, die einige Features beinhaltet, die der Entwicklergemeinde das Leben leichter machen sollen. Dart in Kombination mit Flutter erfindet sicherlich nicht das Rad neu, hat aber im Vergleich zu Java die folgenden interessanten Eigenschaften:

• Benannte und optionale Parameter: Methoden und Konstruktoren können Parameter als optional deklarieren. Aufrufer können gezielt Parameter angeben, die verwendet werden sollen. Damit kann eine Methode viele Parameter enthalten, der Aufrufer muss aber nur die relevanten mitgeben. Dadurch entfallen unnötige Parameterplatzhalter wie meineMethode(10, null, null, null, 4, null, null).
• Hot Reload: Änderungen im Quellcode werden in den meisten Fällen on the fly übernommen. Dadurch wird der Zyklus Änderung – Deployment – Test deutlich beschleunigt. Während sich das Bauen und das Deployment für die native Android-Entwicklung träge und altbacken anfühlen, mutet die Flutter-Entwicklung dynamisch und modern an.
• Rendering: Flutter übernimmt das komplette Rendering der Applikation. Dabei werden viele bekannte Widgets der Zielplattformen bereitgestellt. Diese können nativ aussehen oder auch individuell gestylt werden. Unter Android wird eine Aktivität erzeugt, die dann die Flutter Engine lädt, die danach das Zeichnen übernimmt.

Installation des Flutter SDKs und der Entwicklungstools
Die Installation von Flutter ist schnell erledigt, doch eine genaue Beschreibung würde diesen Artikel unnötig verlängern. Deshalb haben wir die entsprechenden offiziellen Links in unserem freien Flutter-Tutorial [1] gesammelt. Wir aktualisieren sie auch stetig, sodass sie immer aktuell sein sollten.
Als Entwicklungsumgebung empfehlen wir Visual Studio Code, auch wenn im Prinzip ein beliebiger Texteditor und eine Kommandozeile ausreichen. Android Studio kann man auch verwenden, doch fühlt sich die Flutter-Entwicklung dann nicht mehr so innovativ an, da man wieder die gleiche träge IntelliJ-IDEA-Variante verwenden muss, die man eventuell schon während der nativen Android-Entwicklung im Einsatz hatte. Einer der Gründe, warum die mobile Entwicklung mit Flutter effizienter ist, ist die mögliche Verwendung leichtgewichtiger Tools wie Visual Studio Code. Diese Chance sollte man auch nutzen.

Kann man Flutter-Applikationen auch mit der Eclipse IDE entwickeln?
Android-Entwickler neigen dazu, ihre Werkzeuge nicht zu mögen, da die Android Tools leider immer recht langsam und instabil waren. Da die Eclipse IDE außerhalb der Android-Entwicklung immer noch sehr populär ist und in jedem Release schneller und besser wird, stellt sich für den einen oder anderen die Frage, ob sie auch für die Flutter-Entwicklung verwendet werden kann. Hier arbeitet Jonas, einer der Autoren dieses Artikels, zurzeit daran, den technischen Unterbau von Visual Studio Code auch in die Eclipse IDE zu integrieren. Sobald das gelungen ist, sollte man die gleiche Editorfunktionalität von Visual Studio Code auch in Eclipse nutzen können. Interessierte Leser können dem Fortschritt unter [2] folgen.

Eine erste Flutter-Applikation
Sind die Tools installiert, kann man am schnellsten mit flutter create meinerstesfluttterproject sein erstes Flutter-Projekt über die Kommandozeile anlegen. Danach wechselt man in das entsprechende Verzeichnis, und mit code öffnet man seine Entwicklungsumgebung.
Schaut man sich die generierte Applikation an, erkennt man eventuell bekannte Strukturen aus Android- und macOS-Entwicklungen. Im Ordner android bzw. ios liegen generierte Anwendungsgerüste, die für die nativen Applikationen verwendet werden. Für die Entwicklung mit Flutter ist der Ordner lib der wichtigste. Hier liegen die .dart-Dateien, die den gesamten Flutter-Quellcode enthalten. Die Datei main.dart definiert in der main-Methode den Einstiegspunkt für unsere Applikation: void main() => runApp(MyApp());
Eine weitere wichtige Datei ist puspec.yaml. Sie beschreibt im Prinzip Applikationsmetadaten wie die verwendete SDK-Version, externe Dependencies sowie interne Ressourcen wie Bilder oder Schriftarten. Hat man, wie in der Anleitung zur Installation beschrieben, einen Android-Emulator angelegt bzw. sein physikalisches Gerät verbunden, kann man die Applikation mit F5 starten. Man sieht dann das generierte UI mit einem Zähler und einem Button, der den Zähler hochtreibt (Abb. 1).

Abb. 1: Ein erstes Flutter-Projekt

Sucht man in main.dart nach primarySwatch, kann man die generierte Farbe auf Colors.red setzen und nach dem Speichern den Hot Reload sowie die neue Farbe im Emulator bewundern.

Alles ist ein Widget
In Flutter wird das UI über Widgets aufgebaut. Ein Widget kann wiederum ein oder mehrere Children Widgets haben und Applikationslogik über Methoden definieren. Jedes Element auf dem Bildschirm ist ein Widget – von einfachen Buttons über komplexere Scrolling Lists bis hin zur ganzen Seite. Das hat den Vorteil, dass auch aufwendige UI-Komponenten recht einfach überall wieder genutzt werden können.
Das Flutter SDK kommt schon mit einer großen Menge an Widgets daher, die einem den Einstieg leichter machen. Gestylte Buttons, Dialoge und Navigationsleisten lassen sich einfach in die App einbauen. Hierbei gibt es für die meisten Elemente sowohl eine Material-(Android-)Version als auch eine für die iOS-Plattform im Cupertino-Stil. Es lässt sich also für beide Plattformen recht einfach das jeweilige Look and Feel implementieren.
Selbstverständlich ist es auch möglich, eigene Widgets zu bauen. Ein Widget ist eine Klasse, die von StatelessWidget oder StatefulWidget erbt. Erstere sollte benutzt werden, wenn das Widget keine Variablen besitzt, die während der Laufzeit verändert werden, wie zum Beispiel eine Informationskarte. Das Stateless Widget hat eine abstrakte build-Methode, die immer implementiert werden muss. Sie wird genutzt, um andere Widgets zu definieren, und bekommt zusätzlich einen BuildContext, über den viele Informationen zur aktuellen Applikationsinstanz oder dem Gerät verfügbar sind. Zusätzlich müssen alle Variablen der Klasse als final markiert werden, da Veränderungen an ihnen unangenehme Nebeneffekte zur Folge haben können. Dart hat hier leider keine Möglichkeit, dies zur Kompilierzeit zu erzwingen, und daher wird nur eine Warnung in VS Code angezeigt (Listing 1).

Listing 1: Dart
class Homepage extends StatelessWidget {
final int count;

Homepage({this.count});

@override
Widget build(BuildContext context) {
return Text(‘Pressed: $count’);
}
}

Ein Stateful Widget bietet hingegen die Möglichkeit, die eigenen Variablen zu verändern. Das Framework kümmert sich dann automatisch darum, die betroffenen Widgets neu zu rendern. Im Gegensatz zum Stateless Widget benötigt das Stateful Widget noch eine weitere Klasse, die den aktuellen Zustand des Widgets beinhaltet, denn auch die Variablen dieses Widgets müssen final sein. Eine State-Instanz wird in der Methode createState des StatefulWidgets zurückgegeben und muss dabei eine Klasse sein, die von State erbt, wobei „T“ das zugehörige Stateful Widget ist. Diese Klasse hat wiederum die abstrakte Methode build, die die Widgets zurückgibt.
Außerdem kann diese Klasse nicht finale Felder aufweisen, die während der Laufzeit verändert werden können. Hierfür steht die Methode setState(() {}) zur Verfügung. In der Funktion, die ihr übergeben wird, können Instanzvariablen der Klasse verändert werden, und sie löst daraufhin ein Re-render des aktuellen Widgets aus. Hierbei sollte darauf geachtet werden, dass nur die Änderung der Variable selber in der Methode aufgerufen wird und nicht etwa die Berechnung oder gar eine Netzwerkabfrage (Listing 2).

Listing 2
class Homepage extends StatefulWidget {
@override
_HomepageState createState() => _HomepageState();
}

class _HomepageState extends State {
int count = 0;

@override
Widget build(BuildContext context) {
return MaterialButton(
child: Text(‘Pressed: $count’),
onPressed: () => setState(() => count++),
);
}
}

Da jedes Element in einer Flutter-Applikation ein Widget ist, gibt es auch das Konzept von Activities oder Pages nicht mehr. Jede Seite der App ist nur ein weiteres Widget, das sich ebenso gut in anderen Widgets unterbringen lässt. So ist es zum Beispiel recht einfach, eine App sowohl auf dem Smartphone als auch auf dem Tablet gut aussehen zu lassen. Hier genügt meist nur eine Abfrage der Orientation und der Bildschirmabmessungen, und schon lassen sich zwei Seiten nebeneinander rendern. Beispielsweise ist der Screenshot in Abbildung 2 einfach eine Ansammlung von Center, Row, Column, Text, Button und ListWidgets in weniger als 140 Zeilen Code. Das Beispiel findet sich bei GitHub unter [3] im Verzeichnis layoutsexample.

Abb. 2: Layoutbeispiel

Fazit: Mobile Entwicklung ohne Rattenschwänze
Während den iOS-Entwicklern mit Swift eine relativ moderne Entwicklungsumgebung zur Verfügung steht, wirkt die native Android-Entwicklung mit Java oder Kotlin etwas veraltet. XML Layouts werden geschrieben, externe Libraries stellen Lösungen bereit, damit Daten beim Drehen des Geräts nicht verloren gehen, und die Verwendung von Activities und Fragments fühlt sich immer noch nicht elegant an. Darüber hinaus ist und bleibt Android Studio buggy und träge. Man merkt eben, dass Android inzwischen auch schon mehr als 10 Jahre auf dem Buckel hat und viele Altlasten mitschleppt.
Daneben strahlt Flutter wie eine aufgehende Sonne. Durchdachte Konzepte mit Stateful Widgets und Stateless Widgets inklusive Ablauflogik, ein einheitliches UI-Design und eine moderne Programmiersprache wie Dart machen in Verbindung mit effizienten Tools einfach Spaß. Für neue Android-Projekte empfehlen wir deshalb definitiv Flutter – und als Nebeneffekt bekommt man auch noch eine solide iOS-Applikation dazu.

The post Flutterhaft | Mobiles Entwickeln mit dem Flutter SDK appeared first on MobileTechCon.

Jörg Neumann: Eine gute Usability zeichnet sich vor allem dadurch aus, dass die App einen wirklichen Mehrwert bietet und dabei intuitiv zu bedienen ist. Das hört sich jedoch leichter an, als es ist. Denn nur, wenn man die Anwender mit ihren unterschiedlichen Eigenarten, Bedürfnissen und Wünschen versteht, kann man sie aktiv unterstützen. Design-Thinking-Techniken sind bei dieser Analyse sehr hilfreich.

JAXenter: Um die Anwender einer App proaktiv zu unterstützen, rätst Du zu Storyboards. Wie sieht ein gutes Storyboard aus und was sind seine Vorteile?

Jörg Neumann: Anders als Sketches oder Wireframes bieten Storyboards ein konkretes Design. Das hilft insbesondere bei der Kommunikation mit dem Kunden, da diese eine sehr genaue Vorstellung davon bekommen, wie die App später aussehen wird. Zudem demonstriert ein Storyboard das Verhalten der App. So können Navigation und Animation direkt erlebt und bewertet werden, bevor die Implementierung beginnt. Dies spart eine Menge unnötige Arbeit und hilft auch dem Entwickler, denn ein Storyboard sagt mehr als tausend Seiten Konzept und Styleguide.

JAXenter: Kannst Du Tools empfehlen, die sich für das Erstellen von Storyboards besonders eignen?

Jörg Neumann: Ich arbeite gern mit Indigo Studio. Das ist sehr leicht zu erlernen, läuft auf PC sowie Mac und bietet insbesondere im Bereich State-Management einige nützliche Funktionen. Ansonsten finde ich Adobe XD super. Vor allem das Aufnehmen von Bedienvideos und das Übertragen der Entwürfe auf ein Mobilgerät sind hier besondere Stärken.

JAXenter: Wie lässt sich sicherstellen, dass ein Storyboard wirklich effektiv genutzt wird bzw. den gewünschten Erfolg umsetzt?

Jörg Neumann: Ein Storyboard muss man als gemeinsames Zielbild verstehen. Erst wenn alle daran glauben, kann daraus eine wirklich gute App entstehen. Daher ist es wichtig, bei jeder Diskussion und bei allem was der Einzelne im Team tut, das Storyboard als Grundlage zu verwenden. Jede Abweichung sollte vor der Umsetzung mit dem Team besprochen und im Anschluss zunächst im Storyboard geändert werden. Denn es bildet die Grundlage der Entwicklung über den gesamten Lifecycle der App.

JAXenter: Was ist, Deiner Meinung nach, die beste Programmiersprache für mobile Entwicklung?

Jörg Neumann: Typische Beraterantwort: Kommt darauf an! Wenn ich nur für iOS entwickle, finde ich Swift super. Heute sollte man sich jedoch mehr auf Cross-Plattform-Lösungen fokussieren. Hier bietet sich aus meiner Sicht Xamarin an, da ich damit native Apps erzeugen kann, obwohl ich in C# entwickle. Neuerdings finde ich auch Google Flutter sehr interessant. Damit können ebenfalls native Apps für iOS und Android entwickelt werden, jedoch mit Dart – was insbesondere für Web-Entwickler interessant sein dürfte.

JAXenter: Welches Thema wird dieses Jahr in der Mobile-Entwicklung besonders wichtig sein bzw. in welche Richtung geht es wohl in den nächsten Jahren?

Jörg Neumann: Nach dem Hype der letzten Jahre wird sich das Thema, aus meiner Sicht, vom Consumer-Bereich noch mehr in Richtung Business bewegen. Viele Unternehmen fangen aktuell erst an, ihre Prozesse zu mobilisieren. Zudem werden die Themen Machine Learning und Augmented Reality die Entwicklung mobiler Lösungen befördern.

JAXenter: Vielen Dank für das Interview!

Geschrieben von: Katharina Degenmann

The post Mobile-App-Entwicklung: „Eine gute Usability ist das A und O für eine App“ appeared first on MobileTechCon.

Pierre Liebsch: Aus technischer Sicht ist es eher eine Glaubensfrage, was eine gute App ausmacht. Wichtig ist, dass die Software gut wartbar ist. Bei mobilen Geräten sollte man außerdem einen genaueren Blick auf Performance und Energieverbrauch legen. Außerdem sollte man sich nach Möglichkeit im Vorfeld überlegen, ob man einzelne Features als Module bereitstellt.

JAXenter: Welche Tools sind für die Entwicklung einer Android-App unverzichtbar?

Pierre Liebsch: Zum Entwickeln setze ich auf die offizielle Entwicklungsumgebung Android Studio. Darüber hinaus kann es von Vorteil sein, Bildbearbeitungsprogramme wie Adobe Photoshop zu haben, um Icons erstellen oder anpassen zu können.

JAXenter: Wer muss sich alles an einen Tisch setzen, damit eine App nachhaltig Erfolg hat?

Pierre Liebsch: Wichtig für eine App sind vor allem der Nutzen sowie die Usability. Daher ist es unerlässlich, dass man den App User versteht. Sowohl zur Planung der Funktionalitäten als auch zum Gestalten des UI’s muss die Zielgruppe verstanden werden.

JAXenter: Welche Fehler machen Unternehmen oder Entwickler bei der App-Entwicklung am häufigsten? Hast Du eine “Flop 3”?

Pierre Liebsch:

1. Es werden Rechte angefragt, ohne dass der User weiß warum. Der User muss verstehen können, warum eine App auf beispielsweise die Kontakte zugreifen können möchte. Ansonsten wird dieser der App nicht trauen.
2. Leider wird gerade im mobilen Umfeld noch immer häufig das Schreiben von Tests ignoriert.
3. Overengineering: Es werden oft Features eingebaut, bei denen man glaubt, der Nutzer könnte sie brauchen, doch letztendlich finden sie nie Verwendung.

JAXenter: Welche Tipps würdest Du für den Bau einer erfolgreichen App geben? Kannst Du uns 3 Best Practices nennen?

Pierre Liebsch:

1. Kenne deine Zielgruppe.
2. Pflege deine App und beachte das Feedback der User.
3. Setze auf Standards, d.h. nutze dem User bekannte Icons und Bedienkonzepte, anstatt alles neu zu erfinden.

JAXenter: Wie sieht, Deiner Meinung nach, die Zukunft der App-Entwicklung aus?

Pierre Liebsch: Eine genaue Aussage über die Zukunft lässt sich z.Z. nur schwerlich treffen. Mit Fuchsia hat Google ein neues Betriebssystem geschaffen, welches u.a. für den mobilen Markt geeignet ist. Die Zukunft wird sich wohl stark danach richten, wie Google Fuchsia einsetzen wird.

JAXenter: Vielen Dank für das Interview!

Geschrieben von: Katharina Degenmann

The post Erfolgreiche App-Entwicklung: “Nutze bekannte Icons und Bedienkonzepte, anstatt alles neu zu erfinden” appeared first on MobileTechCon.

Manuel Rauber und Thomas Hilzendegen: Eine offlinefähige App bedeutet, dass sowohl der Anwendungsrahmen (der Code der App) als auch die Daten selbst offline zur Verfügung gestellt werden müssen und die App nicht einfach nur mit einem Fehler abstürzt. Gerade bei den Daten beginnen hier schon die ersten Use-Case-abhängigen Herausforderungen. Sollen die Daten nur gelesen werden? Oder sollen die Daten auch im Offlinemodus verändert/gelöscht werden können?

Sobald man über schreibende Zugriffe nachdenkt, kommt automatisch die Überlegung von Konfliktmanagement hinzu. Gewinnt der letzte schreibende Zugriff? Soll der Benutzer entscheiden können, was im Falle eines Konflikts passiert? Alle schreibenden Änderungen müssen im Offlinemodus auf dem Gerät gespeichert werden, sodass sie beim Onlinegehen an das API geschickt werden können. Hierbei ist auch zu beachten, wie IDs der neuen Datensätze generiert werden. Zusätzlich haben Browser unterschiedliche Limits in Bezug auf die zu speichernde Datenmenge.

Weitere Herausforderungen entstehen im Backend. Zum einen muss in jedem Datensatz ein Tracking von Änderungen möglich sein. Bspw. bietet der Microsoft SQL Server den Spaltentyp rowversion hierfür an. Er kann genutzt werden, um Schnittstellen (JSON-basierte Web-APIs) zu entwickeln, die auf Basis der rowversion Delta-Updates generieren. Hierbei handelt es sich um alle geänderten Daten auf Basis der zuletzt gespeicherten rowversion auf dem Client. Bei gelöschten Datensätzen müssen die IDs separat gespeichert werden, sodass diese auch Bestandteil des Delta-Updates sind.

Spannend wird das Vorhaben, wenn Daten auf Basis von Security (Benutzerrollen und -rechten) dem Benutzer nicht mehr zur Verfügung stehen, denn hierbei ändert sich mit hoher Wahrscheinlichkeit der eigentliche Datensatz nicht. Das bedeutet, dass sich die rowversion nicht ändert, dennoch muss dieser Datensatz als „vermeintlich gelöscht“ an den Client übertragen werden.

JAXenter: Progressive Web Apps versprechen hier Abhilfe. Wie funktionieren sie?

Rauber und Hilzendegen: Obwohl Progressive Web Apps die Eigenschaft „Offline“ in sich tragen, lösen PWAs nicht gleich alle Probleme. Eine PWA hilft, den Anwendungsrahmen (Code) offline zur Verfügung zu stellen, aber nur bedingt bei den Daten. Möchte man die Daten, die man bereits angeschaut hat, nur rein lesend „offline“ anzeigen, kann eine PWA mit dem Service Worker hier auch unterstützen. Bei einem echten Synchronisierungsvorgang hilft eine PWA aber leider nicht.

JAXenter: Wie hoch schätzt Ihr den Mehraufwand beim Erstellen einer Progressive Web App im Vergleich zu anderen Single-Page Applications ein?

Rauber und Hilzendegen: Eine PWA würden wir nicht als Mehraufwand bezeichnen. Die eigentliche Single-Page Application muss sowieso erstellt werden, da diese die normale Anwendung darstellt. PWA ist nur ein weiteres Feature dieser Anwendung. Da eine PWA aus verschiedenen Charakteristika besteht, die aus einer Anwendung eine PWA machen, ist es abhängig von den Anforderungen, die man unterstützen möchte und die das dazu passende Feature implementiert.

JAXenter: Wo liegen die Nachteile einer PWA?

Rauber und Hilzendegen: Aktuell ist zu beachten, dass noch nicht alle neuen APIs, die eine PWA ausmachen, unter allen Browsern zur Verfügung stehen. Zum Beispiel ist hier das Push API zu nennen, das bereits in Chrome (auch unter Android) funktioniert, aber es unter iOS noch nicht mal klar ist, ob es überhaupt seitens Apple implementiert werden wird.

Auch sollte man sich bewusst sein, dass eine offlinefähige App nicht unbedingt auch offlinefähige Daten bedeutet, da hierfür mehr nachgedacht und implementiert werden muss. Dazu kommt, dass gewisse APIs im PWA-Umfeld verwirrend benannt sind. Allen voran das Background Sync API, dessen Name vermeintlich bedeutet, dass man Synchronisationsvorgänge starten kann. Doch es handelt sich dabei vielmehr um einen intelligenten Scheduler, der es erlaubt, zu gewissen Zeitpunkten Code auszuführen. Die Entscheidung, ob dieser Code einen echten Synchronisierungsvorgang startet, obliegt dem Entwickler.

Generell gilt natürlich auch, dass gewisse Browserlimitationen auch bei PWAs gelten, sei es die Bereitstellung von Speicherplatz oder die allgemeine Browserperformance. Und, wie im Web üblich, gilt, dass nicht alle nativen Funktionen genutzt werden können, wenn der Browser hierfür generell kein API bereitstellt.

JAXenter: Ihr demonstriert in eurem Workshop beim MobileTech Conference & Summit die Entwicklung einer PWA mit Angular und .NET Core. Welche Besonderheiten gilt es bei der Entwicklung von PWAs mit Angular zu beachten?

Rauber und Hilzendegen: Bei PWAs mit Angular ist zu beachten, dass die Anwendung zwangsläufig als Production Build erzeugt werden muss, damit der Service Worker von Angular funktioniert. Dieser Build ist deutlich zeitintensiver als ein Development Build, weswegen die Entwicklungsgeschwindigkeit darunter leiden könnte.

Ansonsten sind generell die Besonderheiten von PWAs und dem Web als Applikationsplattform zu beachten, unabhängig davon, ob Angular oder ein anderes Framework eingesetzt wird.

JAXenter: Zum Schluss nochmal eine Einschätzung aus eurer Praxis: Wann lohnt sich der Mehraufwand einer PWA – und wann nicht?

Rauber und Hilzendegen: Nutzt man die vom Angular Service Worker gegebenen PWA-Funktionalitäten, ist der Mehraufwand im Vergleich zur eigentlichen Anwendung nicht sehr hoch. Im Vergleich zu einer echten App, die im jeweiligen Store veröffentlicht wird, hat man aber folgende Vorteile:

• Die App unterliegt nicht den Regulationen und Prüfungen des Store-Anbieters.
• Auch Updates können somit jederzeit bereitgestellt werden und müssen nicht erneut durch den jeweiligen Store-Anbieter überprüft und freigegeben werden.

Der Mehraufwand für eine PWA lohnt sich aktuell nicht, wenn das Hauptziel der App iOS-Benutzer sind, da die Unterstützung auf iOS für PWAs bisher sehr rudimentär ist und o. g. Vorteile nicht als notwendig erachtet werden oder generell eine native im Store erhältliche App gewünscht ist.

JAXenter: Vielen Dank für dieses Interview!

Geschrieben von: Hartmut Schlosser

Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser

The post Progressive Web Apps: So lässt sich die Lieblingsapp auch offline nutzen appeared first on MobileTechCon.

Till Krempel: Die größten Erfolge am Markt konnte Augmented Reality sicher im Gaming-Bereich verzeichnen, allerdings nutzen auch heute schon soziale Medien in ihren Kameras AR-Filter zum Aufwerten des Nutzer-Contents. Es gibt aber auch durchaus Szenarien mit echtem Mehrwert für den Nutzer, wie bei der Produktvorschau in den eigenen vier Wänden oder eben bei der Indoor-Navigation in öffentlichen Gebäuden. Es gibt außerdem viele weitere denkbare professionelle Anwendungsfälle, z.B. in Industrie, Bauwesen, Luftfahrt, Retail, Logistik oder Medizin. Diese werden aber oft nicht auf dem Smartphone stattfinden, sondern auf dedizierter Hardware.

Wenn die echte Welt zentimetergenau vermessbar wird, hat das Konsequenzen. Es werden ganz neue ortsgebundene Services möglich werden.

Die für Mobilgeräte meiner Einschätzung nach spannendsten Anwendungen sind jene, die nicht nur ad-hoc eine augmentierte Realität aufbauen und diese sofort wieder vergessen, sobald das „Spiel“ vorbei ist, sondern die eine parallele digitale Welt aufbauen, die auch mit der echten Realität in Zusammenhang steht. Durch die Fortschritte in den kamerabasierten Trackingverfahren wird es möglich, die Realität auf einem sehr viel feineren Detailgrad als bisher digital zu erschließen. Wenn die echte Welt zentimetergenau vermessbar wird, und das nur anhand der schon existierenden Milliarden Smartphones die die Menschen auf diesem Planeten benutzen, hat das Konsequenzen. Es werden so ganz neue ortsgebundene Services möglich werden, die wir bisher noch nicht kennen.

JAXenter: Hardwaregestützte Ansätze sind auf dem Markt gescheitert, Lösungen wie ARCore und arKit sind praktikabler, da hierfür keine spezielle zusätzliche Hardware nötig ist. Hat die Technologie rund um die Augmented Reality einen wichtigen Schritt gemacht, oder bedeutet das letztlich nur, dass die Endprodukte zwar funktionieren, aber besser funktionieren könnten, hätte man entsprechend dedizierte Hardware?

Till Krempel: Hardware ist kein Selbstzweck, sondern wird in der Regel immer erst dann angeschafft, wenn damit neue Dinge möglich werden, die der Nutzer braucht. Solange es nicht die „Killer-Anwendung“ gibt, die der Nutzer wirklich benötigt, wird sich niemand ein neues Hardware Device anschaffen.

Wir haben die Qualität des Motion Tracking auf ARCore und Tango verglichen und die Ergebnisse sind überraschend gut. Das zeigt, dass die Hardware eben nicht für alle Aspekte des Themas zwingend erforderlich ist. Der Schritt, die in Tango Devices verfügbaren Features mit kleinen Abstrichen für jeden verfügbar zu machen, der ein halbwegs aktuelles Device hat, ist daher eine erfreuliche Entwicklung. Dies wird der Verbreitung von AR-Anwendungen helfen.

JAXenter: Es wird gemunkelt, dass GPS möglicherweise bald von einem neuen Google-Service beerbt werden könnte. Glaubst du GPS ist eine Auslauftechnologie? Welche Vorteile hätte der „Visual Positioning Service“?

Till Krempel: VPS wird GPS meiner Einschätzung nach in naher Zukunft definitiv nicht ablösen, höchstens ergänzen. Allein schon für die Fahrzeugnavigation ist GPS unabdingbar. Der Vorteil einer rein visuell-basierten Lösung ist die Erschließung der Innenräume und die höhere Genauigkeit. Für den Service wird aber eine teils massive Datengrundlage in Form von visuellen Informationen benötigt, die, wenn man sich nicht aus vorhandenen Quellen erheben kann, auch erstmal erstellt werden muss. Theoretisch kann dann aber jedes Device, welches eine Kamera und eine Internetverbindung hat, die Technologie verwenden, solange die Verarbeitung in der Cloud stattfindet. In Kombination mit der Größenordnung des Android-Ökosystems, hängt die Etablierung hier eigentlich nur von der Leistungsfähigkeit des Systems und der Verfügbarkeit der Daten ab, wenn und falls es der Service in den Produktivbetrieb schafft.

JAXenter: Was wird kurzfristig und langfristig in Sachen Augmented Reality passieren?

Till Krempel: Ich denke man muss hier unterscheiden, welche Endgeräte wir betrachten. Bisher sind arKit und ARCore nur für Nutzer eines aktuellen Smartphones verfügbar. Dementsprechend sind die Märkte für die Anwendungen hier zwar im Vergleich zu Google Tango gewachsen, allerdings immer noch klein. Da die Leute voraussichtlich nicht so schnell aufhören werden, Smartphones zu kaufen, wird die Verfügbarkeit für diese Anwendungen steigen. So werden sich auch mehr Firmen für diese Technologien interessieren und sie für ihren Anwendungsfall bewerten.

Apple & Google werden die komplexen technologischen Grundlagen für Augmented Reality in iOS und Android implementieren – so wird aus dem Nischen-Feature ein Standard-Feature.

Virtual Reality wird schneller einen zufriedenstellenden Reifegrad erreichen, z.B. als Erweiterung des „klassischen“ Videobilds bei Live-Übertragungen von Events, wie bei den olympischen Winterspielen. Der Markt ist mittlerweile voll von VR Headsets der verschiedensten Hersteller und auch über Cardboard, GearVR oder Daydream kann man schon ohne größere Investitionen daran teilhaben. In diesem Bereich ist der Wettstreit, welche Plattform sich durchsetzt, schon in vollem Gange.

Die Hardware für AR ist hier noch in einem früheren Stadium, und obwohl die Qualität der Lösungen immer besser wird, ist die finanzielle Einstiegshürde für den Endverbrauchen noch zu hoch. Es wird daher noch etwas dauern, bis der Endverbraucher sich für kleines Geld eine AR-Brille kaufen kann, für die es auch genügend Anwendungen gibt. Bis dahin ist das Smartphone für diesen Bereich noch das Mittel der Wahl.

JAXenter: Welche Erkenntnis sollte jeder Besucher deiner Session mit nach Hause nehmen?

Till Krempel: Die Session wird sich vornehmlich mit den Fortschritten in Sachen ARCore und arKit beschäftigen. Wir werden das Feature-Set erläutern, aktuelle Beispiele sehen, die wir selbst entwickelt haben, und Anforderungen an die Entwicklung von AR Apps diskutieren. Auch ein Ausblick darauf, wie solche Technologien unseren Alltag und auch das Berufsleben verändern können soll diskutiert werden.

Perspektivisch werden Apple und Google die komplexen technologischen Grundlagen für Augmented Reality in die Plattformen iOS und Android implementieren. Damit wird AR von einem Nischen-Feature zu einem einfach nutzbaren Standard-Feature. Als Entwickler programmiere ich ja auch keinen eigenen Bluetooth Stack oder GPS-Empfänger, sondern nutze die Features des Betriebssystems, um meine Anforderungen zu realisieren. Gerade für Entwickler aus dem mobilen Umfeld ist die Umsetzung von AR Features so nie einfacher gewesen als heute.

Interviewt von: Dominik Mohilo

Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.

The post Augmented Reality – wo wir stehen und was auf uns zukommt appeared first on MobileTechCon.

Christian Schwendtner: Hallo Dominik, sehr gerne! GraphQL ist vorrangig eine flexible Abfragesprache. Das sieht man auch auf der offiziellen Seite von GraphQL, wo getitelt wird „A query language for your API“. Das trifft den Kern von GraphQL ganz gut, denn es stehen die Client-seitigen Datenbedürfnisse im Vordergrund, also die Möglichkeit, auf einfache und flexible Weise die benötigten Daten für Clients abfragen zu können.

Ein spannender Punkt ist hier sicher die Flexibilität, die der Client gewinnt. Dieser kann einfach und genau definieren, welche Daten (inklusive Relationen) er vom Server benötigt. GraphQL ermöglicht also eine sehr Client- bzw. Use-Case-orientierte Sicht. Der Client kann mit einem Request genau die Daten laden, die er für einen Use Case bzw. eine Bildschirmmaske benötigt (kein Under- oder Overfetching).

Wie unterscheidet sich GraphQL von RESTful Web Services?

Christian Schwendtner: Diese Frage bekomme ich sehr oft gestellt, wenn Personen das erste Mal mit GraphQL in Berührung kommen. Bevor man diese Frage beantworten kann, ist es meiner Meinung nach wichtig, den Begriff RESTful Web Services etwas genauer unter die Lupe zu nehmen. Der Begriff ist an sich gut definiert, wird in der Praxis aber oft sehr inflationär verwendet. Wir sagen sehr gern zu jedem Service, das Ressourcen, HTTP-Verben und HTTP-Statuscodes verwendet und Daten in JSON zur Verfügung stellt, REST. Genau genommen ist es das aber nicht. Von REST oder einem RESTful Web Service dürfte man eigentlich erst dann sprechen, wenn alle Kriterien, die Roy Fielding (der Erfinder von REST) definiert hat, erfüllt sind. Ein wichtiges Kriterium dabei ist HATEOAS, also Hypermedia As The Engine Of Application State. Gerade HATEOAS wird aber bei vielen Services, die angeblich RESTful sind, nicht oder nicht ausreichend umgesetzt.

Eine gute Möglichkeit, um eine Idee davon zu bekommen, „wie RESTful“ ein Service ist, bietet das Richardson Maturity Model. In ihm sind verschiedene Level definiert, je nachdem welche Aspekte von REST umgesetzt sind. Ein Service, der nur manche Kriterien von REST erfüllt (z.B. „nur“ Ressourcen, HTTP-Verben, Statuscodes aber nicht HATEOAS) wird gerne REST-ish, REST-like oder REST-wannabe genannt. Das klingt jetzt vielleicht etwas nach Haarspalterei, aber ich denke es ist wichtig, dass man sich darüber im Klaren ist was genau man mit GraphQL vergleicht – speziell, wenn es um den Vergleich mit RESTful Web Services geht.

Meiner Erfahrung nach kann man sagen, dass GraphQL eine gute Alternative zu Level 2 des Richardson Maturity Models darstellt (Verwendung von Ressourcen, HTTP-Verben, Statuscodes), aber nicht gut geeignet ist, um als Alternative zu „echten“ REST-Services zu gelten (Stichwort HATEOAS).

Ein wesentlicher Unterschied bei GraphQL ist die verpflichtende Verwendung eines Schemas. In einem GraphQL-Schema sind alle Typen, die abgefragt werden können (Queries), und Operationen, die durchgeführt werden können (Mutations), definiert. Dadurch ergibt sich die Möglichkeit, eine Abfrage schon zur Übersetzungszeit der Anwendung auf Korrektheit überprüfen zu können oder Features wie Code-Completion zur Verfügung zu stellen.

GraphQL bietet aber einige interessante Konzepte – z.B. Fragmente: Am Client kann man GraphQL-Fragmente verwenden, um ein großes Query in kleinere Teile aufzuteilen. Das kann verwendet werden, um das Query des jeweiligen Use Cases (bzw. der jeweiligen Maske) nicht an einer Stelle definieren zu müssen, sondern die Datenbedürfnisse pro UI-Komponente definieren zu können. Das hat den Vorteil, dass die Datenbedürfnisse dort definiert werden, wo sie am besten bekannt sind. Aus den Fragmenten kann dann ein (großes) Query zusammengesetzt werden, das alle Datenbedürfnisse aller Komponenten der jeweiligen Maske enthält und die benötigten Daten können dann mithilfe eines Querys – per Request – geladen werden.

Eine weitere interessante Sache bei GraphQL sind Subscriptions. Mit einer Subscription kann sich ein Client auf ein Event des Servers registrieren, um so über Änderungen informiert zu werden (z.B. unter Verwendung von WebSockets). So kann man sehr einfach Push-Funktionalität in Anwendungen realisieren. Man könnte sagen, dass GraphQL ein opinionated Ansatz ist – das bedeutet, dass für bestimmte Probleme bestimmte Lösungen vorgesehen sind, man bekommt also einen kompletten Lösungsansatz mit allen Vor- und Nachteilen.

Wo liegen die Schwächen von GraphQL?

Christian Schwendtner: Viele sind von der Einfachheit, wie man die Client-seitigen Datenbedürfnisse in GraphQL definiert, beeindruckt. Man darf aber auch nicht die Serverseite vergessen. Durch die Freiheit, die man am Client gewinnt, muss man am Server oft mehr Denkarbeit investieren, um nicht in Performance-Probleme zu laufen. Da der Client flexibel seine Datenbedürfnisse definieren kann – frei nach dem Motto „wünsch dir was“ – ist auf der Serverseite besonderes Augenmerk auf Performance zu legen. Das sollte nicht zu spät im Projekt geschehen.

Eine indirekte Schwäche von GraphQL ist, dass es manchmal als „REST 2.0“ oder als „das bessere REST“ angepriesen wird. Ich denke nicht, dass das stimmt. Hier werden oft unterschiedliche Dinge verglichen. Die Abfragesprache ist meiner Meinung nach keine Alternative für einen „echten“ REST-Service, aber durchaus für viele REST-ish Services, wie man sie sehr oft sieht. Bei denen geht es eher darum, auf einfache und flexible Art Daten für den Client zur Verfügung zu stellen.

Nehmen wir an, ich habe eine App entwickelt, die noch auf RESTful Web Services setzt, wie schwer wäre eine Umrüstung auf GraphQL und ist das überhaupt praktikabel?

Ich denke, dass sich RESTful Web Services und GraphQL gut ergänzen können. Man kann GraphQL als Gateway einsetzen, um dem Client eine einheitliche Sicht auf die Daten zu ermöglichen. Der GraphQL-Gateway würde dann nicht selbst die Daten (z.B. aus einer Datenbank) laden, sondern die vorhandenen REST-Endpunkte aufrufen und als Aggregationspunkt fungieren.

Man würde damit einem Client die Flexibilität von GraphQL zur Verfügung stellen und trotzdem die eigentlichen Services als RESTful Services belassen. Gerade bei Microservice-Architekturen kann diese Vorgehensweise durchaus sinnvoll sein.

Bei einem neuen Projekt kann man natürlich über den alleinigen Einsatz von GraphQL nachdenken. In diesem Fall würde ich die Entscheidung von der konkreten Problemstellung abhängig machen. Blind jedes Problem mit GraphQL zu lösen, halte ich nicht für den richtigen Ansatz.

Welche Erkenntnis sollte jeder Besucher deiner Session mit nach Hause nehmen?

Dass GraphQL ein interessanter Ansatz ist, aber auch nicht die Lösung für alle Probleme. Sehr oft suchen wir nach der Lösung für all unsere Probleme. Oft vergessen wir dabei vielleicht, auf das konkrete Problem einzugehen und manchmal landen wir dann an dem Punkt „Wir hatten zwar eine Lösung, aber sie passte nicht zum Problem“. Ich denke, dass die Verwendung von GraphQL sehr sinnvoll sein kann, aber dass es nicht alle unsere Probleme auf magische Weise löst.

Ich hoffe, dass bei meiner Session für REST-Liebhaber und -Gegner etwas dabei ist. Erstere können dann vielleicht die Session mit der Überzeugung verlassen, dass GraphQL nichts für sie ist und Letztere finden eventuell endlich das Tool ihrer Wahl.

In der täglichen Arbeit als Entwickler und Architekt muss man oft Entscheidungen für eine Technologie treffen. Wichtig ist nicht selten aber auch die fundierte Entscheidung gegen eine Technologie. Ich hoffe, dass meine Session etwas zur Entscheidungsfindung beitragen kann – für oder gegen GraphQL – beides ist ein legitimer und wichtiger Output.

Interviewt von: Dominik Mohilo

Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.

The post „GraphQL ist gut, aber keine Alternative zu echten REST-Services“ appeared first on MobileTechCon.

In einer weiteren Studie kam Forrester zu dem Ergebnis, dass 64 bis 70 Prozent der Unternehmensapps nicht angenommen werden, da die Nutzer – also die Mitarbeiter –schlechte Erfahrungen mit ihnen machten. Kein Wunder also, dass viele Unternehmen vor der Umsetzung von Unternehmensmobilitätslösungen immer noch zurückschrecken. Eine sorgfältige Angebotssichtung sollte deshalb an Anfang stehen.

Möglichkeiten bei der Umsetzung von Enterprise Mobility

Sowohl Anbieter von Mobilplattformen als auch Softwareanbieter bieten Möglichkeiten zur Umsetzung von Enterprise Mobility. Es muss jedoch immer im Einzelfall entschieden werden, für welche Option man sich entscheidet. Die Vorteile beider Anbieter sind im Folgenden beschrieben. Alternativ kann man natürlich auch auf einen Anbieter von maßgeschneiderten Anwendungen zurückgreifen.

Anbieter von Mobilplattformen: Wann sollte man sich dafür entscheiden?

Anbieter von Mobilplattformen können die richtige Wahl sein, wenn besonders komplexe kundenspezifische Prozesse umgesetzt werden sollen. Um das Mobilisierungsprojekt auf diese Weise realisieren zu können, müssen jedoch im Haus genügend Entwicklungsressourcen verfügbar sein. Anbieter von Mobilitätsplattformen erstellen in der Regel die Komponenten für den Aufbau der spezifischen Anwendung und einige Grundfunktionen. Das Inhouse-Entwickler-Team setzt auf diesen Bausteinen auf und entwickelt die Funktionalitäten weiter, abgerundet von einer individuellen Benutzeroberfläche. Diese Lösung bietet mehr Flexibilität als die Erweiterung vorhandener ERP-Lösungen auf mobile Nutzung, setzt aber entsprechendes Entwickler-Know-How voraus.

Softwareanbieter: Wann sollte man sich dafür entscheiden?

Falls Sie bereits eine Zusammenarbeit mit einem der großen Anbieter von ERP-Software eingegangen sind, ist es sinnvoll, die mobile Lösung vom gleichen Anbieter zu erwerben. Deckt jedoch der Standard-Workflow in der ERP Ihre Prozesse nicht ab, wird auch der mobile Workflow nicht zufriedenstellend sein – ihre Produktivität wird dann sogar behindert.

Anbieter von maßgeschneiderten Anwendungen: Wann sind diese sinnvoll?

Mit einer individuellen mobilen Anwendungsentwicklung haben Auftraggeber den Luxus der vollen Kontrolle über das Ergebnis, ohne direkt involviert sein zu müssen. Vorausgesetzt der Kunden hat  eine genaue Vorstellung von den benötigten Funktionalitäten, muss er lediglich ein genaues Briefing an den Entwickler weiterleiten.

Anbieter von Mobilplattformen

• Wenn man einen komplexen und sehr spezifischen Prozess mobil machen möchte.
• Wenn man ein absolut individuell zugeschnittenes User Interface benötigt
• Wenn man genügend Ressourcen (Zeit, Arbeitskräfte und Geld) zur Verfügung hat, um dies zu realisieren

Softwareanbieter

• Wenn man mit der Funktionalität der vorhandenen ERP Lösung zufrieden ist, aber eben auch mobilen Zugriff benötigt.
• Wenn man bereits eine Software nutzt, die eine mobile Lösung bereits integriert hat.

Anbieter von maßgeschneiderten Anwendungen

• Wenn man nur bestimmte Workflow mobil umsetzen möchten, dies jedoch nach den besten Branchenstandards.
• Wenn eine End-to-End-Lösung benötigt wird.
• Wenn man eine maßgeschneiderte Anwendung braucht.
• Wenn die einfache und nutzerfreundliche Bedienung eine Priorität hat.

Next-Generation-Anwendungsentwickler setzen Enterprise-Mobility-Tool-Kits ein

Anbieter wie Scolvo bieten inzwischen eine neue Generation der mobilen Anwendungsentwicklung an. Basierend auf der Erfahrung mehrerer umgesetzter mobiler Anwendungsentwicklungen für bestimmte Branchen wie etwa Versicherungen, Handel oder Versorgungsunternehmen bieten diese Unternehmen Lösungen „von der Stange an“, die aber den hohen Standards entsprechen und die nötigen Funktionalitäten nach spezifischen Branchenstandards für bestimmte Arbeitsabläufe abdecken.

Die Vorteile solcher Lösungen liegen auf der Hand: die Risiken für die Entscheider im Unternehmen werden minimiert und die mobile Lösung ist viel schneller einsatzfähig – in der Regel sogar innerhalb einer Woche. Sie sind leicht in existierende Backends zu integrieren und können individuell angepasst werden. Diese neuen Enterprise-Mobility-Toolkit-Lösungen sind außerdem einfach in der Nutzung, was sich auch in einem anwendungsfreundlichen User Interface niederschlägt.

6 Gründe für „Ready-to-Use“-Enterprise-Mobility-Lösungen

5 Regeln für die Implementierung von Enterprise-Mobility-Apps

Regel Nr.1: Das Hauptaugenmerk muss auf den Nutzer der App gelegt werden.

Praktische Einsatzfähigkeit, Konsistenz und Lesbarkeit entscheiden über ihren Erfolg oder Misserfolg.

Regel Nr. 2: Mobile-First-Ansatz fahren

Der mobile Arbeitsablauf unterscheidet sich in allen Branchen erheblich von den Abläufen am Desktop, das muss sich auch in der mobilen Anwendung widerspiegeln.

Regel Nr. 3: Nativen webbasierten mobilen Apps den Vorzug geben

Diese liefern aufgrund ihrer umfangreichen grafischen Funktionen und leichten Integrierbarkeit das bessere Nutzungserlebnis.

Regel Nr.4: Den Erfolg einer mobilen B2E-Anwendung über Leistungskennzahlen messen.

KPIs helfen, die Effizienz einer App zu messen und auf mögliche Schwierigkeiten hinzuweisen. Hier bietet sich beispielsweise die Transaktionsrate an: Wie viele Transaktionen wurden von dem Nutzer über eine App getätigt? Steigt der Nutzer beispielsweise früher aus, weist dies auf ein Defizit bei der Nutzerfreundlichkeit hin.

Regel Nr. 5: Der Benutzeroberfläche den Stellenwert als Herzstück einer Enterprise-Mobility-Anwendung zuerkennen.

Sie entscheidet über die Qualität der Umsetzung der mobilen Arbeitsabläufe und trägt wesentlich zum Erfolg der mobilen Lösung bei. Nicht umsonst beansprucht die Benutzeroberfläche 40 Prozent des gesamten Entwicklungsaufwandes, sowie 47–66 Prozent des gesamten Codes. Demgegenüber tendieren IT-Entscheider nach wie vor dazu, die Kompatibilität mit Geschäftsprozessen oder die Backend-Sicherheit höher zu bewerten, wenn es um die Umsetzung von mobilen Geschäftsprozessen geht.

The post Enterprise Mobility: 6 Gründe für die Implementierung von Enterprise-Mobility-Apps appeared first on MobileTechCon.

Durch Spracherkennungstechnologien werden Diktate automatisiert, Videos und Audiofiles textdurchsuchbar, Navigationsgeräte, Smartphones und die Websuche leicht steuerbar. In der Session „Smartphones getting smarter: Automatische Spracherkennung auf dem Weg in die Praxis“ stellte Prof. Dr.-Ing. Dorothea Kolossa (Ruhr-Universität Bochum) auf der MobileTech Conference 2016 stellt die Grundlagen von Spracherkennungssystemen vor.

Dabei blickt sie auf die aktuellen Methoden der Deep Neural Networks, diskutiert die Anbindung von Spracherkennungs-Apps, Software Development Kits und Hardwarelösungen, beleuchtet die Grenzen der Technologie in Bezug auf Privacy-Fragen und zeigt den aktuellen Stand der Forschung zur robusten Sprachsteuerung auch unter schwierigsten akustischen Bedingungen.

Auch auf der MobileTech Conference / Internet of Things Conference 2017 in München erwarten die Teilnehmer Sessions zu den Themenbereichen Spracherkennung, Bots und Deep Neural Networks. So demonstriert Dominik Helleberg (inovex GmbH) in seiner Session „Sprachsteuerung mit dem Google Assistant – Add a new User Interface to your product“ anhand von Google Home/Assistant die prinzipielle Funktionsweise einer Sprachsteuerung und ihre Vergleichbarkeit mit Chatbots.

Dean Bryen, Technology Evangelist für Amazon Alexa, stellt in der Session „Enabling Voice-driven Smart Home Experiences with Amazon Alexa“ Amazons Sprachassistentin und ihre neuesten Features vor und wirft einen Blick auf das Smart Home Skills API.

Und in der Session „Tiefes Lernen und die breiten Möglichkeiten intelligenter mobiler Anwendungen“ nimmt Sie Prof. Dr. Björn Schuller (Universität Passau) mit auf einen Kurztrip durch das Universum tiefer neuronaler Verfahren, bei dem er mit den Teilnehmern entsprechende Methoden und Möglichkeiten erkundet. Wie tief werden mobile Endgeräte bald denken?

The post Smart Home, Smartphones und Spracherkennung – So funktionieren Alexa, Cortana, Siri & Co. appeared first on MobileTechCon.