Das Kunstwerk stellt die immer kleiner werdenden Ränder zwischen Mensch und Maschine, Realität und Simulation, Fakt und Fiktion. Auch die Diskussionen rund um das Thema bezogen sich hauptsächlich auf genau diese Themen und wurden ausführlich besprochen.

Für die Erstellung des Werkes wurden sowohl im Audio- als auch Videobereich Programme verwendet, die sich aus verschiedensten Gründen Machine Learning Modelle zur Hilfe genommen haben, um ihren NutzerInnen beim Ausleben ihrer kreativen Ziele unterstützen können.

Credits

Sound Design
Christoph Fuchs
Fabian Gaugusch
Thomas Klein
Manuel Schumach

Visual Design
Anna Schürmann
Felix Hadi
Lena Kernstock
Michael Stidl
Theresa Neurauter

Lecturers
Andrew Blanton
Clara Blume
Michael Iber

Links

The post Artificial Creativity – Summer School 2022 appeared first on Mobile USTP MKL.

In diesem Blogeintrag werde ich Schritt für Schritt erklären, wie man sich bei der API von Spotify autorisiert und somit Zugang zu verschiedensten Datenquellen des Musikanbieters bekommt.

Spotify Access Token

Zuerst müssen sich EntwicklerInnen auf der Website Spotify for Developers mit ihren regulären Spotify Nutzerdaten anmelden und anschließend unter dem Reiter “Dashboard” eine neue App registrieren.

Der Appname sollte aus Gründen der Einfachheit gleich dem Namen der geplanten Applikation sein, kann aber auch irgendwas sein. Nach dem Erstellen landet man auf der Übersichtsseite der neuen App, in der man später Einsicht über verschiedenste Datenvisualisierungen der Applikation bekommt.

Ganz wichtig sind hier die beiden Keys “Client ID” und “Client Secret”. Diese werden später für das Autorisieren der NutzerIn benötigt. Im Code kann es sich nun um eine simple Front-End-Applikation halten, in der die Requests durchgeführt werden.

Zur Hilfe kann hier die Library Spotify-Web-Api-Node verwendet werden, die den Autorisierungsprozess erleichtert.

const credentials = {
    clientId: 'Deine Client ID',
    clientSecret: 'Dein Client Secret',
    redirectUri: 'localhost:xxx',
    scopes: [
        'user-read-currently-playing',
        'user-read-recently-played',
        'user-read-playback-state',
        'user-top-read',
        'user-modify-playback-state',
        'streaming',
        'user-read-email',
        'user-read-private',
        'playlist-modify-private',
        'playlist-read-private',
    ],
    state: 'Dein State',
};

Zunächst wird ein Javascript-Objekt definiert, welches nicht nur Client Id und Client Secret beinhaltet, sondern auch eine URL, auf die nach dem Autorisieren wieder zurückverwiesen wird und die Scopes, die NutzerInnen darüber informieren, welche Funktionen über deren Account sie innerhalb der zu schreibenden Applikation erlauben.

Mithilfe der zuvor genannten Library kann über die Methode createAuthorizeUrl() anhand der Credentials einfach ein Link zur Spotify-Autorisierungsseite generiert werden, die dann innerhalb der Webapplikation verlinkt werden kann.

const spotifyApi = new SpotifyWebApi(credentials);

const authorizationURL = spotifyApi.createAuthorizeURL(
    credentials.scopes,
    credentials.state
);

Nun kann sich eine NutzerIn anhand diesen Links bei Spotify anmelden und wird wieder auf die definierte URL zurückgeleitet, wobei sie hier zusätzlich einen eine Stunde lang gültigen Access Token erhält. Dieser Token kann in der Applikation nun bei jedem Request im Header als Bearer-Token mitgesendet werden und die gewünschten Daten können abgefragt werden!

The post Nutzung der Spotify API in einem Projekt appeared first on Mobile USTP MKL.

