Web-Applikationen für unterschiedliche Geräte mit GWT

Oliver Schmid hat als Doktorarbeit das Google Web Toolkit (GWT) erweitert, um die Entwicklung von verteilten Web-Applikationen zur Förderung kollaborativer Tätigkeit zu erleichtern.

Die Vielfalt der Geräte für die Nutzung des Internets hat in den letzten Jahren markant zugenommen. Dabei zeigt sich, dass die Portierung der auf herkömmliche Computer optimierte Inhalte durch die unterschiedliche Grösse und Bedienung der neuen mobilen Endgeräte keineswegs trivial ist. Sie muss explizit behandelt werden, um die Herausforderungen zu meistern und die neuen Möglichkeiten nutzen zu können.

Nützliche Features von GWT

Bereits in früheren Blogs (GWT 2.0, Des GWT neuen Kleider) habe ich auf die nützlichen Features von GWT für die moderne Entwicklung von Rich Internet Applications (RIAs) hingewiesen. Eines der Grundkonzepte von GWT besteht in der Idee, eine Web-Applikation in einer Meta-Sprache (Java) zu entwickeln und diese zur Kompilierzeit an die Eigenheiten der verschiedenen Web-Browser anzupassen, indem für jede Konfiguration ein separates JavaScript-File generiert wird.

Die verschiedenen JavaScript-Versionen sind auf die Ausführungslogik der jeweiligen JavaScript-Engine angepasst und werden je nach aufrufendem Web-Browser heruntergeladen und ausgeführt. Dies verbessert nicht nur die Lesbarkeit des zu wartenden Codes, sondern bietet auch ein ideales Mittel zur Entwicklung von Web-Applikationen, welche auf die Eigenheiten der jeweiligen Geräte eingehen können. Das sogenannte “Deferred Binding” erlaubt nämlich, nicht nur zwischen Browsern zu unterscheiden, sondern bietet zudem die Möglichkeit jegliche Informationen, welche durch JavaScript zugänglich sind, zu einer Unterscheidung von Teil-Implementationen zu nutzen. So können spezielle Benutzerschnittstellen für berührungsempfindliche Geräte erstellt werden, während die grundlegende Logik aus der gleichen Code-Basis für Mauszeiger-basierende Geräte wiederverwendbar bleibt.

GWT-Erweiterung im Rahmen einer Doktorarbeit

TWICE: Verteilte Web-Applikationen für kollaborative Tätigkeiten leichter entwickeln

Im Rahmen meiner Doktorarbeit an der Universität Fribourg entwickelte ich eine Erweiterung des Google Web Toolkits, welches die Entwicklung von verteilten Web-Applikationen zur Förderung kollaborativer Tätigkeit erleichtern soll. Das “Toolkit for Web-based Interactive Collaborative Environments” (TWICE) zeigt beispielhaft, wie Web-Technologien dazu genutzt werden können, verteilte, computer-unterstützte kollaborative Systeme zu entwickeln, welche installations- und konfigurationsfrei auf persönlichen End-Geräten der Benutzer ausgeführt werden können. Neben der Integration von bi-direktionalen Kommunikationskanälen und der zur Verfügungstellung von verteilten Event-Handling Mechanismen stellt das Toolkit einen Rahmen zur Entwicklung von verschiedenen Komponenten (Modulen) dar, welche zu komplexen kollaborativen Applikationen kombiniert werden können. Diese (meist grafischen) Komponenten können dann zwischen den in einer kollaborativen Sitzung involvierten Geräte in Form einer verteilten Benutzerschnittstelle (“Distributed User Interface”) ausgetauscht werden und erlauben so den Aufbau von Mehr-Geräte und Mehr-Benutzer-Systemen zum Austausch von Informationen und der gemeinsamen Erarbeitung und Manipulation von Inhalten (z.B. Brain-Storming, kollaboratives Web-Browsing, etc.). Da diese Komponenten auf nicht vorherbestimmten, persönlichen und somit sehr unterschiedlichen Geräten ausgeführt werden (Smart Phones, Tablets, Notebooks, Game-Konsolen), jedoch auf allen Geräten die gleiche Grundfunktionalität bieten sollen, hat sich die oben beschriebene “Deferred Binding”-Technologie für die Umsetzung als sehr nützlich erwiesen.

Ein Beispiel: Mauszeiger auf einem entfernten Gerät steuern

Ein Beispiel dafür ist eine Komponente, welche es erlaubt, einen Mauszeiger auf einem entfernten Gerät zu steuern: Die gleich bleibende Grundfunktionalität dieser Komponente ist das Versenden von X- und Y-Koordinaten, welche dem entfernten Gerät sagen, wohin sich der Mauszeiger bewegen soll. Die Herleitung dieser Werte unterscheidet sich allerdings deutlich zwischen einem zeiger-orientierten und einem berührungsempfindlichen Gerät: Während sich bei einem zeiger-orientierten Gerät die Position des lokalen Zeigers direkt auf den entfernten Rechner übertragen lässt, soll ein berührungsempfindliches Gerät in der Form eines “TouchPads”, wie es bei Notebooks üblich ist, funktionieren und den entfernten Zeiger über Fingerbewegungen auf dem Touch-Screen steuern. Mit Hilfe des “Deferred Bindings” können nun die Unterschiede zwischen den beiden Gerätetypen separat implementiert werden, wobei die Grundfunktionalität (das Versenden der Koordinaten) wiederverwendet werden kann. Wird in der Komponente nun noch eine Unterscheidungslogik zwischen berührungsempfindlichen und zeiger-orientierten Geräten definiert, wechselt das System die Implementierung bei der Übertragung der Komponente vom Gerät des einen auf ein Gerät des anderen Typs automatisch und verhindert zudem den Download und somit die unnötige Belegung von Bandbreite und Ressourcen durch gerätespezifischen Code, welche dieses Gerät nicht betrifft.

Weitere Möglichkeiten

Neben solchen funktionalen Unterscheidungen lassen sich durch diesen Mechanismus selbstverständlich auch alternatives Layouting (zur Optimierung der Benutzerschnittstelle), Anpassungen des Umfangs von Abfragen von Servern (zur Performanzoptimierung) und die Restriktion von Funktionalitäten (zur Reduktion der Programmgrösse) realisieren, was das “Deferred Binding” zu einem idealen Hilfsmittel für die Implementierung von jeglichen Applikationen macht, welche auf die Eigenheiten und Kapazitäten verschiedener Gerätetypen eingehen sollen (z.B. zusätzliche Versionen für mobile Geräte zur Verfügung stellen sollen).

Fazit

Im Rahmen der Evaluation des entwickelten Toolkits TWICE konnte einerseits durch das Testing auf einer Vielzahl an Geräten belegt werden, dass der Mechanismus zuverlässig zwischen verschiedenen Gerätetypen unterscheiden kann und andererseits im Rahmen von Befragungen von Entwicklern, welche mit dem Toolkit gearbeitet haben, gezeigt werden, dass die punktuelle Ausimplementierung von Alternativlogik für Gerätetyp-spezifische Eigenheiten sowohl komfortabel als auch effizient ist.

Kommentare sind geschlossen.