Am Anfang war das X

Webbasierte Cross-Plattform-Entwicklung – für alle
Kommentare

Wie kann ich meine Software zukunftssicher machen und für meine Nutzer auf möglichst vielen Devices und Plattformen zur Verfügung stellen?

Die Spatzen pfeifen es seit Langem von den Dächern: Endanwender im privaten Leben besitzen in der Regel mehr als ein elektronisches Gerät, mit dem sie arbeiten – oder zumindest Daten sichten und bearbeiten. Windows ist schon lange nur noch eines unter vielen Betriebssystemen. Die Tablets und Smartphones dieser Welt haben zudem mittlerweile auch im Geschäftsumfeld den Siegeszug angetreten. Ein Umstand, dem Softwarehersteller realistisch entgegensehen müssen.

Nicht nur ein Mal in den letzten Jahren sind Softwareentwickler auf mich zugekommen mit Sätzen wie „Mein Chef hat gesagt, er will die Informationen aus unserer Hauptsoftware auch auf dem iPad sehen und bearbeiten können.“ Oder „Unsere Kunden rennen uns die Türen ein, weil sie jetzt mit Smartphones und dem Tablet von unterwegs ihre Anwendungen und Daten nutzen wollen.“ Nur war leider das jeweilige Hauptprodukt der Enterprise- bzw. ISV-Klientel eine rein Windows-basierte Software. Produkte, die seit Jahren etabliert sind und wunderbar funktionieren – auf dem Desktop im Büro. Man muss heute also weg vom reinen Windows und dem Desktop, sich öffnen für die neuen mannigfaltigen Ideen und Anforderungen der Endanwender.

Viele Entwickler wissen nicht, wie sie die schiere Fülle an neuen Plattformen und die damit verbundenen neuen Herausforderungen meistern sollen. Es bedarf neuer, zukunftsträchtiger Ansätze. Webbasierte Technologien rund um HTML5 und JavaScript erscheinen als große Chance, eine nachhaltige Antwort auf die Frage nach echter Cross-Plattform-Fähigkeit zu finden. Cross-Plattform-Entwicklung bedeutet jedoch nicht nur mobile Plattformen; allerdings geistert seit einiger Zeit ein Begriff durch die Onlineportale, News-Feeds und Fachzeitschriften, der derartiges suggerieren könnte: Mobile-First.

Mobile-First – oder doch Mobility-First?

Mobile-First bedeutet nicht, dass Software zuerst oder gar ausschließlich auf den Handys und Tablets laufen muss. Eigentlich ist Mobile-First eine irreführende Bezeichnung – Mobility-First würde viel besser passen. Es geht darum, dass wir im alltäglichen Leben unsere Daten und unsere Anwendungen überall nutzen wollen. Wir als Menschen sind mobil. Und erwarten das auch von unserer Software und von den Daten, die damit erstellt und verwaltet werden.

Um einen Mobile-First-Ansatz realisieren zu können, bedarf es gewisser strategischer, architektureller und letztendlich auch technischer Maßnahmen. Eine Ausprägung ist sicherlich die berühmte „App“. Doch was ist eine App überhaupt und ist sie wirklich alles, was wir benötigen?

Apps, Apps, Apps

In der Tat ist die klassische App, wie wir sie seit einigen Jahren bspw. von iOS, Android oder Windows Phone kennen, nicht das Maßgebliche. In einer hoch vernetzten Welt gibt es immer einen oder mehrere Server – bzw. Services – die mit im Spiel sind. Daten kommen, Daten gehen. Und die App ist nur eine bestimmte Ausprägung der Visualisierung und Nutzung dieser Daten und der damit verbundenen Abläufe und Prozesse. Auf einem Smartphone kann man nicht eben mal die gleichen komplexen Use Cases durchführen wie auf einer großen Desktopinstallation.

Das hat zur Folge, dass unsere Software, unsere „Applikation“, nicht mehr nur ein Stück ist – wie viele klassische Windows-Anwendungen. Vielmehr muss Software Use-Case-spezifisch geschnitten und via Services (im Sinne von Serviceorientierung) bereitgestellt werden. Damit man dann kleine Apps, größere Apps oder aber Desktopanwendungen davor spannen kann.

Leichtgewichtige Servicearchitekturen statt Monolithen

Dabei ist die Idee von Serviceorientierung seit Jahren etabliert. Zentrum der Idee rund um Services ist die Kapselung von fachlicher Funktionalität, um diese dann einfacher implementieren, verteilen, nutzen und weiterentwickeln zu können.

