Stolpersteine bei der Cordova / PhoneGap Entwicklung

Logo PhoneGap und Cordova
© bluesource.at

Eine Cross-Plattform PhoneGap bzw. Cordova Entwicklung erscheint auf den ersten Blick recht einfach, denn was ist schon dabei, eine Webseite mit ein paar zusätzlichen Features, optimiert für kleine Displays, zu programmieren? Der Aufwand einer solchen App wird sehr häufig unterschätzt, denn es gibt zahlreiche kleinere und größere Hürden, die es zu überwinden gilt. Nicht grundlos wird der Aufwand einer PhoneGap oder Cordova-App eineinhalbmal so hoch eingeschätzt, wie der für die native Entwicklung einer App für eine Plattform. Dieser Artikel beleuchtet einige der häufigsten Schwierigkeiten bei der PhoneGap und Cordova Entwicklung einer App und wie diese überwunden werden können.

Doch bevor es los geht, gilt es noch zu klären, warum bisher von PhoneGap UND Cordova die Rede war, und im folgenden Artikel nur mehr PhoneGap genannt. PhoneGap baut auf Apache Cordova auf und somit gelten die nachfolgenden Erklärungen und Hilfestellung für beide Tools. Der Einfachheit halber, werden wir aber nur auf PhoneGap referenzieren.

PhoneGap Projektstruktur

Ein PhoneGap Projekt bietet die Möglichkeit, mehrere Plattformen im selben Projekt zu verwalten. Wenn man jedoch Plattformen im selben Projekt verwaltet, die unterschiedliche Betriebssysteme für den Betrieb der Entwicklungsumgebung benötigen (z. B. WP8 und iOS, die Windows 8 und Mac benötigen), so führt es bei der Installation von Plugins oder einem Update von PhoneGap sehr häufig zu Problemen. Grund hierfür ist, dass die Plugins oder das Update nur für eine der beiden Plattformen funktionieren und man diese somit auf beiden Betriebssystemen installieren müsste. Das führt in der Regel aber zu Merge-Konflikten in der Versionsverwaltung, bis hin zur Unbenutzbarkeit des Projekts. Daher empfiehlt es sich, für jede Plattform ein eigenes PhoneGap Projekt und Repository zu erstellen und den – auf allen Plattformen identen – www-Ordner ebenfalls in einem eigenen Repository zu verwalten. Dieser kann dann bei der Nutzung von GIT als Submodule, beziehungsweise bei der Benutzung von SVN als External zu den einzelnen Projekten hinzugefügt werden.

ViewPort

Auch wenn man die Breite der Webseite im CSS-Stylesheet als 100% angibt, so erscheint die Webseite am Smartphone größer als der Bildschirm und sie ist weit heraus gezoomt. Auch das Zoomen sollte in einer Web-App für gewöhnlich unterbunden werden. Dieses Problem lässt sich einfach lösen mit einer zusätzlichen Zeile innerhalb des HTML-Head Tags:

<META NAME="VIEWPORT" CONTENT="width=device-width,height=device-height,user-scalable=no,initial-scale=1.0,maximum-scale=1.0" />

Für Windows Phone wird zusätzlich folgende Zeile im CSS-Code eingefügt:

@-ms-viewport { width: device-width; }

Damit sollte auf sämtlichen Plattformen gewährleistet sein, dass die Webseite nicht gezoomt werden kann und der Bildschirmgröße entspricht.

Touch-Events

Wenn man eine PhoneGap-App am Smartphone nutzt, fällt einem gleich auf, dass diese sehr träge reagiert, das heißt, die Wartezeiten nach einem Klick sind größer als bei einer nativen App. Das liegt daran, dass die Web-View, in der die App angezeigt wird, nach einem Klick ca. 300 Millisekunden abwarten muss, ob ein zweiter Klick folgt, um im Falle des Falles einen Doppelklick zu erkennen. Es gibt verschiedene Möglichkeiten, dieses Problem zu umgehen: Zum einen kann man Anstelle der „click“-Events auf „mouseup“ oder „touchend“-Events reagieren, zum anderen kann man eine Library wie FastClick verwenden, welche die Verzögerung ebenfalls eliminiert.

Unerwünscht ist außerdem auch das mögliche Markieren von Text in der App. Dies kann mit CSS unterbunden werden, jedoch sollte man dabei in Betracht ziehen, dass man Textfelder in der Anwendung hat, bei denen man das Markieren von Text erlauben möchte. Aus diesem Grund sind hier daher mehrere CSS Regeln nötig:

*{ user-select: none; }

input, textarea{ user-select: auto; }

Der obige Code unterbindet das Markieren von Text auf sämtlichen Elementen, erlaubt es aber auf Elementen vom Typ „input“ und „textarea“ wieder explizit.

Pixeldichten

Je nach Pixeldichte und Displaygröße erscheinen die App und deren Elemente unterschiedlich groß auf dem Display. Auf Geräten mit geringer Pixeldichte erscheinen Elemente enorm groß, benötigen daher sehr viel Platz und lassen wenig Platz für andere Elemente – vor allem, da dies meist Geräte mit kleinem Display sind. Auf Tablets mit sehr hoher Pixeldichte hingegen erscheinen dieselben Elemente sehr klein, Buttons lassen sich manchmal kaum noch klicken. Um diesem Problem entgegen zu wirken, kann man CSS Media Queries nutzen, um die Elemente in ihrer Größe entsprechend anzupassen. Mehr dazu können Sie im Artikel „Responsive Web Design“ nachlesen.

Screenshot PhoneGap - Cordova
© bluesource.at

Fazit

Bei jedem Projekt stößt man auf neue, unerwartete Probleme bei der Entwicklung von PhoneGap/Cordova-Apps. Auch im PhoneGap/Cordova Code kommt es hin und wieder zu Fehlern, da bleibt es einem nicht erspart, im PhoneGap/Cordova Code selbst Änderungen vorzunehmen. Vor allem Windows Phone zeigt häufig ein unerwartetes Verhalten, daher ist es notwendig sehr oft und sehr genau auf möglichst vielen Geräten zu testen. Das Debugging erweist sich oft auch als relativ schwierig. Die besten Debugging Techniken können Sie im Artikel „Debugging in PhoneGap Apps“ nachlesen.

Alle Einträge anzeigen

Diese Webseite nutzt Cookies

Wir verwenden Cookies um die Webseite für Sie noch angenehmer zu gestalten. Wenn Sie unsere Webseite weiterhin nutzen ohne Ihre Einstellungen zu ändern, stimmen Sie unserer Verwendung von Cookies zu. Weitere Informationen zur Verwendung und Deaktivierung von Cookies durch Einstellungs-Änderungen finden Sie in unseren Cookie Richtlinien.

bluesource