Die Webentwicklung hat in den letzten Jahren enorme Fortschritte gemacht und CSS, die Sprache, die für das Styling von Webseiten verantwortlich ist, war dabei keine Ausnahme. CSS kann mittlerweile weit mehr als einfach nur Farben und Größen definieren. Vor allem mit der Verwendung von CSS Preprocessors können Entwickler Dinge Umsetzen, die in der Vergangenheit noch den Einsatz von JavaScript bedürft hätten.

Einheiten

Für die Definition von Größen im Web gibt es mittlerweile viele Möglichkeiten. Von fest definierten Größen wie Pixeln über prozentuelle Angaben bis hin zu Einheiten die sich auf die Größe des Screens beziehen. Gerade Letztere sind bei der Erstellung von modernen Webseiten relevant, da Inhalt so responsive gestaltet werden können. Die bekanntesten Einheiten sind hier vh – viewport height und vw – viewport width, welche sich wie die Namen sagen auf die Höhe und Breite des Viewports beziehen. Gerade bei der Höhe kann es bei mobilen Browsern jetzt aber zu Problemen kommen, da auch die Navigationsleiste oben einen gewissen Platz einnimmt und sich deren Höhe oftmals beim nach unten scrollen verändert. Wie in Abbildung 1 zu sehen wurden dafür neben dem klassischen vh auch noch die Einheiten dvh, lvh und svh eingeführt. SVH steht dabei für smallest viewport height und bezieht sich auf die Höhe ohne Navigationsleiste. Largest Viewport height (LVH) bezieht sich dagegen auf gesamte spanne des Viewports. Der Optimalfall wäre die dynamic viewport height (DVH) welche sich automatisch anpasst, was in der realen Umsetzung allerdings noch nicht immer reibungslos funktioniert.

CSS Preprocessors

Um Entwicklern bei der CSS Erstellung zusätzliche Möglichkeiten zu geben wurden sogenannte CSS Preprocessors eingeführt. Mit ihnen haben Entwickler ein Werkzeug zur Hand, das die Art und Weise, wie CSS geschrieben und verwaltet wird, grundlegend verändert. Sie ermöglichen es, CSS auf der Grundlage einer eigenen Syntax zu generieren und bieten gleichzeitig zahlreiche fortschrittliche Funktionen, die die Entwicklung und Wartung von Stylesheets erleichtern. Dabei stehen eine Vielzahl an Preprocessors zur Verfügung. Darunter zählen SASS und SCSS, Less, PostCSS und viele weitere. Im Folgenden wird dieser Artikel auf die Vorteile von SCSS eingehen, da er gemeinsam mit SASS zu einem der Beliebtesten gehört. Dabei unterscheidet sich SCSS zu SASS lediglich in der Syntax. Wie in Abbildung 2 zu sehen, gleicht der Syntax von SASS eher Python, während sich SCSS sehr am nativen CSS Syntax bedient und somit vor allem für Einsteiger attraktiv ist.
Die Abbildung zeigt zugleich den ersten großen Vorteil von SCSS – das CSS Nesting. Dabei können verschachtelte Selektoren verwendet werden. Somit müssen Selektoren nicht ständig wiederholt werden, was die Lesbarkeit und Wartbarkeit von Stylesheets erheblich verbessert.

Darüber hinaus ergänzt der Preprocessor CSS um einige Features. Es ermöglicht es Variablen zu verwenden, mit denen Werte wie Farben, Schriftarten und Abstände an einer zentralen Stelle definiert und dann im gesamten Stylesheet verwendet werden können. Das erleichtert die Konsistenz und das Design-Management erheblich. Für eine bessere Übersichtlichkeit ist es ebenfalls Möglich CSS modular abzukapseln. Logisch Abgeschlossene Teile wie das Styling für Buttons können in einem File abgelegt und anschließend importiert werden, wenn es benötigt wird. Darüber hinaus bietet SCSS Mixins und Funktionen, die es ermöglichen, wiederkehrende CSS-Regeln und Blöcke zu abstrahieren und wiederzuverwenden. Dadurch sparen Entwickler Zeit und reduzieren den Codeumfang erheblich. Somit kann beispielsweise eine Funktion geschrieben werden, welche als Parameter einen Farbwert hat. Als Ergebnis liefert sie dann immer einen Button mit der entsprechenden Farbe, was redundanten Code reduziert. Auch die Browser Kompatibilität ist ein wichtiger Aspekt, da darauf geachtet wird die Regeln möglichst so umzuwandeln, dass sie von allen gängigen Browsern richtig interpretiert werden können.

