Beim Thema mobile Endgeräte gibt es zwei wesentliche Erkenntnisse. Die erste Erkenntnis ist, dass Smartphones und Tablets die Art und Weise wie wir leben und arbeiten in wenigen Jahren grundlegend verändert haben. Man darf gespannt sein, was die Zukunft noch alles bringt, denn bei dieser Entwicklung stehen wir erst am Anfang,
Die zweite Erkenntnis aus Sicht des Softwareentwicklers betrifft die Frage, wie mobile Anwendungen am Besten zu entwickeln sind. Die verschiedensten Ansätze gehen von einfachen Web Anwendungen bis hin zu nativen Anwendungen, die für das jeweilige Smartphone / Tablet Betriebssystem geschrieben werden. Das Spannungsfeld liegt, wie bei den meisten Entscheidungen in der Software-Entwicklung, im Dreieck zwischen Qualität, Zeit und Budget. Wobei in dem Fall Qualität sich auf die optimale Nutzung der Möglichkeiten des jeweiligen Betriebssystem bezieht.
Um es klar zu sagen: Wenn Zeit und Budget keine Rolle spielt, ist eine native Anwendung sicherlich das Optimum. Vor zwei/drei Jahren war diese Entscheidung noch einfacher. Das iPhone und damit iOS war das Maß aller Dinge. Mit dem stärker werdenden Marktanteil von Android mussten mindestens zwei Plattformen unterstützt werden. Im primär geschäftlichen Umfeld konnten Anwendungen auch für BlackBerry entwickelt werden. Eventuell schafft es Microsoft zusammen mit Nokia doch noch, Windows 8 zu einem erst zu nehmenden Player in dem Markt werden zu lassen.
Mit dem stärker werdenden Trend Bring-Your-Own-Device fällt die Entscheidung, welche Plattform unterstützt werden soll, zunehmend schwieriger. Für zwei oder drei, eventuell sogar vier, Plattformen native Anwendungen zu entwickeln und auch noch "Feature"-gleich zu halten, bedeutet erhebliche Mehraufwände. Zumal das notwendige Know-how für jede dieser Plattformen vorhanden und stets aktuell gehalten werden muss.
Eine Alternative sind Entwicklungsumgebungen wie PhoneGap. Der Anwendungscode wird Plattform-unabhängig entwickelt und anschließend werden für die jeweiligen Plattformen native Clients generiert. Es kann dementsprechend nur der kleinste gemeinsame Nenner aller Plattformen unterstützt werden, aber auch der hat schon einen beträchtlichen Umfang. Gegebenenfalls kann aber auch PhoneGap so eingesetzt werden, dass auf die besonderen Fähigkeiten der einzelnen Plattformen Rücksicht genommen wird.
Auf der anderen Seite werden Web Anwendungen für Smartphones / Tablets mit den Möglichkeiten von HTML5 und CSS3 auch immer mächtiger. Das neueste Schlagwort in diesem Bereich heißt "Responsive (Web) Design". Ziel dabei ist es, die Anwendung von vorne herein so zu entwickeln, dass sie möglichst sowohl im Desktop-Browser als auch von mobilen Browsern optimal zu bedienen ist. Dieser Ansatz verspricht deutlich geringere Kosten bei der Entwicklung.
Bleibt also die Frage, was ist die richtige mobile Entwicklungsstrategie insbesondere im Hinblick auf XPages-Anwendungen?
Die vielleicht auf den ersten Blick unbefriedigende Antwort lautet: Es hängt von den Anforderungen ab.
Themen wie Push-Notifikationen, Zugriff auf Kalender / Kontakte auf den mobilen Geräten und Verschlüsselung sprechen für einen nativen Client. Auch der Themenbereich Offline-Fähigkeit ist eventuell ein Grund eher in Richtung nativer Client zu gehen.
Ist ein nativer Client notwendig, so favorisieren wir PhoneGap. Einfach aus dem Grund heraus, dass in PhoneGap in HTML und JavaScript entwickelt wird. Wir können also das Know-how und die Erfahrung aus der XPages-Welt nutzen.
Wenn die Anforderungen aber den nativen Client nicht zwingend erforderlich machen, so ist die Web Entwicklung unsere erste Wahl. Eine Anwendung so zu entwickeln, die sowohl vom Desktop als auch von mobilen Endgeräten bedient werden kann, ist allein vom Zeit- und Kostenaspekt her absolut sinnvoll.
Was bedeutet diese Unsicherheit bezüglich der Architektur nun für unser XPages-Framework?
Das in meinem letzten Blogeintrag "assono XPages-Framework - Trennung von Business Logik und Darstellung" beschriebene Prinzip des Model View Controller?Pattern kann seine Vorteile voll ausspielen.
Das Model View Controller?Pattern ist so aufgebaut, dass die Business?Logik sich komplett im so genannten Model befindet. Die Oberfläche wird in der View realisiert. Die gesamte Interaktion zwischen dem Model und der View wird über den Controller gesteuert. Das Model View Controller?Pattern auf XPages angewendet hat folgenden Aufbau.
Betrachten wir einmal die verschiedenen Szenarien für mobile Anwendungen.
Responsive (Web) Design
Sollte sich die Anforderungen an das Projekt so umsetzen lassen, dass sich die Anwendung mit der gleichen Weboberfläche gut sowohl im Desktop-Browser als auch im mobilen Browser bedienen lässt, so benötigen wir lediglich ein Model, einen Controller und die XPage.
Separate Webseiten für mobile Browser
Bisweilen greift der Ansatz des "Responsive (Web) Design" zu kurz und separate Webseiten für mobile Browser sind unumgänglich. In einem solchen Fall können die gleichen Klassen für das Model verwendet werden. Jeglicher Code, die Business-Logik betreffend, ist also nur einmal vorhanden. Es müsste lediglich ein weiterer Controller für die Interaktion geschrieben werden und die XPages für den mobilen Browser.
Native Anwendung
Für die Datenanbindung für native Anwendungen bieten sich REST-Services an. Selbstverständlich müssen für Daten, die über eine native Anwendung in das System gelangen, die gleichen Regeln gelten wie für Daten vom Desktop-Browser. Über einen separaten Controller wird wiederum der gleiche Code im Model angesprochen, so dass Business-Logik immer die gleiche ist.
Zusammenfassend liegt der große Vorteil in unserem XPages-Framework darin, dass unabhängig von der Zugriffsart immer der gleiche Code im Model angesprochen wird. Jede Anpassung auf der Ebene muss nur einmal vorgenommen werden. Dieses Prinzip spart Entwicklungszeit und sorgt für eine bessere Wartbarkeit der Anwendung.
