Responsive Web Design als Notwendigkeit für professionelle Internetpräsenzen

Google Web Toolkit – so realisiert man anpassungs- und reaktionsfähiges Design
Kommentare

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. 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 Artikel 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.

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.

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 serverseitige Systematik, die automatisiert Anpassungen vornimmt.

Kategorisierung und Adaption durch Server
Vor nicht allzu langer Zeit waren die mobilen Browser nicht fähig, eine vollwertige Anzeige von Webinhalten zu gewährleisten. Daher mussten die Inhalte separat in einem eigenen Format ausgegeben werden: der „Wireless Markup Language (WML)“. Davon ausgehend können Informationen auch heutzutage über eine spezielle Domainerweiterung entweder als Subdomain wie bspw. http://m.spiegel.de oder eigene TLD wie bspw. http://www.kicker.mobi explizit in einer für mobile Geräte optimierten Darstellung abgerufen werden. Dieser Ansatz erfordert allerdings vom Nutzer Kenntnis über die korrespondierende Adresse und macht das Weitergeben und Teilen von URLs über verschiedene Medientypen hinweg unbequem, da sie sich unterscheiden. Schon beim automatisierten Weiterleiten auf das passende Angebot ist eine serverseitige Identifizierung und Klassifizierung des Client-Devices notwendig. Erst mit dieser Information kann die eigentliche Auslieferung „mundgerechter“ Webseiten stattfinden.

User-Agent-Detection
Zur Bestimmung des Clients wird beim Browser-Sniffing der HTTP-Header des Requests analysiert und ausgewertet. Hauptsächlich wird das Feld „User-Agent“ zum Abgleich mit einem „Device Description Repository“ verwendet. Diese Technik wird nicht erst seit dem Bekanntwerden des RWD eingesetzt, sodass bereits eine Vielzahl an Bibliotheken bereitsteht, die diese Aufgabe bewältigen. In diesem Artikel wird eine leicht abgewandelte Version von Brett Jankords Categorizr (Achtung: Categorizr wird nicht mehr aktiv weiterentwickelt!) verwendet, einem kleinen PHP-Skript mit Portierungen u. a. für Java und JavaScript. Eine beispielhafte Kategorisierung ist in Tabelle 1 zu sehen, wobei auch gleich auffällt, dass die Identifizierung eines Geräts anhand der HTTP-Header im Falle des Samsung-Fernsehers nicht korrekt ist: Das Skript sucht zwar nach dem String SmartTV, das Gerät meldet sich aber als SMART-TV. Es ist offensichtlich, dass die zugrunde liegende Datenbank nicht wartungsfrei ist und ein Updateservice entweder durch Einkauf von entsprechenden Dienstleistungen oder durch eigenständige Wartung Kosten verursacht.
 
Device Browser  Categorizr Media Queries Auflösung, DPR
Sony PlayStation 3 Mozilla tv screen 1 920 x 1 080, 1
Microsoft Xbox 360 IE 9 (Windows) tv screen 1 167 x 656, 0
Sony Bravia KDL-40EX525 Opera 11 (Linux) tv screen 1 920 x 1 080, 1
Samsung UE40ES6300 Safari 5 (Linux) desktop screen 1 280 x 720, 1
Google Nexus 7 Chrome 27 (Linux) tablet screen 962 x 553, 1,33
Google Nexus 4 Chrome 27 (Linux) mobile screen 592 x 384, 2
BlackBerry Torch 9800 Mozilla mobile screen 360 x 480, 1
Samsung Galaxy Note II Chrome 27 (Linux) mobile screen 640 x 360, 2
Sony PlayStation Vita Mozilla mobile screen 960 x 544, 1
iPod touch (4. Generation) Safari 6 (iPhone/iPod) mobile screen 320 x 480, 2

Tabelle 1: Vergleich zwischen User-Agent-Detection und Media Queries für einige Medientypen

Einordnung der Kandidaten Server und Client

