Mobile Web-Apps

Mobile Web-Apps Besonderheiten mobiler Anwendungen Netzwerk Mobilgerät Internet auf mobilen Geräten Wireless Application Protokoll (WAP) Funktionsprinzip von 1.1 – 1.2 WAP 2.0 Praktische Verfahrensweisen Design mehrerer Anwendungsvarianten Bedachter Gebrauch von Ressourcen Design für verschiedene Interaktionsmethoden Anwendungsdaten Grafiken Zusammenfassung Mobile = nur bezug auf handheld devices. Nicht laptop Web-App = hat lokal ausführbaren Teil im Gegensatz zu Web-Content. Vermittelt Look and Feel einer Desktopanwendung im Browserfenster

Besonderheiten mobiler Anwendungen Netzwerk Unterschiedliche Bandbreiten und Latenzzeiten beeinträchtigen die Performance einer Webanwendung Verlässlichkeit des Netzwerkes kann die sichere Datenübertragung beeinflussen Verfügbarkeit des Netzes variiert sehr stark Standard Uplink Downlink GPRS 53,6 kbit/s EDGE 110 kbit/s 220 kbit/s HSUPA / HSDPA 1450 kbit/s 7200 kbit/s Datenübertragungsstandards HSUPA = highspeed uplink package access GPRS = general packet radio service (paketorientierte datenübertraung) EDGE = enhanced data rates for GSM evolution GSM = Mobilfunkstandard 2te Generation UMTS = Mobilfunkstandard 3te Generation

Besonderheiten mobiler Anwendungen Mobilgerät Generell viele verschiedene Geräte und Plattformen Auswahl von 5 aktuellen Plattformen Hersteller Plattform Nokia (Symbian) Symbian OS Google Android Apple iPhone OS Microsoft Windows Mobile Palm Palm webOS Nokia bietet auf Basis des Symbian OS die S60 Plattform. Das ist die eigentliche Oberfläche, die man in den Handys sieht Google relativ neu dabei mit Android, welches auf einem Linux System basiert. Problem war früher immer, das die Handys zu langsam waren, um mit Linux klar zu kommen Apple mit iPhone OS, welches ein umgebautes MAC OS X ist Microsoft mit Windows Mobile, basiert auf der bekannten Win32 Api Palm mit dem brandneuen webOS, früher Palm OS, dann aber eingestellt.

Besonderheiten mobiler Anwendungen Mobilgerät Einschränkungen die Geräte mit sich bringen kleine Displays (z.B.: 240x320) langsame CPU (z.B.: ARM 32bit RISC CPU ~370 MHz) Wenig Arbeits- und Festspeicher Batterieverbrauch beachten (häufiges lesen/schreiben auf Festspeicher, CPU intensive Berechnungen) Eingabemöglichkeiten (Tastatur, Touchscreen, Sprache)

Internet auf mobilen Geräten Aufgrund der genannten Einschränkungen, gibt es seit 1997 eine Sammlung von Techniken und Protokollen, zur Darstellung von Internetinhalten auf mobile Geräten Wireless Application Protokoll (WAP) Version 1.0 war unausgereift, keine Browsersoftware und keine WAP fähigen Endgeräte Version 1.1 übernahm XHTML Konventionen. Nicht kompatibel zu 1.0. Konnte sich durchsetzen. Jedes Mobiltelefon wurde WAP fähig. WML als Berscheibungssprache für Websites (zuvor HDML) Idee war, Lesbarkeit der Beschreibungssprache und Reduktion der zu übertragenden Daten. Widersprüchliche Anforderung Daher Kodierung des Quelltextes in eine binär Form zur Übertragung Keine direkte Kommunikation mit dem Web-Server HDML = Handheld Device Markup Language von der Firma openwave Seit WAP 1.2 gib es den Push Dienst (WAP Push). Dadurch kann ein Server content an ein Mobile Device senden, ohne dass das Device erst eine Anfrage an den Server stellt WML = Wireless Markup Language

