14.12.2012

assono XPages-Framework - mobile Entwicklungsstragie

>>Author:  Bernd Hort
>>Ort:     Hamburg
        
URL: http://www.assono.de/blog/d6plinks/assono_XPages-Framework-mobile-Strategie

Category: XPages, assono, mobil

assono XPages-Framework

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.

Model View Controller-Pattern in XPage-Anwendungen

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.

XPages-Framework und mobile Entwicklungsstragie

Comments

#1 Ich hatte mir Phonegap auch angesehen, war aber ziemlich enttäuscht davon. Phonegap Anwendungen sehen nicht aus und fühlen sich nicht an wie native Apps.

Und die Art der Entwicklung fand ich extrem unkomfortabel, ständig muss man mit tausend Callbacks um sich schmeißen, das ist gerade für den typischen Notes Entwickler eine große Umstellung.

Ich finde den Ansatz von Appcelerator Titanium erheblich schlauer: ein JavaScript Code, der auf der jeweiligen Platform in einem nativen Container läuft und alle nativen Controls und die komplette Hardware nutzt.

So arbeitet man im bekannten JavaScript (aber ohne die tausend Callbacks wie bei PhoneGap) und muss nicht mit HTML und CSS versuchen, das Look & Feel einer nativen App nachzubilden.

Und mit dem neuen Alloy-Framework ist auch die Gestaltung der UI viel einfacher geworden, Stichwort MVC.

Und schließlich wird Titanium in naher Zukunft auch Windows 8 und Blackberry 10 unterstützen, damit hat man dann alle relevanten Plattformen beisammen.
Gravatar Image
#2 Wenn ich mir den Großteil der apps auf meinem iPhone ansehen, so haben die meisten inzwischen ihr eigenes Look & Feel. Gerade im Hinblick auf plattformübergreifende Apps ist es vielleicht sogar besser, wenn ein einheitliches Aussehen auf allen Plattformen hat.

Das "Programmieren" der Oberfläche in Titanium via JavaScript hat mir nicht so gut gefallen. Wobei ich mir das Alloy-Framework noch nicht angesehen habe.

Aber auch unsere Entscheidung für PhoneGap ist nicht in Stein gemeizelt. Wichtig war mir in dem Artikel darauf hinzuweisen, dass es den immer passenden Ansatz sowieso nicht gibt.
Gravatar Image

Post A Comment

Comments

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)

Tags

Deutsche RSS-Feeds (German)

Custom Button Custom Button

English RSS feeds

Custom Button Custom Button