Da bei einer Webanwendung von Natur aus zwei Akteure involviert sind, ist der Browser ebenso ein Kandidat zur Realisierung der Adaptionslogik. Diese Variante ist im Allgemeinen gemeint, wenn der Terminus „Responsive Webdesign“ fällt (Kasten: „Responsive Webdesign“). Die dritte Möglichkeit stellt eine hybride Lösung dar, die versucht, die Vorteile der Einzellösungen zu kombinieren, indem sie die entsprechende Anwendungsintelligenz zwischen Server und Client aufteilt.
Luke Wrobleweski gruppiert anpassungsfähige Webseiten in ebendiese drei Kategorien und nennt Entscheidungskriterien, während Ronan Cremin in einem Blogeintrag eine feinere Einteilung in fünf Kategorien vornimmt:

• Responsive Design
• Mobile-first Responsive Design
• Progressive Enhancement
• Server-side Adaptation
• Hybrid

Die ersten vier Techniken werden in den beiden nebenstehenden Kästen insbesondere im Hinblick auf die im Folgenden übernommenen Technologien kurz vorgestellt. Zur intensiveren Auseinandersetzung mit diesen Themen sind an selber Stelle Verweise auf weiterführende Informationsquellen zu finden. In den nächsten Abschnitten wird untersucht, inwiefern sich durch eine hybride Lösung positive Synergieeffekte erzielen lassen und warum sich das GWT aufgrund seiner Architektur hierfür besonders eignet.

Responsive Webdesign
Der Begriff „Responsive Webdesign“ wird geprägt von einem Artikel und Buch Ethan Marcottes mit dem jeweils gleichnamigen Titel, [13]. Grundlegend für seinen Ansatz sind drei zentrale Zutaten: ein flexibles, Grid-basiertes Layout, flexible Bilder und Medien und CSS3-Media-Queries (S. 9). Jedem dieser Punkte widmet er in seinem Buch ein Kapitel. Eine detaillierte Einführung in deutscher Sprache bietet Christoph Zillgens.
 
Media Queries
Mit Media Queries können über CSS bestimmte Eigenschaften des Browsers und Client-Geräts wie Medientyp, Dimension des Bildschirms und Farbtiefe ausgelesen werden und anhand dieser Werte spezialisierte Style Sheets gesetzt werden. Tabelle 1 zeigt allerdings beispielhaft, dass als Medientyp immer ’screen‘ zurückgegeben wird, obwohl für Fernseher und Handheld eigene Kategorien zur Verfügung stehen. Deswegen definieren reaktionsfähige CSS-Frameworks Breakpoints zur Klassifizierung der Device-Typen in Abhängigkeit von minimaler bzw. maximaler Bildschirmgröße und/oder -breite.
 
Flexibilität und Breakpoints
An diesen Breakpoints können strukturelle Umbrüche im Layout implementiert werden: Auch wenn mit relativen Größenangaben gearbeitet wird, ist das Browserfenster ab einer gewissen Breite für eine horizontale Darstellung von Inhalten nicht mehr angemessen und ein vertikales Grid kann das Rendering übernehmen. Ein gutes Beispiel ist das derzeit populärste GitHub-Projekt „Twitter Bootstrap“. Es lohnt, sich mit dem Showcase ein wenig zu beschäftigen, um ein Gefühl für die Möglichkeiten des RWD zu bekommen. RWD ist ein breites Feld, in dem noch einiges in Bewegung ist. Brett Jankord gibt einen guten Einstieg in die Diskussion und thematisiert den hybriden Einsatz, den dieser Artikel aus GWT-Sicht beleuchtet. Einige Weiterentwicklungen des klassischen Ansatzes werden im Folgenden vorgestellt:
 