Funktionsprinzip von WAP 1.1 – 1.2 Mobile Device binäre Anfrage an Gateway WAP-Gateway (proxy) Umwandeln in WML Quelltext http request an Server WEB-Server Empfängt request mit WML Dokument Bereitet response für Mobile Device vor Mobile Device Empfängt WMLC und stellt es dar WAP-Gateway (proxy) Codierung in binär Form (WMLC) Senden an Mobile Device WEB-Server Sendet response mit WML Dokument

Internet auf mobilen Geräten WAP 2.0 Kodierung verworfen bzw. darf umgangen werden. Somit wurde eine direkte Kommunikation mit Web-Servern möglich. Moderne Geräte können auch HTML Dokumente direkt anzeigen. Sind nicht mehr auf WML angewiesen. Hat sich kaum durchgesetzt da verhältnismäßig teuer gegenüber den gesunkenen Internetgebühren für Mobilgeräte und spärliches Angebot an Content Konkurrenz zu WAP ist i-mode. Erfolgreichster mobile Datendienst der Welt i-mode in Deutschland 2002 eingeführt und 2008 eingestellt

Internet auf mobilen Geräten WML praktisch bedeutungslos. Für die Praxis genügt Optimierung der Websites auf Mobile Device spezifische Einschränkungen W3C schlägt „best practices“ vor, um Web Content auf Mobile Devices zu bringen http://www.w3.org/TR/mwabp/ Oktober 2009 bewährte Praxis Standardverfahren Erfolgsmethode

Praktische Verfahrensweisen

Design mehrerer Anwendungsvarianten Eine Anwendung, die versucht alles abzudecken, ist zu aufwändig und kann unübersichtlich werden Sehr viele Abfragen auf diverse Geräteeigenschaften Einteilung der Zielgeräte in Klassen Klasse A XHTML Basic 1.1 CSS JPEG und GIF 89a Eingeschränkter Scriptsupport Klasse B: AJAX fähig Klasse C: spezielle API Funktionen stehen zusätzlich zur Verfügung. (z.B. Zugriff auf GPS System)

Bedachter Gebrauch von Ressourcen Wichtige Aspekte: Energieverbrauch senken, Batterielebenszeit beachten Netzwerkzugriffe und Netzwerkbelastung minimieren Datenkomprimierung HTTP 1.1 kennt gzip und DEFLATE Algorithmen. Der Browser muss dies Unterstützen. Web Server muss dafür konfiguriert werden. Z.B. für Apache WebServer in .htaccess Datei 1. Browser request GET /index.html HTTP/1.1 Accept-encoding: gzip 2. Web Server findet Datei Durchsucht Komprimierungsfilterregeln auf angefragten Dateityp oder mime-Typ (z.B. text/html) Komprimiert Datei 3. Web Server response HTTP/1.1 200 OK Content-encoding: gzip 4. Browser empfängt Dekomprimierung Anzeige

Bedachter Gebrauch von Ressourcen Datenkomprimierung Lohnt sich nur für größere Daten, die sich gut komprimieren lassen (z.B. sehr große Textdateien) Nicht zu empfehlen bei komprimierten Bildern (JPG) oder sehr kleinen Textdateien Auch Komprimierung kostet Energie. Daher sinnvoll einsetzen.

Bedachter Gebrauch von Ressourcen HTTP 1.1 Cache Möglichkeiten Nutzen Die hohe Latenz und niedrige Bandbreite des Netzes beeinträchtigt die useability von Websites Es lohnt sich, Bilder, Stylesheets und Sites zu cachen Kann auch dazu dienen, Wiederverwendung von speziell auf ein Gerät angepassete Sites, für andere Geräte zu vermeiden. Cache-Control public Daten im Cache können von anderen Zwischenstellen, vom Server zum Client, gespeichert werden. Z.B. bei Proxy Servern private Daten unterscheiden sich für jeden Client. Nur der Browser des anfragenden Clients kann die Daten für sich in den Cache legen nocache Nicht zum cachen bestimmt. Z.B. nützlich für Ergebnisse von Suchanfragen

