14. Dez 2021
Lesedauer 33 Min.
Bereitstellung einer Ionic-App für alle Plattformen
Cross-Plattform-Development mit Webtechnologien (Teil 13)
Für die Cross-Plattform-Entwicklung mit Ionic gilt es, die große Bandbreite an Zielumgebungen vollständig abzudecken.
Shutterstock
Während der Build-Prozess im Rahmen der agilen, kontinuierlichen Erstellung der App laufend in der Entwicklung stattfindet – kommen endgültiges Deployment und Publishing in der Regel erst nach der Freigabe durch einen erfolgreichen Abnahmetest zum Einsatz. Grundsätzlich müssen Entwickler vor der Bereitstellung der fertig gestellten App immer eine ausreichende Entwicklungsqualität durch Tests sichergestellt sein.Nur dann entsteht eine hohe Akzeptanz in der Fachabteilung, die Voraussetzung für den langfristigen Erfolg der App darstellt. Zudem müssen in der Welt der mobilen Endgeräte und im Internet die besonderen Anforderungen seitens Zuverlässigkeit und Sicherheit auch seitens der Bereitstellung einer App Berücksichtigung finden.Unter der Tätigkeit des Builds (Erstellung) versteht man den Vorgang der Überführung des Quellcodes der App in ein fertiges, vollständiges (ausführbares) Programm. Dieser Erstellungs- oder Build-Prozess findet bereits beim Testen innerhalb der Software-Entwicklung statt – er umfasst das Kompilieren, Verknüpfen und Verpacken unterschiedlicher Quellen zu einem testfähigen oder letztendlich auslieferbaren Produkt. Komplexität und Aufwand des Build-Prozesses erfordern größte Sorgfalt, die man am besten durch Automatisierung erreicht. Deshalb haben sich in der Praxis spezielle Build-Tools/Umgebungen etabliert, um die Aufgabe automatisiert durchzuführen (Bild 1). Grundsätzlich endet der Prozess des Builds nicht mit der reinen Fertigstellung des Endprodukts – der ausführbaren App. Vielmehr folgt im nächsten Schritt die Auslieferung des Endprodukts an die Endkunden – man spricht von Software-Verteilung (Deployment). Während im Build-Prozess die Konfiguration der Software – sprich der Bauplan für das Endprodukt im Zentrum steht, rückt bei der Verteilung die Einbettung der App in die Infrastruktur beim Kunden in den Vordergrund. Diese Einbettung der App stellt im letzten Arbeitsschritt technisch gesehen immer eine Installation dar. Die Installation fügt die App so in die individuelle Betriebsumgebung ein, dass deren Ausführung ohne auftretende Probleme sichergestellt ist.
Mit Appflow will Ionicden kompletten Prozess der Bereitstellung einer App für alle Zielumgebungen möglichst optimal unterstützen(Bild 1)
Simon
Zusätzlich müssen bei der Installation alle kritischen Schnittstellen der Betriebsumgebung berücksichtigt werden. Dies betrifft vor allem die Gesichtspunkte Sicherheit und Zuverlässigkeit. Durch die Installation der App darf es zu keinen Störungen oder gar Ausfällen in der Betriebsumgebung kommen. Zudem muss eine Kompromittierung der Sicherheit in der Betriebsumgebung bei der Ausführung der App durch Manipulation oder externe Angriffe ausgeschlossen werden. Im Internet, vor allem aber in der mobilen Welt, steigt diese Gefahr mit zunehmender Freizügigkeit der Endbenutzer an.Insbesondere dann, wenn Unternehmen auf die Bring-Your-Own-Device (BYOD)-Strategie zurückgreifen. In diesem Fall schützt ein standardisierter Bereich mit besonderen Sicherheitsmaßnahmen vor möglicher Kompromittierung. Jedoch auch ohne BYOD gilt es, die App auf allen Endgeräten immer aktuell zu halten. Insbesondere muss eine Installation von Sicherheitsupdates der App gewährleistet sein. Aufgrund dieser speziellen Anforderungen hat sich in der mobilen Welt ein weiterer Fachbegriff Publishing herausgebildet. Unter Publishing versteht man die Bereitstellung der App in den App Stores der verschiedenen Betriebssysteme.
Keine zentrale Konfigurationsdatei für Assets und Ressourcen einer App
Strebte das W3C ursprünglich noch einen offenen Standard für die Bereitstellung einer Web-App an, so wurden diese Bemühungen Ende 2018 eingestellt. Der vorgesehene Standard bekam damals die Bezeichnung Packaged Web App, abgekürzt: PWA. Jedoch darf man diese Packaged Web App nicht mit dem im Umfeld moderner Web-Apps verbundenen Begriff der Progressiven Web App (mit der gleichen Abkürzung) verwechseln.Die Abkehr des W3C von der geplanten Standardisierung einer zentralen Konfigurationsdatei lag sicherlich in der großen Anzahl neuer Technologien, die sich sehr schnell und kurzfristig im Umfeld der Web-Apps entwickelten. Dieser Sachverhalt führte zu einer großen Vielfalt an Individualisierung – was die Standardisierung in diesem Bereich technologieübergreifend erheblich erschwerte.Nur Release-Management führt langfristig zum Erfolg
Release-Management gilt als Voraussetzung, um Build, Deploy und Publishing erfolgsorientiert durchzuführen. Viele Software-Hersteller haben inzwischen ein Change- und Konfigurationsmanagement etabliert, um Änderungen und Vollständigkeit für ihre Produkte sicherzustellen. Jedoch verfügen nicht alle Software-Hersteller über ein eigenes Release-Management. Das Release-Management bündelt Änderungen von Konfigurationen und gewährleistet deren ordnungsmäße Einbettung in die Infrastruktur des Kunden.
Aus den Spezifikationen des W3C entstand jedoch der Gedanke einer zentralen Konfigurationsdatei für die einzelnen Aufgabenstellungen der Software-Bereitstellung (Build, Deploy, Publish). Im Zusammenhang einer Web- oder Mobile-App handelt es sich dabei häufig um JSON- und in seltenen Fällen um XML-Dateien. Der Siegeszug des JSON-Dateiformats für Konfigurationsdateien lag zum einen in der leichten Lesbarkeit, zum anderen aber auch am Einsatz von JavaScript.Eine JSON-Datei beschreibt ein JavaScript-Objekt und lässt sich direkt mit JavaScript verarbeiten. Im Unterschied dazu benötigt man für die Verarbeitung einer XML-Datei immer zusätzliche Informationen, die man über das XML-Schema ermitteln muss. Im Bedarfsfall überführt eine Serialisierung das JavaScript-Objekt der JSON-Datei in eine schlanke Alternative für die einfachere Verarbeitung über Netze.
Quasi-Standards durch Einsatz von JavaScript-Tools in der Praxis
Inzwischen existieren für jede Aufgabe im Rahmen der Bereitstellung einer App, sei es für Tests, Fehlersuche oder zur Überführung in die Produktion mehrere verschiedene JSON-Dateien. Im Zentrum aus Sicht eines Projekts steht die package.json-Datei; sie beschreibt alle für ein Projekt benötigten Module zusammen mit den benötigten Versionen. Zudem befinden sich in der package.json-Datei weitere Metadaten des Projekts wie Autor, Versionsnummer oder Lizenz.
Projektübergreifende Assetsund Ressourcen für eine komplette Anwendungslandschaft, die mehrere Apps gemeinsam nutzen, macht ein spezieller Ordner zugänglich(Bild 2)
Simon
Ebenfalls enthalten sind Aufrufe von Skripts, um zentrale Aufgaben zu automatisieren, die auf der Projektebene anfallen. Eine dieser zentralen Aufgaben der Projektebene stellt die Kompilierung dar; diese umfasst auch die Bündelung (Packaging) der App zu einer möglichst zusammengehörenden Einheit. Für Kompilierung und Packaging kommen abhängig von der zusammen mit Ionic eingesetzten Entwicklungstechnologien (Angular, React, Vue) verschiedene Konfigurationsdateien zum Einsatz – die bekanntesten aus Sicht von Java/TypeScript sind:Aufgabe des Build-Prozesses besteht darin, die Assets zu übersetzen und als Einheit für das spätere Deployment bereitzustellen. Der Compiler überführt den Quellcode/Assets des src/public-Verzeichnisses der Ionic-App in den <build>-Ordner. Eine mit Ionic entwickelte Web-App basiert auf Angular, React oder Vue – insofern handelt es sich bei der Ionic-App immer um eine Angular-, React oder Vue-App.
Bereitstellung einer Web-App automatisiert vornehmen
Beim Build-Prozess kommen die mit dem Framework beziehungsweise der User-Interface-Library verwendeten Build-Tools zum Einsatz. Das bedeutet das implementierte Ionic-Tooling greift beim Build auf die in Angular, React oder Vue jeweils eingesetzten Werkzeuge zurück. Die Aufrufe des zugehörigen Call-Level-Interface (CLI)-Befehle für den Build findet man direkt in der package.json-Datei des jeweiligen Projekts. Im Falle einer Ionic/Angular-App führt der npm run build-Befehl das CLI-Kommando ng build von Angular aus und legt die Ergebnisse im dist-Verzeichnis ab. Nähere Informationen zu den verfügbaren Optionen für diesen CLI-Befehl erhält man über ng build --help. Die dortigen Beschreibungen konkretisieren die Arbeitsweise des build-Befehls, die man auf der Website: angular.io/cli/build nachlesen kann.Um die Build-Ergebnisse insgesamt zu verkleinern, steht die Option --prod zur Verfügung. Der Application Builder von Angular verwendet webpack und eine über die Datei angular.json definierte Workspace-Konfiguration. Deren Definitionen dienen dazu, das Verhalten des Angular-CLI und seiner Kommandos zu steuern. Mit ihr passt man das Angular-CLI so an spezifische Vorstellungen an, wie sie das jeweilige Projekt benötigt.Create React App für die Neuanlage einer React-App
Facebook liefert für die Entwicklung mit React eine Web-App mit der Bezeichnung Create React App aus. Diese enthält alle wichtigen Befehle für die Neuanlage einer React-App und das Management der im Projekt anfallenden Aufgaben. Der Build einer Ionic/React-App erfolgt über den in der Create React App enthaltenen Befehl: react-scripts build. Das Kommando npm run build führt diesen Befehl aus, bündelt, verkleinert und minimiert die Ergebnisse und legt sie im build-Ordner ab.Installation des Gradle Wrapper
Jeden Gradle-Build sollte man mittels des Gradle Wrapper (kurz: Wrapper) durchführen. Der Gradle Wrapper benötigt ein installiertes Gradle-System, das seinerseits auf dem Java JDK Version 8 oder höher basiert.
Ein wichtiger build-Parameter stellt die Option --profile dar, die das seit React Version 16.5 über die React DevTools unterstützte Profiling einschaltet. Bei den React DevTools handelt es sich um ein npm-Package, das man eigenständig oder über eine Browser-Erweiterung für Debugging oder Profiling ausführt.Der Build-Prozess für eine Ionic/Vue-App verwendet die build-Option des vue-cli-service. Dabei handelt es sich um eine Binärdatei, die man entweder direkt über den Befehl ./node_modules/.bin/vue-cli-service im Projektordner oder über ein npm-Skript ausführt. Für alle im Projekt anfallenden Aufgaben steht das Vue-CLI GUI-Tool zur Verfügung, das man über den Befehl vue ui startet.
Das Vue.js-Frameworkenthält eine Web-App, UI-Tool genannt, um alle innerhalb eines Projekts anfallenden Aufgaben wie den Build einer App durchzuführen(Bild 3)
Simon
Anschließend öffnet der Standard-Browser dieses GUI-Tool; ein Klick in der ganz linken vertikalen Toolbar auf das Aufgaben-Icon zeigt die Projekt-Aufgaben an. Nach Auswahl des Build-Icons, startet die Schaltfläche Aufgabe ausführen einen Compile und bündelt die Dateien im dist-Ordner. Über die Vue-UI-App kann man alle Parameter für den Build-Prozess einstellen. Zusätzlich sind Analysen der Größen anhand von Webpack-Statistiken, Parser- und Gzip-Dateien verfügbar (Bild 3).
Bereitstellung einer Progressive Web-App (PWA) für vorhandene Ionic-App
Ionic unterstützt PWAs (siehe Teil 5) für alle drei Frameworks: Angular, React und Vue. Dazu benötigt eine Ionic-App die Realisierung eines Service Worker und einer Web Manifest-Datei (siehe Teil 5, Teil 11). Der Service Worker entspricht einem im Hintergrund ausgeführten Script, das eigenständig ohne Webpage oder Benutzerinteraktionen abläuft. Die Web Manifest-Datei enthält Spezifikationen wie den App Namen, deren Icons und die zugehörige URL. Der Zugriff auf eine PWA erfolgt mittels einer URL, ohne dass eine komplexe Installation über einen App Store notwendig ist – diese wichtige Besonderheit einer PWA heißt linkable.Für eine PWA vom Typ Ionic/Angular benötigt man das Angular-Package @angular/pwa; das der Befehl: npm run ng add @angular/pwa installiert. Anschließend nimmt man die Konfiguration der Service Worker über die neu erzeugte ngsw-config.json-Datei vor. Das Web Manifest findet man im src-Ordner in der manifest.webmanifest-Datei. Für eine Ionic/React-App aktiviert man das PWA-Feature in der index.ts-Datei; dort ändert man die unregister()-Methode für die serviceWorkerRegistration auf register ab. In der TypeScript-Datei service-worker.ts findet man Beispielcode für einen Service Worker.Icon-Generator von Ionic basiert auf Cordova
Der Resource Generator von Ionic erzeugt für den Desktop (Android, iOS, Windows) schnell die benötigten Icons. Das npm-Package cordova-res enthält diesen Icon-Generator. Einblick in dessen Dokumentation erhält man über das --help-flag: cordova-res --help.
Eine PWA vom Typ Ionic/Vue benötigt das PWA-Plugin von Vue, das man über den Befehl vue add pwa dem Projekt hinzufügt. Dieser Befehl erzeugt eine neue TypeScript-Datei registerServiceWorker.ts, die man in die main.ts-Datei der Vue-App importiert. Zusätzlich legt man eine manifest.json-Datei im public-Ordner an. In der Ionic-Dokumentation befinden sich im Abschnitt ionicframework.com/docs/vue/pwa0 passende Vorgaben für deren Inhalt. Abschließend trägt man einen Verweis auf die manifest.json-Datei über eine link-Anweisung in die index.html-Datei ein.
Deployment einer Ionic-Web-App/PWA über eine Cloud-Plattform
Das Deployment einer Ionic-PWA setzt einen Hosting Service voraus, der HTTPS unterstützt, da die Ausführung von Service Worker einen Secure Context verlangen. In der Regel lässt sich jede Cloud-Plattform nutzen, die einen Filehosting-Service mit Zugriff über HTTPS bereitstellt. In alphabetischer Reihenfolge sind die bekannten PaaS (Platform as a Service): AWS (Amazon Web Services), Google Cloud Platform (GCP), IBM Cloud, Microsoft Azure oder Oracle Cloud Platform; aber auch Heroku, Netlify, Render oder Vercel.Hinzu kommen neuere Entwicklungsplattformen für Mobile- und Web-Apps mit speziellen Features wie AWS Amplify, Googles Firebase oder Netlify, die Cloud-Storage für PWAs zur Verfügung stellen. Als Open Source-Alternativen für Firebase befinden sich Supabase oder nHost in der Entwicklung; diese besitzen aber noch nicht dessen vollkommenen Funktionsumfang. Daher benötigt man für das Deployment einer mit Ionic entwickelten Web-App grundsätzlich einen Account auf der gewünschten Cloud-Plattform.Cloud-Plattformen mit direkter Node.js-Unterstützung
Die nachfolgenden Betrachtungen beziehen lediglich die Cloud-Plattformen mit ein, die eine direkte Node.js-Unterstützung über npm-Bibliotheken bereitstellen. Dazu gehören zum Beispiel AWS Amplify, Googles Firebase, Supabase oder nHost; sie ermöglichen es bereits in der Entwicklung Dienste in der Ionic-App zu nutzen. Für diese Zwecke benötigt man zusätzlich zum Account auf der jeweiligen Cloud-Plattform eine Installation des dazugehörigen CLI (Command Line Interface). Dazu greift man auf das passende npm-Package zum Beispiel für Firebase die firebase-tools oder für AWS Amplify die beiden Packages @aws-amplify/cli und aws-amplify zurück.Ferner muss man die Web-App/PWA für das spätere Deployment konfigurieren und auf der Cloud-Plattform das Projekt anlegen. Für das Deployment bieten aktuell nHost und Supabase noch keine geeignete Unterstützung. Daher verwenden die nachfolgenden Beispiele AWS Amplify und Googles Firebase. Die Konfiguration der Cloud-Plattform im Ionic-Projekt erfolgt mittels spezieller Befehle über das CLI der jeweiligen Cloud-Plattform. Bei AWS Amplify erledigen dies die beiden Befehle amplify configure und amplify init. Unter Firebase greift man im Ionic-Projekt auf den firebase init-Befehl zurück.Voraussetzung für das eigentliche Deployment der Web-App/PWA ist ein für die Produktion erzeugter optimierter Build. Über die Ablagestruktur dieses Produktionsbuild definiert man die Einträge in der Deployment-Datei firebase.json. Der Befehl firebase deploy macht die Web-App/PWA bei einer aktiven Verbindung zu Firebase über das Web zugänglich. Über AWS Amplify erledigen das Deployment die beiden Befehle amplify add hosting und amplify publish.Grundlagen zum Build für Android, iOS/iPadOS mit Cordova/Capacitor
Die Programmierung einer mobilen App mit Ionic für die Plattformen Android oder iOS/iPadOS erfolgt entweder mit Cordova/PhoneGap oder Capacitor (siehe Teil 11). Wobei Entwickler nicht mehr Cordova/PhoneGap sondern Capacitor einsetzen sollten, da Adobe die Weiterentwicklung von PhoneGap eingestellt und Ionic sich auf Capacitor konzentriert. Aus diesen Gründen unterstützt Ionic für Vue- und React-Apps jetzt aktuell seit Version 6 nur noch Capacitor. Somit steht Cordova lediglich für Ionic/Angular-Apps zur Verfügung. Andere Ionic-Apps können jedoch über Capacitor fast alle Cordova-Plugins verwenden, da Capacitor grundsätzlich zu Cordova kompatibel ist.Um Cordova einzusetzen, benötigt man eine globale Installation der beiden npm-Packages: npm install -g cordova für das Framework und npm i -g cordova-res zum Anpassen der Icons und Startbildschirme an die Gegebenheiten der mobilen Betriebssysteme. Grundsätzlich entscheidet man sich bei der Einrichtung eines neuen Projekts für Ionic/Angular, ob man Cordova oder Capacitor einsetzen will. Dazu greift man beim ionic start-Befehl im Falle einer Angular-App auf die Option --cordova oder --capacitor zurück. Aufgrund der Empfehlung seitens Ionic für neue Projekte nur noch Capacitor und nicht mehr Cordova zu verwenden, erscheint bei Angabe der Option --cordova eine Warnmeldung.Neues Standard-Dateiformat für Android-Apps
Google hat mit den AABs (Android App Bundles) ein eines Dateiformat für den Google Play Store eingeführt. Google strebt an, ab Mitte 2021 nur noch das aab-Format für Android im Play Store zu akzeptieren. Mit den AABs hofft Google, eine größere Erfolgsrate für den Installationsprozess aus dem App Store zu erreichen. Die zunehmende Größe einer App macht die Installation auf einem mobilen Endgerät immer schwieriger. Es gilt zu verhindern, dass Endbenutzer den Installationsprozess einer App aufgrund des damit verbundenen hohen Zeitaufwands abbrechen. Inhaltlich unterscheiden sich AAB und APK nur wenig – ihr Hauptunterschied liegt im strukturellen Aufbau, der zu einer viel kleinere Dateigröße führt.
Existiert im Wurzelverzeichnis des Projekts einer Ionic/Angular-App die Datei config.xml, so handelt es sich immer um eine Cordova-App. Somit befindet sich diese (anfänglich) nicht wie bei den anderen Ionic-Apps üblich im Unterverzeichnis des jeweiligen Plattform-Ordners der Mobile-App. Zusätzlich enthält der Projekt-Ordner in der ionic.config.json-Datei als integrations-Eintrag cordova und in der angular.json die entsprechenden cordova-Referenzen. Bei einer Ionic/React- oder Ionic/Vue-App greift der ionic start-Befehl automatisch auf Capacitor zurück und installiert die benötigten npm-Packages. Alternativ erledigt dies der Befehl: ionic integrations enable capacitor.
Vorbereitungen für den Build-Prozess einer Mobilen-App mit Ionic treffen
In ein bereits vorhandenes Ionic-Projekt lässt sich das Capacitor-Framework nachträglich integrieren. Dazu installiert man die beiden npm-Moduln @capacitor/cli und @capacitor/core in das Projekt. Zusätzlich benötigt man für die mobilen Betriebssysteme noch eine Installation der beiden npm-Packages @capacitor/android und @capacitor/ios.Abschließend erzeugt der Befehl npx cap init die Konfigurationsdatei capacitor.config [ .ts | .json] von Capacitor; bei dessen Ausführung beantwortet man noch einige Fragen zum Management der Mobile-App (Name der App (appName), Bundle ID/appID). Da die Bundle ID/appID innerhalb eines App Stores einheitlich sein muss, orientiert sich diese wie üblich an der umgekehrten Reihenfolge eines Domain-Namens.Handelt es sich bei der Ionic-App um eine reine Web-App, so entspricht diese immer einer Ionic/Angular-App. Daher kann man die Beantwortung der Fragen für die Initialisierung von Capacitor mit npx cap init anhand der Einträge in der config.xml-Datei von Cordova/PhoneGap ableiten. Die Einträge in der config.xml-Datei basieren auf den Vorgaben des W3Cs zur Packaged Web Apps (Widgets)-Spezifikation. Einer Ionic-App fügt man eine mobile Plattform immer mit dem npx cap add [android | ios]-Befehl hinzu.Allerdings greift dieser Befehl auf den webDir-Eintrag in der capacitor.config [.ts | .json]-Datei und damit auf die Inhalte des www-Ordner der Web-App zurück. Deshalb erfordert eine Web-App vor dem Hinzufügen einer mobilen Plattform immer die Ausführung mindestens eines Builds.Um eine Ionic/Angular-App für eine mobile Plattform zugänglich zu machen, setzt man für Cordova den Befehl ionic cordova platform add [android | ios] ab – für Capacitor greift man auf das Projektkommando cap[acitor] add android | ios] zurück. Sollte bei einer Ionic/React- oder Ionic/Vue-App das Capacitor-Framework fehlen, so führt man den cap add-Befehl für Android oder iOS/iPadOS nachträglich aus. Um eine Plattform wieder zu entfernen, gibt es Stand heute keinen cap-Befehl, daher muss man den kompletten Plattform-Ordner von Hand löschen.Das Hinzufügen eines Cordova-Plugins erfolgt in einem Capacitor- analog einem Cordova-Projekt über den npm install-Befehl und Angabe des gewünschten Plugins. Einen zu einem Cordova-Plugin vorhandenen Ionic Native-Wrapper installiert man ebenfalls mittels npm. Danach erscheinen diese Plugins zusammen im eigenständigen cordova-Bereich in der package.json-Datei.Voraussetzungen für den Build einer Nativen-App für Android/iOS/iPadOS
Vor der Durchführung eines Builds für eine Native-App sollte man immer einen Web-App-Build angestoßen und erfolgreich abgeschlossen haben. Den Build eines Web-Projekts erledigt der Befehl npm run build – unabhängig davon, ob es sich um eine Ionic/Angular-, Ionic/React- oder Ionic/Vue-App handelt. Anschließend sind alle für den Build einer Native-App notwendigen Dateien die sogenannten Web-Assets vorhanden. Zudem sollte man vor dem System-Build einer Mobile-App prüfen, ob es eventuell aktuelle Versionen der in der Native-App verwendeten Capacitor/Cordova-Plugins gibt. Grundsätzlich gibt das Projektkommando cap ls eine Liste alle vorhandenen Plugins, ob Cordova oder Capacitor, aus.Im Falle einer Aktualisierung auf eine bestimmte Version eines Plugins erledigt man diese mittels des npm install-Befehls und direkter Angabe der gewünschten Version: npm install plugin-name@version. In diesem Fall müssen danach auch die eingerichteten mobilen Plattformen mittels cap sync ebenfalls aktualisiert werden. Dabei kopiert cap sync zunächst die aus dem Web-App-Build benötigten Dateien zusammen mit der Capacitor Konfigurationsdatei capacitor.config [.ts | .json] in die Verzeichnisse der eingerichteten mobilen Plattformen. Das heißt ein cap sync führt im ersten Schritt immer einen cap copy-Befehl aus.
Capacitor macht alle benötigten Ressourcenfür den Build einer mit Ionic entwickelten App in der gängigen IDE der mobilen Plattform (hier: Android Studio) verfügbar(Bild 4)
Simon
Erst im zweiten Schritt aktualisiert cap sync die in der packages.json-Datei angegebenen Plugins und sonstigen Abhängigkeiten. Das heißt, die im zweiten Schritt ausgeführten Aktionen entsprechen einem cap update-Befehl. Als Besonderheit gibt die sync-Option des cap-Befehls alle enthaltenen Cordova-Plugins aus, zeigt die inkompatiblen an und kopiert auch die Web-Assets in den Ordner der mobilen Plattform. Der eigentliche Build einer Native-App erfolgt innerhalb der zur jeweiligen mobilen Plattform zugehörigen IDE. Für Android kommt Android Studio und für iOS/iPadOS Xcode zum Einsatz. In einem Ionic-Projekt öffnet man über ein Terminalfenster mit dem npx cap open [android | ios]-Befehl die zugehörige IDE (Bild 4).
Vorgaben zum System-Build mit Gradle für Android Studio einrichten
Beim Einrichten der Android-Plattform mittels cap add android erzeugt Ionic alle benötigten Build-Spezifikationen mit den zugehörigen Build-Dateien. Die Befehle cap [sync | update] generieren die seitens Cordova und Capacitor erforderlichen Build-Spezifikationen. Der eigentliche System-Build einer Ionic-App für Android erfolgt über das Gradle-Build-Tool, das Bestandteil des Android SDKs ist. Android Studio greift dazu auf das Android Gradle-Plugin (AGP) zurück – jede Version der IDE enthält eine auf sie abgestimmte spezielle Plugin-Version. Das AGP nutzt für den System-Build automatisch diese standardmäßig zugeordnete Version von Gradle.Über den Eintrag buildToolsVersion in der build.gradle-Datei im Bereich android spezifiziert man im Bedarfsfall eine andere Gradle-Version. Zu beachten ist, dass ein Update von Android Studio nicht automatisch ein bereits auf einem Build-System installiertes AGP aktualisiert. Liegt eine neue Version vor, so erfolgt eine Informationsmeldung in Android Studio, um über den Android Gradle Plugin Upgrade Assistant eine Aktualisierung durchzuführen. Dieser nimmt ein Update sowohl des installierten Gradle als auch des AGPs vor. Innerhalb von Android Studio öffnet man über Tools > AGP Upgrade Assistant… den AGP Upgrade Assistant.System-Build einer Ionic-App für Android mit Gradle durchführen
Android Studio benötigt die Android SDK Build-Tools, um einen System-Build für eine Android-App durchzuführen. Der Android SDK Manager von Android Studio zeigt die installierte Version der Build-Tools an. Diese Liste öffnet die Menü-Kaskade Tools > SDK Manager mit anschließendem Klick auf das Register SDK Tools; dort gibt es den Eintrag Android SDK Build-Tools. Dieser Listeneintrag zeigt an, welche Version der Android SDK Build Tools derzeit auf dem Build-System installiert ist; gleichzeitig erhält man darüber einen Hinweis, ob Google ein Update für diese Version zur Verfügung stellt.Wichtige Informationen der App aus der Sicht eines Packages, was das Betriebssystem Android, die Einstellungen zur Sicherheit, den App Store Google Play oder die Android Build-Tools betrifft, enthält die Datei AndroidManifest.xml. Benötigt die Ionic-App bestimmte Berechtigungen, so trägt man diese gemäß den Android-Spezifikationen hier im Bereich <!-- Permissions --> ein. Natürlich muss der Endbenutzer über Android die Ausführung dieser Berechtigungen zusätzlich erteilen.Die AndroidManifest.xml-Datei enthält das Ionic-Projekt im Ordner android/app/src/main; Android Studio zeigt diese Datei im Bereich manifests unterhalb des app-Eintrags an. Die Vorgaben zum Gradle Build-Tool befinden sich in mehreren Dateien; mit Ausnahme der gradle.properties-Datei besitzen alle anderen die Erweiterung .gradle. Die Einträge der nachfolgenden .gradle-Dateien beziehen sich entweder auf Gradle selbst, das komplette Projekt oder gelten für einzelne Moduln der App:Die Vorgaben für einen System-Build der App mit Gradle verdeutlicht das Settings (Windows)- | Preferences (macOS)-Fenster von Android Studio. Alle Einstellungen im Überblick zeigt der dortige Listeneintrag Build, Execution, Deployment an, um diese im rechten Fensterausschnitt direkt zu ändern. Vorhandene Einstellungen zu Gradle im aktuellen Projekt findet man im Abschnitt Build Tools durch Klick auf den Eintrag Gradle. Die von Gradle benutzen Einstellungen für einen Compile-Vorgang listet der Eintrag Compiler auf. Der Listeneintrag Deployment erlaubt es, Vorgaben für einen automatischen Neustart der App zu treffen.Gradle unterstützt verschiedene Build-Varianten zum Beispiel debug für die Test- oder release für die Produktionsversion der Mobile-App. Android Studio gibt über die Menükaskade Build > Select Build Variant… in einem eigenen Fensterausschnitt alle Build-Einstellungen der im Ionic-Projekt definierten Vorgaben aus (Bild 5).
Gradle erzeugt von einer Ionic-Appverschiedene Build-Typen für die Mobile-App; die gewünschte Form legt die Einstellung Active Build Variant fest(Bild 5)
Simon
Über die Drop-Down-Liste Active Build Variant ändert man bei Bedarf die aktuelle Vorgabe für den Build der App entsprechend ab. Eventuell findet der DevOp-Mitarbeiter dort zwei weitere Auswahlmöglichkeiten für den Build:
cordova und capacitor, um noch ältere Android-Systeme zu unterstützen.
cordova und capacitor, um noch ältere Android-Systeme zu unterstützen.
Besonderheiten beim System-Build für eine Ionic-Android-App
Anhand der Auswahl eines Listeneintrags legt das Feld Active Build Variant die für den Build-Prozess gewünschte Variante (den Build-Typ/Form) fest. Alle für einen Build mit Gradle definierten Tasks findet man im Gradle-Fensterausschnitt, der sich in Android Studio über View > Tools Windows > Gradle öffnet. Standardmäßig ist für Gradle die Experimental Einstellung Do not build Gradle task list during Gradle sync aktiviert, da es sonst zu Performance-Problemen in großen Projekten kommt.Den Build führt man entweder interaktiv in Android Studio oder im Hintergrund über eigenständige Gradle-Kommandos durch. Seit August 2021 benötigt man für den Google Play-Store als Paketformat ABB (Android App Bundles) für alle neuen Apps. APK-Dateien (Android Packages) bleiben lediglich für ältere Apps erlaubt.Zur Durchführung eines System-Builds stehen in Android Studio mehrere Befehle im Build-Menü zur Verfügung. Vor dem eigentlichen Build sollte man prüfen, die korrekte Build-Variante/Typ wie oben beschrieben, ausgewählt zu haben. Die Make-Befehle im Build-Menü stoßen ein Compile aller Moduln des Projekts (Make Project) oder der geänderten Moduln (Make Module) an. Über Build Bundle(s)/APK(s) erzeugt man je nach Auswahl im Untermenü die Ionic-App als AAB (Android App Bundle) oder APK (Android Application Package). Führt man diesen Vorgang für ein APK zum ersten Mal durch, legt man wie für eine Android-App üblich das Zertifikat an. Die zugehörige aab- oder apk-Datei für eine Ionic-App besitzt den für jede Android-App gängigen Aufbau.Nach Abschluss des System-Builds gibt Android Studio eine Informationsmeldung aus. Die zugehörigen Dateien befinden sich im Ablageordner der Android-Plattform der Ionic-App im Verzeichnis app/build/outputs entweder im apk- oder bundle-Ordner im Unterverzeichnis release. Anhand der AAB/APK-Datei führt man das Publishing oder direkt die Installation der Android-App durch. Alle Aufgaben für einen System-Build der Ionic-App über einen Terminalbefehl macht der Gradle Wrapper verfügbar; dabei handelt es sich um ein Command-Line-Tool. Den Wrapper spricht man über den Befehl ./gradlew und Übergabe einer Task an. Der Befehl gradlew task gibt eine Liste aller Tasks eines Projekts aus.System-Build einer Ionic-App für iOS/iPadOS mit Xcode durchführen
Sind die Voraussetzungen für den System-Build einer iOS/iPadOS-App erfüllt, startet man Xcode mit der Ionic-App über den Befehl cap open ios. Ein Doppelklick im Fensterausschnitt des Xcode-Navigators auf den Eintrag App öffnet deren aktuelle Einstellungen. Aus diesen wählt man im Targets-Bereich einen Eintrag zum Beispiel App aus. Anschließend zeigt Xcode die Build-Einstellungen für den aktuellen Target an. In der Regel handelt es sich seitens der Ionic-Vorgaben für die Build-Optionen bei den Projekt-Einstellungen um geeignete Standardwerte, die man nur im Bedarfsfall überschreibt. Zu den wichtigsten Einträgen gehören im Bereich General die beiden Felder Version und Build. Über den Eintrag im Feld Version gibt man die nach außen sichtbare Versionsnummer der App vor. Im Feld Build verwaltet man die seitens der Entwicklung verwendete interne, extern nicht sichtbare, Versionsnummer der App.Wichtige Informationen zur App enthält die Info.plist-Datei im XML-Format. Dazu gehören die Definition der Bundles, ihre Konfiguration oder Einrichtung von Services wie Berechtigungen. Diese Datei findet man im ios-Ordner der Ionic-App im Verzeichnis App/App. Um im Info-Bereich von Xcode die tatsächlichen Namen und Werte zu den möglichen Schlüsseln zu sehen, wählt man bei den Info-Einstellungen über dessen Kontextmenü den Eintrag Raw Keys & Values aus. Im Bereich Signing & Capabilities muss für automatisches Signing der App bei Team ein Entwicklungsteam eingetragen sein.Um einen erneuten Review-Prozess seitens Apple anzustoßen, setzt man die Versionsnummer bei den Vorgaben zu General hoch – allerdings berücksichtigt Apple dabei immer nur die ersten beiden Zahlenangaben. Wichtig bei den Vorgaben beim Build für einen App-Store ist es, über Product > Destination bei Build das Endgerät Any Generic iOS Device festzulegen. Für Tests oder Debugging wählt man ansonsten gezielt das gewünschte Endgerät aus. Zudem öffnet man die Schema-Konfiguration über Product > Scheme > Edit Scheme. Dort prüft man beim Eintrag Run, ob für die Build-Konfiguration die passende Voreinstellung für die Ausführung des Build eingetragen ist. Beim Bauen der App über Product > Run | Build greift Xcode auf diese Einstellung zurück.Pilotierung von iOS/iPadOS-Apps über TestFlight
Apple stellt das TestFlight-System für die Pilotierung beziehungsweise für Betatests einer App zur Verfügung. Auf jedem Endgerät, das man für Pilotierung/Betatests mit TestFlight einsetzen möchte, benötigt man eine Installation der gleichnamigen App. Nach dem Hochladen einer neu gebauten App in den App Store schaltet man diese über das dortige TestFlight-Feature frei. Zugeordnete Tester erhalten eine E-Mail-Einladung zur Teilnahme an der Pilotierung/Betatest. Die Zeitdauer und die Anzahl der Endgeräte für eine Pilotierung/Betatest einer App über TestFlight ist beschränkt. Für In-App-Käufe während des Testens fallen keine Kosten an.
Zur Ausführung von Tests oder zum Debugging dient der Eintrag Debug. Für ein anschließendes Publishing wählt man über die dortige Drop-Down-Liste Build Configuration den Wert Release aus. Product > Archive baut das Image der App für das ausgewählte iOS/iPadOS-Gerät. Xcode zeigt in der Liste Archives jedes neu gebaute Image an, dieses lädt man durch Klick auf die Schaltfläche Upload to App Store…/Distribute App in den App Store von Apple hoch. Die dabei erfolgte automatische Anmeldung setzt ein vorhandenes Entwicklerkonto und ein Einrichten/Definition der App wie üblich über App Store Connect voraus.
Icons und Startbildschirme für App (Android, iOS/iPadOS, PWA) anlegen
Ausgehend von einem (in der Regel für eine Desktop-App) entworfenen Icon und Startbildschirm erzeugt man die zugehörigen Ressource-Dateien/Asset-Bundle für die Ionic-App, am einfachsten über eine der im Internet verfügbaren Generator-Apps. Dazu eignen sich Abiro Cordova Image Generator (pgicons.abiro.com), pwa-asset-generator (www.npmjs.com/package/pwa-asset-generator, github.com/onderceylan/pwa-asset-generator) oder Image Gorilla (apetools.webprofusion.com). Alternativ verwendet man dazu ein Bildbearbeitungsprogramm oder den speziellen Splash Screen-Generator (splashscreen.pro).Nach Auswahl von Programmicon und Startbildschirm im jeweils vorausgesetzten Dateiformat erzeugt man für die gewünschte Plattform (Android, iOS, PWA) die benötigten Ressourcen für die App (Bild 6). Anschließend legt das Tool einen Ordner mit Icon und Startbildschirm mit allen für die jeweilige Plattform notwendigen Dateiformaten an. Für Android-App kopiert man diese Dateien in das jeweils dazugehörende Verzeichnis des src/main/res-Ordners. Dabei muss darauf geachtet werden, für das neue Programmicon und die Startbildschirm-Dateien die bisherigen im Verzeichnis vorhandenen Dateinamen wieder zu verwenden.
Image Gorilla von Ape Toolserzeugt aus einem Programicon und einem Startbildschirm ein Asset-Bundle für die Android- und iOS-App(Bild 6)
Simon
Für die iOS/iPadOS-App öffnet man in Xcode in der Auswahlliste App den Eintrag Assets. Daraufhin zeigt Xcode im mittig stehenden Fensterausschnitt bei Auswahl von AppIcon die Programmicons beziehungsweise bei Auswahl von Splash die Icons des Startbildschirms an. Durch Drag & Drop aus dem vom Generator erzeugten Ordner auf das passende Icon in Xcode ordnet man entsprechend Programmicon und Startbildschirm zu.Für die PWA erfolgt die Zuordnung von Programmicon und Startbildschirm anhand der manifest.json-Datei. Dort findet man den Schlüssel icons, der das Programmicon über den Dateinamen icon.png und den Startbildschirm über favicon.png zuordnet. Diese teilt man anhand eines weiteren Schlüssels src, sizes und types auf. So verweist src auf die zugehörige PNG-Datei zum Beispiel /assets/icon-256x256.png, in sizes steht 256x und in type der String img/png. Am schnellsten erzeugt man die manifest.json-Datei über den PWA Manifest Generator von SimiCart.
Vorhandene Ionic-App für Desktop-Build verfügbar machen
Electron gilt als Framework der Wahl, um eine Cross-Plattform-App von Ionic auf dem Desktop (Linux, macOS, Windows) verfügbar zu machen. Zahlreiche in der Software-Entwicklung eingesetzte Produkte nutzen Electron intensiv (siehe Teil 2). Jedoch müssen für eine möglichst hohe Portabilität der Ionic-App verschiedene Aspekte betrachtet werden (siehe Teil 11). Als Alternative zur Bereitstellung einer Ionic-App auf dem Desktop ohne Einbindung von Electron kann man die Ionic-App als PWA entwickeln. Abhängig vom Typ der Ionic-App (Angular, React, Vue) führt man unterschiedliche Vorarbeiten für den abschließenden Build und Packaging der App.Grundsätzlich benötigt man eine Installation des npm-Package electron: npm i electron im Projekt. Für eine Ionic/Vue-App fügt der CLI-Befehl vue add electron-builder das gleichnamige Vue-CLI-Plugin dem Projekt hinzu – eine Capacitor-Installation wird nicht benötigt. Im Unterschied zu einer Ionic/Angular- oder Ionic/React-App, sie muss Capacitor enthalten; dies erledigt schnell die Befehlsfolge: npm i @capacitor/core und npm i @capacitor/cli --save-dev.Der Befehl npx cap doctor zeigt an, welche Capacitor-Dateien bereits im Projekt installiert sind. Alle von der Ionic-App benutzen Capacitor-Plugins gibt man mit npx cap ls in einer Liste aus. Anschließend erzeugt npx cap init mit der Beantwortung der Fragen die benötigte capacitor.config.ts-Datei.Im Falle einer Ionic/Angular-App mit Capacitor (ab Version 3.2) hilft das npm-Package ngx-electron von Thorsten Hans, das Electron-API einfacher zu nutzen: npm install ngx-electron. Sollte man noch mit Angular 8 oder älter arbeiten, so muss man ein Update der Templates durchführen: ng update @angular/cli @angular/core --allow-dirty.Erweiterungen/Änderungen für Ionic Appflow
Ionic Appflow erschließt als Build/Deploy-Service viele Vorteile, besitzt aber auch Features mit Potenzial für Änderungen oder Erweiterungen. Derzeit speichert Appflow temporär den kompletten Quellcode bei Einsatz von Git, Zertifikate für den Quellcode und die Passwörter online auf den Ionic-Servern. Hier wäre es sinnvoll, über einen Client/Server-Dienst nachzudenken, der keinerlei Daten der App online zwischenspeichert, sondern das gesamte Projekt immer auf dem Entwicklungssystem vorhält.
Nach der Installation von electron und Capacitor im Projekt richtet man die Capacitor-Community-Edition von Electron in einem Ionic/Angular- oder Ionic/React-Projekt ein: npm i @capacitor-community/electron; da das Electron-Plugin für Capacitor von Ionic veraltet ist. Um der Ionic-App als Plattform Electron hinzuzufügen, benötigt man vorher einen Build der App.Der Befehl ionic build generiert für eine Ionic/Angular-App das erforderliche www-Verzeichnis mit den Web-Dateien. Für einer Ionic/React-App legt der Build-Prozess von Ionic die Ergebnisdateien im build-Ordner ab. Im Falle einer Ionic/Angular- oder Ionic/React-App erzeugt man jetzt mit dem Capacitor-Befehl npx cap add electron einen Ordner electron und legt dort die Ionic-App in einem Electron-Container ab. Für diese beide Ionic-Projekttypen (Angular, React) startet der Capacitor-Befehl npx cap open electron im Projekt-Ordner die Ionic-App in einem Electron-Container.
System-Build und Bereitstellung einer Ionic-App für den Desktop
Der System-Build der Ionic-App vom Typ Angular oder React für den Desktop erfolgt über das electron-Verzeichnis. Daher erklärt man im Projektordner der Ionic-App über den Befehl cd electron dieses als aktuelle Arbeitsverzeichnis. Anschließend startet man im neuen Arbeitsverzeichnis den Build für die Electron-App mit dem Befehl npm run build. Nach vollständiger Erledigung des Build-Prozesses erscheint die Informationsmeldung Rebuild Complete.Die Capacitor Community Electron Platform setzt für Build und Packaging der Electron-App standardmäßig das npm-Package electron-builder ein. Dieser Electron-Builder verfügt für die Aktualisierung der App über ein integriertes Auto-Update-Feature. Alternativ stehen die Electron-Builder electron-forge und electron-packager über die Electron-Community zur Verfügung. Über das Internet steht ein frei zugänglicher Cloud-Dienst Electron Build Service zur Verfügung; dazu setzt man in der Konfigurationsdatei electron-builder.json den Eintrag remoteBuild auf true. Mit electron-builder führt man interaktive Tests über den Befehl npm run electron:start-live im Falle einer Ionic/Angular- oder Ionic/React-App durch. Dieser Befehl startet Nodes in einem abgespeckten Google-Chrome-Browser und öffnet für das Debugging dessen Dev Tools (Bild 7). Im Falle einer Ionic/Vue-App startet man Testing und Debugging über den Befehl npm run electron:serve.
Ein Electron-Containerbringt die Ionic-App auf der Zielplattform (macOS, Linux, Windows) zur Ausführung(Bild 7)
Simon
Das Packaging der Electron-App mit integrierter Ionic/Angular- oder Ionic/React-App nimmt der Befehl npm run electron:pack vor. Der zugehörige Prozess stellt zunächst über einen erneuten Build die Aktualität der Dateien sicher. Anschließend erfolgt der Build der Electron-App anhand der electron-builder.config.json-Datei.Standardmäßig generiert der electron-builder nur Installationsdateien für die aktuelle Plattform auf Basis deren Architektur. Die Ergebnisdateien des Build legt electron-builder im Verzeichnis dist des electron-Ordners ab. Den Build einer Ionic/Vue-App startet der Befehl npm run electron:build; die Ergebnisse findet man im dist_electron-Verzeichnis. Der electron-builder besitzt eine Vielzahl an Möglichkeiten das Build-Ergebnis zu beeinflussen; auch Code-Signing wird unterstützt. Die Konfiguration des Build-Ergebnisses nimmt man in der electron-builder.json-Datei beim entsprechenden Bereich vor. Für macOS erfolgt dies über den Bereich dmg oder mac (.pkg-Dateien), für Linux über linux und für Windows über win.Für jedes dieser Betriebssysteme existieren verschiedene Optionen, um das Endergebnis des Packaging auf die im Deployment anzutreffende Betriebsumgebung abzustimmen. Soll zum Beispiel für macOS ein pkg-Paket erzeugt werden, so ändert man den dmg-Bereich auf mac ab und gibt dort als „target“: „pkg“ vor. Ergänzend unterstützt Docker ein Packaging mit Einbindung des electron-builder. Dieser Docker-Build findet innerhalb eines Docker-Container statt. Dabei lassen sich entweder Docker-Images aber auch Packages für ein spezielles Betriebssystem (Linux, Windows, Squirrel.Windows) erzeugen.Bei Appflow handelt es sich um eine DevOps-Lösung für Mobile-Apps, die als Bestandteil der Ionic-Development-Platform jedem Entwickler automatisch über einen Ionic-Account zur Verfügung steht. Die Abkürzung DevOps setzt sich aus Development (Entwicklung) und IT Operations (IT-Betrieb) zusammen. DevOps zielt darauf ab, die Qualität der Software, die Geschwindigkeit in der Entwicklung, die Auslieferung der Software und die Zusammenarbeit der beteiligten Teams zu verbessern.Für diese Zwecke kombiniert DevOps die vorhandene Infrastruktur, die benötigten Mitarbeiter, spezielle Werkzeuge und möglichst agile Arbeitsprozesse zu einer in sich stimmigen und aufeinander abgestimmten Einheit – einem software-gestützten Zusammenarbeitsmodell. Zu den zentralen Diensten von Appflow gehören:Appflow besitzt ein besonderes Feature, das man im Zusammenhang mit DevOps hervorheben sollte: Integration von Appflow in bereits existierende CI/CD (Continuous Integration/Continuous Delivery/Deployment)-Plattformen. Die neuste Appflow-Version besitzt ein Cloud CLI, aber leider nicht im Basic- sondern nur im Standard- und Enterprise-Plan. Über dieses neue Call Level Interface (CLI) lassen sich alle über die Cloud verfügbaren Funktionen von Ionic und somit auch von Appflow innerhalb der eigenen CI/CD-Plattform (zum Beispiel Azure DevOps, CircleDI GitLab, GitHub, Jenkins oder Travis) nutzen.
Arbeiten mit Ionic Appflow im Projekt
Mit dem Befehl ionic login oder über die Website https://ionicframework.com/login meldet sich der Entwickler in seinem Ionic-Account an. Bei Eingabe von ionic login erscheint, nach Eingabe von Y zum Öffnen eines Browsers, der bekannte Log in to Ionic-Dialog. Sollte man als Entwickler noch keinen Ionic-Accout besitzen, so legt man über ionic signup einen neuen an. Nach der Anmeldung im Ionic-Account öffnet sich das Dashboard, welches man auch über die URL dashboard.ionicframework.com erreicht. Für das Arbeiten mit Ionic Appflow benötigt man im Ionic-Account eine App – dazu legt man im Dashboard entweder eine neue über den App Wizard an oder importiert eine vorhandene App. Im letzten Fall erfolgt der Import über ein Git-Repository.Für das Git-Repository unterstützt Ionic standardmäßig die folgenden drei Repository-Typen: Bitbucket, GitHub oder GitLab. Drei weitere Repository-Systeme Bitbucket Server, GitLab Self-Managed und Azure DevOps macht Appflow über den Scale Plan zugänglich. Über die Schaltfläche Launch App Wizard legt man eine neue App an – dazu vergibt man einen App name, wählt ein App-Icon, ein Theme color, ein Ionic-Template und das gewünschte Framework aus.Anschließend baut man eine Verbindung zu einem Repository auf. Ein Klick auf die Choose-Schaltfläche erzeugt die neue Ionic-App und zeigt diese im Dashboard an. Zusätzlich erscheinen im Fensterausschnitt Start here eine Reihe von Kommandos, um die neue Ionic-App in einen lokalen Projektordner für die Entwicklung bereitzustellen.Das Dashboard listet über den Overview-Eintrag den Namen der App zusammen mit dem zugehörigen Git-Repository auf. Lädt man über dieses Repository die App herunter, so richtet der Befehl npm install die benötigten Packages ein und die initiale App steht zur Weiterentwicklung bereit. Im Dashboard erreicht man die Hauptfunktionen von Appflow über den gleichnamigen Fensterausschnitt. Wählt man dort den Eintrag Build aus, so erscheint über die Schaltfläche + New build und Auswahl der gewünschten Versionsnummer aus dem Git-Repository der Create new build-Dialog (Bild 8).
Ionic Appflow unterstütztüber die Cloud den Build einer App für die Zielplattformen Web, iOS und Android(Bild 8)
Simon
Ein Klick auf die rechts untenstehende Build-Schaltfläche startet den Build-Prozess und gibt im Details-Fenster rechts oben dessen Fortschrittsanzeige aus. Die Meldung Job succeeded und das rechts oben erscheinende Success verdeutlicht den Abschluss des Build-Prozesses. Klickt man nach erfolgreichem Build erneut auf den Builds-Eintrag, so erscheint eine Liste aller durchgeführten oder aktuell laufenden Builds der App. Bei einem Build mit gesetztem Web preview-Schalter (grün) erscheint hier ein Auge als Icon-Symbol. Ein Klick auf dieses Auge-Icon öffnet die Ionic-App zum Testen im Webbrowser.
Deployment mit Live Updates over the Air
Das Deployment einer Ionic-App in Appflow basiert auf einem vorherigen Build der App, daher legt man als erstes bei der Anlage eines neuen Deployments den gewünschten Build fest. Der wichtigste Parameter für das Deployment einer App stellt die Auswahl eines sogenannten Channels dar – er spezifiziert das Ziel, wohin die App verteilt werden soll. Sobald man über ein kostenpflichtiges Abo von Appflow verfügt, kann man über den Menüpunkt Destinations im Deploy-Bereich eigene Zielumgebungen festlegen. Zielumgebungen stellen zum Beispiel Produktion, verschiedene Native-Builds oder speziell eingerichtete Beta-Channels für die Pilotierung der App dar.Als Besonderheit beim Deployment bietet Appflow das Live Update-Feature, um Änderungen wie Hotfixes schnell in Echtzeit an alle vorhandene Installationen der App auszuliefern. Damit entfällt die übliche Notwendigkeit, die Verteilung der App über App Stores vorzunehmen. Dieses Live-Update-Feature bezeichnet man manchmal auch Over-the-Air-Update (OTA) (angelehnt an die Konzeption von Google, Updates für Android direkt online zu installieren). Die Definition beziehungsweise Einrichtung dieses OTA-Update erfolgt in Appflow über Destinations; dort gibt es den Punkt Install Instructions. Ein Klick auf diesen Link öffnet in Appflow den Set up Ionic Deploy-Dialog.Dieser Dialog bietet verschiedene Strategien für die Durchführung des OTA-Update zur Auswahl an (Bild 9). So lässt sich ein Update im Hintergrund herunterladen, dessen Installation erfolgt erst beim nächsten Start der App. Alternativ kann man Updates beim Start der App sofort installieren, dabei erscheint der Startbildschirm der App (Splashscreen) für einen längeren Zeitraum. Auch eine manuelle Installation von Updates über eigenes JavaScript unterstützt dieses OTA-Feature. Grundsätzliche Voraussetzung um Live-Update zu nutzen, ist die Installation des Appflow SDK (häufig auch Ionic Deploy-Plugin genannt).
Mit dem Live-Update-Featurevon Ionic Appflow umgeht man eventuelle Zeitverzögerungen der App Stores, um Hotfixes mit dringenden Fehlerbehebungen schneller zu installieren(Bild 9)
Simon
Die zugehörige Anleitung für diese Installation erscheint nach Klick auf den Install Instructions-Link im Set up Ionic Deploy-Dialog – diese ist allerdings nur lesbar, solange die Auswahlliste für die Update-Strategien nicht geöffnet ist. Die Installation des Appflow SDKs erfolgt über den ionic deploy add-Befehl und Übergabe der Parameter für app-id, channel-name und der update-method. Sobald diese Plugin-Variablen belegt sind, sollte man mit dem git add .-Befehl alle Änderungen im Quellcode (der Working-Area) in die Staging-Area überführen und mit git commit die Dateien aus der Staging-Area in einen Snapshot im Repository übernehmen.
Build einer Native-App über die Cloud unter Windows auch für iOS/iPadOS
Um einen Build für eine Native-App in Appflow durchzuführen, benötigt man mindestens einen Basic-Plan von Ionic. Wie immer setzt auch der Build über die Cloud mit Appflow die üblichen Zertifikate voraus. Die Erzeugung dieser Zertifikate für Android erfolgt mittels der im Java SE Development Kit (JDK) enthaltenen keytool-Utiliy. Zertifikate für iOS/iPadOS generiert man wie üblich über den Apple Developer-Account. Die Zertifikate stellt man durch Hochladen über das Dashboard in Appflow mit Build > Certificates und Klick auf die Add certificate-Schaltfläche bereit.Als besonderes Feature stehen Native Configurations zur Verfügung, um Vorgaben seitens der Konfiguration einer App zu überschreiben – ohne dass diese sich in der Versionsverwaltung widerspiegeln müssen. Damit ermöglicht man Installationen verschiedener Versionen einer App und deren Betrieb auf einem einzigen mobilen Endgerät. Für den Build über die Cloud mit Befehlen steht das Ionic Cloud CLI zur Verfügung – dazu ist ein Standard- und Enterprise-Plan erforderlich. Um das Ionic Cloud CLI zu benutzen, muss man vorher einen Personal Access Token (PAT) über das Dashboard erzeugen. Dies erfolgt bei den Einstellungen des Benutzerprofils im gleichnamigen Bereich durch Klick auf Generate new token. Das PAT dient der Authentifizierung gegenüber dem Ionic Cloud CLI.Durch Definition einer Umgebungsvariable des Betriebssystems erhält das Ionic Cloud CLI Zugriff auf das PAT. Den eigentlichen Build der Native-App stößt man über den ionic-cloud build-Befehl an. Dieser Befehl besitzt eine größere Anzahl von Parameter; die beiden wichtigsten stellen <ios | android> und <build_type> dar. Während der erste Parameter das mobile Betriebssystem für den Build festlegt, bestimmt der zweite, welche Zielsetzung man mit dem Build verfolgt. Mit dem zweiten Parameter erzeugt man Builds für den App Store, die Entwicklung oder für ein individuelles Deployment.Mit weiteren zur Verfügung stehenden Optionen richtet man den Build-Prozess auf spezielle Anforderungen aus. So kann man für die Native-App Umgebungsvariable einrichten, für den Build native Konfigurationsvariablen einbeziehen, die Versionsnummer für Xcode setzen oder den Typ für die Build-Datei zum Beispiel APK oder AAB festlegen. Zusätzlich steuert man hierüber auch, welche vom Build-Prozess erzeugten Dateien lokal bereitzustellen sind; zum Beispiel iOS IPA (iOS App Store Package) oder iOS dSYM (Debug Symbol). Die Optionen ermöglichen auch ein Überschreiben oder Umbenennen der erzeugten Build-Datei.Automatisierte Builds mit Packaging & Deploy
Entwickler ab einem Basic-Plan von Ionic steht das Automation-Feature in Appflow zur Verfügung. Darüber definiert man Builds, deren Ausführung automatisch erfolgt. So lassen sich, immer wenn das Entwicklungsteam Änderungen im Quellcode als Abspaltung in die Versionsverwaltung übernimmt, automatisch Builds für Packaging und Deployment auslösen. Dabei unterstützt Appflow das Einrichten verschiedener Umgebungen und Native-Konfigurationen (Native Configs), um verschiedene Versionen der App für Entwicklung/Test, Qualitätssicherung und Produktion bereitzustellen.Mit Native Configs kann man Konfigurationen der Software überschreiben, ohne Änderungen für sie im Versionsmanagement durchführen zu müssen. Die über Native Configs definierten Änderungen gelten speziell für den Build der App. Sie zielen darauf ab, verschiedene Umgebungen mit derselben Version der App bedienen zu können. Darüber lässt sich zum Beispiel auch der Channel oder die Methode für Updates durch eine andere Vorgabe überschreiben. Bei der Anlage einer Automatisierung in Appflow stellt der Automation Type ein wichtiger Parameter dar. Der Automation Type steuert, ob ein Package Build (binär) oder ein Deploy Build (Live-Update) erstellt werden soll.Zusätzlich verknüpft man bei der Neuanlage eine Automatisierung über den Parameter Git Branch mit einer Abspaltung (Branch) im Versionsmanagement. Sobald ein Commit im Versionsmanagement für diese Branch erfolgt, löst Appflow die Automatisierung aus. Als Besonderheit besitzt Appflow für eine Automation ein Test-Feature; darüber prüft man, ob eine neu definierte Automation korrekt funktioniert.Build und Deployment in CI/CD-Pipeline/Infrastruktur integrieren
Um eine Automatisierung in einem eigenen CI/CD-System verwenden zu können, hat Ionic Webhooks kreiert. Mittels eines Webhooks übergibt man recht leicht Informationen der Automatisierung an das CI/CD-System. Die Übergabe dieser Informationen erfolgt mittels eines HTTP-POSTs mit automatischem Retry bis dieser einen OK-Statuscode zurückliefert. Dabei stehen die Informationen im Request-Body (Payload) als JSON-Daten zur Verfügung (Bild 10).
Das Webhook-Featuredient als externe Schnittstelle einer Appflow-Automation zur Weitergabe von Daten(Bild 10)
Simon
CI/CD (Continuous Integration/Continuous Delivery/Deployment) gilt als Schlüssel zum Erfolg bei der Entwicklung von Software. CI/CD zielt darauf ab, alle Prozesse und Techniken der Entwicklung möglichst automatisiert durchzuführen. Dabei gilt es vor allem die Integrations- und Auslieferungsprozesse zu automatisieren, damit diese wiederholbar und damit zuverlässig ausführbar sind. Es sollen mögliche Bruchstellen zwischen der Entwicklung und dem IT-Betrieb überwunden, am besten vollständig beseitigt werden.Änderungen im Programmcode, die in der Versionsverwaltung erfolgen, sollen über den Build-Prozess für Tests bereitgestellt und nach Freigabe automatisch für die Endbenutzer veröffentlicht werden. Ein hoher Grad an Automatisierung benötigt aufeinander abgestimmte Werkzeuge mit der passenden Infrastruktur. CI/CD unterstützt agiles Arbeiten und führt zu lernenden Organisationen. Der Einsatz von Appflow setzt keine vorherigen Erfahrungen mit CI/CD voraus.Die Automatisierung von CI/CD mit Appflow lösen bestimmte Arbeitsschritte aus. Im Prinzip lässt sich jede vorhandene Werkzeugkette zusammen mit Appflow einsetzen. Recht häufig trifft man Appflow im Umfeld von Azure DevOps, CircleCI, GitHub Actions, Jenkins oder Travis an. Appflow macht für die mit diesen Tools gebildete CI/CD-Pipelines die besonderen Features Live-Updates, App Store-Deploy und Native Builds verfügbar. Dabei ist Appflow speziell auf die Bedürfnisse von Web-Entwicklern abgestimmt, die Mobile-Apps programmieren.Für die Integration von Appflow in eine vorhandene CI/CD-Pipeline verwendet man die von Appflow bereitgestellten Arbeitsschritte im eigenen CI/CD-Prozess. Die CI/CD-Pipeline greift auf diese Appflow-Arbeitsschritte zurück, bringt diese zur Ausführung und verwendet die über Appflow erhaltenen Arbeitsergebnisse im eigenen CI/CD-Prozess weiter. Die Realisierung der Integration von Appflow in die eigene CI/CD-Pipeline erfolgt über das Ionic Cloud CLI. Jeder Ionic-Anwender mit Standard- und Enterprise-Plan erhält Zugriff auf das Ionic Cloud CLI und kann dieses installieren.Über das Ionic Cloud CLI erstellt man Native-Builds zum Beispiel ionic-cloud build ios, veröffentlicht die Ionic-App im App Store mit ionic-cloud deploy ios oder führt Live-Updates über ionic-cloud build web und ionic-cloud deploy web aus. Alle Befehle stehen für alle Steps der eigenen CI/CD-Pipeline zur Verfügung. Das Tool ist mächtig, so unterstützt es das Zwischenspeichern von Variablen und deren spätere Wiederverwendung in den Arbeitsschritten der CI/CD-Pipeline.
Links zum Thema
<b>◼ <a href="https://ionicframework.com/" rel="noopener" target="_blank">Homepage von Ionic</a> <br/></b>