Sicherlich sollte man heutzutage seine Software immer „Distributed-First“ modellieren. Denn es ist so sicher wie das Amen in der Kirche, dass gewisse Komponenten und Services über sichere entfernte Aufrufe zugänglich gemacht werden müssen. Damit das in einer einfachen und interoperablen Art und Weise geschehen kann, sind HTTPS-basierte Programmierschnittstellen in Form von Web-APIs als Quasistandard gesetzt. Web-APIs gemischt mit Push Services für bidirektionale Kommunikation bilden heutzutage das Rückgrat einer leichtgewichtigen Servicesarchitektur.

Web-APIs und Push Services

Der eine sagt Web-API, der andere HTTP-API – und wieder ein anderer redet gerne über REST APIs. Über REST will ich hier nicht schreiben, das ist in der Tat ein Fass ohne Boden. Im Geiste von pragmatischen Lösungen, die üblicherweise über einen sinnvollen Mittelweg erreicht werden, geht es mir um eine schlanke, HTTPS-basierte Kommunikation zwischen Services und Konsumenten. Als Datenaustauschformat für strukturierte Daten bedienen wir uns JSON (JavaScript Object Notation), ein Standard, der sich v. a. in der mobilen und der Webwelt gegenüber XML und Co. durchgesetzt hat.

Clients können benötigte Daten im Request-Response-Verfahren per HTTPS-GET-Operation in Form von JSON von einem fachlichen Service beziehen und die JSON-Struktur in die jeweilige native Objektstruktur der verwendeten Programmiersprache umwandeln. Ebenso kann eine Objektstruktur im Client nach JSON umgewandelt und zum Service bspw. mit HTTPS-POST gesendet werden. Für die gängigsten Serverplattformen gibt es featurereiche und robuste Web-API-Frameworks, die Sie in Tabelle 1 sehen können (dies ist nur eine Auswahl).

Zudem wächst der Wunsch, bei auftretenden Updates im Datenbestand oder bei wichtigen Ereignissen, die bekannten Clients (ob mit UI oder ohne) vom Server aus zu benachrichtigen – und zwar über ein proaktives Push vom Server aus. Mit dem Push-Services-Design-Pattern ist das sehr einfach möglich. Stellen Sie sich vor, dass bei einer essenziellen Änderung an den Daten in der Browseranwendung automatisch die mobilen Apps auf allen Plattformen plus die anderen Browser auf Windows, Linux und Mac OS X benachrichtigt werden. Technologisch lässt sich eine Push-Kommunikation entweder über HTTP Long Polling, über Server-sent Events oder aber via WebSockets realisieren. Damit der Entwickler sich nicht um die zugrunde liegenden Netzwerk- und Protokolldetails kümmern muss, gibt es Programmierframeworks für alle größeren Plattformen wie Java, .NET und Node.js. Eine exemplarische Auswahl finden Sie wieder in Tabelle 1.

.NET Java Node.js
Web-API ASP.NET Web API Jersey/JAX-RS Restify
Push Services ASP.NET SignalR Atmosphere Socket.io

Tabelle 1: Typische Programmierframeworks für Web-APIs und Push Services

Immer wenn verteilte Kommunikation im Spiel ist, kommt man natürlich nicht um diverse Sicherheitsaspekte herum. Vor allem die Authentifizierung von Benutzern und die Feststellung von autorisierten Zugriffen sind zentraler Bestandteil einer jeden Software. In der leichtgewichtigen Welt der Web-APIs und Push Services gilt dies umso mehr. Mit auf HTTPS und JSON fußenden Standards wie OAuth 2.0 und OpenId Connect können wir diese Anforderungen schnell und vor allem plattformübergreifend lösen.

Vor allem der Browser manifestiert sich immer mehr dabei. Heutige Browser können viel, haben viel „eingebaut“ und entwickeln sich weg von der reinen dummen Darstellungssoftware.

Webbrowser als omnipotente Plattform

In der Tat schlummert ein großes Potenzial in modernen Webbrowsern. Egal ob Chrome, Firefox, Safari oder auch Edge (und teilweise Internet Explorer): Der gemeine Browser hat sich zur wirklich potenten Betriebsumgebung gemausert. Hersteller investieren sehr viel in die optimierte Darstellung und das Rendering von HTML und CSS – und vor allem in die performante Ausführung von JavaScript.

