Entwicklung

Eine hybride Web-App für ein Blog oder ein ähnliches Medium zu entwicklen, ist mit Cordova - dem früheren PhoneGap - und NetBeans sehr einfach. NetBeans und das integrierte Cordova-Plugin generieren per Scaffolding alle erforderlichen Ressourcen, so dass wir nur eine einzige Zeile Source-Code benötigen, um unsere App zu realisieren.

Haben wir unser Blog nach den Prinzipien des Responsive Design entwickelt, funktioniert unsere App nicht nur technisch, sondern auch optisch sofort.

Ein Tool, welches die Produktivität bei der Entwicklung hybrider Web-Apps erheblich verbessert, ist der Chrome-Ripple-Emulator.

Das Testen mit dem Android-SDK-Emulator kostet viel Zeit für das Build sowie das Launchen der Anwendung im Emulator. Die Android-Emulatoren bieten allerdings den Vorteil, das sie das Testen für viele verschiedene Betriebssystem-Versionen und Endgeräte-Typen ermöglichen, weshalb das SDK im Entwicklungsprozess nicht überflüssig wird.

Der Ripple-Emulator dagegen eignet sich für die effiziente Programmierung der App als solche, solange neue Funktionalitäten während eines Entwicklungszyklus aufgebaut und vorläufig getestet werden.

Vor allem auch die Sensorik von mobilen Endgeräten kann mit dem Ripple-Emulator viel besser getestet werden, als mit dem SDK-Emulator.

In diesem Beitrag geht es hauptsächlich um die Vor- und Nachteile hybrider Web-Apps aus der Entwicklungsperspektive. Mit hybrid ist das aus der Anwendungsentwicklung bekannte Prinzip "Write once, compile anywhere" gemeint.

Native Apps benötigen für jedes Betriebssystem jeweils eine eigene Entwicklung. Hybride Apps werden in Html5, CSS3 und Javascript realisiert und benötigen für die Auslieferung an verschiedene Betriebssysteme (Android, iOS, Windows, ...) nur noch einen Betriebssystem-spezifischen Wrapper, der zudem automatisch generiert werden kann, z.B. mit Cordova, das früher bekannt war unter dem Namen PhoneGap.

Der Entwicklungsaufwand von hybriden Apps ist deshalb gegenüber dem für native Apps wesentlich geringer (vgl. Abb. 1).

Wer Apps für mobile Endgeräte entwickelt, wird sich das Software-Development-Kit von Android (SDK) installieren. Analoge Systeme für iOS gibt es natürlich, werden hier aber zunächst nicht diskutiert, da sich das Android-Betriebssystem für erste Schritte am besten eignet. Da wir nur hybride Apps entwickeln, benötigen wir nicht das Android-Studio mit der speziellen Eclipse-Java-IDE, sondern nur die Stand-alone SDK-Tools.

In der kleinen Artikel-Reihe zum Thema Grunt war die Installation von Node.js auf dem lokalen Rechner vorausgesetzt worden. Grunt ist nichts anderes als eine Node.js-Applikation. Es ist Zeit, sich einmal mit Node. js näher zu befassen.

NetBeans ist eine freie OpenSource-IDE für Java, Javascript, Html, PHP, C++ und andere Programmiersprachen und erfreut sich weltweit wachsender Beliebtheit.

Ich habe früher lange mit Eclipse PHP und dem Aptana-Studio, einer für Javascript optimierten Eclipse-Version, gearbeitet und das sogar parallel. Der Grund war, dass es offensichtlich nicht möglich war, die Vorzüge einer für PHP und einer für Javascript optimierten Version in einer einzigen Eclipse-Konfiguration zu vereinen. Das hatte mich lange sehr gestört, denn wer Backend und Frontend im PHP-Umfeld entwickelt, der braucht beides in einem einzigen System.

Genau diese Erwartung erfüllte dann NetBeans für PHP und Html5 (Download) ganz ausgezeichnet. Das wichtigste Argument für Netbeans für meine Bedürfnisse als Front- und Backend-Entwickler im Umfeld von PHP ist, dass PHP und Javascript von einer einzigen IDE gleich gut unterstützt werden.

Eine einfache Möglichkeit in Drupal Popup-Fenster zu erzeugen, bietet das Drupal-Modul Colorbox, das auf dem gleichnamigen jQuery-Plugin basiert.

Dies wird in folgendem Beispiel anhand eines einfachen Szenarios gezeigt.

Bei einem größeren Projekt entstehen höhere Anforderungen an die Organisation und Dateistruktur der Sourcen. Diese Anforderungen gelten sowohl für die Modul- als auch die Theme-Entwicklung. Dazu muss man sich in jedem Projekt Gedanken machen,

• wie man den Source-Code innerhalb eines Moduls oder Themes auf verschiedene Ordner und Dateien verteilt,
• wie man Teile des Source-Codes über mehrere Module hinweg gemeinsam nutzen kann und
• wie man Ordner-, Datei-, Klassen- und Funktionsnamen so wählt, dass der Source-Code am Ende gut lesbar ist.

Drupal bietet hierfür verschiedene gestufte Ansätze, die je nach Komplexität des Projekts mehr oder weniger in Frage kommen. Insbesondere empfiehlt es sich, bei jedem nicht-trivialen Projekt das Autoloading zu nutzen.

Im folgenden werden die Möglichkeiten der Sourcecode-Strukturierung in Drupal kurz diskutiert, um dann ausführlicher auf das PSR-4 Autoloading einzugehen, das für Drupal 8 den aktuellen Standard darstellt und für das es in Drupal 7 das Modul X Autoload gibt.

Wer häufiger mal einen View gebaut hat, wird auf dieses Problem gestoßen sein: Für einige Felder des Views werden keine Daten ausgegeben.

Meist liegen die Ursachen in einer fehlerhaften Konfiguration. Gerade in Drupal sind aufgrund des aspektorientierten Ansatzes Konfigurationen für das gleiche Objekt häufig in verschiedenen Modulen vorzunehmen, so dass man leicht den Überblick verliert. Meist stößt man nach einiger Zeit auf die Lösung, allerdings eben gerade nicht, wenn man verzweifelt danach sucht.

Bis dahin kann man sich mit folgendem Provisorium helfen.

Wer ein etwas komplexeres Modul erstellt, wird seinen Source-Code dafür in der Regel auf mehrere Ordner und Dateien aufteilen. Diese Ressourcen müssen an der richtigen Stelle geladen werden. In der Drupal-Dokumentation wird hierfür die Funktion module_load_include empfohlen. Die Anwendung führt aber manchmal zu Problemen, die im folgenden dargestellt werden.