Mobile First und Conditional Loading
Der Gedanke hinter „Mobile First“ ist, wie der Name schon sagt, nicht, die Desktopversion einer Webseite an kleinere Bildschirme anzupassen, sondern im Entwicklungsprozess mit eben diesen Geräten zu beginnen und das Design sukzessive anzureichern. So wird in der klassischen Variante ein hochauflösendes Bild auf dem Client nötigenfalls herunterskaliert, während Mobile First Bilder in unterschiedlichen Dateigrößen ausliefert. Luke Wroblenski hat diesen Ansatz schon 2009 in seinem Blog vorgestellt und geht in seinem Buch auch kurz auf das Zusammenspiel mit RWD ein: „With responsive web design, you can set a baseline (mobile) experience first, then progressively enhance or adapt your layout as device capabilities change“ (S. 113).
 
Progressive Enhancement
Während sich vorhergehende Konzepte eher mit der Darstellung der Inhalte beschäftigen, adressiert „Progressive Enhancement“ das Problem der Interoperabilität im Hinblick auf Funktionalität. Über JavaScript-Frameworks wie bspw. Modernizr werden die vom Browser unterstützten Features ermittelt und gegebenenfalls über Polyfills emuliert. Dem Benutzer wird dann ein an die Fähigkeiten des Browsers angepasstes „Erlebnis“ präsentiert.

Aufmacherbild: Tablet pc on digital background von Shutterstock / Urheberrecht: rvlsoft

[ header = Seite 2: Anwendungsbeispiel ]

Anwendungsbeispiel

Als Prototyp soll eine einfache Webseite dienen, die in mehrere Abschnitte unterteilt ist. Jeder Abschnitt hat eine Überschrift und eine Grafik als optischen Leseanreiz. Dieser Inhalt wird in ein Container-Element verpackt, sodass dieses Fragment auch in andere Kontexte und Anwendungen eingebunden werden kann:

<div class="container">
  <div class="section">
    <div><i class="icon-home"></i>Willkommen...</div>
    <div class="content">Lorem ipsum dolor sit amet, consectetur...</div>
  </div>
  <div class="section">
  ...
  </div>
</div>

In Abbildung 1 ist zu sehen, wie diese Ausgangswebseite im Browser dargestellt wird. Die verwendeten Icons stammen aus der CSS-Bibliothek „Font Awesome“ und bieten in Hinblick auf RWD den Vorteil, dass sie skalierbare Vektorgrafiken sind. Sie werden im Quellcode mit einem <i>-Tag eingebunden und über dessen class-Attribut ausgewählt.

Abb. 1: Das Anwendungsbeispiel in natura

Das Webseitenfragment verfügt über mehrere Abschnitte, die jeweils eine gewisse Menge an Text enthalten. Die Darstellung soll je nach Medientyp gemäß dem Prinzip des Progressive Enhancement angereichert werden. Dazu sollen die Überschriften farbig hinterlegt und in den Versionen für Handheld, Tablet und TV der Inhalt der Abschnittselemente vorerst verborgen werden. Letzteres soll über Anklicken bzw. Antippen der korrespondierenden Überschrift wieder sichtbar gemacht werden können.

Vorüberlegungen und Umsetzung

Auf alle genannten Kriterien kann in diesem Artikel nicht eingegangen werden, aber es wird im Folgenden das nötige Handwerkszeug vorgestellt, um die übrigen Konstellationen ebenfalls abzudecken. Dazu werden die Darstellungen für Tablet, TV und Handheld sowie für Desktop und Fallback-Lösung zusammengefasst. Die erste Kategorie soll sich am Kacheldesign von Windows 8 orientieren, wobei jeweils in Bezug auf Bildschirmgröße und -entfernung Anpassungen vorgenommen werden. Die zweite Gerätegruppe wurde nicht gemäß dem Mobile-First-Prinzip gewählt, da für Desktop und Fallback eine herkömmliche RWD-Lösung angedacht ist (inkl. eben genanntem Vorgehen).

Abb. 2: Skizze zur geräteabhängigen Anordnung der einzelnen Textabschnitte

