Datenverarbeitung innerhalb von Webapps mit WebStorage

Vortrag im Seminar "Re-usable Content in 3D und Simulationssystemen".

Transcript

1. Universität zu Köln Historisch-Kulturwissenschaftliche Informationsverarbeitung Re-usable Content in 3D und Simulationssystemen, SS 2013 Dozent: Prof. Dr. Manfred Thaller Datenverarbeitung innerhalb von Webapps Am Beispiel von Web Storage Stefan Grund, 27.06.2013
2. Datenverarbeitung in nativen Applikationen Persistente, lokale Speicherung von Daten war lange Zeit einer der Hauptvorteile von nativen Applikationen gegenüber Webapps: → Betriebssysteme stellen Möglichkeiten zur Speicherung bereit → Daten können in Dateien in verschiedensten Formaten ausgelagert werden; eigene Formate können angelegt werden → Speicherlimit ist prinzipiell unbegrenzt Datenverarbeitung in Webapps Lokales Speichern lange Zeit nur in Form von Cookies. Probleme: → maximale Speichergröße von 4 KB pro Domain → werden bei jedem HTTP-Request übertragen und können die Webapp verlangsamen (Mobile!)
3. Warum sollten Webapps lokalen Speicher nutzen? - Speicherung von Nutzereinstellungen (keine Anmeldung nötig) - geringerer Traffic - Daten können gecached werden → schnellerer Zugriff auf diese, da sie nicht immer wieder geladen werden müssen (= u.a. schnellerer Start der Webapp) - Zustand der Web-Applikation kann wiederhergestellt werden nachdem der Nutzer seinen Browser geschlossen hat → „That’s how ‘real’ applications work and this is how the web ones should, too.“ (http://24ways.org/2010/html5-local-storage/) - Verhinderung von Datenverlust bei Disconnects
4. Geschichte der Local Storage-Lösungen Cookies: Speicherlimit von 4 KB* (= nur 20 Key/Value-Paare); werden bei jedem HTTP-Request übertragen; schlechter Ruf 1999: DHTML userData: Speicherlimit von 64 KB* (bei vertrauens- würdigen Seiten 640 KB*); Internet Explorer-spezifische Methode 2002: Flash Local Shared Objects („Flash Cookies“): Speichert 100 KB*; ermöglicht per Nachfrage an den Nutzer Vergrößerung des Speicherlimits; Zugriff per JavaScript; Weiterentwicklung als dojox.storage, Teil des Dojo Toolkits (http://dojotoolkit.org/) 2007: Google Gears: Open-Source Browser-Plugin, das den Browser um eine proprietäre, auf SQLite basierte Speicher- möglichkeit erweitert; 2010 zugunsten von HTML5 eingestellt * pro Domain
5. Geschichte der Local Storage-Lösungen Problem: - bei den genannten Storage-Lösungen handelt es sich um Drittanbieter-Plugins (Flash, Google Gears) oder ungeeignete (Cookies) und Browser-spezifische (userData) Lösungen - keine Browser-übergreifende, standardisierte Storage-Lösung Lösung: - HTML5 stellt verschiedene standardisierte APIs zur lokalen Datenverarbeitung bereit → Web Storage, WebSQL, IndexedDB - diese werden von den meisten modernen Browsern unterstützt
6. Kompatibilität der HTML5-APIs bei Mobile Devices → http://mobilehtml5.org/
7. Web Storage (auch HTML5 Storage, Local Storage, DOM Storage oder Client-side Storage genannt) - ermöglicht das lokale Speichern von Key/Value-Paaren - Speicherlimit hängt vom Browser ab, meist 5 MB pro Domain (laut Spezifikation soll die Möglichkeit gegeben werden, das Speicherlimit bei Bedarf zu erhöhen → bisher kaum unterstützt) - bietet zwei unterschiedliche Speichermodelle an: → Session Storage: speichert Daten für die Dauer der Session; Datenzugriff nur für das Fenster/Tab, in dem sie erstellt wurden → Local Storage: speichert die Daten lokal beim Nutzer; Datenzugriff für alle Fenster/Tabs (desselben Browsers), die die Webapp ausführen - beide Arten von Speicher arbeiten mit derselben Schnittstelle
8. Web Storage - Persistenz: → bei Session Storage bis zum Ende der Session → bei Local Storage bis der Nutzer die Website-Daten entfernt
9. Web Storage - die gespeicherten Nutzerdaten werden nicht mehr wie Cookies mit jedem HTTP-Request auf den Server übertragen zu den Key/Value-Paaren: - der Key ist ein String - die Values können beliebige Datentypen (String, Integer, Float, Boolean) sein und werden ebenfalls als String gespeichert → gespeicherte Zahlen müssen somit wieder mit parseInt() oder parseFloat() in die Welt der Zahlen zurück geholt werden - Zugriff per JavaScript
10. Exkurs: CRUD Schema, das die elementaren Operationen der Datenverarbeitung beschreibt: CREATE = Erzeugen neuer Datensätze READ = sämtliche Leseoperationen UPDATE = Modifizieren bestehender Datensätze DELETE = Löschen von Datensätzen CRUD SQL HTTP (REST) CREATE INSERT PUT / POST READ SELECT GET UPDATE UPDATE PUT / PATCH DELETE DELETE DELETE CRUD-Verben in verschiedenen Umgebungen
11. Wie speichert man Daten mit Web Storage? - setItem erzeugt einen neuen Eintrag oder überschreibt den Eintrag ohne Warnung, wenn der key schon existiert - getItem gibt null zurück, wenn der key nicht existiert - localStorage.clear() löscht den kompletten Datensatz - localStorage.remainingSpace() gibt den noch verfügbaren Speicherplatz für das Storage-Objekt an Create localStorage.setItem(key, value); Read localStorage.getItem(key); Update localStorage.setItem(key, value); Delete localStorage.removeItem(key);
12. Wie speichert man Daten mit Web Storage? - das localStorage-Objekt kann auch als assoziatives Array verwendet werden → localStorage["foo"]; statt localStorage.getItem("foo"); - localStorage.length() gibt die Anzahl der gespeicherten Werte an (analog hierzu kann jeweils sessionStorage verwendet werden) - Veränderungen an den gespeicherten Daten können per StorageEvent ermittelt werden - in der Praxis werden oft mehrere Werte per JSON.stringify() in ein Value-Feld gespeichert und per JSON.parse() ausgelesen
13. Beispiel einer Webapp, die Web Storage verwendet - Forecast.io, Wettervorhersage für Mobile und Desktop
14. Beispiel einer Webapp, die Web Storage verwendet - über die Entwickler-Tools der Browser können die per Local Storage bzw. Session Storage gespeicherten Daten eingesehen und editiert werden - auch Web SQL, IndexedDB, Cookies und Application Cache einsehbar
15. Ist eine Verwendung von Web Storage im Rahmen der Lehrveranstaltung zu empfehlen? - Für die „Mobile Devices“-Gruppen, die eine Webapp umsetzen, ist der Einsatz, sobald Daten persistent gespeichert werden sollen, definitiv empfehlenswert! - gespeichert werden könnten z.B. → die Position des Avatars → das eigentliche Labyrinth, sofern als String abbildbar → der aktuelle (Speicher-)Stand des „Spiels“, um zu diesem zurückzukehren falls der Browser bspw. wegen eines Anrufs verlassen werden musste
16. Quellen - Developer's Guide - Client-side Storage (Web Storage). In: Google Developers, Oktober 2012, URL: https://developers.google.com/web-toolkit/doc/latest/ DevGuideHtml5Storage - Christian Heilmann: Wrapping Things Nicely with HTML5 Local Storage. In: 24 Ways; Dezember 2010; URL: http://24ways.org/2010/html5-local-storage/ - Michael Galpin: Creating mobile Web applications with HTML 5, Part 2: Unlock local storage for mobile Web applications with HTML 5. In: IBM Developer Works, Mai 2010, URL: http://www.ibm.com/developerworks/xml/library/x-html5mobile2/ - Mark Pilgrim: The Past, Present & Future of Local Storage for Web Applications. In: Dive Into HTML5, Februar 2011, URL: http://diveintohtml5.info/storage.html - Eric Redmond, Jim R. Wilson: Sieben Wochen, sieben Datenbanken. Moderne Datenbanken und die NoSQL-Bewegung. Köln 2012. - Web Storage-Spezifikation des W3C, URL: http://www.w3.org/TR/webstorage/ (alle Webseiten wurden am 26.06.2013 auf Erreichbarkeit hin überprüft)