EnterpriseTales

Just another Client: Mobile HTML

Lars Röwekamp und Matthias Weßendorf

Was hat ein „Ausflug“ in die mobile Welt in einer Enterprise-Kolumne zu suchen? Ganz einfach: Mehr und mehr Unternehmen entdecken in den letzten Monaten für ihre klassischen Enterprise-Webanwendungen Smartphones und Tablets – und somit auch das Mobile Web – als zusätzlichen Channel. Dabei vernachlässigen sie häufig, dass der Benutzer auch von mobilen Webanwendungen eine optimale Ausrichtung an sein Gerät erwartet. Die Displays von modernen Handys und Tablet-PCs sind bekanntermaßen deutlich kleiner als die von gewöhnlichen Notebooks oder Desktop-PCs. Daher ist es wichtig auf diese Unterschiede beim Entwurf einer mobilen Anwendung bewusst einzugehen. Dabei kommt es nicht nur auf technische Details, wie die korrekte Anzeige von Schriften und Grafiken auf den kleinen Bildschirmen, an, sondern vor allem auch darauf, dass die Webseite übersichtlich und zielgerichtet für das mobile Device designt wird. Eine überladene Website ist zwar nicht nur auf einem Smartphone nervig – dort wird sie aber nahezu unbrauchbar.

Mobile First – Mobile Only

Unter [1] und in [2] führt Luke Wroblewski wichtige Gründe auf, warum bei der Planung einer neuen Webanwendung das „mobile Frontend“ sogar im Vordergrund stehen sollte. Neben dem Mobile First-Ansatz gibt es im Silicon Valley auch einige Firmen, die ihre Anwendungen nach dem Mobile Only-Prinzip erstellen [3]. Neben dem naheliegenden Problem der deutlich kleineren Displays gibt es aber auch noch eine Reihe anderer Dinge, die in einer guten mobilen Anwendung beachtet werden sollten, wie beispielsweise die jeweils aktuelle Empfangsstärke oder der Status der Batterie. Während derartige Aspekte für Native-Mobile-Entwickler (z. B. iOS oder Android) mittlerweile eine Selbstverständlichkeit sind, tun sich Webentwickler an dieser Stelle erfahrungsgemäß eher schwer. Dabei bieten HTML5 & Friends bzw. das W3C alles was man braucht. Das Abfragen der aktuellen Empfangsstärke des mobilen Devices kann mit dem Network Information API [4] erfolgen:

...
var myConnection = navigator.connection.type;

switch(myConnection) {
  case "2g":
    // handle 2g
  break;
  case "none":
    // handle none
  break;
  case "unknown":
    // handle unknown connection type
  break;
.... 

Das connection API ist sehr einfach und enthält derzeit nur das type-Attribut, das die aktuelle Verbindungsstärke als String zurückliefert:

  • unknown
  • ethernet
  • wifi
  • 2g
  • 3g
  • 4g
  • none

Die Webanwendung kann so entsprechend auf Verbindungsschwankungen reagieren – ein MUST für eine gute User Experience.

Sichtbar oder etwa nicht?

In eine ähnliche Richtung geht die Intention des Page Visibility API [5]: Hier kann der Entwickler gezielt auf das „Browsing-Verhalten“ des Nutzer reagieren und so Ressourcen sparen. Man könnte zum Beispiel das Abspielen eines Videos unterbrechen, sobald es für den Web-Surfer nicht mehr sichtbar ist. Kehrt der Nutzer zu dem Fenster (oder dem Tab) zurück, kann das Video dann weiter abgespielt werden (Listing 1).

Listing 1
document.addEventListener("visibilitychange", function(event) {
   // Seite sichtbar?
   if (document.hidden) {
     // 
   }

   //Abfragen des genauen 'visibilityState':
   var myVisibility = document.visibilityState;
   ...

}, false); 

Wie Listing 1 zeigt, wird auf das visibilitychange-Event über eine anonyme JavaScript-Funktion zugegriffen. Dieser Callback wird automatisch durch den Browser aufgerufen, sobald sich der „Sichtbarkeitszustand“ der Webseite verändert. Das boolsche hidden-Feld gibt dabei an, ob eine Seite sichtbar ist oder nicht. Den exakten Wert (hidden, visible oder preview) kann der Entwickler aus dem visibilityState-Feld lesen. Neben dem Pausieren eines Videos bietet dieses API noch weitere nützliche Anwendungsfälle. Ein webbasierter Instantmessaging-Client könnte so beispielsweise zwischen idle und active entscheiden solange die Seite nicht sichtbar ist, eine aktive WebSocket-Verbindung auf das Aktualisieren der Daten verzichten:

myWebSocketConnection.onmessage = function(event) { 

  if (! document.hidden) {
     var payload = event.data;
     ...
  }
}; 

Alternativ kann im obigen Beispiel die Verbindung auch vollständig beendet und bei der Rückkehr durch ein neues Connect wieder hergestellt werden.

Geschrieben von
Lars Röwekamp und Matthias Weßendorf
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.