Obwohl SCSS eine leistungsstarke Ergänzung zur CSS-Entwicklung ist, muss beachtet werden, dass es vor der Verwendung in nativen CSS kompiliert werden muss. Somit können trotzdem nur die Möglichkeiten genutzt werden, welche vom Browser auch verstanden werden. Preprocessors erleichtern somit die Arbeitsweise, können aber dennoch nur mit Zutaten kochen, die bereits vorhanden sind.  

The post Modernes CSS appeared first on Mobile USTP MKL.

EINLEITUNG

Über die Jahre hat sich das Web zur wichtigsten Plattform entwickelt, um Applikationen für Nutzer:innen zugänglich zu machen [1]. Durch diese große Nachfrage mussten neue Technologien entwickelt werden, um das breite Spektrum an benötigten Funktionalitäten abdecken zu können. Hier kommen Rich Internet Applications (RIAs) ins Spiel [2]. Das Ziel dabei ist es eine app-ähnliche User Experience zu erzielen, welche schnell userspezifische Inhalte anzeigen kann. Dabei werden Teile der Webseite auf den Client verschoben um server-unabhängig agieren zu können [2]. Grundsätzlich sind Webapplikationen dabei in drei verschiedenen Schichten unterteilt. Bei traditionellen Webseiten sind sowohl Presentation Layer als auch Business Layer und Data Layer auf dem Server angesiedelt. Moderne Ansätze tendieren dazu sowohl die Präsentation als auch Teile der Business Logik auf den Client zu übertragen um auf Usereingaben ohne Serverabfragen reagieren zu können [3]. Doch wie schaut es jetzt mit dem Data Layer und weiter noch mit der Datenbank selbst aus? Kann es Sinn machen auch diese für gewisse Anwendungsfälle auf den Client auszulagern und wenn ja, welche Möglichkeiten stehen Entwickler:innen zur Verfügung, um eine clientseitige Datenspeicherung umzusetzen?

VORTEILE VON LOKALER DATENSPEICHERUNG

Bei der Frage nach clientseitiger Datenspeicherung dreht sich die Diskussion nicht darum Data Layer und Datenbank auf Serverseite zu ersetzen. Genau wie beim Business Layer wird es immer Aspekte geben, die in einer sicheren Serverumgebung besser aufgehoben sind als am Client. Ganz im Gegenteil, soll die lokale Verfügbarkeit von Daten serverseitige Datenbanken ergänzen und somit zu einer besseren Performance der Webapplikation beitragen [2]. Im Grunde ist es das Ziel dieses Ansatzes die Vergesslichkeit des Browsers zu kompensieren. Diese werden zwar immer mächtiger und leistungsfähiger aber alle Daten, welche einer Webapplikation zu Grunde liegen, müssen zunächst mittels HTTP Request von einem Server abgefragt werden. Dies führt dazu, dass bestimmte Daten bei jedem Seitenaufruf erneut abgerufen werden müssen, auch wenn sich diese in der Zwischenzeit gar nicht verändert haben. Eine lokale Instanz der Daten würde somit die Anzahl der benötigten Request reduzieren. Häufig benötigte Daten könnten so zuerst aus dem lokalen Speicher geladen und nur bei Bedarf vom Server abgefragt werden. Somit wird nicht nur der Netzwerk Traffic und die benötigte Bandbreite reduziert sondern auch die Arbeitslast des Servers verringert [4]. Zudem wirkt sich dieses Vorgehen auch positiv auf die Performance der Applikation aus, da das Abrufen von lokal verfügbaren Daten in der Regel immer schneller ist als der Zugriff auf Server Ressourcen [2]. Ein weiterer großer Vorteil liegt in der Offline-Verfügbarkeit. Gerade wenn man Webapplikationen so nahe wie möglich an native Apps heranführen möchte, müssen diese auch zu einem gewissen Grad offline nutzbar sein. So kann die Interaktion auch ohne Internetverbindung weitergeführt werden. Änderungen werden dabei zunächst lokal festgehalten und bei der nächsten Möglichkeit an den Server übermittelt. So kann die Verfügbarkeit eines Service weiterhin aufrecht gehalten werden [5].

WEBSTORAGE