Das Thema Artificial Creativity befasst sich mit der Verwendung von künstlicher Intelligenz bei der Erschaffung verschiedenster kreativer Kreationen. Das konkrete Ziel ist es, menschliche Kreativität zu simulieren und/oder replizieren. Dies beinhaltet die Erforschung des Begriffes „Kreativität“ selbst und wie diese nachgeahmt werden kann. Ein weiterer Anwendungsbereich ist die Erschaffung eines Programmes oder einer Maschinerie, welche Menschen dabei unterstützt, ihre Kreativität zu verbessern oder zu entdecken.

(What Is Computational Creativity (Artificial Creativity)?, n.d.) (“Computational Creativity,” 2022)

Das wohl erwähnenswerteste Beispiel gegenwärtiger Entwicklungen im Bereich Artificial Creativity ist das zuvor angeführte AI-System „Dall-E 2“. (Link) Dabei handelt es sich um ein Programm, welches realistisch aussehende Bilder und Kunstwerke anhand einer Vorgabe kreieren kann. Dabei können sehr spezifische Vorgaben an das System gemacht werden, die alle bei der Erstellung der Kunstwerke berücksichtigt werden. Nicht das erwartete Bild, sondern auch Positionen der einzelnen Elemente darin oder der nachzuahmende Zeichenstil können dabei definiert werden. Das Programm kreiert darauf folgend mehrere individuelle Bilder, um noch näher an genau das von der NutzerIn erwartete Bild heranzukommen.

Ein weiterer Anwendungsbereich von Dall-E 2 ist das Editieren existierender Bilder. Auch hier versteht das System die Relationen von Objekten zueinander, sowie deren Schatten, Texturen und Reflektionen. Mithilfe von Dall-E 2 können so
Elemente aus Bildern entfernt und hinzugefügt, vergkleinert oder vergrößert werden und vieles mehr. (DALL·E 2, n.d.)
Grundlegende Programmlogik des Systems basiert hauptsächlich auf einem im April 2022 veröffentlichten Paper, betitelt „Hierarchical Text-Conditional Image Generation with CLIP Latents“. (Ramesh et al., 2022)

Fazit

Dies waren nur zwei der vielen Features, die Dall-E 2 NutzerInnen zur Verfügung stellt. Momentan handelt es sich dabei nur um ein fortlaufendes Forschungsprojekt, welches zu diesem Zeitpunkt noch nicht öffentlich zugänglich ist. Doch eines ist ganz klar: Nach Dall-E 2’s Veröffentlichung wird die Welt der künstlichen Kreativität einen neuen Grundpfeiler haben, der große Wellen schlagen wird.

Quellen

Computational creativity. (2022). In Wikipedia. https://en.wikipedia.org/w/index.php?title=Computational_creativity&oldid=1085146887

DALL·E 2. (n.d.). OpenAI. Retrieved June 8, 2022, from https://openai.com/dall-e2/

Ramesh, A., Dhariwal, P., Nichol, A., Chu, C., & Chen, M. (2022). Hierarchical
Text-Conditional Image Generation with CLIP Latents (arXiv:2204.06125). arXiv.
https://doi.org/10.48550/arXiv.2204.06125

What is computational creativity (artificial creativity)? – Definition from WhatIs.com.
(n.d.). WhatIs.Com. Retrieved June 8, 2022, from
https://www.techtarget.com/whatis/definition/computational-creativity

The post Dall•E 2 – Künstliche Kreativität angewandt appeared first on Mobile USTP MKL.

Wahrscheinlich stand im Laufe des Bachelor-/ oder Masterstudiums jeder von uns schon mindestens einmal vor dem Problem, dass ESLint oder der sogenannte “Linter” den Entwicklungsprozess verlangsamt hat, da bestimmte Syntax nicht als valide galt und so der Code nicht ausgeführt werden konnte. Dies führt bei ProgrammierInnen (wie mir selbst) oft zu mehr Kopfschmerzen als das eigentlich zu lösende Problem. Doch was genau ist ESLint überhaupt und wieso sollte sich jede DeveloperIn die Zeit nehmen, um das Tool zu verstehen und zu meisten?

ESLint