Öffnen Sie einfach mal die Developer-Tools im Browser Ihrer Wahl. Hier finden wir nicht nur einen Debugger für HTML, CSS und natürlich JavaScript, sondern auch komplette Profiling-Möglichkeiten, um Speicher- oder Laufzeitprobleme direkt im Browser analysieren und adressieren zu können. Zudem besitzen Browser heute mehrere Speichermechanismen, um Daten auch lokal ablegen zu können. Sie reichen vom simplen Name-Value-Speicher bis hin zu umfangreichen SQL-und NoSQL-Datenbanken. All das in Ihrem Browser. Auf dem Desktop und mobil. Überall und für alle.

Mit den lokalen Speichermöglichkeiten lassen sich auch wunderbar komplett offline funktionierende Anwendungen erstellen. Ja, richtig: Obwohl im Browser ausgeführt, benötigen diese Anwendungen dann keine permanente Onlineverbindung, sondern können komplett im Browserkontext mitsamt zwischengespeicherter Daten betrieben werden. Für die Kommunikation mit den serverseitigen Web-APIs muss natürlich eine Verbindung vorhanden sein. Damit bei der Umsetzung einer offlinefähigen Lösung keine bösen Überraschungen auftreten, sollte man das Thema Offline sofort von Beginn an beim Entwurf mitberücksichtigen: Offline-First heißt hier die Maxime.

JavaScript und TypeScript: die Sprachbasis

JavaScript selbst hat sich in den letzten Jahren stark weiterentwickelt und ist mittlerweile eine ernstzunehmende Sprache. Mit ECMAScript 2015 hat die Sprache einen guten und modernen Stand erreicht, und die Pläne für ECMAScript 7 lassen die Hoffnungen weiterleben, dass wir es hier mit einer lebendigen und der Realität offen gegenüberstehenden Programmiersprache zu tun haben.

Die Natur von JavaScript ist freilich immer noch dynamisch. Und eben genau diese Dynamik macht sie so interessant. Ich persönlich habe viele Jahre mit statischen Sprachen wie Java und C# gearbeitet und nutze sie immer noch – doch bin ich immer wieder positiv angetan, welchen Programmier-Flow und vor allem -Speed man mit JavaScript auf dem Client erreichen kann. Wenn man Java oder .NET-UI-Frameworks gewöhnt ist, stellt das in der Tat eine willkommene Abwechslung und vor allem Verbesserung dar.

Aber ja, nicht jeder kann sich mit den Eigenheiten und der Natur von JavaScript anfreunden. Microsoft hat dies erkannt und bietet mit TypeScript eine Alternative an, die sich immer größerer Beliebtheit erfreut. Mit einem optionalen Typsystem und Compilerunterstützung können alle Nettigkeiten aus der Java- und .NET-Welt eins-zu-eins auch in der Webwelt genossen werden. Einige Faktoren aus der reinen JavaScript-basierten Entwicklung – wie der erwähnte Flow und Speed – gehen dabei zwar teilweise verloren, aber ein Programmierer bzw. ein Projektteam kann und muss für sich selbst entscheiden, welchen Weg man hier beschreiten möchte.

Doch wie bauen wir nun echte Anwendungen im Browser – anstatt nur Webseiten? Die SPAs kommen uns hier zur Hilfe.

Single Page Applications (SPAs) als Smart Clients

Das Geheimnis für das erfolgreiche Beschreiten des neuen Pfads der webbasierten Softwareentwicklung für alle und alles geht über drei Buchstaben: SPA. Die Single Page Applications sind gewissermaßen die Smart Clients für den Browser. Eine Anwendung wird gebündelt in Form von HTML Markup, CSS3 Styles, Assets wie Bilder und natürlich JavaScript (ob nativ geschrieben oder über den TypeScript-Compiler erzeugt) initial von einem Webserver ausgeliefert. Nach dem Anwendungsstart erfolgt die Ausführung der Clientlogik im Browser (oder der Browser-Engine bei nativen Anwendungen und Apps), und jegliche Kommunikation geschieht über JSON-Austausch via HTTPS mit Web-APIs oder Push Services. Abbildung 1 gibt einen schematischen Überblick über eine typische Gesamtarchitektur und wie die SPA-Teile im Browser mit hineinspielen.

Abb. 1: Architekturüberblick einer Single Page Application (SPA) mit Web-APIs und Push Services

Abb. 1: Architekturüberblick einer Single Page Application (SPA) mit Web-APIs und Push Services

Es werden in SPAs keine kompletten Seitenreloads gemacht, sondern es wird vielmehr nur der vom Use Case betroffene Teil der Clientanwendung mit einer neuen View versorgt und die Daten darin gebunden. Die verwendeten Views können dabei sogar komplett vorher geladen werden, sodass in der Praxis keinerlei HTML mehr nachgeladen werden müsste.