Die verschiedenartigen Anordnungsformen für die einzelnen Elemente sind in Abbildung 2 grob skizziert. Es wird für die Kategorien TV und Tablet vereinfachend ein Seitenverhältnis von 16:8 bzw. 2:1 an Stelle des gängigen 16:9-Formats zur Berechnung der Kachelgröße und -position angewandt.
Da in GWT sowohl die Programmierung der clientseitigen als auch der serverseitigen Logik in Java erfolgt, kann durch Vererbung und Shared-Objekte Codedopplung weitestgehend vermieden werden. Auch lässt sich der GWT-Compiler ansteuern, was einen Eingriff in den Übersetzungsprozess des clientseitigen Codes von Java nach JavaScript ermöglicht. Diese Eigenschaft wollen wir uns zunutze machen, um neue Permutationen und bedingtes CSS für unterschiedliche Medientypen einzuführen.

Kategorisierung: Device-Informationen als Shared Object

Wie schon erwähnt, lehnt sich die exemplarische Entwicklung einer Geräteerkennung an den Java-Port des Categorizr-Skripts an. Listing 1 umreißt die statischen Methoden zur Kategorisierung des Clients anhand des User-Agent-Strings. Die entsprechende Logik ist im Shared-Package des Projekts abgelegt, damit die Klassen sowohl clientseitig als auch serverseitig kompiliert werden. Das hat den Hintergrund, dass beide Akteure Zugriff auf die Funktionalität erhalten sollen. Denn die ermittelbaren Daten bzgl. eines Clientgeräts sind vielfältiger als die einzige, im enum gespeicherte Information der Gerätekategorie, sodass die Speicherung auch auf ein umfangreicheres Category-Objekt zum Austausch zwischen den beiden Akteuren ausgedehnt werden kann.

public static enum Category {TV, TABLET, MOBILE, DESKTOP};

public static Category categorize(String userAgent) {
  // mobile first
  Category category = Category.MOBILE;

  if (match("GoogleTV|SmartTV|AppleTV|boxee|...", userAgent)) {
    category = Category.TV;
  } else if (match("Xbox|PLAYSTATION.3|Wii", userAgent)) {
    category = Category.TV;
  
  ...
  
  }
  
  return category;
}

public static String categorizeAsString(String userAgent) {
  Category category = categorize(userAgent);
  return category.name();
}

Progressive Enhancement: Mit Deferred Binding die Anwendungslogik anpassen

Durch das Deferred Binding wird es dem GWT-Compiler ermöglicht, eine spezielle Implementierung einer Klasse zu erstellen bzw. auszuwählen. Google bezeichnet dies als die Antwort von GWT auf Reflections in Java. Um diese Technik zu verwenden, muss das GWT-Objekt explizit durch das GWT.create(Class)-Literal instanziiert werden. In der Konfigurationsdatei eines Moduls kann zwischen den Modi „Ersetzen“ und „Codegenerierung“ gewählt werden (Listing 2).

<module>
...
  <define-property name="devicecategory" values="TV, TABLET, MOBILE, DESKTOP" />
  
  <replace-with class="com.pckg.client.section.SectionWidgetImplDesktop">
    <when-type-is class="com.pckg.client.section.SectionWidget" />
    <when-property-is name="devicecategory" value="DESKTOP" />
  </replace-with>
  
  <replace-with class="com.pckg.client.section.SectionWidgetImplTV">
    <when-type-is class="com.pckg.section.SectionWidget" />
    <when-property-is name="devicecategory" value="TV" />
  </replace-with>
...
</module>

In diesem Beispiel wird das UI-Objekt SectionWidget je nach Belegung der Variable devicecategory durch eine spezielle Klasse für DESKTOP oder das Pendant für TV ersetzt. Die übrigen Kategorien müssen in diesem Fall mit der Standardimplementierung Vorlieb nehmen.
Diese Variable kann analog zum Internationalisierungsmodul des GWT in der Host Page gesetzt werden. Im vorliegenden Anwendungsfall geschieht dies über das Einbinden des Rückgabewerts gemäß der statischen Categorizr-Methode in JavaServer-Page-Direktiven:

<%@ page import = "com.codekoffer.gwt.responsive.shared.Categorizr" %>
<meta name="gwt:property" content="devicecategory=<%=
           Categorizr.categorizeAsString(request.getHeader("User-Agent")) %>" />

Die spezialisierten Klassen mit der Anwendungsintelligenz zur Anordnung und zum Handling der Kacheln haben allesamt eine gemeinsame, abstrakte Oberklasse. Diese realisiert eine Methode zum Wrappen von DOM-Elementen der CSS-Klasse section, die die abstrakte Methode initImpl(Element domElement, int index, int childCount) aufruft. Hier können sich die Unterklassen einklinken, um das DOM-Element mithilfe von Informationen bzgl. der Anzahl an Siblings und des eigenen Indizes zu modifizieren. Listing 3 skizziert die Berechnung der Kachelgrößen auf einem Fernsehgerät unter Berücksichtigung des eingangs definierten Seitenverhältnisses von 2:1, und Abbildung 3 zeigt die resultierende Bildschirmrepräsentation.

public class SectionWidgetImplTV 
  extends SectionWidget implements HasClickHandlers {
  
  public SectionWidgetImplTV() {
    this.addClickHandler(new ClickHandler() {
      @Override
      public void onClick(ClickEvent event) {
        showContent();
      }
    });
  }
  public void initImpl(Element element, int index, int childCount) {
    double xQuantity = Math.ceil(Math.sqrt(childCount));
    double yQuantity = Math.ceil(childCount/xQuantity);
    double width = 100/xQuantity;
    double height = 100/yQuantity;
    getElement().setAttribute("style", "width: "  + width
                         + "%; height: " + height
                         + "%; color: #ffffff; background-color: "
                         + ColorFactory.generateDarkColorString(instanceCounter)
                         + ";");
  }
  ...
}

Der eigentliche Deferred-Binding-Aufruf geschieht in einem GWT-Wrapper für das Container-Element. Diese Panel-Unterklasse durchsucht alle Kinder-Koten und generiert für jeden section-Knoten ein SectionWidget, das mit den passenden Parametern initialisiert und dem Panel hinzugefügt wird.

Abb. 3: Darstellung der Webseite auf einem Fernsehapparat

[ header = Seite 3: Reaktionsfähiges Design mit ClientBundles ]

Reaktionsfähiges Design mit ClientBundles

Es existieren vier Möglichkeiten, Style Sheets in GWT-Applikationen einzubinden: Die beiden veralteten Wege über die Host-Seite oder das Modul-XML und die im Developer’s Guide empfohlene Umsetzung über ClientBundles und UiBinder. Letzterer bietet eine XML-Syntax zum Erstellen von UI-Elementen bzw. UI-Vorlagen, jedoch keine Sprachkonstrukte für Schleifen oder if-then-else-Anweisungen und ist daher für diesen Anwendungsfall nicht zweckdienlich. Es steht also nur noch das Konzept der ClientBundles zur Disposition, und dieses erweist sich als gute Wahl, denn es enthält die gewünschte Funktionalität, in CSS-Dateien sowohl zur Laufzeit als auch zur Compile-Zeit strukturelle Veränderungen vorzunehmen.
Diese CSS-Dateien werden über ClientBundles mit der Klasse CssResource eingebunden, indem sie über Deferred Binding instanziiert werden:

public interface AdaptiveResource extends ClientBundle {
  public static final AdaptiveResource INSTANCE = GWT.create(AdaptiveResource.class);
  
  @Source("adaptive.css")
  public CssResource css();
}
...
AdaptiveResource.INSTANCE.css().ensureInjected();

Die Methode ensureInjected() muss anschließend mindestens einmal auf dem CssResource-Objekt aufgerufen werden, damit die Style Sheets Anwendung finden. Ein weiterer Vorteil der ClientBundles ist, dass sowohl die CSS-Statements als auch die Selektoren nach Möglichkeit minifiziert werden. Um den Traffic im Hinblick auf mobile Datenverbindungen weiter zu reduzieren, sollte in der Konfigurationsdatei des Moduls das Standard-Theme entfernt werden, das mit ca. 27 kB zu Buche schlägt. Dazu muss <inherits name=’com.google.gwt.user.theme.*.*’/> auskommentiert werden.