Der WebStorage stellt die einfachste und bekannteste Möglichkeit dar, um Daten persistent im Browser zu hinterlegen. Er wurde mit HTML5 eingeführt um Cookies als damals alleinstehende Möglichkeit zur clientseitigen
Datenspeicherung zu ergänzen. Der große Vorteil des WebStorage liegt dabei in Speicherplatz und Datensicherheit. Anders als bei Cookies werden Daten nicht mehr mit jedem Request übertragen und können somit auch nicht so leicht ausgelesen werden. Zusätzlich bietet der WebStorage Speicherplatz für mindestens 5 MB, was die maximalen 4 KB von Cookies deutlich übersteigt [6]. Die WebStorage API setzt sich dabei aus zwei verschiedenen APIs zusammen: LocalStorage und SessionStorage. Beide speichern die Datensätze anhand von Key-Value Paaren, wobei jeweils Schlüssel als auch zugehöriger Wert in String Form angegeben werden müssen. Der Hauptanwendungsfall liegt dabei einfache Datensätze wie Access-Tokens zu speichern. Der Unterschied der beiden Schnittstellen zeigt sich in der Speicherdauer ihrer Einträge. Der Session Storage ist, wie sein Name andeutet, für Daten vorbehalten, die nur in der aktuellen Session benötigt werden. Die Einträge werden gelöscht, sobald das zugehörige Fenster geschlossen wird. Somit eignet sich diese API nicht zur persistenten Speicherung von Daten [7]. Für diese Zwecke ist der LocalStorage vorgesehen. Er hat den Vorteil, dass die Einträge auch über eine Session hinaus bestehen bleiben. Die Erreichbarkeit der Daten ist so abgekapselt, dass jede Webseite auf ihre eigene Instanz des LocalStorage zugreift. So können Daten zwar von mehreren Tabs derselben Seite, nicht aber von anderen Webseiten aufgerufen werden [6]. Ein weiterer Vorteil der API ist ihre einfache Nutzung, wobei die Getter und Setter Funktionen die wichtigsten Bestandteile darstellen. Der Funktion „localstorage.getItem()“ wird der gewünschte Key übergeben um den Entsprechenden Wert zu erhalten. Ein neuer Eintrag wird mit „localstorage.setItem()“ angelegt. Die zwei benötigten Parameter sind hierbei Key und Value [8]. Die LocalStorage API wird von allen verfügbaren Browsern unterstützt [9]. Zwar lassen sich einfache Werte leicht mit dieser Technologie speichern aber bei großen und komplexen Datenstrukturen stößt man hier schnell an seine Grenzen, da man auf String Werte limitiert ist. Um Objekte im JSON-Format abzuspeichern, müssen diese folglich vorher serialisiert und anschließend wieder rückgewandelt werden. Vor allem bei größeren Datenmengen wird der API zusätzlich auch ihre Synchronität zum Verhängnis. Da die Ausführung von anderen JavaScript Funktionen blockiert wird bis ein Lese- oder Schreibvorgang durchgeführt wurde, kann es zu Hängern in der Seite kommen. Dabei kann die API auch nicht an Web Worker übergeben werden, um das Problem zu beheben. Auch bei der Suche nach bestimmten Werten stößt man bei Key-Value Paaren an Grenzen, vor allem da Werte nur anhand des Schlüssels aus dem Storage ausgelesen werden können [7].

INDEXEDDB

