Unternehmensansatz zur Entwicklung mobiler Anwendungen, Teil 3: Interaktion der App-Komponenten

NB: Im nachfolgenden Artikel gehen wir davon aus, dass wir zuvor den plattformübergreifenden Ansatz zur Entwicklung mobiler Apps gewählt haben.

Logischer Datenfluss

Bei der Verwendung Ihrer mobilen Unternehmensanwendung interagieren die Benutzer mit unterschiedlichen Bereichen der Unternehmensinfrastruktur:

• Während der Anmeldung sendet die App eine Anfrage an die mobilen Unternehmensserver, die auf ihr eigenes Datenrepository zugreifen. Bei der Verarbeitung der Anmeldeanfrage wird die Antwort an die App zurückgeleitet und muss ordnungsgemäß interpretiert werden.
• Wenn ein Benutzer mit einer App interagiert, werden alle Anfragen von der App an das App-Backend gesendet.
• Die Interaktion mit dem Dienst für Push-Benachrichtigungen erfolgt über einen separaten Kanal und hängt von den plattformspezifischen Technologien ab.

Dieses Wissen können wir vertiefen.

Konzeptionelles Diagramm

Vor dem Zugriff auf die App-Funktionen muss ein Benutzer den Authentifizierungsprozess durchlaufen. Wenn der Benutzer seinen Benutzernamen (“jsnow”) und sein Passwort (“Kn0wsN0th1ng”) korrekt eingegeben hat, sollte das System erkennen können, dass der Benutzer tatsächlich Jon Snow ist. Zu diesem Zweck können wir OAuth oder ähnliche Technologien verwenden.
Der Serverseite liegt normalerweise die Web-API zugrunde. Üblich ist der Einsatz von einem Server sowohl für mobile als auch für Webanwendungen. Dies kann zu Konflikten führen, es sei denn, Sie trennen die Webmethoden für Ihre Apps. D.h., dass die Web-Methoden, die für den mobilen Client sichtbar sind, nicht für den Web-Client sichtbar sein sollten und umgekehrt.
Darüber hinaus können auf der Seite der Kunden andere Unternehmensdienste wie Sicherheitsdienste, Registrierung von Mobilgeräten, Benachrichtigungsdienste usw. eingesetzt werden. Die Interaktion mit ihnen erfolgt über die so genannten wiederverwendbaren Bibliotheken.

Wiederverwendbare Komponenten

Die Web- und mobile Anwendungen können sehr unterschiedlich sein! Unter Berücksichtigung der oben genannten Mechanismen und der gemeinsamen Infrastruktur können jedoch einige der Komponenten wiederverwendet werden. Dadurch kann die Menge an Code minimiert werden, die zum Aufrufen der gleichen Unternehmensdienste von verschiedenen Projekten aus erforderlich ist.

Die wiederverwendbaren Komponenten sollten immer für alle Plattformen gleichzeitig implementiert werden. Normalerweise benötigen sie nur zwei Aktionen: Integration und Konfiguration. Gehen wir mal die beliebtesten davon durch:

• Durch die Plattformsicherunglässt sich überprüfen, ob ein Gerät im Unternehmensnetzwerk angemeldet ist und für die Nutzung der Anwendung geeignet ist.
• Mit Hilfe der Versionskontrolle stellt man sicher, dass die Anwendung aktuell ist. Wenn ein neueres optionales oder obligatorisches Update bereitgestellt werden kann, müssen die Benutzer die Möglichkeit zum sofortigen oder späteren Herunterladen dieses Updates haben.
• Die Wartungsprüfung wird durchgeführt, um die Aktualisierung des Verfügbarkeitsstatus aus dem App-Backend zu erhalten und um zu prüfen, ob technische Wartung demnächst ansteht.
• Das einmalige Anmelden ermöglicht eine bequeme Anmeldung in der Anwendung, wenn ein Benutzer bereits in der gleichen Domäne authentifiziert wurde (d.h. der Benutzer hat sein Kennwort und sein Passwort in einer anderen Unternehmensanwendung bereits erfolgreich eingegeben).
• Der Push-Benachrichtigungsdienst hilft den Benutzern einer mobilen Anwendung dabei, aktiv zu bleiben, wobei die Benachrichtigungen üblicherweise vom App-Backend oder von der Webanwendung aus versandt werden.
• In der Seitenanalytik werden Statistiken zum Datenfluss und zur Benutzeraktivität gesammelt (ähnlich einer Webseitenanalyse). In diesem Fall muss der Kunde den Einsatz der Analysedienste im Voraus genehmigen.