@if devicecategory DESKTOP {
  body {}
  div {border-radius:5px; padding: 12px; spacing: 10px;}
  @external container;
  .container {width: 100%;}
  @external section;
  .section {
    ...
}
@if devicecategory TABLET TV MOBILE {
  @external container, header;
  html, body, .container, .header {
    min-height: 100%;
    height: 100%;
    margin: auto;
  }
  
  * {margin: 0; padding: 0; border: 0;	overflow: hidden;}
  *, *:after, *:before { -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; }
  
  @external section;
  .section {padding: 5%;	float: left;}

  @external content;
  .content {visibility: hidden;	padding: 0px; margin: 0px; height: 0px; width: 0px; }
}
@if devicecategory TV {
  body {font-size: 4em;}
  i {font-size:4em;}
}

In Listing 4 ist zu sehen, wie für bestimmte Gerätegruppen unterschiedliche Styles definiert werden. Die Auswertung der @if-Statements erfolgt bereits zur Compile-Zeit, die Annotation @external signalisiert dem Compiler, dass der Klassenselektor auch außerhalb des GWT-Quellcodes Anwendung findet und somit nicht minifiziert werden darf.

Abb. 4: Umsetzung des RWD auf einem Handheld

Optimierte Requests

Im Hinblick auf mobile Datenverbindungen lassen sich Widgets entwerfen, für die dedizierte „Remote Procedure Calls (RPCs)“ realisiert werden. Denkbar ist ein zweistufiges Request-System, bei dem dem Server für eine erste Anfrage lediglich die nötigsten Informationen zurückgeschickt werden und beim zweiten Mal die gleiche Antwort wie bei einem „Rich Client“ gesendet wird.
So könnte ein UI-Fragment, das einen längeren Text anzeigen soll, in der mobilen Version erst einmal einen Teaser anzeigen und bei entsprechender Userinteraktion anschließend den restlichen Text nachladen und vollständig zur Anzeige bringen.

Fazit

Auch wenn die Verwendung des GWT zur Implementierung von RWD auf den ersten Blick wie ein Arbeiten nach dem Gießkannenprinzip erscheinen mag, stellt sich bei genauerem Hinsehen heraus, dass durchaus „chirurgische Eingriffe“ in eine Webapplikation möglich sind: Durch die Technik des Deferred Binding müssen nur diejenigen UI-Fragmente und Requests angepasst werden, die auch wirklich eine gesonderte Handhabung benötigen.
Angesichts der gemeinsamen Codebasis und Vererbungshierarchien lassen sich Mehraufwand und Codereplikationen im Entwicklungsprozess weitestgehend vermeiden. Im produktiven Einsatz machen sich die Minifizierung sowohl von CSS als auch JavaScript, deren clientspezifische Generierung und Code Splitting in der Ladegeschwindigkeit bemerkbar. Außerdem ist die inhärente Unterstützung für Browser aller Art – auch rückständige Versionen wie bspw. der Internet Explorer 6 werden berücksichtigt – ein herausragendes Merkmal des GWT.
Insgesamt konnte im Rahmen dieses Artikels belegt werden, dass das GWT prinzipiell zur Adaption von Webseiten bestens gerüstet ist. Dies soll als Anreiz dienen, die vorgestellten Techniken zur Lösung eigener Problemstellungen im Bereich des RWD in Betracht zu ziehen und die gezeigten Ansätze gegebenenfalls detaillierter auszuarbeiten. Im Rückblick auf die eingangs aufgestellten Kriterien sei noch erwähnt, dass das GWT neben Touch- und Keyboard-Events auch HTML5-Features wie Geolocation etc. bietet.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -