Cordova Integration in Visual Studio 2013 (Part 2) – Unterschiede im Workflow verstehen

Als Entwickler, der genau zum Zeitpunkt der Bekanntgabe von „Cordova in Visual Studio“ in einem Phonegap-Projekt unterwegs war, waren meine Erwartungen, Wünsche und Freude enorm. Denn das entwickeln auf dem „alten Weg“ über Phonegap, war/ist alles andere als komfortabel oder spaßbehaftet, wenn man Entwicklungsumgebungen wie Visual Studio gewohnt ist. Doch Vorsicht: Neue Möglichkeiten bedeuten meist auch neuen Workflow!

Denn nicht nur der Build-Prozess, auch das Tooling zum Editieren des Codes ist eine Ansammlung von vielen einzelnen Insellösungen, zusammengestellt nach eigenen Geschmäckern. Aber wirklich „effizienzschwanger“ kam meine Entwicklungsumgebung nie daher. Da klingt es schon wie eine Fata Morgana, dass Visual Studio den gesamten Prozess vom Editing bis zum Deployment übernimmt und beherrscht. Doch sollte man mit nüchternen Erwartungen an die Sache heran gehen – denn auch jetzt mit der Integration in Visual Studio bedarf es einiges an Umdenken, wenn man mit Cordova arbeiten möchte. Es wollen hier immerhin Android, iOS, Windows und Windows Phone gleichermaßen angesprochen werden. Vorweg kann man sagen, dass dies zum Teil richtig gut funktioniert, zum Teil etwas umständlich, und zum Teil überhaupt nicht.

Neu Strukturiert

Doch alles der Reihe nach – der erste Schritt um diese Gesamtheit zu ermöglichen, ist die Veränderung der physischen Projektstruktur. Betrachten wir ein frisch erstelltes Cordova-Projekt in Visual Studio und vergleichen dies mit einem Phonegap-Projekt, fällt direkt die geänderte Ordner-Struktur auf.

CordovaProjectVS

 

 

 

 

 

 

 

 

 

 

Abbildung: die Cordova-Projektstruktur neu in Visual Studio

 

CordovaPGProject

 

 

 

 

 

 

 

 

Abbildung: die Projektstruktur in PhoneGap (Klicken für volle Größe)

 

Doch warum ist die Ordner-Struktur so anders? Vor dem „Ausbruch des Luxus“ in Visual Studio war der Content eines Cordova-Projektes so organisiert, dass er in einem generellen „www“-Ordner mit Edit-Tools des Entwicklers Wahl gepflegt und verwaltet wurde. Galt es gemachte Änderungen zu testen, gab es zwei lokale Möglichkeiten dies zu bewerkstelligen. Die erste Möglichkeit ist, den Content auf einem lokalen Webserver in Chrome zu starten, und mit dem Ripple-Emulator auszuführen (kann über Google-Web-Apps für Chome installiert werden). Wenn es mit der App auf ein natives Device gehen soll, braucht es allerdings die Console und z.B. Phonegap. Über die Eingabe von Consolen-Befehlen muss zum Einen die gewünschte Target-Platform zum Projekt hinzugefügt, zum Anderen für die gewünschte Plattform der Build- bzw. Emulate-Prozess angestoßen werden.

CordovaConsoleAddPlattform

.

.

.

.

.

Abbildung: Line-Commands für das Hinzufügen von Targetplatforms in PhoneGap

CordovaConsoleBuild

.

.

Abbildung: Line-Commands für den Build und das Starten des Emulators in PhoneGap

 

Diese beiden Vorgänge hatten zur Folge, dass das Cordova-Projekt das vorher nur den eigentlichen Content im „www“-Ordner bereitgestellt hat, um weitere Ordnerstrukturen für alle angelegten Plattformen erweitert und mit den Plattforms-spezifischen Notwendigkeiten ausgestattet wurde.

Beim Bauen der App für die gewünschte Plattform wird der generelle „www-Ordner“ mit dem App-Content für die gewünschte Plattform eingepflegt und zur Verfügung gestellt. Mühsam war/ist der Umstand, dass bei Änderungen im globalen „www“-Content-Ordner der Cordova Build Prozess neu angestoßen werden muss, damit die Änderungen greifen. Diese Schritte sowie die Projektstruktur gehören in Visual Studio nun der Vergangenheit an. Beim Starten der App mit F5 (natürlich abhängig von der Platform-Angabe) in Visual Studio wird das Projekt dynamisch mit allen plattformspezifischen Assets bestückt, ohne dass die Struktur der Projekt-Sourcen davon betroffen sind.