Wenn einfache Key-Value Pairs nicht mehr ausreichen und komplexere Datenstrukturen am Client abgespeichert werden sollen, kommt IndexedDB ins Spiel. Dabei handelt es sich um eine auf JavaScript basierende objektorientierte Datenbank [10]. Es ist somit eine NoSQL Datenbank auf Browserebene. NoSQL ist dabei ein Überbegriff für Datenbanken, deren Datensätze nicht in relationalen Verbindungen festgehalten sind. Anders als bei SQL gibt es hier keine standardisierte Sprache zur Datenabfrage. Folglich unterscheidet sich der Syntax von Datenbank zu Datenbank. Der Fokus bei NoSQL liegt dabei auf der Verfügbarkeit und Skalierbarkeit der Systeme.
Bei IndexedDB handelt es sich zwar um einen einheitlichen Standard, die Implementierung fällt allerdings in verschiedenen Browsern unterschiedlich aus. Beispielsweise nutzt Chrome LevelDB als Grundlage für ihre Umsetzung, wogegen Firefox auf SQLite setzt. Genau wie beim WebStorage kommt auch hier die Same-origin security policy zum Einsatz. Diese schreibt fest, dass Ressourcen unterschiedlicher Webseiten nicht miteinander interagieren dürfen. Somit sind die gespeicherten Inhalte nur der Webseite zugänglich, welche sie generiert hat [2].
Die Struktur von IndexedDB wurde in Form eines Key-Value Stores umgesetzt. Wie beim WebStorage hat jeder Eintrag einen eindeutigen Key [2]. Dieser Schlüssel kann jedoch auch automatisch erzeugt werden und es besteht die Möglichkeit ihn als Teil in einen Datensatz zu inkludieren. Die Daten selbst werden in Form von Objekten gespeichert [7]. Es wird zunächst ein Objekt Speicher angelegt und an diesen ein JavaScript Objekt gebunden [2]. Hier ergibt sich der größte Vorteil gegenüber den String Values des LocalStorage. Es kann eine Vielzahl an unterschiedlichen Datentypen abgelegt werden, ohne dass diese vorher serialisiert oder umgewandelt werden müssen. Somit können auch komplexere Strukturen abgebildet werden. Ein weiterer Vorteil liegt in der Asynchronität der IndexedDB API. Bei größeren Datenmengen wird der Thread jetzt nicht mehr blockiert und die Applikation kann unbeeinflusst weiterarbeiten, während die Daten im Hintergrund abgefragt werden. Zudem können die Aufrufe jetzt auch einen Web Worker abgegeben werden. Anders als beim Webstorage, bringt IndexedDB wie eine vergleichbare Backend Datenbank Funktionen zur Abfrage von Datensätzen mit. So können diese auch gefiltert und sortiert werden [7]. Zudem unterstützt der Service ebenfalls Versionen und Transaktionen [11].
Aufgrund der umfangreicheren Möglichkeiten gestaltet sich auch die Implementierung komplizierter. Zunächst muss erst einmal eine Verbindung mit der Datenbank hergestellt werden. Dafür wird wie in Listing 1 zu sehen mit der open-Methode ein request-Objekt angefordert. Der Funktionen werden dabei Datenbankname und Version übergeben [12]. Um Datensätze speichern zu können muss zunächst ein ObjectStore instanziiert werden, welcher ebenfalls einen Namen und den Namen des Schlüsselfeldes bekommt. Im angeführten Beispiel wird der Key automatisch generiert. Anschließend werden mit „createIndex“ die weiteren Felder des Objekts hinzugefügt werden. Danach können Transaktionen genutzt werden, um auf einen ObjectStore zuzugreifen. Mit ihnen können Daten hinzugefügt, ausgelesen oder gelöscht werden [13].

<script>
const request = indexedDB.open(dbName, 3);
const objStore = db.createObjectStore("names", { autoIncrement : true });
objectStore.createIndex("name", "name", { unique: false });
</script>

Listing 1: Nutzung von IndexedDB, in Anlehnung an [13]

SQL.JS

Zwar gibt es mit IndexedDB bereits eine Möglichkeit umfangreiche Daten im Frontend zu speichern, allerdings basiert diese auf einer NoSQL Datenbank. Gerade um komplexe Abfragen durchzuführen, bedarf es hier einiges an

Vorwissen und Kreativität, um Daten teils über Umwege zu bekommen. Zudem ist SQL immer noch die vorherrschende Sprache für Datenbanken im Backend. Mit WebSQL gab es bereits den Versuch einer SQL-Datenbank für den Client. Diese scheiterte allerdings an einer einheitlichen Implementierung, woraufhin die Browserunterstützung eingestellt wurde [7]. Mit SQL.JS gibt es eine Möglichkeit, um eine relationale Datenbank im Browser auszuführen. Diese basiert dabei auf SQLite. Somit können auch die Features von SQLite wie Views und komplexe Abfragen genutzt werden. Es können auch bereits vorhandene Datenbankfiles importiert und die Datenbank als JavaScript typed array exportiert werden. Der SQLite Code wird dabei nach WebAssembly kompiliert und läuft damit fast mit nativer Geschwindigkeit. Die einzige Einschränkung, welche sich dabei ergibt ist, dass die Daten nicht persistent im Browser gespeichert werden. Es kann nur die gesamte Datenbank im Anschluss exportiert und im WebStorage oder IndexedDB abgelegt werden [7], [14].
Um dieses Problem zu beheben, wurde mit dem Projekt absurd-sql ein Interessanter Ansatz verfolgt. Dieses Package nutzt IndexedDB um ein Backend für SQL.JS zu erstellen, in welchem die Daten im Endeffekt gespeichert werden. Es wird also im Prinzip eine Datenbank in der Datenbank gespeichert. Somit erhält man die mächtigen Möglichkeiten von SQLite und kann den persistenten Storage des Browsers nutzten. Auch die Geschwindigkeit dürfte dabei nicht beeinflusst werden, denn laut Autor werden die Abfragen in der Regel sogar schneller ausgeführt als die nativen Funktionen von IndexedDB. Auch wenn diese Lösung noch keine standardisierte Technologie für größere Projekte darstellt, zeigt es welche Möglichkeiten sich für die Speicherung von Daten mittels moderner Webtechnologien ergeben [7], [15].