Nun sind wir fast dazu bereit, unsere App zusammenzustellen, wir müssen nur noch sicherstellen, dass wir die App-Versionen verfolgen können.

Versionskontrolle

Das Teilen von Softwaremodulen über Disketten macht immer Spaß. Die moderne Kultur der Teamentwicklung impliziert jedoch neuere Ansätze und Standards. Heutzutage müssen Sie ein Versionsverwaltungssystem (VCS) zur Verfolgung der Änderungen im Quellcode beherrschen.

Außerdem hat die Projektmanagement-Methodik einen großen Einfluss auf die Entwicklungsprozesse. Wenn Sie in Ihrem Projekt mit Scrum arbeiten, müssen Sie überlegen, wie Sie alle vorherigen Produktversionen aktualisieren oder ändern können.

Aus dem Gesagten resultiert also, dass sich das folgende Verzweigungsschema im Quellcode-Repository ergibt:

• Im Bereich ”Develop”werden interne Versionen zusammengestellt
• Im Bereich ”Master”befinden sich die Versionen für den Kunden.

Alle Entwickler haben individuelle Aufgaben, die in einem temporären Zweig im Ordner “Features” platziert werden. Wenn eine Aufgabe abgeschlossen ist, kann dieser Zweig zum Zweig “Develop” verschoben werden.

Von dort aus wird der Quellcode in den Zweig “Master” verschoben. Dadurch kann man alle Änderungen an der vorherigen, an den Kunden ausgelieferten Version automatisch verfolgen.

Der Ordner “Releases” dient zum Speichern der bereits ausgelieferten Code-Versionen.

Der Ordner “Fixes” und der Ordner “Features” sind äquivalent. “Fixes” enthält temporäre Abzweigungen zur Behebung von Fehlern, die in den bereits ausgelieferten Versionen einer Anwendung gefunden werden.

Das Einzige, was noch zu tun ist, bevor Sie die Anwendung an Ihre Endbenutzer versenden, ist, sie in verschiedenen Umgebungen zu testen.

Tests in verschiedenen Umgebungen

In den isolierten Testumgebungen wird die Infrastruktur des Unternehmens nachgeahmt. Allerdings können diese Testumgebungen weder die Infrastruktur beeinflussen noch reale Kundendaten enthalten.

Nachstehend sehen Sie eine Liste der typischen Testumgebungen:

• Devwird von den Entwicklern für ihre eigenen Aufgaben genutzt;
• QAist für die Entwickler da, damit diese ihren Teil der Tests durchführen können;
• Stagingnutzen die QA-Entwickler, die beim Kunden arbeiten;
• Loadingist für die Lasttests;
• Prod– für die Tests unter realen Bedingungen.

Beim Testen in mehrschichtigen Umgebungen können alle möglichen Defekte erkannt und schnell behoben werden, damit die Endbenutzer zuverlässige und fehlerfreie Anwendungen bekommen.

Anwendungsdeployment

Es gibt mehrere Möglichkeiten, die Anwendungen für die Handheld-Geräte der Benutzer bereitzustellen. Beispielsweise kann der Entwickler ein App-Paket zusammenstellen und es dann auf dem Mobiltelefon installieren. Natürlich eignet sich dieser Ansatz nicht für das Deployment der App im gesamten Unternehmen.

Um die Anwendungen zusammenzustellen, wird ein spezieller Build-Server (z.B. basierend auf Jenkins) mit plattformspezifischen und anpassbaren Aufgaben bereitgestellt.

Jede Aufgabe besteht aus folgenden Phasen:

• Quellcode der App erhalten;
• App-Konfigurationsdateien den ausgewählten Einstellungen entsprechend ändern;
• Anwendung zusammenstellen;
• Anwendung mit einem Zertifikat versehen;
• Benachrichtigung mit den Ergebnissen an den Projektmanager versenden.

Wenn die Anwendung nach den strengen Tests für die Produktion reif ist, wird sie im Anwendungszentrum des Unternehmens hochgeladen (falls vorhanden) und kann bei den entsprechenden Diensten (App Store, Play Market usw.) veröffentlicht werden.

Wir hoffen, dass Sie unsere kleine Artikelreihe über den Unternehmensansatz zur Entwicklung mobiler Anwendungen genossen haben.

Möglicherweise haben Sie noch weitere Fragen, die in unserem Blog nicht behandelt wurden. Wenden Sie sich gerne dazu an unsere Experten für die mobile Softwareentwicklung. Wir freuen uns immer darauf, Ihnen bei allen Fragen oder Anfragen behilflich zu sein!