Seite 2: Mögliche Entwicklungsansätze

Inhaltsverzeichnis

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.