SPEICHERPLATZ

Neben der Frage, wo die Daten auf Clientseite am besten abgespeichert werden sollen, ist es auch relevant zu wissen wie viel Speicherplatz im Browser zur Verfügung steht. Diese Frage kann mit keinem pauschalen Wert beantwortet werden, da die Implementierung von Browser zu Browser unterschiedlich ist. Jedoch ist der Speicherplatz in den meisten Fällen vom verfügbaren Gerätespeicher abhängig. Zusätzlich wird er durch individuelle Usereinstellungen beeinflusst [16].

A. Chrome
Im Chrome Browser kann der Speicherplatz bis zu 80% des verfügbaren Gerätespeichers einnehmen. Eine einzige Webseite bekommt dabei jedoch nur bis zu 60%. Bei der Nutzung des Inkognito Modus wird der Speicherplatz jedoch drastisch eingeschränkt. Hier stehen nur mehr 5% zur Verfügung [16].

B. Firefox
Firefox erlaubt dem Browser bis zu 50% des Speicherplatzes zu beanspruchen. Jedoch wird auch hier der Platz für Inhalte einer einzelnen Domain weiter eingeschränkt. Hier wird ein Maximum von 2GB vorgegeben [16].

C. Safari
Die Kapazitätsgrenze liegt in Safari bei rund 1GB. Wenn diese Grenze erreicht wurde, kann diese vom User mittels eines Dialogs in Schritten von 200MB erhöht werden [16].
Um herauszufinden, wie viel Speicher auf lokaler Ebene noch zur Verfügung steht, kann die StorageManager API genutzt werden. Diese verfügt über eine asynchrone Estimate Funktion, welche sowohl den Wert des bereits belegten Speichers als auch den noch verfügbaren Platz zurückliefert. So kann bereits vorzeitig abgeschätzt werden, ob der benötigte Speicherplatz vorhanden ist. Die API Funktion ist für alle Browser mit der Ausnahme von Safari verfügbar [7], [17].
Wenn die maximale Speicherkapazität des Browsers einmal erreicht ist, können keine Daten mehr auf lokaler Ebenen gespeichert werden. Dies führt zu Fehlermeldungen in den einzelnen Services, welche abgefangen werden müssen [16]. Um dieses Limit gar nicht erst zu erreichen, reagieren chromium-basierte Browser und Firefox, indem sie Daten löschen. Dabei werden zunächst alle Einträge der Seite entfernt, welche schon am längsten nicht mehr aufgerufen wurde. Von dort an wird Seite für Seite abgearbeitet, bis wieder genug Speicherplatz verfügbar ist. Wenn die Webapplikation jetzt kritische Daten lokal gespeichert hat, sollte dieser Vorgang verhindert werden [18]. Dabei kann man sich den Umstand zu Nutze machen, dass der Webstorage aus zwei Teilen besteht. Auf der einen Seite steht der „Best Effort“ Bereich, dessen Inhalte entfernt werden können ohne Nutzer:innen zu unterbrechen. Für Daten, welche möglichst lange erhalten bleiben sollen oder besonders kritisch sind, ist der “Persistent“ Bereich vorgesehen. Die darin befindlichen Daten können nur vom User manuell gelöscht werden. Um Daten in den Persistent-Storage zu schreiben muss allerdings erst die Berechtigung über die Permissions API angefragt werden [16]. Diese ist für alle Browser mit Ausnahme von Safari und Internet Explorer nutzbar [19]. Das Handling der Permission erfolgt dabei wieder unterschiedlich. Bei Chromium-basierten Browsern wird die Entscheidung vom Browser selbst getroffen. Sie basiert unter anderem auf Daten über die Seiteninteraktion und ob diese als Lesezeichen markiert wurde. Firefox überlässt die Entscheidung den Nutzer:innen, welche über einen Dialog festlegen, ob Daten in den persistenten Teil des Webstorages geschrieben werden dürfen [19].

FAZIT

