GWT Best Practices II

Von Frank Wisniewski, Elisabeth Blümelhuber und Christian Proinger

Im zweiten Teil der shortcut-Serie zu GWT Best Practices geht es zunächst um die Verwendung des GWT zur Implementierung von RWD, das aufgrund der zunehmenden Device-Divergenz für eine moderne und professionelle Internetpräsenz notwendig erscheint. Zudem zeigt der Autor Möglichkeiten auf, Style Sheets in GWT-Applikationen einzubinden. Es folgt ein Kapitel über Formulare im GWT, dabei werden die entsprechenden Komponenten aus Benutzersicht dargestellt sowie ihre Implementierung illustriert. Letztlich erläutert der Autor auch die Implementierungseigenheiten von GWT. Wie jede Webapplikation sind auch jene, die auf dem Google Web Toolkit (GWT) basieren, angreifbar. Im dritten Kapitel des shortcuts werden die Bedrohungen aufgezeigt und es erfolgt eine Erläuterung, wie das Google Web Toolkit den Entwickler mit seinen vorgefertigten Widgets bei der Vermeidung von XSS-Sicherheitslücken unterstützt.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 26. Feb. 2014
• ISBN: 9783868025026

Buchvorschau

GmbH

1 Anpassungs- und reaktionsfähiges Design mit dem Google Web Toolkit

Die zunehmende Device-Divergenz macht „Responsive Web Design (RWD)" nicht nur zu einem der Trends in 2013, sondern zur Notwendigkeit für eine moderne und professionelle Internetpräsenz [1]. Im Vergleich zur herkömmlichen Vorgehensweise über die neueren Webstandards wie HTML5 und CSS Media Queries bietet die Umsetzung in GWT durchaus Vorteile, die in diesem Kapitel gezeigt werden sollen.

Immer mehr und immer verschiedenartigere Geräte tummeln sich im World Wide Web. Nicht mehr nur der Desktoprechner, sondern auch Smartphones, Tablets, Spielekonsolen, Fernseher, E-Book-Reader, ja selbst Kühlschränke sind internetfähig. Was des Nutzers Herz erwärmt, stellt den armen Webdesigner vor neue Herausforderungen in puncto Interoperabilität und Nutzbarkeit seines Webangebots.

Zugegeben muss die Darstellung nicht für Kühlschränke optimiert werden. Aber sie sollte auf einem möglichst großen Anteil der übrigen Medien adäquat sein. Auch muss sich das Navigationsmenü mit der jeweils angebundenen Peripherie bedienen bzw. ansteuern lassen und der Einsatzbereich des Geräts beachtet werden. So wird eine HD-Auflösung vor einem Fernsehapparat sitzend anders wahrgenommen als vor einem Notebook.

1.1 Auf der Suche nach der eierlegenden Wollmilchsau

Zu Beginn soll eine kleine Checkliste einen groben Überblick geben, welche Kriterien für eine Webanwendung zur Emulation eines nativen Erlebnisses auf dem Wiedergabegerät herangezogen werden könnten:

Medientyp: Berücksichtigung von Typografie, Layout und Farbgebung (Braille, Sprachausgabe, TV, Bildschirm ...)

Peripherie: Optimiertes Handling für Maus, Touchpad und Gamepad; Sprachsteuerung

Ressourcen: Content mit Rücksicht auf Art der Datenverbindung generieren; Fallbacks für Browserinkompatibilitäten definieren

Einsatzgebiet und Anwendungskontext: Unterschiedliche Startseiten durch Priorisierung des Content-Typs; bspw. könnte eine Lebensmittelkette auf einem Handheld direkt auf ihr Angebot im App Store verweisen, auf einem Fernsehapparat den neuesten Werbespot zeigen und in der Desktopversion aktuelle Sonderangebote anpreisen

Geographie: Sprache und Content in Abhängigkeit der GPS-Position; bspw. könnte die Lebensmittelkette die Öffnungszeiten der nächsten Filiale anzeigen

Diese Liste zeigt nur in Ansätzen, welche Bandbreite an Punkten beachtet werden muss. Allerdings können schwerlich alle aufgeführten Punkte Berücksichtigung finden, denn ihnen stehen sowohl der Mehraufwand als auch besondere Problemstellungen in der technischen Umsetzung gegenüber. Dennoch differenziert bspw. Google innerhalb einer Device-Kategorie: An iPhone, BlackBerry Curve und Nokia 6300 werden jeweils unterschiedliche HTML-Dokumente gesendet [2].

Bekanntlich besitzt Google enorme Ressourcen. Doch wird hier sicherlich nicht für jede Kombination aus den obigen Anforderungen eine dedizierte Benutzerschnittstelle implementiert. Vielmehr greift eine