Bedachter Gebrauch von Ressourcen Minimierung der Größe der Anwendung Bei HTML, CSS und JavaScript Kommentare und WhiteSpace entfernen. Ersetzung von Variablen und Methodennamen durch kurze Bezeichnungen Nicht von Hand erledigen. Es gibt dafür Programme. Nur für die Programmversion, die ausgeliefert werden soll.

Design für verschiedene Interaktionsmethoden Navigieren durch die Anwendung mittels selektierbaren Elementen Fokus Basiert Elemente können weit auseinander platziert sein Browserfokus springt von Link zu Link Aktuelle Position ist erkennbar durch hervorgehobenen Link Zeiger Basiert Durch Tasten lässt sich ein Zeiger beliebig auf der sichtbaren Fläche bewegen SE die logisch zusammengehören, müssen nahe zusammen sein, da Zeigerbewegung oft sehr langsam SE müssen groß genug sein, da Zeiger sich auf einem Pixelraster bewegt. Grafische Anzeige sobald Zeiger den aktivierbaren Bereich eines SE betritt bzw. verlässt.

Design für verschiedene Interaktionsmethoden Touchscreen Basiert Ereignisse treten direkt an der Stelle auf, wo der Bildschirm berührt wird Große SE (mind. 30 pixel in der Höhe) und weiter auseinander, damit Selektion bequem möglich ist. Keine Elemente sind fokussiert bevor sie ausgewählt wurden. Z.B. „rollover“ Effekt bei Links funktioniert nicht

Anwendungsdaten Anwendungen müssen oft Daten lokal und persistent Ablegen. Cookies Sparsam Verwenden, werden bei jedem Request mit gesendet Könnten abgeschaltet sein durch Einstellung am Gerät oder sogar durch das Mobilnetz Anwendung sollte auch ohne Cookies funktional bleiben

Anwendungsdaten Client-side Storage API APIs zum Abspeichern von evtl. auch größeren Datenbeständen auf dem Mobilgerät. (BONDI, HTML5, ...) Reichen von simplen key=value Modellen bis zu SQL Datenbanken Beispiel für HTML5 window.openDatabase( DB-Name, DB-Version, Anzeigename, geschätzte Größe in Bytes) transaction.executeSQL( SQL-Statement, SQL-Parameter, Resultset-Callback, Error-Callback ) window.openDatabase( DatabaseName, DatabaseVersion, DisplayName, EstimatedSize ) transaction.executeSQL( SQLStatement, SQLParameters, ResultsetCallback, ErrorCallback )

Anwendungsdaten Client-side Storage API function initDb(){ if(window.openDatabase) { db = window.openDatabase("testDb","","DB Test", 1048576); } else { alert("DB nicht unterstützt") function insertDb(key, value) { db.transaction(function(tx) { tx.executeSql("INSERT INTO TestTable VALUES(?, ?)", [ key, value ], function(tx, rs) { // … }, function(tx, error) { }); } window.openDatabase( DatabaseName, DatabaseVersion, DisplayName, EstimatedSize ) transaction.executeSQL( SQLStatement, SQLParameters, ResultsetCallback, ErrorCallback ) function selectDb() { db.transaction(function(tx) { tx.executeSql("CREATE TABLE IF NOT EXISTS TestTable(key TEXT, value TEXT)", [], function(tx, rs){}, function(tx, error){}); tx.executeSql("SELECT * FROM TestTable", [], function(tx, rs) { for(var i = 0; i < rs.rows.length; i++) { // … } }, function(tx, error) {}); });

Anwendungsdaten Client-side Storage API Cache-manifest zum expliziten lokalen Speichern von essentiellen Web-App Dateien. Somit kann der Benutzer die Web-App auch offline noch nutzen. <!-- clock.html --> <!DOCTYPE HTML> <html manifest="clock.manifest"> <head> <title>Clock</title> <script src="clock.js"></script> <link rel="stylesheet" href="clock.css"> </head> <body> <p>The time is: <output id="clock"></output></p> </body> </html> <!– clock.manifest --> CACHE MANIFEST clock.html clock.css clock.js Now, if the user goes to the page, the browser will cache the files and make them available even when the user is offline.

Grafiken JavaScript basiertes Zeichnen von Bitmaps mit <canvas>-Tag in HTML5 Schneller und Speichereffizienter als ein Bild zu laden Rendering übernimmt Browser Komplexe Formen zeichnen Fotokompositionen Animationen (auch mit Benutzerinteraktion möglich)

Grafiken Simple Formen Quellcode <html> <head> <script type="application/x-javascript"> function draw() { var canvas = document.getElementById("canvas"); if (canvas.getContext) { var ctx = canvas.getContext("2d"); ctx.fillStyle = "rgb(200,0,0)"; ctx.fillRect (10, 10, 55, 50); ctx.fillStyle = "rgba(0, 0, 200, 0.5)"; ctx.fillRect (30, 30, 55, 50); } </script> </head> <body onload="draw();"> <canvas id="canvas" width="150„ height="150"></canvas> </body> </html>

Grafiken Komplexere Formen Quellcode (Auszug) function drawShape(){ var canvas = document.getElementById('tutorial'); if (canvas.getContext){ var ctx = canvas.getContext('2d'); // Draw shapes roundedRect(ctx,12,12,150,150,15); roundedRect(ctx,19,19,150,150,9); roundedRect(ctx,53,53,49,33,10); roundedRect(ctx,53,119,49,16,6); roundedRect(ctx,135,53,49,33,10); roundedRect(ctx,135,119,25,49,10); // Character 1 ctx.beginPath(); ctx.arc(37,37,13,Math.PI/7,-Math.PI/7,false); ctx.lineTo(34,37); ctx.fill(); // blocks for(i=0;i<8;i++){ ctx.fillRect(51+i*16,35,4,4); } for(i=0;i<6;i++){ ctx.fillRect(115,51+i*16,4,4); ctx.fillRect(51+i*16,99,4,4); ….

Grafiken Benutzen von skalierbaren Vektorgrafiken (SVG) XML Sprache zum definieren von Vektorgrafiken Beliebig skalierbar und daher Auflösungsunabhängig Da XML Format, Knoten und Elemente in DOM Objekt abgelegt Kann daher per JavaScript verändert werden

Grafiken SVG Grafik Quellcode <?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd"> <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="280" height="280"> <title>dummy</title> <desc>ein SVG Smilie</desc> <defs> <style type="text/css"> <![CDATA[ text {font-family:Verdana,sans-serif; font-size:60px; font-weight:bold; fill:black; stroke:black; stroke-width:4px;} ]]> </style> <symbol id="smilie"> <desc>ein Symbol-Smilie</desc> <circle cx="20" cy="20" r="15" fill="yellow" stroke="black" /> <path d="M 13 26 A 5 3 0 0 0 27 26" stroke="black" fill="none" stroke-width="2" /> </symbol> </defs> <use xlink:href="#smilie" transform="translate(-20,-20) scale(8)" /> <text x="79" y="119">S</text> <text x="117" y="170">V</text> <text x="156" y="119">G</text> </svg> CDATA = character data. Daten in diesem Bereich werden von der xml interpretierenden Software nicht als xml Code gesehen Defs = container bereich. Nicht sichtbar in Graffik. Kann mit use Instanziiert werden

Zusammenfassung Darstellung von Web-Apps auf Mobile Devices ist einfacher geworden, da moderne Geräte die entsprechende Browsersoftware mitliefern Dennoch gilt es, für die Web-Apps und auch Websites allgemein, noch Optimierungen durchzuführen. Vor allem im Bereich Displaygröße und dynamischen Inhalten Der Problemfokus liegt nicht mehr darin, wie man den Content am schnellsten auf das Mobilgerät bringt, sondern dass eine gutes Look and Feel geschaffen wird Die Web-App sollte so erscheinen, als wäre es eine lokale Anwendung Der Aktuelle Stand der Technik bietet noch weitaus mehr. Z.B. Stichwort Widgets Widgets = kleine Web-Apps die ausserhalb eines Browsers laufen. Allerdings wird eine Widget-Engine benötigt, welche meistens auf einem Browser basiert bzw. sich dessen Funktionen zu Nutze macht

End Of Document