Dieses Paper setzt sich mit der Speicherung von Daten in Webapplikationen auf Clientseite auseinander. Dabei wurden zunächst die Vorteile einer lokalen Datenspeicherung ausgearbeitet. Die Frage bezieht sich hierbei darauf, wie Backend-Datenbanken von Lokalen Datenbanken unterstützt werden können. Es wird nicht der Anspruch gestellt diese zu ersetzten. Anschließend wurden vorhandene Lösungen für diese Problemstellung analysiert und deren Vor- und Nachteile ausgearbeitet. Hierbei zeigt sich, dass der Webstorage und dabei insbesondere der Localstorage einen guten Startpunkt bietet, um Daten auf Clientseite zu speichern. Aufgrund der einfachen Handhabung bedarf es nur geringer Vorkenntnisse. Gerade bei einfachen Datensätzen ist diese Speichermethode damit das Mittel zur Wahl. Dennoch hat sich gezeigt, dass die Technologie gerade bei komplexen Datenstrukturen und großen Datenmengen schnell an ihre Grenzen stößt. Dabei ist vor allem die Speicherung als Key-Value Paare ausschlaggebend, weil diese auf String Werte beschränkt sind. Für umfangreichere Daten bietet sich daher die Nutzung von IndexedDB an. Hierbei handelt es sich um eine JavaScript basierte NoSQL Datenbank, die ihre Daten in Form von Objekten abspeichert. Somit können nahezu alle Datentypen abgelegt werden. Zudem verfügt die Datenbank über alle wichtigen Funktionen, wie sie auch in einer Backend Datenbank zu finden wären. Darunter fallen Versionen, Transaktionen und die Möglichkeit Daten gefiltert abzufragen. Aufgrund ihrer zahlreichen Möglichkeiten steigt allerdings auch die Komplexität der Implementierung. Zusätzlich ist die API nicht sonderlich intuitiv gestaltet, was es vor allem für neue Entwickler:innen zum Einstieg schwer macht. Über die bereits bestehenden Lösungen hinaus, zeigt sich, dass auf Basis dieser auch die Umsetzung von relationalen Datenbanken am Client möglich ist. Trotz aller Vorteile bleiben Einschränkungen, welche sich durch die Client Umgebung ergeben. Hierbei muss vor allem die unterschiedliche Umsetzung einzelner Technologien in verschiedenen Browsern betrachtet werden. Zudem verliert man als Entwickler die Kontrolle über lokale Ressourcen. Die Speicherung von kritischen Daten auf Clientseite sollte also weiterhin gut abgewogen werden.

REFERENZEN

[1] J. Kuuskeri, „Experiences on a Design Approach for Interactive Web Applications“, 2011.
[2] A. Al-Shaikh und A. Sleit, „Evaluating IndexedDB performance on web browsers“, in 2017 8th International Conference on Information Technology (ICIT), Mai 2017, S. 488–494. doi: 10.1109/ICITECH.2017.8080047.
[3] S. Tilkov, J. Heron, und L. Dohmen, „Klassischer Architekturansatz für Webanwendungen – JavaScript? Gern, aber bitte in Maßen“, PHP Magazin, Nr. 4, 2019.
[4] R. Camden, Client-Side Data Storage: Keeping It Local. O’Reilly Media, Inc., 2015.
[5] M. Jemel und A. Serhrouchni, „Security assurance of local data stored by HTML5 web application“, in 2014 10th International Conference on Information Assurance and Security, Nov. 2014, S. 47–52. doi: 10.1109/ISIAS.2014.7064619.
[6] W. Jiang, M. Zhang, Y. Y. Huo, und Y. J. Jiang, „Research on application of the HTML5 local storage in a service system of theater 3D model“, in 2015 IEEE 5th International Conference on Electronics Information and Emergency Communication, Mai 2015, S. 368–371. doi: 10.1109/ICEIEC.2015.7284560.
[7] R. Grundwald, „Der Browser als Datenbank“, entwickler.de Deine Wissensplattform. https://entwickler.de/reader/ (zugegriffen 7. November 2022).
[8] „Using the Web Storage API – Web APIs | MDN“. https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API/Using_the_Web_Storage_API (zugegriffen 7. November 2022).
[9] „‚localstorage‘ | Can I use… Support tables for HTML5, CSS3, etc“. https://caniuse.com/?search=localstorage (zugegriffen 7. November 2022).
[10] „IndexedDB API – Web APIs | MDN“. https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API (zugegriffen 8. November 2022).
[11] „IndexedDB – eines der am meisten unterschätzten Web-APIs“, entwickler.de Deine Wissensplattform, 10. August 2022. https://entwickler.de/javascript/indexeddb-web-api (zugegriffen 30. Oktober 2022).
[12] S. Springer, „IndexedDB – eines der am meisten unterschätzten Web-APIs“, entwickler.de Deine Wissensplattform. https://entwickler.de/reader/ (zugegriffen 7. November 2022).
[13] „Using IndexedDB – Web APIs | MDN“. https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB (zugegriffen 8. November 2022).
[14] „sql.js“. https://sql.js.org/#/ (zugegriffen 9. November 2022).
[15] J. Long, jlongster/absurd-sql. 2022. Zugegriffen: 9. November 2022. [Online]. Verfügbar unter: https://github.com/jlongster/absurd-sql
[16] „Storage for the web“, web.dev. https://web.dev/storage-for-the-web/ (zugegriffen 8. November 2022).
[17] „StorageManager.estimate() – Web APIs | MDN“. https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate (zugegriffen 9. November 2022).
[18] „Persistent storage“, web.dev. https://web.dev/persistent-storage/ (zugegriffen 8. November 2022).
[19] „Permissions API: persistent-storage permission | Can I use… Support tables for HTML5, CSS3, etc“. https://caniuse.com/mdn-api_permissions_persistent-storage_permission (zugegriffen 8. November 2022).

The post Clientseitige Datenspeicherung für Webapplikationen – SOTA appeared first on Mobile USTP MKL.

Was man über Karten wissen sollte

Bevor wir uns mit den eigentlichen Visualisierungen beschäftigen, möchte ich noch auf ein paar grundlegende Aspekte zum Thema Kartendarstellungen im Allgemeinen eingehen, die es zu beachten gilt. Denn wer scharf beobachtet erkennt, dass es sich bei der Form unserer Erde, sehr vereinfacht gesehen, um eine Kugel handelt. Diese Kugel jetzt in der rechteckigen Form einer Karte oder eines Handy Displays darzustellen, stellt die Menschheit nicht erst seit heute vor eine Herausforderung. Dementsprechend viele Lösungsansätze wurden bereits für dieses Problem kreiert.  Ein bewährter Ansatz hierbei ist es einen Zylinder, um die Erdkugel zu legen und jeden Punkt auf der Kugel in gleicher Höhe auf den Zylinder zu übertragen. Ein Vertreter dieser Projektion ist die „Marcador projection“, welche auch für online Karten wie beispielsweise OpenStreetMap genutzt wird. Sie hat den Vorteil, dass Länderformen und Winkel erhalten bleiben, wodurch sie sich sehr gut für die Navigation eignet. Ein großer Nachteil hierbei sind allerdings die verlorenen Größenverhältnisse. Je weiter ein Punkt am Globus vom Äquator entfernt liegt, desto größer wird er auf der späteren Karte dargestellt. Dies führt zum bekannten Problem, dass die Insel Grönland (2,2 Mio. km²) in dieser Kartenprojektion fast so groß dargestellt wie der Kontinent Afrika (30,3 Mio. km²). Ein Umstand, der bei der Visualisierung von Geodaten beachtet werden sollte.

Woher die Daten?

Nachdem wir uns mit den Grundlagen der Kartographie beschäftig haben, stellt sich uns die Frage wo wir die Kartendaten, welche unseren Visualisierungen zu Grunde liegen überhaupt herbekommen. Der verbreitetste Anbieter ist hier sicher der Kartendienst von Google mit Google Maps. Hierbei wird allerdings ein API Key benötigt und der Service wird ab einer bestimmten Zugriffszahl kostenpflichtig. Zudem sind alle Daten in den Händen von Google. Eine kostenlose Alternative bietet hier OpenStreetMaps, was auch standardmäßig von Leaflet empfohlen wird. Der Service basiert auf dem Open Data Prinzip, was die Daten für alle zugänglich macht. Wenn nur Karten aus Österreich benötigt werden, sind die Daten von Basemap.at ebenfalls eine tolle Option.

Los geht’s mit Leaflet

Leaflet bietet ein breites Toolset an Funktionen und Visualisierungsmöglichkeiten, um interaktive Karten effizient umsetzen zu können. Dabei überzeugt es vor allem auch in Hinblick auf die Performance. Die Library selbst ist trotz eines großen Funktionsumfangs nur wenige KB groß und die Visualisierungen führen auch bei steigenden Datenmengen nicht zu Performance Einbußen der Seite. Zusätzlich handelt es sich um eine open-source Library.

Eine Karte mit Leaflet anzuzeigen ist denkbar einfach. Hierfür benötigen wir zunächst ein HTML-Element, welches als Container für unserer spätere Karte dient. Wichtig ist dabei, dass der Container eine definierte Höhe hat. Gerade für mobile Applikationen empfiehlt es sich aber der Karte so viel Platz wie möglich zu geben.

