Rapid Application Development für künftige Mobilsysteme

Inhaltsverzeichnis

Der US-amerikanische Psychologe Abraham Maslow (1907-1970) erlangte für seine Bedürfnispyramide Weltruhm. In diesem streng hierarchischen Modell bilden die physischen Grundbedürfnisse des Menschen den Sockel der Pyramide. An der Spitze steht die Selbstverwirklichung. Heute im 21. Jahrhundert bräuchte es wohl eine viel komplexere Form, um die Bedürfnisse zu differenzieren. Allein in der Arbeitswelt entstehen Anforderungen, die man sich zu Maslows Zeiten noch gar nicht ausmalen konnte. Das gilt ganz besonders für den Bereich der mobilen Anwendungen.

Heutige Anwender wechseln bei der Verwendung von Mobil-Apps schnell zwischen komplexen Inhalten und lösen damit automatisch mehr und umfangreichere API-Anfragen an die Cloud aus. Damit es keine Abstriche beim Benutzerkomfort gibt, müssten sich die Anforderungen an die Verbindungsqualität und an das Backend erhöhen. Damit einher geht also eine verstärkte Abhängigkeit von Netz- und Serverbetreibern, die beispielsweise bei QR-Codes häufig zum Tragen kommt, da diese meistens nur einen einfachen Link zu einer Website enthalten. Vielfach wäre es aber möglich, alle für die jeweilige Anwendung relevanten Informationen direkt in den QR-Code einzubauen und somit ohne Internetverbindung und Server auszukommen.

Wer unterwegs beim Pendeln oder auf Reisen mobil arbeiten möchte, empfindet die Schattenseiten der mobilen Infrastruktur oftmals als frustrierend. Noch nie gab es so viele nützliche Apps, die in Sachen Anwenderfreundlichkeit das Beste herausholen. Die meisten Anwendungen sind allerdings von einem Server-Backend abhängig und funktionieren nur dann, wenn auch eine stabile Internetverbindung verfügbar ist. Zugreisende, die sich auf eine Fahrkarten-App verlassen, schätzen zwar den Gewinn an Flexibilität, empfinden es aber natürlich als ärgerlich, wenn diese kurz vor Abfahrt des Zuges plötzlich den Dienst verweigert.

Doch wieso übersieht der aus der digitalen Transformation erwachsende Entwicklungsschub diesen technischen Rückstand? Die Ursachen mögen in der vergangenen Dekade liegen. Seit etwa zehn Jahren sind die Verkaufs- und Nutzungszahlen von Desktop-Computern respektive von klassischen Rich-Clients rückläufig. Die damals häufige Verwendung schwacher Mobilgeräte schränkte die Funktionalität auf den Endgeräten drastisch ein (Thin-Client-Ansatz). Seither hat sich die Leistungsfähigkeit von Mobilplattformen und Chips jedoch exponentiell erhöht, sodass die starke Severabhängigkeit geradezu anachronistisch anmutet. Oder wie ist es zu erklären, dass sich kein einziges komplexeres Softwaresystem bei voller Funktionalität immer, das heißt an jedem Ort und mit jedem Gerät, verwenden lässt? Man denke hierbei an gängige ERP-Systeme oder CRM-Anwendungen, aber auch an Fachapplikationen und technische Anwendungen. Verbessert hat sich in jüngster Zeit dank des Mobile-First-Ansatzes immerhin die Ausrichtung der Benutzerschnittstellen auf Bedürfnisse mobiler Benutzer.

Anforderungen an moderne mobiltaugliche Informationssysteme

Für den Autor haben sich einige wesentliche Aspekte für ein zukunftsorientiertes Informationssystem herauskristallisiert, die er im Folgenden kurz vorstellt:

• Dezentrale Datenablage und Geschäftslogik: An vorderster Front steht die Forderung nach einer verteilten Ablage von Daten sowie einer autonom funktionierenden Geschäftslogik. Ganz egal wo, in welcher Situation oder mit welchem Gerät Anwender gerade unterwegs sind, sie wollen sich auf eine voll funktionierende Cloud-Anwendung mit vollem Zugriff auf alle Daten und Funktionen verlassen können. Das erlaubt ihnen, flexibler zu planen und ihre geistigen Ressourcen optimal einzusetzen.
• Plattformunabhängigkeit: Anwender möchten prinzipiell geräteübergreifend arbeiten. Somit darf es keine Rolle spielen, ob sie die Arbeit offline, an einem Desktop-Computer, im Webbrowser oder mit einem Smartphone ausführen. Die Benutzererfahrung soll der gerade verwendeten Plattform bestmöglich entsprechen; trotzdem soll aber überall dieselbe volle Funktionalität verfügbar sein. Um das zu gewährleisten, muss eine Software von Grund auf plattformunabhängig entwickelt worden sein.
• Schnelle Anwendungsentwicklung und -bereitstellung: Die obigen beiden Aspekte dürfen jedoch weder eine höhere Entwicklungszeit noch einen größeren Aufwand in Bereitstellung und Betrieb rechtfertigen. Im Gegenteil: Eine ideale Lösung sollte eher noch schnellere Veröffentlichungszyklen erlauben. Unmittelbare und geradlinige Anpassungen an neue oder sich ändernde Bedürfnisse oder Geschäftsprozesse sind im heutigen Informationszeitalter ein entscheidender Wettbewerbsvorteil. Eine Antwort darauf kann der Einsatz von Rapid Application Development (RAD) sein, der in der Entwicklung von Cloud-Applikationen den Aufwand für die Implementierung redundant vorkommender Elemente stark reduziert. Das betrifft beispielsweise Standardfunktionen wie Menüeinträge, Links und Buttons zum Speichern, Schließen oder Weiterleiten. Ebenfalls werden immer wieder Tabellenansichten mit mächtigen Sortier-, Such- und Filterfunktionen benötigt. Vorausgesetzt, dass hierbei der gesamte Technologie-Stack berücksichtigt wird, kann RAD ein bedeutender Schritt zur Automatisierung in der Softwareentwicklung sein.
• Von der Datenstruktur unabhängige Anwendungslogik: Der konsequente Einsatz von RAD verlangt nach Anwendungslogik, die von der Datenbankstruktur unabhängig ist. Darum braucht es keine Anpassungen in der Geschäftslogik und aufwendige Aktualisierungsverfahren bei Änderungen am Datenschema.
• Skalierbarkeit: Ein skalierbares Backend mit einer leistungsfähigen, zuverlässigen Datenbank ist für einen nachhaltigen Betrieb unerlässlich. Nur so wird es in der Zukunft möglich sein, auf alle zukünftige Entwicklungen und Anforderungen mit vertretbarem Aufwand einzugehen.
• Intuitive Entwicklungsumgebung: Schließlich sollte es auch für Power User ohne Programmierkenntnisse möglich sein, dank visueller Bedienungshilfen selbstständig einfache Applikationen entwickeln oder modifizieren zu können.

Wenn all diese Anforderungen erfüllt sind, sind die Voraussetzungen dafür geschaffen, dass Informationssysteme einen höheren Level an Flexibilität und Autonomie haben.

Mögliche Entwicklungsansätze

Im Web- und Mobile-Development-Umfeld sind in den vergangenen Jahren einige interessante Lösungsansätze zusammengekommen, die den obigen Anforderungen zumindest teilweise gerecht werden.

• Frameworks wie PhoneGap, Appcelerator oder React konzentrieren sich hauptsächlich auf die Benutzeroberfläche und den Zugang zu Gerätefunktionen. Obwohl damit die Entwicklung von Apps erleichtert wird, fällt der Ansatz noch nicht in die Kategorie des RAD. Es wird zwar eine Abstraktion für Datenbankoperationen angeboten, man muss sich aber beispielsweise selbst um die Synchronisierung von Daten kümmern. Deshalb ist man schnell gezwungen, Plug-ins zu installieren oder gleich von Grund auf eine eigene Entwicklung zu kreieren.
• Angebote wie das Backend as a Service (BaaS) Firebase oder das Objektgraph- und Persistenz-Framework "Apple Core Data" bieten sicherlich attraktive Vorzüge. Doch mangels Benutzeroberfläche ist der Aufwand für die Integration eines UI-Frameworks miteinzubeziehen. Unterschiede zwischen den verschiedenen Mobilplattformen und der Umstand, dass sich die Anwendungslogik nicht komplett von der Datenbankstruktur trennen lässt, erhöhen die Komplexität noch weiter.
• Alternative Optionen wie die individuelle Programmierung einer Anwendung sind ebenfalls zu berücksichtigen. Zumindest der Aufwand für die lokale Umsetzung einer Datenablage und performanter Berechnungen wird dank des relativ jungen Ansatz der Progressive-Web-Apps reduziert. Gibt es die ideale Lösung?

Zusätzlich zu den erwähnten Anforderungen sollte eine ideale Lösung die folgenden Attribute aufweisen:

• Von Grund auf eingebaute Unterstützung mehrerer Sprachen. Jedes geschriebene Wort muss in jede gewünschte Sprache übersetzbar sein. Dieses Feature sollte einfach zu verwenden und zu warten sein.
• Die Installation zusätzlicher Server ist für die meisten zu mühselig. Zunehmend werden ausgereifte Cloud-Angebote bevorzugt. Trotzdem muss für spezielle Situationen die Möglichkeit von On-Premise-Hosting bestehen.
• Es braucht eine dynamisch konfigurierbare Schnittstelle, um andere Datenbanken, Services, Applikationen und Websites zu integrieren.

Im Folgenden soll nun anhand von Erfahrungen bei der Entwicklung der Softwareentwicklungsplattform Protogrid auf ausgewählte interessante Überlegungen bezüglich der Architektur einer möglichen Lösung eingegangen werden.

Als Basis für Mobile Clients hat der Autor Couchbase Lite betrachtet, da es das verbreitete und stabile CouchDB-Replikationsprotokoll vollständig implementiert. Es darf guten Gewissens als ausgereifte, robuste NoSQL-Datenbank für mobile Geräte mit einer aktiven Community bezeichnet werden. Der einzige Wermutstropfen: Unter erschwerten Bedingungen tauchen vereinzelt Probleme mit der Geschwindigkeit der Synchronisation auf.

Ein weiterer zentraler Aspekt der Entwicklung ist die Geschäftslogik. Sie lässt sich fast vollständig in JavaScript implementieren. Dieser Code ist eins zu eins sowohl auf Server und Client vorhanden. Der Betrieb läuft jeweils auf Googles JavaScript-Engine V8 oder auf Apples JavaScriptCore.

Selektive Replizierung

Was die Replizierung mit Mobilgeräten anbelangt, gibt es ein paar Hürden zu meistern. Beispielsweise sind für eine funktionierende Applikation gewisse Daten von zentraler Bedeutung. Konkret geht es um Parameter, Kategorien oder Definitionen der Geschäftslogik. Das Risiko durch unerlaubten Zugriff oder durch Hackerattacken auf lokal abgelegte Daten ist zu berücksichtigen. Ein mobiles Smartphone in fremdem Besitz kann schließlich nie so gut abgesichert werden wie ein stationärer Server unter eigener Aufsicht. Ferner wird die Speicherkapazität von Mobilgeräten immer begrenzt und die Übertragung über Mobilfunk mit Kosten verbunden sein. Zum Beispiel ist während vieler Auslandsaufenthalte mit einer Einschränkung des mobilen Datenzugriffs zu rechnen.

All diese Herausforderungen lassen sich mit CouchDB-Replizierungsfiltern elegant angehen. Deren Wirkung wird durch Parameter gesteuert, die sowohl das Mobilgerät als auch der Server bestimmen. In der vorgestellten Lösung haben Applikationsentwickler die Möglichkeit, Prioritäten für die Replizierung zu definieren. Dokumente mit hoher Priorität werden gleich nach dem Starten der App repliziert, was einen schnellen Zugriff und korrektes Funktionieren gewährleistet. Danach startet die Replizierung von Daten mit mittlerer Priorität, sofern diese neueren Datums sind oder von kleiner Größe. Schließlich startet die kontinuierliche Replizierung, die auch ältere, größere Dokumente oder solche mit geringer Priorität miteinschließt.

Es ist auch möglich, mittels Ausschlussregeln Daten zu definieren, die gar nie repliziert werden sollen. Beispielsweise verbieten die Developer-Guidelines von Apple, den für die Geschäftslogik verwendeten JavaScript-Code zu replizieren. Falls Anwender den Datenverkehr einschränken möchten, können sie die kontinuierliche Replizierung auch jederzeit unterbrechen. Und wenn zu viele Dokumente ein Update benötigen, wird die App automatisch in den Read-only-Modus umschalten.

Automatisierter Rollout

Die zweite Herausforderung ergibt sich aus dem Wunsch heraus, die Cloud-Anwendung schnell und einfach auf Mobilgeräte auszurollen. Trotzdem sollte es Entwicklern noch möglich sein, den nativen Code der App anzupassen und die App in einem Simulator zu testen, bevor sie sie in die App-Stores stellen. Zusätzlich sollten die Apps mit einer gefüllten Datenbank ausgeliefert werden. Das ist einerseits sinnvoll, um den Review-Prozess der Stores zu erleichtern, und andererseits, um eine App zu liefern, die sich schon beim ersten Start sofort benutzen lässt.

Diese Anforderungen können dadurch erfüllt werden, dass in der Cloud-App eine automatisch generierte Xcode-Projektdatei zum Herunterladen bereitgestellt wird. Das ermöglicht es Entwicklern, ihre bevorzugten Werkzeuge für Änderungen und Tests zu verwenden. Wenn sie die App in ihrem Simulator starten, beginnt automatisch die oben beschriebene Replikation, sodass nach deren Abschluss ein vollständiges Abbild der Cloud-Datenbank im App-Container liegt, der alsdann ausgerollt werden kann.

Fazit

Obwohl die konsequente Integration aller in diesem Artikel diskutierter Anforderungen etliche technische Herausforderungen bedeutet, lohnt sich dieser einmalige Aufwand. Erste Erfahrungen mit der Realisierung komplexer Informationssystemen auf der Softwareplattform Protogrid, deuten darauf hin, dass sich die individuelle Entwicklungszeit aufgrund einer solchen integrierten Plattform wesentlich verkürzen lässt.

Dominik Rüttimann
ist Softwareingenieur im Cloud-Innovation-Team der ATEGRA AG. Als Mobilentwickler schätzt er es sehr, Ideen aus der NoSQL-Welt in die Architektur verteilter Mobilanwendungen zu überführen. Seit 2014 ist er für die Mobilstrategie der Softwareplattform Protogrid verantwortlich.

(ane)