Eine SPA lässt sich selbstverständlich mit reinem JavaScript komplett selbst implementieren. Doch gewisse Features wie View Templates, Datenbindung, lokales Routing/Navigation und einiges mehr bedeuten einen großen Aufwand in der Umsetzung. Nun könnte man sich kleine Frameworks für jede der benötigten Funktionalitäten zusammensuchen und versuchen, sie aufeinander abzustimmen und die Versionsflut in den Griff zu bekommen – oder man bedient sich eines speziell für Smart Clients, also SPAs, entworfenes und entwickeltes Framework, das einem das Leben einfacher macht. Ein solches Framework ist AngularJS.

AngularJS und Co.

Das aktuell populärste SPA-Framework ist mit Abstand das Open-Source-Projekt AngularJS. Die Community rund um das Framework ist sehr aktiv und umtriebig. Selbstredend existieren auch andere Frameworks im SPA-Umfeld – nur AngularJS ist heute am komplettesten, wenn es den typischen Umfang von SPAs zu betrachten gilt.

AngularJS setzt auf einem MVC-(Model-View-Controller-) bzw. MVVM-Design-Pattern (Model-View-ViewModel) auf. Dadurch lassen sich sehr gut essenzielle Dinge für ein UI-Anwendungsframework wie templatebasierte Views und Datenbindung lösen. Zudem zwingt einem die auf Dependency Injection aufsetzende Basisarchitektur zur Trennung von Zuständigkeiten und führt somit geleitet zu einer klaren Struktur in der Codebasis. Mit AngularJS SPAs bauen fühlt sich nicht an wie die vergangene JavaScript-Hackerei, sondern mehr wie professionelle Anwendungsentwicklung, wie man sie sonst von Desktopframeworks her kennt.

Mit seinem MVVM-Design-Ansatz ist es sehr eingänglich für Entwickler aus der .NET- und auch der Java-Welt. Reine jQuery-Programmierer hingegen werden eine gewisse Lernkurve nicht wegdiskutieren können. Doch lohnt sich der Aufwand, denn mit AngularJS lassen sich gut strukturierte und auch große Anwendungen jeglicher Ausprägung realisieren. Auch für native Umgebungen und für die diversen App Stores.

Native Integration

Der installierte Browser ist nach wie vor eine Sandbox. Hier sind nur gewisse Interaktionen mit der lokalen Betriebssystemplattform möglich und erlaubt. Über Tools wie Apache Cordova oder aber NW.js lassen sich unsere SPAs in native Anwendungscontainer verpacken. Mit Cordova können wir Apps für die gängigsten mobilen Betriebssysteme erstellen, und mit NW.js kann ein Entwickler klassische Anwendungen für Windows, Linux und Mac OS X kreieren.

In Abbildung 2 sehen Sie eine kleine Beispielanwendung, die sowohl im Internet Explorer auf Windows, im Safari unter Ma cOS X, auf dem iPhone, auf einem Android-Tablet und schlussendlich über eine Chrome-basierte Browser-Engine auch als native EXE für Windows und Mac OS X läuft. Alles mit einer Codebasis – und mithilfe eines effizienten Build-Prozesses.

Abb. 2: Mit HTML5 und JavaScript Anwendungen auf jeder erdenklichen Plattform laufen lassen

Abb. 2: Mit HTML5 und JavaScript Anwendungen auf jeder erdenklichen Plattform laufen lassen

Die erstellten Binaries von Cordova (und teilweise auch NW.js) lassen sich darüber hinaus problemlos – unter Einhaltung der maßgeblichen Store-Richtlinien – in den App Stores von Apple, Google und Microsoft platzieren. Immer noch alles mit einer einzigen Codebasis.

Übrigens: Ich habe die abgebildete Anwendung auch auf einem Smart-TV am Laufen – nur war es mir bedauerlicherweise zu aufwändig, ein brauchbares Bildschirmfoto davon zu erstellen.

Auf den Weg gebracht

Nach diesem ersten Einblick in die neue Welt werden Ihnen in dem vorliegenden Magazin die Autoren viele der hier diskutierten Themen, Ansätze und Technologien aus der Welt von HTML5, JavaScript und dem Universum der Browser und auch darüber hinaus im Detail näherbringen. So sollten Sie als interessierter Softwareentwickler auf der Suche nach dem Cross-Plattform-Gral bestens gewappnet sein, die ersten Schritte zu gehen und Ihre Projekte bzw. Produkte fit zu machen für die Zukunft. Denn die Zukunft beginnt heute – und sie ist Cross-Plattform.

Aufmacherbild: The way forward railway via Shutterstock / Urheberrecht: hxdyl

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -