03. Jul

Multiscreen-Tutorial, Chat mit Websockets Teil 1: Einführung

Moderne App- und Webprojekte können kaum mehr nur für eine einzige Plattform entwickelt werden. Die immer stärkere Nutzung von Smartphones, Tablets oder Smart-TV nötigt uns fast schon dazu einen ganzheitlichen Multiscreen-Ansatz zu wählen. In diesem fünfteiligen Tutorial erhalten Sie einen Überblick über ein beispielhaftes Multiscreen-Projekt. Für unser Beispiel wählen wir eine kleine Chat-Applikation, die wir mit aktuellen Technologien für Desktop, Tablets, Smartphones und Smart-TV-Geräte Schritt für Schritt umsetzen. Im heutigen ersten Teil verschaffen wir uns zuerst einmal einen Überblick über die Begrifflichkeiten und die unterschiedlich benötigen Komponenten für unseren Multiscreen-Chat.

Multiscreen (Experience) Design

Zuerst einmal wollen wir uns dem Begriff Multiscreen, beziehungsweise etwas deutlicher Multiscreen (Experience) Design, widmen. Ein Synonym für Multiscreen ist Multidevice, was das ganze vielleicht etwas besser darstellt. Genau genommen handelt es sich bei Multiscreen Design oder Multidevice Design um einen Ansatz, der bei der Konzeption und dem Design einer App die unterschiedlichen Devices und Screens beachtet. Wolfram Nagel, Head of Design der digiparden und Mit-Autor des Buches Multiscreen Experience Design gliedert das ganze  in 4 Geräteklassen auf:

  • Smartphone
  • Tablet
  • Desktop/Laptop
  • Smart-TV

Dabei sind natürlich nicht nur die unterschiedlichen Display-Größen, sondern vor allem auch die entsprechenden Nutzungsszenarien, respektive der entsprechende Nutzungskontext zu beachten. Ein Benutzer, der sein Smartphone auf der Fahrt zur Arbeit im Zug benutzt, hat einen anderen Anspruch an eine App, als jemand, der abends entspannt mit dem Tablet auf dem Sofa vor dem Smart-TV sitzt. Für eine umfassende Multiscreen-Konzeption sind also sehr viele Faktoren zu beachten. Einen Überblick erhalten Sie auf der Seite www.multiscreen-experience-design.com.

Es ist verständlich, dass wir im Rahmen dieses Tutorials das Thema Multiscreen Experience Design nur oberflächlich behandeln können und keine tiefgreifende Anpassungen für die unterschiedlichen Nutzungskontexte entwerfen können.

Vielleicht werden wir nach Abschluss der Tutorial-Reihe mal den Chef-Multiscreener Wolfram Nagel drüber schauen lassen und bei einem kühlen Bier Möglichkeiten und weitere Ideen besprechen. Sollten Sie Interesse an professionellen Multiscreen-Strategien und -Konzepte haben, sollte Wolfram Nagel von den digiparden sicherlich der richtige Ansprechpartner sein. Wir als App Agentur setzen das Konzept dann gerne technisch um.

Die 4 Komponenten unseres Chats

Unser kleines Multiscreen-Projekt besteht aus einem Server, einem webbasierten Client, einer mobilen Apps für iOS und Android, sowie einer Smart-TV App für Samsung-Geräte. Im folgenden stellen wir Ihnen die einzelnen Komponenten genauer vor. In den noch folgenden 4 Teilen unseres Tutorial setzen wir die einzelnen Komponenten dann praxisnah mit Quellcode-Downloads um.

Der Server

Um die Kommunikation mit den verschiedenen Clients koordinieren zu können, benötigen wir natürlich in erster Line eine Server-Komponente. Der Server wartet auf Verbindungsanforderungen von den Clients und verteilt die Nachrichten untereinander. Der Einfachheit halber werden wir auf Spielereien wie private Nachrichten und ähnliches verzichten. Jede Chat-Nachricht wird an alle verbundenen Clients gesendet. Das ganze natürlich in Echtzeit – sprich der Benutzer sollte keine, oder kaum eine Zeitverzögerung bemerken.

Das klassische HTTP-Protokoll ist für diese Aufgabe kaum geeignet. Anfragen von einem Browser werden vom Server beantwortet – das war es. Spätere Änderungen auf dem Server bekommt der Browser nur durch eine erneute, eigene Anfrage mit. Die Verbindungen von Client und Server sind im HTTP-Protokoll zustandslos – oder cooler ausgedrückt “stateless”. Vergleichbar mit einer Brieffreundschaft im realen Leben: Brief wird gesendet, Brief wird gelesen – Antwortbrief wird geschrieben und versendet. Zwei letztendlich voneinander unabhängige Aktionen. Genau so verhält es sich mit HTTP-Verbindungen – relativ ungeeignet also für eine Echzeitanwendung wie unseren Chat.

Javascript-Server mit node.js und socket.io

Eine Lösung bieten Socket-Verbindungen. Eine einmal aufgebaute Socket-Verbindung zwischen Client und Server ist bidirektional. Vergleichbar mit einem Telefonat. Beide Seiten hören sich in beide Richtungen in Echtzeit. Genau das, was wir für unseren Chat benötigen. Um einen Socket-Server aufzubauen bietet sich node.js, eine serverseitige Plattform zum Betrieb von Netzwerkanwendungen. Anwendungen in node.js werden in Javascript entwickelt. Ja Sie hören richtig: Javascript für einen Server klingt kurios, war es bis vor “kurzem” auch noch. Inzwischen aber ist die Javascript-Entwicklung und node.js voll im Serveruniversum angekommen.

Um uns die ganze Sache etwas zu vereinfachen, verwenden wir als Grundlage für unseren Chat-Server socket.io – eine Realtime-Engine für node.js. Das Framework erleichtert uns die Programmierung unseres Chat-Servers enorm, wie Sie in unserem kommenden zweiten Teil des Tutorials sehen werden.

Cloud-Hosting auf cloudcontrol.de

Mit node.js und socket.io haben wir schon einmal eine gute Basis für einen performanten Chat-Server. Doch da wir auch sehr optimistisch sind, erwarten wir einen enormen Zulauf zu unserem Chat-Server. Hunderte, tausende, ja abertausende Benutzer sollte unsere Server dann schon verarbeiten können. Da wir die letztendlichen Zugriffe aber kaum einschätzen und diese zudem extrem schwanken können, würden wir selbst mit einem hochoptimierten und aufgerüsteten Root-Server irgendwann an die Grenzen stoßen. Zumal ein solcher Server für ein reines Testprojekt zu Beginn kaum rentabel wäre. Irgendwie benötigen wir hier eine flexiblere Lösung. Cloud-Hosting heißt das Zauberwort.

Wir werden unseren Chat-Server also irgendwo in die Cloud schieben, dort soll er sich automatisch je nach Zugriffen skalieren. Für unserer Beispiel-Projekt wählen wir den Cloud-Hosting-Anbieter cloudcontrol.com – ein deutsches Unternehmen, dass ihre Cloud-Hosting-Plattform intern auf Amazon Servern aufbaut. Der Vorteil für uns Entwickler: Das Hosting ist extrem einfach zu managen und in der Grundstufe sogar kostenlos. Optimal also für unsere Bedürfnisse. Kostenlos starten, aber jederzeit kostenpflichtig hochskalieren können.

Zusammenfassung der Server-Entwicklung im 2. Teil

Wir werden unseren Chat-Server in der zweiten Ausgabe unseres Tutorials also mit folgenden Anforderungen und Rahmenbedingungen praktisch umsetzen:

Webbasierter Client

Als zweite Komponente setzen wir im dritten Teil unseres Tutorials einen webbasierten Client um. Also eine Webapp, die für nahezu alle Geräte und Screens optimiert ist. Das ganze erreichen wir über ein responsive Design. Wir können unseren webbasierten Chat-Client also auf dem Desktop, Smartphone und Tablet gleichermaßen gut bedienen. Für den Realtime-Ansatz greifen wir auf Websockets zurück, mit denen wir in HTML5-fähigen Browsern eine bidirektionale Verbindung zu unserem Chat-Server aufbauen können. Netterweise liefert uns das Framework socket.io auch gleich eine passende Javascript-Client-Bibliothek mit, mit der wir den Zugriff auf unseren Chat-Server relativ einfach implementieren können. Und nebenbei bietet uns unser socket.io-Client auch gleich einen automatischen Fallback auf z.B. Flash wenn unser vollkommen veraltete Browser keine Websockets versteht.

Zusammenfassung Technologien für den Webclient im 3. Teil

  • HTML5-basierter Webclient
  • JS-Framework jQuery
  • Javascript-Client-Bibliothek von socket.io
  • Responsive Design mit Bootstrap

Wir gehen hier bewusst einen eher traditionellen Weg der webbasierten Umsetzung, um die Technologien und Konzepte dahinter besser verstehen zu können. Eine moderne Alternative zu der oben aufgeführten Umsetzung wäre mit Meteor. Ein auf node.js aufbauendes Projekt zum einfachsten Umsetzen von qualitativ hochwertigen, reaktiven Webapps. Ein hochinteressantes Projekt, dem wir uns in Zukunft sicherlich auch einmal in einem extra Blog-Artikel widmen werden.

Mobile App

Unsere mobile Komponente setzen wir als hybride App auf Basis von Titanium Mobile um. Warum als hybride App? Ganz einfach, weil wir damit für unser Testprojekt sowohl für iOS, als auch für Android relativ schnell zum Ziel kommen. Eine native Entwicklung würde den Rahmen dieses Tutorials wahrscheinlich etwas sprengen. Und da wir das ganze Tutorial mehr oder weniger neben dem normalen Tagesgeschäft verfassen, wollen wir dann doch nicht ganz so viel unserer eingeschränkten Freizeit opfern. Schließlich wollen wir ja gerade auch noch die Fussball-WM verfolgen können.

Aber zurück zu unsere hybriden App. Funktionell wird diese in etwa ähnlich wie der webbasierte Client sein, mit entsprechend angepassten “nativen” App-Ansichten. Und mit Titanium Mobile wirkt und ist der Großteil der UI-Elemente auch wirklich nativ. Um unsere mobile App dann aber doch noch ein weniger mehr ausreizen zu können, implementieren wir zusätzlich zur Realtime-Verbindung noch Local Notifications und echte Push-Notifications. Sobald unsere App z.B. im Hintergrund läuft, informieren uns Local Notifications über neuen Nachrichten. Und sollte unsere App ganz beendet sein, erhalten wir über echte Push Notifications trotzdem noch die aktuellen und neuen Meldungen auf unser Smartphone.

Zusammenfassung zur mobilen Entwicklung im 4. Teil

  • hybride Umsetzung auf Basis von Titanium Mobile
  • iOS und Android (optimiert für Smartphones)
  • Local Notifications
  • Push Notifications

Smart-TV App

Im letzten Teil unseres Tutorials setzen wir dann noch eine Smart-TV App um. Der einfachheithalber konzentrieren wir hier uns nur auf eine Plattform, genau genommen den TV-Geräten von Samsung. Auf Basis des Samsung Smart-TV SDK entwickeln wir also eine Smart-TV App, die uns ebenso in Echtzeit die aktuellen Nachrichten in großer Darstellung auf dem Fernsehgerät anzeigt. Hier konzentrieren wir uns, der Lean-Back-Nutzungsart geschuldet, auf die Darstellung der letzten Nachrichten. Verfassen von neuen Nachrichten wird über die Smart-TV App nicht möglich sein – würde über die hässlichen Fernbedienungen auch keinen Spaß machen.

Zusammenfassung der Smart-TV App-Entwicklung im 5. Teil

  • Smart-TV App auf Basis des Samsung SDK
  • Optimiert für Lean-Back-Nutzung

Ausblick

Wir hoffen, Ihnen und Euch, unsere fünfteilige Tutorial-Reihe etwas schmackhaft gemacht zu haben. Der erste Teil und die Einführung ist damit zu Ende. In den kommenden vier Teilen geht es dann an das Eingemachte. Alle Komponenten unser Multiscreen-Anwendung werden wir ausführlich und praxisnah erläutern. Den Quellcode dazu wird es jewweils auf Github zum Download geben. Der zweite Teil und damit die Server-Komponente wird noch im Juli veröffentlicht.

  • Teil 2: Server-Kompnente (geplant bis Ende Juli)
  • Teil 3: Webbasierter Client (geplant Anfang/Mitte August)
  • Teil 4: Mobile App (geplant bis Ende August/Anfang September)
  • Teil 5: Smart-TV App (geplant im September)

In diesem Sinne freuen wir uns auf ein Wiederlesen. Wenn Sie rechtzeitig zu den Veröffentlichung der kommenden Teile informiert werden wollen, folgende Sie uns doch einfach auf:

Bei sonstigen Anfragen zur App-Entwicklung, Multiscreen-Apps oder Smart-TV App-Entwicklung können Sie uns gerne kontaktieren.