<div id=“map-container“></div>

#map-container { height: 100vh; width: 100vw }

Anschließend wird mit JavaScript ein Kartenobjekt erzeugt, welchem als Parameter die ID des Containers mitgegeben wird, in welchem die Karte später gerendert werden soll. Zudem kann eine Standardansicht definiert werden, welche sich aus den Koordinaten des Zentrums und der gewünschten Zoomstufe zusammensetzt. In unserem Fall die Koordinaten der FH St. Pölten.

const map = L.map(“map-container”);
map.setView([48.21368302685891, 15.63142044020101], 17);

Wer jetzt jeden Schritt genau befolgt hat wird vor einer grauen Karte sitzen. Dies liegt daran, dass noch die eigentlichen Kartendaten fehlen. Hierfür wird ein Tilelayer hinzugefügt, welche die einzelnen Ausschnitte von einem geeigneten Anbieter lädt. Wie bereits diskutiert, beziehen wir diese von OpenStreetMaps.

L.tileLayer('https://tile.openstreetmap.org/{z}/{x}/{y}.png', {
            maxZoom: 19,
            attribution: '&copy; <a href="http://www.openstreetmap.org/copyright">OpenStreetMap</a>'
         }).addTo(map);

Nach diesem Schritt ist unsere Karte jetzt auch wirklich eine Karte und wir können anfangen eigenen Elemente hinzuzufügen. Hierfür stellt Leaflet mehrere Elemente wie Pins, Kreise oder komplexere Polygone zur Verfügung. Da sich die Implementierung der Einzelnen Elemente ähnelt schauen wir uns hier einmal nur den klassischen Marker an. Mit dem folgenden Code erzeugen wir zunächst einen Marker und fügen ihn anschließend zur Karte hinzu.

const marker = L.marker([48.21368302685891, 15.63142044020101]).addTo(map);

Diesem Marker kann wiederum ein Popup hinzugefügt werden, welches sich per Klick öffnet. Das Popup kann dabei jeden beliebigen HTML-Code enthalten.

marker.bindPopup("FH St.Pölten");

Dieses kurze Beispiel veranschaulicht, wie schnell man eine Visualisierung mit Leaflet umsetzen kann. Wer jetzt noch Lust auf mehr hat, kann auch eines der Tutorials auf ihrer Webseite ausprobieren.

The post Interaktive Karten mit Leaflet appeared first on Mobile USTP MKL.

Die Idee für mein Projekt kam mir durch ein geplantes Mario Kart Tunier. Da immer nur eine geringe Anzahl an Teilnehmer:innen gleichzeitig spielen kann, haben wir nach einer Möglichkeit gesucht, auch den anderen Spieler:innen währenddessen eine Aufgabe zu geben. So entstand die Idee alle Teilnehmer:innen darüber abstimmen zu lassen, welche Strecken als nächstes gefahren werden sollen. Daher habe ich mein Projekt genutzt um eine Webaplikation zu entwickeln, mit der über die Streckenauswahl abgestimmt werden kann.

it221511.students.fhstp.ac.at/qr-code/

Technische Umsetzung

Da ich die Entwicklung von JavaScript Applikationen zu meinen Stärken zähle, habe ich mich dazu entschlossen, bei diesem Projekt das Hauptaugenmerk auf cientseitige Entwicklung zu legen. Das zugehörige Backend besteht aus einer API, welche mit PHP aufgesetzt wurde und auf eine MySQL Datenbank zugreift. Dabei enthält das Backend mit Ausnahme der Sessionverwaltung keine Logik und hat nur die Aufgabe Daten im JSON Format ans Frontend auszuliefern. Um die Entwicklung herausfordernder zu gestalten, habe ich mich anschließend dazu entschlossen, HTML Seiten auszuliefern, welche bis auf eine geringe Grundstruktur leer sind. Alle Inhalte werden im Nachhinein mit JavaScript eingefügt. Dabei wurde auf ein Framework verzichtet und die meisten Funktionen in Vanilla JavaScript umgesetzt. Für leichtere DOM Manipulationen und Ajax Request wurde die Library JQuery eingebunden. Um eine klare Struktur zu bewahren, wurde für jede HTML Seite eine eigene JavaScript Klasse angelegt, welche anschließend wiederum die Ensprechenden Module lädt, die für die aktuelle Seite benötigt werden.

Resultat

The post Print2Mobile – Webapplikation für Mario Kart Tuniere appeared first on Mobile USTP MKL.