Betrachtet man den Rest der Ordner, fällt außerdem auf, dass der „www“-Content-Ordner so nicht mehr vorhanden ist. Die Inhalte des Ordners verteilen sich über die Projektstruktur des Projektes, wobei die klassischen Seiten wie „index.html“ im Projekt-Root zu finden sind, während der traditionelle „js“-Ordner für Javascripts nun „scripts“ heißt. Per Default werden auch ein „images“ und ein „css“ Ordner angelegt. Das Projekt-Hauptverzeichnis stellt quasi den alten „www“-Ordner dar. Wenn ein bestehendes Cordova-Projekt migriert werden soll, muss gerade bei den Javascripts darauf geachtet werden, dass ein Refactoring bzgl. der Pfadangaben zu den Scripts vorgenommen wird.

Klingt erst einmal nach einer eher kleinen Veränderung – allerdings mit großer Wirkung, da nun nicht mehr mehrere www-Ordner vorhanden sind, und so auf einem zentralen Contentstand gearbeitet wird. Das schafft Klarheit und mindert die Fehleranfälligkeit beim Bearbeiten von Assets.

 

 

Plugins – die eigentliche Magie von Cordova

Solange ein Cordova-Projekt nur HTML-Content visualisiert, ist es eigentlich nur ein Webbrowser in einer nativen App, der Webseiten anzeigt. Für diese Art von eher unspektakulären Apps wurde Cordova nicht konzipiert. Erst wenn man auf gerätespezifische Features, Hardware und Sensoren zugreifen möchte, kommt Schwung ins Cross-Device-Leben. Cordova ermöglicht über Plugins den standardisierten Zugriff auf Geräte-Funktionen wie das Adressbuch oder auch Sensoren wie GPS oder NFC. Über Javascript können diese Plugins dann konsumiert bzw. angesprochen werden.

Mit Phonegap war es bisher notwendig, die gewünschten Plugins über einzelne Consolenbefehle für jedes Plugin in das Projekt zu laden.

CordovaConsolePlugins

.

.

Abbildung: Line Commands für das Hinzufügen von Plugins in PhoneGap

In Visual Studio wird dies nun recht komfortabel über eine Checkbox-Auswahl erledigt. Die „config.xml“ im Projekt-Root-Verzeichnis wird hierzu mit einem Doppelklick geöffnet. Unter dem Tab „Plugins“ befinden sich alle verfügbaren Plugins, die für dieses Projekt zur Verfügung stehen. Wird ein Plugin ausgewählt, kümmert sich Visual Studio automatisch um das Setzen der damit verbundenen Berechtigungen für jede Plattform. Über den händischen Weg mit PhoneGap muss hier bisher bei einigen Plugins Hand in der config.xml angelegt werden.

CordovaConfigXML

.
.

.

.

.

.

Abbildung: Plugins-Verwaltung in der config.xml (klicken für volle Größe)

Betrachten wir die geöffnete config.xml finden sich noch 3 weitere Registerkarten, die mit Optionen aufwarten. So können unter „Application“ hier ganz bequem alle Informationen zur App angegeben werden, bzgl. Name, Version, Start-Seite des Contents etc. Über die Registerkarte „Domains Access“ werden alle Domains eingetragen, die sich außerhalb der App befinden, aber aufgerufen werden können (z.B. Links für OAuth).  Die Sektion „Packaging“ ist nur dann interessant, wenn das Projekt auch für Windows 8 deployed werden soll. Hier sei nebenbei erwähnt, dass dies kein Verschreiber ist – Cordova kann aktuell nur für Windows Store Apps in der Version 8.0 liefern.

IntelliSense on Board

Wo wir gerade über Fehleranfälligkeit und Klarheit gesprochen haben – Ein Segen für viele Entwickler wird die IntelliSense-Unterstützung von Visual Studio sein. Diese kommt mächtiger und präziser daher, als die in vielen freien Javascript-Editoren. Wer Resharper oder andere etablierte 3rd-Party-Tools für Visual Studio verwendet, kann sich außerdem über die damit verbundenen zusätzlichen Features freuen.

CordovaIntellisense

.

.

.

.

.
.

.

Abbildung: IntelliSense-Unterstützung für Cordova

In diesem zweiten Teil ging es um die Veränderungen bei der Arbeit mit Cordova, wenn man Visual Studio dafür bemühen kann bzw. möchte. Einiges ist anders im Handling und der Projektstruktur. Vieles ist besser geworden, einiges aber auch nicht. Gerade beim Debugging und Deployment gibt es wichtige Dinge bzw. Pro und Contras zu beachten. Im dritten Teil geht es deshalb um das Debugging und Deployment von Cordova-Apps, welche in Visual Studio erstellt wurden. Es werden die neuen Möglichkeiten betrachtet und erklärt, wie Anwender den PhoneGap Build Cloud – Dienst für ihren Deploy-Prozess nutzen können, um Ihre Anwendung für iOS zu deployen ohne einen Mac besitzen zu müssen.

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>