ESLint ist eines von einer Reihe an “Linting”-Tools, welches dabei helfen soll, schöneren und richtigeren Code zu schreiben. Der Begriff “to lint/etwas linten” beschreibt den Vorgang der statischen Code-Analyse von einem Tool und kommt vom englischen Begriff “Fussel”. ESLint speziell wurde von Nicholas C. Zakas entwickelt und im Juni 2013 veröffentlicht. Bei dem Tool handelt es sich konkret um einen JavaScript-Linter, welcher nicht nur TypeScript und ECMAScript 2015 unterstützt, sondern in den letzten Jahren auch die Syntax von beliebten JavaScript-Frameworks wie Vue oder React analysieren kann. (https://eslint.org/docs/about/)

Heute ist ESLint der weltweit verbreitetste JavaScript-Linter und hatte am 29. Mai 2022 über 24,000,000 wöchentliche Downloads.

Das Hauptziel von ESLint ist es, EntwicklerInnen in sowohl kleinen als auch großen Projekten/Gruppen dabei zu helfen, einen einheitlichen Code-Styleguide einzuhalten. Dies beinhaltet unter vielen anderen Regeln die einheitliche Verwendung von einfachen oder regulären Anführungszeichen, eine maximale Zeichenanzahl pro Codezeile oder die Einhaltung ausgewählter Namenskonventionen (Camel Case, Pascal Case, …). (https://eslint.org/docs/rules/)

Integration

Durch seine Popularität ist ESLint heute in so gut wie jeder beliebten Entwicklungsumgebung zu finden. Visual Studio Code bietet ESLint als Plugin an, welches in jedem Projekt individuell konfiguriert werden kann. Auch die diversen IDEs des bekannten Softwareunternehmens Jetbrains (IntelliJ IDEA, PhpStorm, Webstorm, etc.) bieten unterstützung für das Analysetool an. (https://de.wikipedia.org/w/index.php?title=ESLint&oldid=221828916)

Funktionalität

Die Funktionalität von ESLint scheint beim ersten Hinblick ja schön und gut zu sein, aber was genau ist es, das ESLint zu so einem hilfreichen Tool für EntwicklerInnen macht? Ähnlich wie TypeScript hilft ESLint dabei, Fehler schon während des Schreibens von Code ausfindig zu machen, anstatt diese erst während der Runtime nach Starten des Programms finden zu können. Folgendes simples Beispiel demonstriert einen Anwendungsfall:

In dem gezeigten Beispiel wird die Konstante “test” zwei mal deklariert, was der Javascript-Engine nicht passt und diese durch den Fehler während der Laufzeit abbrechen lassen wird.

Bei richtig eingestellen ESLint-Regeln wird dieses Codeschnipsel jedoch schon in der Entwicklungsumgebung als fehlerhaft markiert und der Code lässt sich bis zur Behebung nicht ausführen. Innerhalb dieses drei-zeiligen Beispiels ist der Fehler natürlich schnell und leicht ausfindig zu machen, in größeren Applikationen können sich jedoch schnell unbemerkte Fehler einbauen, die ohne Hilfstools wie ESLint teils gar nicht leicht zu finden sind.

Regeln

Was ESLint von andern, nicht so beliebten Lintern unterscheidet, ist seine große Auswahl an genauestens individualisierbaren Regeln. So können Styleguides von allen EntwicklerInnen eines Teams streng eingehalten werden und alle Beteiligten bemerken schon während des Verfassen ihres Codes, wenn der Code nicht den definierten Regeln entspricht.

Regeln für ESLint können auf zwei generelle Wege innerhalb eines Projektes konfiguriert werden. Zum Einen anhand von Konfigurationskommentaren und zum Anderen anhand von Dateien, in denen die Auflistung der Linterregeln definiert ist. Da der Überblick über alle Regeln innerhalb einer Datei viel übersichtlicher ist, wird diese Methode meist von EntwicklerInnen bevorzugt. Diese Regeln sind im Normalfall durch ein simples JSON oder YAML-File definiert.

Wichtig ist auch noch die Möglichkeit, Regeln temporär oder global “auszuschalten”, da es immer wieder auch dazu kommen kann, dass Regeln projektübergreifend nicht 100 prozentig eingehalten werden können. (https://eslint.org/docs/user-guide/configuring/rules)

Probleme mit ESLint

Die bisherig angeführten Punkte beschreiben das Ziel der Verwendung von ESLint und beleuchten auch nur simple oder sogenannte “best case scenarios”. Leider muss erwähnt werden, dass die korrekte Verwendung von ESLint keine leichte ist und das Tool oft mehr Probleme macht als es zu lösen versucht.

Damit ist gemeint, dass sich ProgrammiererInnen schnell von dem Tool eingeschränkt fühlen können, da die definierten Regeln strikt eingehalten werden müssen. Dies führt dazu, dass Code in der Developmentphase, beim “Heranarbeiten” an die korrekte Lösung oft nicht ausführbar ist, da er nicht dem erwarteten Format entspricht.

Fazit

Generell lässt sich ESLint meiner Meinung nach in eine ähnliche Kategorie wie TypeScript stecken. Beide Tools bieten EntwicklerInnen einige Möglichkeiten, schönen und fehlerfreien Code effizienter zu verfassen. Jedoch benötigen beide Tools auch gewissen Aufwand um ihr volles Potential zu entfalten.

Quellen

About. (n.d.). ESLint – Pluggable JavaScript Linter. Retrieved June 7, 2022, from https://eslint.org/docs/about/

ESLint. (2022). In Wikipedia. https://de.wikipedia.org/w/index.php?title=ESLint&oldid=221828916

Rules. (n.d.-a). ESLint – Pluggable JavaScript Linter. Retrieved June 7, 2022, from https://eslint.org/docs/rules/

Rules. (n.d.-b). ESLint – Pluggable JavaScript Linter. Retrieved June 7, 2022, from https://eslint.org/docs/user-guide/configuring/rules

@typescript-eslint/eslint-plugin vs eslint vs jshint vs jslint vs tslint | npm trends. (n.d.). Retrieved June 7, 2022, from https://www.npmtrends.com/jslint-vs-jshint-vs-eslint-vs-tslint-vs-@typescript-eslint/eslint-plugin

The post ESLint – Segen oder Fluch? appeared first on Mobile USTP MKL.

Next.js ist ein auf React basierendes Javascript-Framework, welches zur Entwicklung von Single-Page-Applikationen verwendet wird. Next.js wurde im Oktober 2016 erstmals von Guillermo Rauch und dem Entwicklerteam seines Unternehmens, Vercel, als Open-Source-Projekt auf Github veröffentlicht. Das Ziel des Frameworks ist es, die Features und Möglichkeiten, die React bietet, um einige weitere Funktionalitäten auzubauen und sowohl den Entwicklungsprozess als auch die User Experience der damit erstellten Webapplikation zu verbessern. Zu diesen erweiterten Funktionalitäten zählen unter anderem Server-Side-Rendering (SSR), Static Site Generation (SSG), eingebautes auf der Ordnerstruktur basierendes Routing, die simple Erstellung von API-Endpoints oder optimiertes Code-Splitting und Bundling. (“Next.Js,” 2022)

In diesem Blogeintrag werden einige interessante und spannende Features von Next.js angeführt und genauer untersucht.

Server-Side-Rendering vs. Client-Side-Rendering

Server-Side-Rendering

In den früheren Tagen des Internets war Server-Side-Rendering der verbreitetste Weg, um einer Nutzer:in eine HTML-Seite in ihrem Browser zeigen zu können. Dafür wurde eine statische HTML-Seite auf einem Server gespeichtert, welche dann anhand einer Request an den Server an die Nutzer:in weitergegeben wurde.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Example Website</title>
  </head>
  <body>
    <h1>My Website</h1>
    <p>This is an example of my new website</p>
    <a href="http://example.testsite.com/other.html.">Link</a>
  </body>
</html>

Wollte die Nutzer:in nun auf eine andere Seite navigieren, wurde erneut eine Request an den Server gesendet und die vollständige Seite wurde erneut weitergegeben, auch wenn der Inhalt der Seite fast der gleiche, wie der der ersten Seite war (z.B.: das HTML, welches seitenübergreifend das Menü der Webseite darstellen soll).

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>Example Website</title>
  </head>
  <body>
    <h1>My Website</h1>
    <p>This is an example of my new website</p>
    <p>This is some more content from the other.html</p>
  </body>
</html>

Die beiden oben gezeigten Beispiele einer simplen HTML-Seite unterscheiden sich in nur einer Code-Zeile. Obwohl sich für die Nutzer:in nur dieser eine Text ändert, wird trotzdem der ganze Seiteninhalt erneut geladen, anstatt nur den geänderten Teil der Seite neu zu laden. (Malagi, n.d.)

Client-Side-Rendering

Heutzutage sind Webseiten mehr vollständige Applikationen, die im Browser dargestellt werden, als simple statische Seiten. Oft beinhalten sie mehrere hunderte oder sogar tausende Zeilen Code, welche beim Server-seitigen Laden bei jeder Änderung der Seite erneut geladen werden müssten.

Moderne Frameworks wie der Grundstein von Next.js, React, oder Vue machen sich das Client-Side-Rendering zunutze, um den jeweilig gewünschten Seiteninhalt mithilfe von Javascript in einer einzigen „leeren“ HTML-Datei anzeigen zu können.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
    <meta name="theme-color" content="#000000">
    <link rel="manifest" href="%PUBLIC_URL%/manifest.json">
    <link rel="shortcut icon" href="%PUBLIC_URL%/favicon.ico">
    <title>React App</title>
  </head>
  <body>
    <noscript>
      You need to enable JavaScript to run this app.
    </noscript>
    <div id="root"></div>
  </body>
</html>

Der Vorteil dieser Methode ist, dass nun beim Aufruf einer neuen Unterseite oder dem Verändern von Daten auf der momentanen Seite kein neuer Request an den Server gemacht wird, sondern der Inhalt effizient mithilfe des Javascripts des verwendeten Frameworks ersetzt oder verändert wird. (Client-Side vs. Server-Side Rendering, 2017)

Aber auch das Client-Side-Rendering bringt gewisse Nachteile mit sich, wie zum Beispiel der Search-Engine-Optimization der Applikation. Da die Seite initial noch keinen Inhalt hat, sondern ohne Ausführung des Javascript-Codes nur eine leere HTML-Seite ist, kann diese von Search-Engine Bots gar nicht beziehungsweise nur schwer aufgefunden werden. Weiters leidet unter Umständen auch die Ladezeit der Applikation unter Verwendung von Client-Side-Rendering, da erst das vollständige Javascript geladen werden muss, um den ersten Seiteninhalt anzeigen zu können.

Im folgenden Bereich sind noch einmal zusammenfassend die jeweiligen Vor- und Nachteile von Client-Side-Rendering und Server-Side-Rendering angeführt

(Client-Side vs. Server-Side Rendering, 2017)

Server-Side-Rendering mit Next.js

Innerhalb einer React-Komponente eines Next.js Projektes kann eine Funktion namens “getServerSideProps” exportiert werden.

export async function getServerSideProps(context) {
  return {
    props: {}, // will be passed to the page component as props
  }
}

Diese Methode läuft außschließlich auf dem Server und nie im Browser der Nutzer:in. Wird eine Seite, die eine solche Funktion exportiert aufgerufen, wird “getServerSideProps” zum Zeitpunkt der Request aufgerufen und die Seite wird am Server vorgerendert. Die vollständig geladene Seite wird nun an die Nutzer:in geschickt.

Diese Methode kann optional in einzelne Komponenten eingebaut werden und hilft Entwickler:innen, ein optimales und performantes Nutzererlebnis bieten zu können. (Data Fetching, n.d.)

Dateisystem-basiertes Routing

Auch hier unterscheidet sich Next.js von ursprünglichem React, indem das Framework ein eigenes, einfach verständliches Routing-System integriert hat. Bei einem regulären React-Projekt muss eine externe Library, wie zum Beispiel der weitgehend bekannte React-Router eingebunden werden. Im folgenden Abschnitt werden die Grundideen des Next.js-Routers erläutert.

Index, Nested und Dynamic Routes

Das links zu sehende Beispiel visualisiert eine grundlegende Routing-Struktur im Next.js-Projekt. Das hier wichtigste Verzeichnis heißt “pages” und beinhaltet alle Views als einzelne .js oder .ts-Dateien.

Eine Javascript-Komponente im Hauptverzeichnis kann direkt unter “/Dateiname” über den Browser erreicht werden.

Genau so simpel verhalten sich eingebettete Routen. Hier wird zuerst ein neuer Ordner mit dem Namen der Hauptroute erstellt, dann kann darin über den Namen des Ordners auf die Komponente mit dem Namen “index.js” zugegriffen werden. Jede weitere darunter liegende Komponente wird in den selben Ordner platziert und kann unter “/Ordnername/Dateiname” erreicht werden.

Dynamisch generierte Routen werden in Next.js anhand einer eckigen Klammer um den Dateinamen erstellt. Nun kann innerhalb der Komponente über eine Router-Hook auf die Information in der URL zugegriffen werden und zum Beispiel eine Datei und deren Inhalte mit der zugehörigen ID aus einer Datenbank geladen werden.

(Routing, n.d.)

Fazit

Next.js stellt als Superset von React ein Framework dar, welches Reacts Horizont an Möglichkeiten direkt erweitert. Für eine Entwickler:in kann Next.js mit Typescript verglichen werden, da es wie bei Typescript und Javascript bereits ein umfangreiches Wissen bezüglich dem React-Framework voraussetzt. Der zusätzliche Lernaufwand macht sich aber schnell bemerkbar und lässt React neue, zuvor nicht erreichbare Höhen erreichen.

In diesem Blogeintrag bin ich nur auf ein paar der vielen erweiterten Funktionen eingegangen, um einen ersten Einblick in das Framework zu bieten. Natürlich bleibt es abzuschätzen, ob ein Softwareprojekt Gebrauch von diesen Features machen kann, jedoch ist es definitiv die Zeit wert, sich näher mit dem Framework zu beschäftigen.

Weitere Informationen und eine ausführliche Dokumentation zu den erwähnten Features und vielen mehr sind in der Next.js-Dokumentation zu finden.

Literaturverzeichnis

Client-side vs. server-side rendering: Why it’s not all black and white. (2017, February 28). FreeCodeCamp.Org. https://www.freecodecamp.org/news/what-exactly-is-client-side-rendering-and-hows-it-different-from-server-side-rendering-bd5c786b340d/

Data Fetching: GetServerSideProps | Next.js. (n.d.). Retrieved February 22, 2022, from https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props

Malagi, S. (n.d.). Server-Side Rendering VS. Client-Side Rendering. Retrieved February 22, 2022, from https://www.clariontech.com/blog/server-side-rendering-vs.-client-side-rendering

Next.js. (2022). In Wikipedia. https://en.wikipedia.org/w/index.php?title=Next.js&oldid=1072970217

Routing: Introduction | Next.js. (n.d.). Retrieved February 22, 2022, from https://nextjs.org/docs/routing/introduction

The post Erste Schritte mit Next.js appeared first on Mobile USTP MKL.

Der Begriff Progressive Web App wurde erstmals im Jahr 2015 von Google Chrome Entwickler Alex Russel und Designer Frances Berriman geprägt und beschreibt ein modernes Konzept der Entwicklung von Webapplikationen. PWAs sollen einen Mix der besten Aspekte von klassischen responsiven Webseiten und nativen Applikationen darstellen. Russel und Berriman haben weiters einige Grundanforderungen an eine fertige Progressive Web App beschrieben.

Grundanforderungen

• Responsiv: Das Design muss jedem Formfaktor entsprechen.
• Konntektivitätsunabhängigkeit: Durch die Unterstützung von Service Workern auch offline nutzbar.
• App-ähnliche Interaktionen: Sowohl das Design als auch die Nutzbarkeit soll anhand einer App Shell an eine native App erinnern.
• Updated: Durch Service Worker stets am neuesten Stand.
• Sicher: Sicherer Datentransfer als Grundvoraussetzung.
• Auffindbar: Durch Aspekte einer Webseite mithilfe von Suchmaschinen auffindbar.
• Erneute Interaktion: Durch aus Apps bekannten PushBenachrichtigungen wird die User-Interaktion gefördert.
• Installierbar: Kann über den Webbrowser auf dem mobilen Gerät heruntergeladen werden und im Homescreen per Icon erreicht werden.
• Verlinkbar: Durch den Zugang über den Webbrowser leicht per URL zu verlinken.

Installation

Das Installieren einer PWA läuft gleich über den Browser, in dem die PWA aufgerufen wurde und ist sehr simpel gehalten. Die NutzerIn erhält ein Banner, welches sie zum Herunterladen der Applikation veranlasst. Nach einer Bestätigung wird die Applikation auch schon heruntergeladen und kann nun im Homescreen, wie andere native Applikationen über ihr App-Icon geöffnet werden. Dies führt aus technischer Sicht nur dazu, dass die Webseite im Browser geöffnet wird, jedoch kann hier durch gewisse Voreinstellungen und das oben angeführte “App-ähnliche Design” die gleiche User Experience wie bei einer nativen Applikation geschaffen werden.

Entwicklerinnen und Entwickler können ihre bereits bestehenden Webapplikationen auch relativ schnell in PWAs upgraden, da diese neben bekanntem HTML, CSS und Javascript auch nur zwei weitere grundlegende Komponenten benötigen, um PWA-tauglich gemacht werden zu können. Hierbei handelt es sich zum einen um das Manifest der Applikation und zum anderen um den Service Worker, den wohl wichtigsten Bestandteil einer PWA und über welchen die meisten Funktionalitäten, die Nutzerinnen und Nutzer bei nativen Applikationen gewohnt sind, entwickelt werden können.

Manifest

(Dokumentation: https://developer.mozilla.org/de/docs/Web/Manifest)

Beim Web App Manifest der PWA handelt es sich um ein simples Json-File, in welchem verschiedene Daten zur Applikation eingetragen werden. Diese können dann vom Endgerät genutzt werden, um der Applikation im Homescreen einen Namen zu geben oder das passende App-Icon anzuzeigen. Ein Beispiel folgt:

{
	"name": "PWA Tutorial",
	"short_name": "PWA",
	"start_url": "/index.html",
	"display": "standalone",
	"background_color": "#181818",
	"theme_color": "#181818",
	"orientation": "portrait-primary",
	"icons": [
		{
			"src": "/images/icon-48-48.png",
			"type": "image/png",
			"sizes": "48x48"
		},
	]
}

Weitere erforderliche Eigenschaften sind die Farbe der Benachrichtigungsleiste des Endgerätes, die Farbe des Splashscreens, und einer Auswahl aus Anzeigemöglichkeiten wie zum Beispiel dem Vollbildmodus. Optionale Eigenschaften können der Dokumentation entnommen werden.

Service Worker

Service Worker sind Bestandteil der übergreifenden Web Worker API. Diese Web Workers erlauben es Entwickler*innen, bestimmte Skripte unabhängig vom derzeitigen Hauptthread in einem Hintergrundthread laufen zu lassen. Dies
ermöglicht die Ausführung rechenintensiver Operationen, ohne den Hauptthread zu verlangsamen, welcher in vielen Fällen die grafische Oberfläche behandelt. Die Service Worker, welche unter anderem einen der wichtigsten Bestandteile von Progressive Web Applikationen ausmachen, sind programmierbare Skripte, die definieren, wie Serveranfragen gehandhabt werden. So können Anfragen zwischengespeichert werden, um die Performance der Applikation zu verbessern oder gespeicherte Daten auch offline abgerufen werden.

Der grundlegende Lifecycle eines Service Workers besteht aus drei Teilen: Registrierung, Installation und Aktivierung.

Registrierung

Um einen neuen Service Worker zu installieren, muss dieser zuerst im Browser registriert werden.

if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/service-worker.js')
 .then(function(registration) {
 console.log('Registration successful, scope is:',
registration.scope);
 })
 .catch(function(error) {
 console.log('Service worker registration failed, error:', error);
 });
}

Dieses Beispiel einer Registrierung kontrolliert zunächst anhand der Abfrage nach einem Service Worker im Browsernavigator, ob dieser mit dem Browser kompatibel ist. Ist dies der Fall, kann die „service-worker.js“-Datei mit der Methode „navigator.serviceWorker.register” registriert werden, die ein Promise zurückgibt, welches resolved wird, sobald der Worker erfolgreich registriert wurde und die momentane Scope protokolliert.

Die Scope definiert, welche Dateien in der Applikation vom Service Worker kontrolliert werden können. Liegt die „service-worker.js“-Datei also im root-Ordner, kann der Service Worker in allen darunter liegenden Verzeichnissen verwendet werden.

Installation

Sobald ein Service Worker im Browser registriert wurde, kann eine Installation versucht werden. Dazu wird ein “install”-Event im zu installierenden Worker ausgeführt.

self.addEventListener('install', function(event) {
 // Perform some task
});

Bei der Installation können zum Beispiel gewisse Teile einer Applikation vorgespeichert werden, sodass diese beim nächsten Öffnen sofort geladen werden.

Aktivierung

Ist der Service Worker im Browser installiert, kann er im Anschluss auch sofort aktiviert werden. Es wird, wie bei der Installation, ein „activate“-Event in der Datei des Workers ausgeführt.

self.addEventListener('activate', function(event) {
 // Perform some task
});

Nach der Aktivierung kann der Service Worker auf alle Dateien, die sich in der zuvor definierten Scope befinden, zugreifen. Um die Aktivierung eines potentiell neuen Service Worker vollständig abzuschließen, sollte die Applikation einmal geschlossen und neu geöffnet werden, um alle Inhalte auf den neuesten Stand zu bringen.

Dateien offline anzeigen

Innerhalb des Service Workers können nun auch Requests an den Server angesehen und manipuliert werden. Um eine simple HTML-Datei im Browser anzeigen zu können, muss diese von einem Server geladen werden. Ist eine Nutzerin oder ein Nutzer offline, so kann diese Request natürlich nicht vollständig durchgeführt werden. Mithilfe des Service Workers können nun statische Dateien, wie das benötigte HTML und CSS für die Applikation im Browsercache zwischengespeichert werden. Nun können zuvor gespeicherte Dateien aus dem Cache genommen und angezeigt werden, falls eine fehlende Internetverbindung die Verbindung zum Server verhindert. So kann ein statisches Grundgerüst der Applikation vorgespeichert werden und immer sichtbar sein, auch wenn die NutzerIn einmal offline ist.

Zusammenfassung

Progressive Web Apps sind Webapplikationen, die durch erweiterte Features das Nutzererlebnis einer nativen Applikation simulieren, während sie immer noch die vielen Vorteile von Webapplikationen beibehalten. So bieten sie die Vorteile aus beiden Welten, ohne viel von deren Nachteilen mit sich zu tragen.

The post Einführung in Progressive Web Apps appeared first on Mobile USTP MKL.

Wird der Code nun gescannt, führt ein Link zu einer simpel gehaltenen Seite, die Nutzerinnen und Nutzer zur Netflix-Seite der Serie führt. Natürlich wäre eine wirkliche Umsetzung dieser Idee mit einem großen Vorbereitungsaufwand verbunden, da die Projektionen nicht nur richtig platziert werden müssten, damit sie nicht von nichtsahnenden Passantinnen und Passanten verdeckt werden. Weiters muss auf die Ausrichtung und Größe der Projektion geachtet werden, damit der Code auch einwandfrei von den Kameras der Passantinnen und Passanten aufgenommen werden kann.

The post Print to Mobile – Werbekonzept für “Squid Game” appeared first on Mobile USTP MKL.