Anmelden
Im letzten Teil dieser Serie werden die drei gezeigten Mechanismen noch einmal kurz zusammengefasst. Außerdem geht es um die Frage, wie sich Fehler bei der Hintergrundsynchronisation aufspüren und beheben lassen. Dazu sind die Chrome DevTools besonders nützlich.
In den vergangenen drei Teilen der Serie wurden die folgenden Schnittstellen vorgestellt:
Diese drei Schnittstellen laufen aktuell nur auf Chromium-basierten Browsern. Ob Mozilla und Apple diese auch implementieren, ist nicht sicher. Der Background Fetch, aber vielleicht auch die Web Periodic Background Sync API sind dabei höhere Chancen einzuräumen als der Web Background Sync API in ihrer heutigen Form.
Als vierte Möglichkeit kommt auch noch die Push API in Betracht. Bei eingehenden Push-Nachrichten hat der Service Worker ebenfalls noch kurz Zeit, eine bestimmte Synchronisationslogik durchzuführen. Das ist ebenfalls mehrfach und theoretisch ohne Intervallbeschränkung möglich, allerdings muss für jedes eingegangene Ereignis eine Push-Benachrichtigung dargestellt werden. Auf diese Art können Messenger-Apps etwa die eingegangene Nachricht gleich in der lokalen Clientdatenbank hinterlegen, sodass kein erneutes Abrufen beim Öffnen der Anwendung erforderlich ist. Die Schnittstelle ist neben Google Chrome und Microsoft Edge auch in Mozilla Firefox verfügbar, nicht jedoch in Safari und auf den Plattformen iOS und macOS.
Die vorgestellten Mechanismen zur Hintergrundsynchronisation lassen sich mithilfe der DevTools auf Chromium-basierten Browsern wie Google Chrome oder Microsoft Edge gut debuggen. Geöffnet werden sie mit F12. Als besonders hilfreich erweist sich dazu die Application-Registerkarte in den Entwicklertools. Hier ist im Bereich Service Worker zunächst die Service-Worker-Registrierung zu sehen, die für alle Schnittstellen vorausgesetzt wird. Ebenfalls befindet sich dort die Möglichkeit, ein Ereignis für die Background Sync, Periodic Sync oder Push API zu simulieren. Dazu wird in das Textfeld das Tag (Sync) beziehungsweise die Nachricht (Push) eingegeben, für das das jeweilige Ereignis ausgelöst werden soll. Per Klick auf die Schaltfläche neben dem Textfeld wird es direkt ausgelöst.
Per Klick auf den Skriptnamen wechseln die Entwicklertools in das Sources-Tab und öffnen dort direkt den Quelltext der Service-Worker-Implementierung. Hier können, wie Entwickler es von integrierten Entwicklungsumgebungen gewohnt sind, Breakpoints gesetzt, lokale Variablen inspiziert und die Ausführung bei aufgetretenen Fehlern unterbrochen werden.
Im Sources-Tab lassen sich auch die Quelltexte der Webanwendung untersuchen, sodass auch die Registrierung für Synchronisierungsereignisse auf diese Art geprüft werden kann. Schließlich befindet sich im Application-Tab auch der Bereich Background Services. Hier können in den Sichten Background Sync, Background Fetch, Notifications und Push Messaging per Klick auf das Record-Symbol die aufgetretenen Ereignisse für die jeweilige Schnittstellenart aufgezeichnet werden. Das geschieht für bis zu drei Tage und auch dann, wenn die DevTools nicht geöffnet sind. Die aufgetretenen Ereignisse können dann im Protokoll nachverfolgt werden.
Hintergrundereignisse verbessern die PWA-Erfahrung für Anwender noch weiter. Die Schnittstellen eben Cloud-Sync-Clients, Messenger, Nachrichten-Apps und viele weiteren Anwendungsarten den Weg ins Web. Machen Sie Ihre Progressive Web App also noch besser und statten Sie diese um die gezeigten Möglichkeiten zur Hintergrundsynchronisation aus.
URL dieses Artikels:https://www.heise.de/-4691413
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-1-Background-Sync-API-4676538.html[2] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-2-Background-Fetch-API-4681556.html[3] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-3-Periodic-Sync-API-4685964.html
Copyright © 2020 Heise Medien
Im dritten Teil dieser Serie widmen wir uns der Periodic Sync API, der neuesten Schnittstelle zur Umsetzung von Hintergrundsynchronisation für Progressive Web Apps und andere Anwendungen. Diese soll einen wiederkehrenden Datenaustausch ermöglichen.
Mit der Schnittstelle soll im Gegensatz zur Background Sync API [1] und Background Fetch API [2] eine Möglichkeit geschaffen werden, Synchronisierungsereignisse regelmäßig mehr als einmal auslösen zu können. Das Vorgehen eignet sich etwa für Nachrichtenanwendungen, die regelmäßig im Hintergrund die offline vorgehaltenen Artikel aktualisieren wollen. Die Web Periodic Background Sync API [3] setzt auf der Background Sync API aus dem ersten Teil [4] auf. Sie möchte die originale Schnittstelle erweitern und die dort angesprochenen Schwachpunkte adressieren. So ist zur Verwendung der Schnittstelle diesmal zuerst eine Berechtigungsabfrage erforderlich:
FreshRSS const permission = await navigator.permissions.query({
name: 'periodic-background-sync'
});
if (permission.state === 'granted') {
// Periodic Sync API available
} else {
// Periodic Sync API not available
}
Wie die Background Sync API zeigt auch die Periodic Background Sync API keine Information auf der Benutzeroberfläche an, wenn ein Hintergrundvorgang im Gange ist (vergleichbar zu nativen Apps). Wie alle zuvor genannten Ansätze ist auch für diese Schnittstelle zunächst eine Service-Worker-Registrierung erforderlich und Entwickler müssen separat auf das Vorhandensein der Webschnittstelle prüfen. Ist das PeriodicSyncManager-Interface im globalen Window-Objekt vorhanden, steht die API auf dem Zielsystem zur Verfügung. Auf der Service-Worker-Registrierung steht die Instanz des PeriodicSyncManager zur Verfügung. Wenn der Anwender zuvor zugestimmt hat, können sich Entwickler über die Methode register() für ein periodisches Synchronisierungsereignis registrieren:
navigator.serviceWorker.ready.then(async registration => {
if ('PeriodicSyncManager' in window) {
try {
await registration.periodicSync.register('articles', {
minInterval: 24 * 60 * 60 * 1000
});
} catch (error) {
// Periodic background sync cannot be used.
}
}
});
Neben dem verpflichtenden, aus Teil 1 bekannten Bezeichner (im Beispiel articles) lässt sich in einem Konfigurationsobjekt das gewünschte Mindestintervall angeben (im Beispiel ein Ereignis pro Tag). Über das tatsächliche Aufrufintervall entscheidet jedoch der Webbrowser.
In Chromium-basierten Browsern ist die Anwendung zunächst auf dem Gerät zu installieren. Nur in diesem Fall gibt die oben gezeigte Berechtigungsabfrage granted zurück. Ein Abfragefenster erscheint übrigens nicht, da Chrome die Installation der Anwendung als implizite Einwilligung ansieht. Dann hängt die Entscheidung, ob und wie oft eine Website die Schnittstelle nutzen darf, von ihrem Site-Engagement-Score ab. Dieser beträgt zwischen 0 und 100 Punkten, wird durch die Verwendung der Website beeinflusst und lässt sich unter chrome://site-engagement einsehen.
Da Websites im Hintergrund Rechenzeit nutzen können und damit den Akku belasten, ist die Nutzung überhaupt nur Websites gestattet, die regelmäßig genutzt werden, die also einen Site-Engagement-Score größer 0 haben. Je höher er ist, desto öfter dürfen die Ereignisse ausgelöst werden, im Bestfall einmal pro Tag. Wird eine Website irgendwann nicht mehr so oft genutzt, wird auch die Synchronisierung weniger häufig ausgelöst. Ist der Browser schließlich noch der Ansicht, dass Anwender gerade online sind (mit den im ersten Teil beschriebenen Einschränkungen), wird im Service Worker das Ereignis periodicsync ausgelöst. Wie zuvor ist auch hier keine erneute Prüfung der Existenz der Schnittstelle erforderlich, da das Ereignis auf Browsern ohne Unterstützung für die API einfach nicht aufgerufen wird:
self.addEventListener('periodicsync', event => {
if (event.tag === 'articles') {
event.waitUntil(syncArticles());
}
});
Der Service Worker kann dann wieder eine beliebige Synchronisierungslogik durchführen, etwa einen HTTPS-Request auslösen und die empfangenen Daten in den Cache legen oder den erhaltenen Datenstand mit der lokalen IndexedDB-Instanz zusammenführen.
Die Web Periodic Background Synchronization API ist seit Google Chrome 80 verfügbar – auch auf anderen Browsern, die auf die Chromium-Engine aufsetzen, wie Microsoft Edge. Eine Demoanwendung zum Testen der Schnittstelle steht hier [5] zur Verfügung. Dieser Patch [6] zeigt, was zu tun ist, um eine bestehende PWA mit Periodic-Sync-Funktionalität auszustatten. Die Periodic Sync API bietet sich für alle Anwendungen an, deren Zustand sich im Hintergrund regelmäßig ändert: Nachrichten-, ERP- oder Social-Media-Anwendungen. Dank dieser Schnittstellen erhalten Nutzer beim Öffnen der Anwendung immer einen relativ frischen Datenstand. Im nächsten und letzten Teil dieser Serie werden die drei vorgestellten Synchronisationsmechanismen noch einmal kurz zusammengefasst und gezeigt, wie man diese debuggen kann.
URL dieses Artikels:https://www.heise.de/-4685964
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-1-Background-Sync-API-4676538.html[2] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-2-Background-Fetch-API-4681556.html[3] https://wicg.github.io/BackgroundSync/spec/PeriodicBackgroundSync-index.html[4] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-1-Background-Sync-API-4676538.html[5] https://so-pwa.firebaseapp.com/[6] https://github.com/GoogleChromeLabs/so-pwa/pull/11/files
Copyright © 2020 Heise Medien
Die zweite Schnittstelle zur Hintergrundsynchronisation von Daten ist die Background Fetch API. Über sie können selbst größere Datenmengen im Hintergrund übertragen werden. Der Browser zeigt den Fortschritt an und gibt Anwendern damit eine Kontrollmöglichkeit.
Im vergangenen Teil dieser Serie [1] wurde die Background Sync API vorgestellt, die einmalig im Hintergrund einen Synchronisierungsvorgang durchführen darf. Die Synchronisierungslogik lässt sich im Service Worker feingranular steuern. Da die Schnittstelle bei Aktivität jedoch keinen Indikator anzeigt und keiner Freigabe durch den Anwender bedarf, ist sie im Hinblick auf den Datenschutz unter den Browserherstellern umstritten. Die Background Fetch API [2] geht einen anderen Weg: Hier können Entwickler eine Reihe von Netzabfragen definieren, die im Hintergrund ausgeführt werden. Damit können Daten zum Anwendungsserver hoch- und von diesem heruntergeladen werden.
Die Ausführung übernimmt der Browser, der Service Worker wird hierfür zunächst nicht gebraucht. Außerdem wird eine Benutzeroberfläche dargestellt, die Anwendern die Durchführung und den Fortschritt der Aktion verdeutlicht. Die Schnittstelle eignet sich beispielsweise für Streaming-Dienste, die Inhalte offline speichern wollen, Navigations-Apps, die im Hintergrund Kartenmaterial herunterladen oder Cloud-Synchronisierungsdienste.
Die Background Fetch API stellt eine Erweiterung der Service-Worker-Schnittstellen dar. Und auch hier muss zunächst wieder geprüft werden, ob der Zielbrowser die Schnittstelle unterstützt. Ist das BackgroundFetchManager-Interface vorhanden, kann auf dessen Instanz auf der Service-Worker-Registrierung die Methode fetch() aufgerufen werden.
navigator.serviceWorker.ready.then(registration => {
if ('BackgroundFetchManager' in window) {
registration.backgroundFetch.fetch('offline-songs', [
'songs/Katy_Perry/Firework.mp3',
'songs/Hilltop_Hoods/1955.mp3',
'songs/The_Script/Nothing.mp3'
], {
title: 'Songs für Offlinewiedergabe speichern…'
});
}
});
Diese nimmt zunächst eine ID entgegen, anhand derer die Gruppe der Netzwerkabfragen identifiziert werden kann. Als zweites Argument wird die Liste der abzurufenden Ressourcen hinterlegt. Für einfache GET-Requests genügt es, die Zeichenkette der abzufragenden URL zu hinterlegen. Komplexere Abfragen mit Nutzlast lassen sich hier aber ebenfalls hinterlegen. Schließlich kann ein Konfigurationsobjekt angegeben werden, dem etwa der Titel der Aktion für die Anzeige auf der Benutzeroberfläche mitgegeben werden kann. Auch ließen sich hier ein Icon hinterlegen und die Gesamtanzahl herunterzuladender Bytes überschreiben.
Nach Abschluss der Aktion wird das Ereignis backgroundfetchsuccess auf dem Service Worker aufgerufen. Hierfür ist keine Prüfung erforderlich, die Schnittstelle wird auf Browsern ohne Unterstützung schlichtweg nicht aufgerufen. Hier haben Entwickler Zugriff auf die Antworten des Anwendungsservers und können diese verarbeiten: entweder im Service-Worker-Cache oder in der IndexedDB hinterlegen. Da der Service Worker unabhängig von der Webanwendung ausgeführt werden kann, muss diese hierfür nicht geöffnet sein. Im folgenden Beispiel werden die oben angeforderten Songdateien nach erfolgreichem Download im Service-Worker-Cache hinterlegt und stehen dort künftig auch offline zur Verfügung:
self.addEventListener('backgroundfetchsuccess', event => {
event.waitUntil(async () => {
const cache = await caches.open('songs');
const songRecords = await event.registration.matchAll();
const promises = songRecords.map(async songRecord => {
const response = await songRecord.responseReady;
await cache.put(songRecord.request, response);
});
await Promise.all(promises);
event.updateUI({ title: 'Songs heruntergeladen.' });
});
});
Zugriff auf die Einträge erhalten Entwickler über die Eigenschaft registration. Die Oberfläche lässt sich nach Abschluss der Aktion über die Methode updateUI() auf Wunsch noch aktualisieren.
Die Background Fetch API wurde 2018 in Chromium implementiert [3]. Seit Google Chrome 74 ist sie generell verfügbar und auch in anderen Chromium-basierten Browsern wie Microsoft Edge anzutreffen. Von Mozilla Firefox und Apple Safari wird sie derzeit nicht implementiert. Unter backgroundfetch.com [4] kann sie unter Chromium-basierten Browsern auf dem Desktop oder Android interaktiv ausprobiert werden.
Wie die Background Sync API unterstützt Background Fetch nur einen einmaligen Datenaustausch. Nachrichtenanwendungen könnten hingegen regelmäßig im Hintergrund ihre Inhalte aktualisieren wollen, um dem Anwender direkt beim Öffnen eine aktuelle Auswahl von Artikeln präsentieren zu können. Diese Funktionalität möchte die Periodic Background Sync API ins Web bringen. Mehr dazu im nächsten Teil dieser Serie.
URL dieses Artikels:https://www.heise.de/-4681556
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Teil-1-Background-Sync-API-4676538.html[2] https://wicg.github.io/background-fetch/[3] https://developers.google.com/web/updates/2018/12/background-fetch[4] https://backgroundfetch.com
Copyright © 2020 Heise Medien
In dieser Reihe geht es um die Möglichkeit, im Hintergrund Daten zwischen einer Progressive Web App und dem Anwendungsserver auszutauschen – auch dann, wenn die Anwendung gar nicht geöffnet ist. Den Anfang macht die Web Background Synchronization API, die in auf Chromium basierenden Browsern schon seit 2016 funktioniert.
Progressive Web Apps laufen dank dem Service Worker und der IndexedDB offline: Im Cache des Service Worker können die Quelldateien der Anwendung offline gehalten werden, in der lokalen Clientdatenbank die strukturierten Anwenderdaten. Die Background Sync API [1] möchte Progressive Web Apps nun um die Funktionalität ausstatten, Daten auch im Hintergrund mit dem Anwendungsserver auszutauschen. Das Verhalten ist von nativen Anwendungen wie WhatsApp bekannt: Anwender können eine Nachricht verfassen, absenden und das Smartphone wieder wegpacken. Besteht eine Internetverbindung, wird die Nachricht direkt verschickt. Andernfalls wird sie im Hintergrund übermittelt, sobald wieder eine Verbindung zur Verfügung steht. Die App muss dafür nicht noch einmal geöffnet, das Smartphone nicht noch einmal aus der Hosentasche gekramt werden.
Bei der Background Sync API handelt es sich um eine Erweiterung der Service-Worker-Schnittstellen [2], eine der technischen Grundlagen von Progressive Web Apps. Ein Service Worker ist ein Stück JavaScript, das von der Website registriert wird. Das Skript kann anschließend losgelöst von der ursprünglichen Website laufen – also auch dann, wenn die Website gar nicht geöffnet ist. Genau diese Eigenschaft macht man sich bei der Background Sync API zunutze.
Da nicht jeder Browser mit Unterstützung für Service Worker auch die Web Background Sync API unterstützt, müssen Entwickler vor der Verwendung der Schnittstelle sowohl die Existenz der Service-Worker-API als auch die des SyncManager-Interfaces prüfen. Ist es vorhanden, lässt sich innerhalb der Webanwendung über die Service-Worker-Registrierung auf die Instanz des SyncManagers zugreifen. Hier können Synchronisierungsereignisse mit einem bestimmten Bezeichner (Tag) registriert werden. Im Falle des Messenger-Beispiels würde die register()-Methode des SyncManagers nach jeder abgeschickten Nachricht aufgerufen werden:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('./sw.js');
navigator.serviceWorker.ready.then(registration => {
if ('SyncManager' in window) {
registration.sync.register('messages');
}
});
}
Aufseiten des Service-Worker-Skripts implementiert man einen Ereignis-Handler für das von der Background Sync API definierte sync-Ereignis. Bei der Ereignisregistrierung ist übrigens keine Prüfung auf die Existenz der API erforderlich, das Ereignis wird in Browsern ohne Unterstützung für die Web Background Sync API schlichtweg nicht aufgerufen. Bei bestehender Internetverbindung wird der Ereignis-Handler direkt aufgerufen. Andernfalls wird das Auslösen des Ereignisses solange verzögert, bis der Webbrowser der Ansicht ist, dass wieder eine Verbindung besteht. Mit absoluter Sicherheit lässt sich das aber nie sagen: Trotz hervorragender WiFi-Verbindung muss nicht zwingend eine Verbindung zum Internet bestehen (z.B. Drucker-WLANs). Und trotz EDGE-Empfang müssen Pakete nicht zwingend ihr Ziel finden. Ein Restrisiko, dass die Synchronisation dennoch nicht stattfinden kann, bleibt also.
Sollte beim Durchführen der Synchronisationslogik ein Fehler auftreten, kann der Webbrowser den Ereignis-Handler noch mehrmals aufrufen. Beim letzten Versuch ist die Eigenschaft lastChance in den Ereignisargumenten auf true gesetzt. Auf ihnen ist in der Eigenschaft tag der Bezeichner aus der Webanwendung zu finden. Anhand dessen ließen sich unterschiedliche Synchronisierungsabläufe wählen.
self.addEventListener('sync', event => {
if (event.tag == 'messages') {
event.waitUntil(syncMessages());
}
});
Sowohl der Service Worker als auch die Website teilen sich Zugriff auf dieselbe IndexedDB-Instanz. Die Webanwendung kann hochzuladende Inhalte in der Datenbank hinterlegen. Von dort kann der Service Worker diese dann mit dem Backend austauschen und neue oder geänderte Inhalte auf dem Rückweg in der Datenbank hinterlegen.
Da bei jeder Netzabfrage die IP-Adresse übermittelt wird, könnten Entwickler auf diese Art ein begrenztes Bewegungsprofil der Anwender erstellen. Da weder zur Installation des Service Worker noch zur Nutzung der Background Sync API eine vorherige Berechtigungsabfrage geschieht, haben Anwender keine Möglichkeit, diesem entgegenzuwirken. Auch gibt es bei der Schnittstelle keinen visuellen Indikator, dass eine PWA gerade Ereignisse im Hintergrund ausführt.
Derzeit wird die Web Background Sync API lediglich von Google Chrome und darauf basierenden Browsern wie Opera oder Microsoft Edge unterstützt. Es gilt als unwahrscheinlich, dass Apple die Schnittstelle nutzen wird. Auch in Mozilla Firefox wurde die Implementierung der Schnittstelle pausiert. Deswegen und zur Unterstützung älterer Browser müssen Entwickler immer noch einen zweiten Weg innerhalb der Webanwendung [3] implementieren, über den sich die Daten mit dem Anwendungsserver austauschen lassen. Dafür muss die Anwendung dann aber geöffnet sein.
Mit der Background Fetch API und der Periodic Sync API stehen glücklicherweise Alternativen zur Verfügung, die sich möglicherweise ihren Weg in weitere Browser bahnen könnten. Diese stelle ich in den nächsten beiden Teilen dieser Serie vor.
URL dieses Artikels:https://www.heise.de/-4676538
Links in diesem Artikel:[1] https://wicg.github.io/BackgroundSync/spec/[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[3] https://developers.google.com/web/updates/2015/12/background-sync#progressive_enhancement
Copyright © 2020 Heise Medien
Die zweite Schnittstelle zur Hintergrundsynchronisation von Daten ist die Background Fetch API. Über sie können selbst größere Datenmengen im Hintergrund übertragen werden. Der Browser zeigt den Fortschritt an und gibt Anwendern damit eine Kontrollmöglichkeit.
Im vergangenen Teil dieser Serie [1] wurde die Background Sync API vorgestellt, die einmalig im Hintergrund einen Synchronisierungsvorgang durchführen darf. Die Synchronisierungslogik lässt sich im Service Worker feingranular steuern. Da die Schnittstelle bei Aktivität jedoch keinen Indikator anzeigt und keiner Freigabe durch den Anwender bedarf, ist sie im Hinblick auf den Datenschutz unter den Browserherstellern umstritten. Die Background Fetch API [2] geht einen anderen Weg: Hier können Entwickler eine Reihe von Netzabfragen definieren, die im Hintergrund ausgeführt werden. Damit können Daten zum Anwendungsserver hoch- und von diesem heruntergeladen werden.
Die Ausführung übernimmt der Browser, der Service Worker wird hierfür zunächst nicht gebraucht. Außerdem wird eine Benutzeroberfläche dargestellt, die Anwendern die Durchführung und den Fortschritt der Aktion verdeutlicht. Die Schnittstelle eignet sich beispielsweise für Streaming-Dienste, die Inhalte offline speichern wollen, Navigations-Apps, die im Hintergrund Kartenmaterial herunterladen oder Cloud-Synchronisierungsdienste.
Die Background Fetch API stellt eine Erweiterung der Service-Worker-Schnittstellen dar. Und auch hier muss zunächst wieder geprüft werden, ob der Zielbrowser die Schnittstelle unterstützt. Ist das BackgroundFetchManager-Interface vorhanden, kann auf dessen Instanz auf der Service-Worker-Registrierung die Methode fetch() aufgerufen werden.
navigator.serviceWorker.ready.then(registration => {
if ('BackgroundFetchManager' in window) {
registration.backgroundFetch.fetch('offline-songs', [
'songs/Katy_Perry/Firework.mp3',
'songs/Hilltop_Hoods/1955.mp3',
'songs/The_Script/Nothing.mp3'
], {
title: 'Songs für Offlinewiedergabe speichern…'
});
}
});
Diese nimmt zunächst eine ID entgegen, anhand derer die Gruppe der Netzwerkabfragen identifiziert werden kann. Als zweites Argument wird die Liste der abzurufenden Ressourcen hinterlegt. Für einfache GET-Requests genügt es, die Zeichenkette der abzufragenden URL zu hinterlegen. Komplexere Abfragen mit Nutzlast lassen sich hier aber ebenfalls hinterlegen. Schließlich kann ein Konfigurationsobjekt angegeben werden, dem etwa der Titel der Aktion für die Anzeige auf der Benutzeroberfläche mitgegeben werden kann. Auch ließen sich hier ein Icon hinterlegen und die Gesamtanzahl herunterzuladender Bytes überschreiben.
Nach Abschluss der Aktion wird das Ereignis backgroundfetchsuccess auf dem Service Worker aufgerufen. Hierfür ist keine Prüfung erforderlich, die Schnittstelle wird auf Browsern ohne Unterstützung schlichtweg nicht aufgerufen. Hier haben Entwickler Zugriff auf die Antworten des Anwendungsservers und können diese verarbeiten: entweder im Service-Worker-Cache oder in der IndexedDB hinterlegen. Da der Service Worker unabhängig von der Webanwendung ausgeführt werden kann, muss diese hierfür nicht geöffnet sein. Im folgenden Beispiel werden die oben angeforderten Songdateien nach erfolgreichem Download im Service-Worker-Cache hinterlegt und stehen dort künftig auch offline zur Verfügung:
self.addEventListener('backgroundfetchsuccess', event => {
event.waitUntil(async () => {
const cache = await caches.open('songs');
const songRecords = await event.registration.matchAll();
const promises = songRecords.map(async songRecord => {
const response = await songRecord.responseReady;
await cache.put(songRecord.request, response);
});
await Promise.all(promises);
event.updateUI({ title: 'Songs heruntergeladen.' });
});
});
Zugriff auf die Einträge erhalten Entwickler über die Eigenschaft registration. Die Oberfläche lässt sich nach Abschluss der Aktion über die Methode updateUI() auf Wunsch noch aktualisieren.
Die Background Fetch API wurde 2018 in Chromium implementiert [3]. Seit Google Chrome 74 ist sie generell verfügbar und auch in anderen Chromium-basierten Browsern wie Microsoft Edge anzutreffen. Von Mozilla Firefox und Apple Safari wird sie derzeit nicht implementiert. Unter backgroundfetch.com [4] kann sie unter Chromium-basierten Browsern auf dem Desktop oder Android interaktiv ausprobiert werden.
Wie die Background Sync API unterstützt Background Fetch nur einen einmaligen Datenaustausch. Nachrichtenanwendungen könnten hingegen regelmäßig im Hintergrund ihre Inhalte aktualisieren wollen, um dem Anwender direkt beim Öffnen eine aktuelle Auswahl von Artikeln präsentieren zu können. Diese Funktionalität möchte die Periodic Background Sync API ins Web bringen. Mehr dazu im nächsten Teil dieser Serie.
URL dieses Artikels:https://www.heise.de/-4681556
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Background-Sync-API-Teil-1-4676538.html[2] https://wicg.github.io/background-fetch/[3] https://developers.google.com/web/updates/2018/12/background-fetch[4] https://backgroundfetch.com
Copyright © 2020 Heise Medien
Die zweite Schnittstelle zur Hintergrundsynchronisation von Daten ist die Background Fetch API. Über sie können selbst größere Datenmengen im Hintergrund übertragen werden. Der Browser zeigt den Fortschritt an und gibt Anwendern damit eine Kontrollmöglichkeit.
Im vergangenen Teil dieser Serie [1] wurde die Background Sync API vorgestellt, die einmalig im Hintergrund einen Synchronisierungsvorgang durchführen darf. Die Synchronisierungslogik lässt sich im Service Worker feingranular steuern. Da die Schnittstelle bei Aktivität jedoch keinen Indikator anzeigt und keiner Freigabe durch den Anwender bedarf, ist sie im Hinblick auf den Datenschutz unter den Browserherstellern umstritten. Die Background Fetch API [2] geht einen anderen Weg: Hier können Entwickler eine Reihe von Netzabfragen definieren, die im Hintergrund ausgeführt werden. Damit können Daten zum Anwendungsserver hoch- und von diesem heruntergeladen werden.
Die Ausführung übernimmt der Browser, der Service Worker wird hierfür zunächst nicht gebraucht. Außerdem wird eine Benutzeroberfläche dargestellt, die Anwendern die Durchführung und den Fortschritt der Aktion verdeutlicht. Die Schnittstelle eignet sich beispielsweise für Streaming-Dienste, die Inhalte offline speichern wollen, Navigations-Apps, die im Hintergrund Kartenmaterial herunterladen oder Cloud-Synchronisierungsdienste.
Die Background Fetch API stellt eine Erweiterung der Service-Worker-Schnittstellen dar. Und auch hier muss zunächst wieder geprüft werden, ob der Zielbrowser die Schnittstelle unterstützt. Ist das BackgroundFetchManager-Interface vorhanden, kann auf dessen Instanz auf der Service-Worker-Registrierung die Methode fetch() aufgerufen werden.
navigator.serviceWorker.ready.then(registration => {
if ('BackgroundFetchManager' in window) {
registration.backgroundFetch.fetch('offline-songs', [
'songs/Katy_Perry/Firework.mp3',
'songs/Hilltop_Hoods/1955.mp3',
'songs/The_Script/Nothing.mp3'
], {
title: 'Songs für Offlinewiedergabe speichern…'
});
}
});
Diese nimmt zunächst eine ID entgegen, anhand derer die Gruppe der Netzwerkabfragen identifiziert werden kann. Als zweites Argument wird die Liste der abzurufenden Ressourcen hinterlegt. Für einfache GET-Requests genügt es, die Zeichenkette der abzufragenden URL zu hinterlegen. Komplexere Abfragen mit Nutzlast lassen sich hier aber ebenfalls hinterlegen. Schließlich kann ein Konfigurationsobjekt angegeben werden, dem etwa der Titel der Aktion für die Anzeige auf der Benutzeroberfläche mitgegeben werden kann. Auch ließen sich hier ein Icon hinterlegen und die Gesamtanzahl herunterzuladender Bytes überschreiben.
Nach Abschluss der Aktion wird das Ereignis backgroundfetchsuccess auf dem Service Worker aufgerufen. Hierfür ist keine Prüfung erforderlich, die Schnittstelle wird auf Browsern ohne Unterstützung schlichtweg nicht aufgerufen. Hier haben Entwickler Zugriff auf die Antworten des Anwendungsservers und können diese verarbeiten: entweder im Service-Worker-Cache oder in der IndexedDB hinterlegen. Da der Service Worker unabhängig von der Webanwendung ausgeführt werden kann, muss diese hierfür nicht geöffnet sein. Im folgenden Beispiel werden die oben angeforderten Songdateien nach erfolgreichem Download im Service-Worker-Cache hinterlegt und stehen dort künftig auch offline zur Verfügung:
self.addEventListener('backgroundfetchsuccess', event => {
event.waitUntil(async () => {
const cache = await caches.open('songs');
const songRecords = await event.registration.matchAll();
const promises = songRecords.map(async songRecord => {
const response = await songRecord.responseReady;
await cache.put(songRecord.request, response);
});
await Promise.all(promises);
event.updateUI({ title: 'Songs heruntergeladen.' });
});
});
Zugriff auf die Einträge erhalten Entwickler über die Eigenschaft registration. Die Oberfläche lässt sich nach Abschluss der Aktion über die Methode updateUI() auf Wunsch noch aktualisieren.
Die Background Fetch API wurde 2018 in Chromium implementiert [3]. Seit Google Chrome 74 ist sie generell verfügbar und auch in anderen Chromium-basierten Browsern wie Microsoft Edge anzutreffen. Von Mozilla Firefox und Apple Safari wird sie derzeit nicht implementiert. Unter backgroundfetch.com [4] kann sie unter Chromium-basierten Browsern auf dem Desktop oder Android interaktiv ausprobiert werden.
Wie die Background Sync API unterstützt Background Fetch nur einen einmaligen Datenaustausch. Nachrichtenanwendungen könnten hingegen regelmäßig im Hintergrund ihre Inhalte aktualisieren wollen, um dem Anwender direkt beim Öffnen eine aktuelle Auswahl von Artikeln präsentieren zu können. Diese Funktionalität möchte die Periodic Background Sync API ins Web bringen. Mehr dazu im nächsten Teil dieser Serie.
URL dieses Artikels:https://www.heise.de/-4681556
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Hintergrund-Synchronisation-fuer-PWAs-Background-Sync-API-Teil-1-4676538.html[2] https://wicg.github.io/background-fetch/[3] https://developers.google.com/web/updates/2018/12/background-fetch[4] https://backgroundfetch.com
Copyright © 2020 Heise Medien
In dieser Reihe geht es um die Möglichkeit, im Hintergrund Daten zwischen einer Progressive Web App und dem Anwendungsserver auszutauschen – auch dann, wenn die Anwendung gar nicht geöffnet ist. Den Anfang macht die Web Background Synchronization API, die in auf Chromium basierenden Browsern schon seit 2016 funktioniert.
Progressive Web Apps laufen dank dem Service Worker und der IndexedDB offline: Im Cache des Service Worker können die Quelldateien der Anwendung offline gehalten werden, in der lokalen Clientdatenbank die strukturierten Anwenderdaten. Die Background Sync API [1] möchte Progressive Web Apps nun um die Funktionalität ausstatten, Daten auch im Hintergrund mit dem Anwendungsserver auszutauschen. Das Verhalten ist von nativen Anwendungen wie WhatsApp bekannt: Anwender können eine Nachricht verfassen, absenden und das Smartphone wieder wegpacken. Besteht eine Internetverbindung, wird die Nachricht direkt verschickt. Andernfalls wird sie im Hintergrund übermittelt, sobald wieder eine Verbindung zur Verfügung steht. Die App muss dafür nicht noch einmal geöffnet, das Smartphone nicht noch einmal aus der Hosentasche gekramt werden.
Bei der Background Sync API handelt es sich um eine Erweiterung der Service-Worker-Schnittstellen [2], eine der technischen Grundlagen von Progressive Web Apps. Ein Service Worker ist ein Stück JavaScript, das von der Website registriert wird. Das Skript kann anschließend losgelöst von der ursprünglichen Website laufen – also auch dann, wenn die Website gar nicht geöffnet ist. Genau diese Eigenschaft macht man sich bei der Background Sync API zunutze.
Da nicht jeder Browser mit Unterstützung für Service Worker auch die Web Background Sync API unterstützt, müssen Entwickler vor der Verwendung der Schnittstelle sowohl die Existenz der Service-Worker-API als auch die des SyncManager-Interfaces prüfen. Ist es vorhanden, lässt sich innerhalb der Webanwendung über die Service-Worker-Registrierung auf die Instanz des SyncManagers zugreifen. Hier können Synchronisierungsereignisse mit einem bestimmten Bezeichner (Tag) registriert werden. Im Falle des Messenger-Beispiels würde die register()-Methode des SyncManagers nach jeder abgeschickten Nachricht aufgerufen werden:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('./sw.js');
navigator.serviceWorker.ready.then(registration => {
if ('SyncManager' in window) {
registration.sync.register('messages');
}
});
}
Aufseiten des Service-Worker-Skripts implementiert man einen Ereignis-Handler für das von der Background Sync API definierte sync-Ereignis. Bei der Ereignisregistrierung ist übrigens keine Prüfung auf die Existenz der API erforderlich, das Ereignis wird in Browsern ohne Unterstützung für die Web Background Sync API schlichtweg nicht aufgerufen. Bei bestehender Internetverbindung wird der Ereignis-Handler direkt aufgerufen. Andernfalls wird das Auslösen des Ereignisses solange verzögert, bis der Webbrowser der Ansicht ist, dass wieder eine Verbindung besteht. Mit absoluter Sicherheit lässt sich das aber nie sagen: Trotz hervorragender WiFi-Verbindung muss nicht zwingend eine Verbindung zum Internet bestehen (z.B. Drucker-WLANs). Und trotz EDGE-Empfang müssen Pakete nicht zwingend ihr Ziel finden. Ein Restrisiko, dass die Synchronisation dennoch nicht stattfinden kann, bleibt also.
Sollte beim Durchführen der Synchronisationslogik ein Fehler auftreten, kann der Webbrowser den Ereignis-Handler noch mehrmals aufrufen. Beim letzten Versuch ist die Eigenschaft lastChance in den Ereignisargumenten auf true gesetzt. Auf ihnen ist in der Eigenschaft tag der Bezeichner aus der Webanwendung zu finden. Anhand dessen ließen sich unterschiedliche Synchronisierungsabläufe wählen.
self.addEventListener('sync', event => {
if (event.tag == 'messages') {
event.waitUntil(syncMessages());
}
});
Sowohl der Service Worker als auch die Website teilen sich Zugriff auf dieselbe IndexedDB-Instanz. Die Webanwendung kann hochzuladende Inhalte in der Datenbank hinterlegen. Von dort kann der Service Worker diese dann mit dem Backend austauschen und neue oder geänderte Inhalte auf dem Rückweg in der Datenbank hinterlegen.
Da bei jeder Netzabfrage die IP-Adresse übermittelt wird, könnten Entwickler auf diese Art ein begrenztes Bewegungsprofil der Anwender erstellen. Da weder zur Installation des Service Worker noch zur Nutzung der Background Sync API eine vorherige Berechtigungsabfrage geschieht, haben Anwender keine Möglichkeit, diesem entgegenzuwirken. Auch gibt es bei der Schnittstelle keinen visuellen Indikator, dass eine PWA gerade Ereignisse im Hintergrund ausführt.
Derzeit wird die Web Background Sync API lediglich von Google Chrome und darauf basierenden Browsern wie Opera oder Microsoft Edge unterstützt. Es gilt als unwahrscheinlich, dass Apple die Schnittstelle nutzen wird. Auch in Mozilla Firefox wurde die Implementierung der Schnittstelle pausiert. Deswegen und zur Unterstützung älterer Browser müssen Entwickler immer noch einen zweiten Weg innerhalb der Webanwendung [3] implementieren, über den sich die Daten mit dem Anwendungsserver austauschen lassen. Dafür muss die Anwendung dann aber geöffnet sein.
Mit der Background Fetch API und der Periodic Sync API stehen glücklicherweise Alternativen zur Verfügung, die sich möglicherweise ihren Weg in weitere Browser bahnen könnten. Diese stelle ich in den nächsten beiden Teilen dieser Serie vor.
URL dieses Artikels:https://www.heise.de/-4676538
Links in diesem Artikel:[1] https://wicg.github.io/BackgroundSync/spec/[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[3] https://developers.google.com/web/updates/2015/12/background-sync#progressive_enhancement
Copyright © 2020 Heise Medien
In dieser Reihe geht es um die Möglichkeit, im Hintergrund Daten zwischen einer Progressive Web App und dem Anwendungsserver auszutauschen – auch dann, wenn die Anwendung gar nicht geöffnet ist. Den Anfang macht die Web Background Synchronization API, die in auf Chromium basierenden Browsern schon seit 2016 funktioniert.
Progressive Web Apps laufen dank dem Service Worker und der IndexedDB offline: Im Cache des Service Worker können die Quelldateien der Anwendung offline gehalten werden, in der lokalen Clientdatenbank die strukturierten Anwenderdaten. Die Background Sync API [1] möchte Progressive Web Apps nun um die Funktionalität ausstatten, Daten auch im Hintergrund mit dem Anwendungsserver auszutauschen. Das Verhalten ist von nativen Anwendungen wie WhatsApp bekannt: Anwender können eine Nachricht verfassen, absenden und das Smartphone wieder wegpacken. Besteht eine Internetverbindung, wird die Nachricht direkt verschickt. Andernfalls wird sie im Hintergrund übermittelt, sobald wieder eine Verbindung zur Verfügung steht. Die App muss dafür nicht noch einmal geöffnet, das Smartphone nicht noch einmal aus der Hosentasche gekramt werden.
Bei der Background Sync API handelt es sich um eine Erweiterung der Service-Worker-Schnittstellen [2], eine der technischen Grundlagen von Progressive Web Apps. Ein Service Worker ist ein Stück JavaScript, das von der Website registriert wird. Das Skript kann anschließend losgelöst von der ursprünglichen Website laufen – also auch dann, wenn die Website gar nicht geöffnet ist. Genau diese Eigenschaft macht man sich bei der Background Sync API zunutze.
Da nicht jeder Browser mit Unterstützung für Service Worker auch die Web Background Sync API unterstützt, müssen Entwickler vor der Verwendung der Schnittstelle sowohl die Existenz der Service-Worker-API als auch die des SyncManager-Interfaces prüfen. Ist es vorhanden, lässt sich innerhalb der Webanwendung über die Service-Worker-Registrierung auf die Instanz des SyncManagers zugreifen. Hier können Synchronisierungsereignisse mit einem bestimmten Bezeichner (Tag) registriert werden. Im Falle des Messenger-Beispiels würde die register()-Methode des SyncManagers nach jeder abgeschickten Nachricht aufgerufen werden:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('./sw.js');
navigator.serviceWorker.ready.then(registration => {
if ('SyncManager' in window) {
registration.sync.register('messages');
}
});
}
Aufseiten des Service-Worker-Skripts implementiert man einen Ereignis-Handler für das von der Background Sync API definierte sync-Ereignis. Bei der Ereignisregistrierung ist übrigens keine Prüfung auf die Existenz der API erforderlich, das Ereignis wird in Browsern ohne Unterstützung für die Web Background Sync API schlichtweg nicht aufgerufen. Bei bestehender Internetverbindung wird der Ereignis-Handler direkt aufgerufen. Andernfalls wird das Auslösen des Ereignisses solange verzögert, bis der Webbrowser der Ansicht ist, dass wieder eine Verbindung besteht. Mit absoluter Sicherheit lässt sich das aber nie sagen: Trotz hervorragender WiFi-Verbindung muss nicht zwingend eine Verbindung zum Internet bestehen (z.B. Drucker-WLANs). Und trotz EDGE-Empfang müssen Pakete nicht zwingend ihr Ziel finden. Ein Restrisiko, dass die Synchronisation dennoch nicht stattfinden kann, bleibt also.
Sollte beim Durchführen der Synchronisationslogik ein Fehler auftreten, kann der Webbrowser den Ereignis-Handler noch mehrmals aufrufen. Beim letzten Versuch ist die Eigenschaft lastChance in den Ereignisargumenten auf true gesetzt. Auf ihnen ist in der Eigenschaft tag der Bezeichner aus der Webanwendung zu finden. Anhand dessen ließen sich unterschiedliche Synchronisierungsabläufe wählen.
self.addEventListener('sync', event => {
if (event.tag == 'messages') {
event.waitUntil(syncMessages());
}
});
Sowohl der Service Worker als auch die Website teilen sich Zugriff auf dieselbe IndexedDB-Instanz. Die Webanwendung kann hochzuladende Inhalte in der Datenbank hinterlegen. Von dort kann der Service Worker diese dann mit dem Backend austauschen und neue oder geänderte Inhalte auf dem Rückweg in der Datenbank hinterlegen.
Da bei jeder Netzabfrage die IP-Adresse übermittelt wird, könnten Entwickler auf diese Art ein begrenztes Bewegungsprofil der Anwender erstellen. Da weder zur Installation des Service Worker noch zur Nutzung der Background Sync API eine vorherige Berechtigungsabfrage geschieht, haben Anwender keine Möglichkeit, diesem entgegenzuwirken. Auch gibt es bei der Schnittstelle keinen visuellen Indikator, dass eine PWA gerade Ereignisse im Hintergrund ausführt.
Derzeit wird die Web Background Sync API lediglich von Google Chrome und darauf basierenden Browsern wie Opera oder Microsoft Edge unterstützt. Es gilt als unwahrscheinlich, dass Apple die Schnittstelle nutzen wird. Auch in Mozilla Firefox wurde die Implementierung der Schnittstelle pausiert. Deswegen und zur Unterstützung älterer Browser müssen Entwickler immer noch einen zweiten Weg innerhalb der Webanwendung [3] implementieren, über den sich die Daten mit dem Anwendungsserver austauschen lassen. Dafür muss die Anwendung dann aber geöffnet sein.
Mit der Background Fetch API und der Periodic Sync API stehen glücklicherweise Alternativen zur Verfügung, die sich möglicherweise ihren Weg in weitere Browser bahnen könnten. Diese stelle ich in den nächsten beiden Teilen dieser Serie vor.
URL dieses Artikels:https://www.heise.de/-4676538
Links in diesem Artikel:[1] https://wicg.github.io/BackgroundSync/spec/[2] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-2-Die-Macht-des-Service-Worker-3740464.html[3] https://developers.google.com/web/updates/2015/12/background-sync#progressive_enhancement
Copyright © 2020 Heise Medien
Metaphern für Softwareentwicklung gibt es viele. Sie als Spiel zu begreifen, scheint zunächst respektlos. Wenn man tiefer gräbt, ergeben sich aber zahlreiche Parallelen.
Der Begriff "Spiel" steht erst mal für Spaß. Softwareentwicklung ist aber kein Spaß – es geht meistens um ernsthafte Geschäftsziele und oft hohe Budgets. So etwas ist kein Spiel.
Die Spieltheorie [1] ist allerdings eine wissenschaftlich anerkannte Theorie, die sich mit Strategien für Spiele und andere Entscheidungssituationen beschäftigt. Diese Theorie hat viele Anwendungen. Auch Kriege oder Vorgehen in der Wirtschaft werden spieltheoretisch untersucht und so bessere Strategien entwickelt.
Spiele scheinen außerdem trivial zu sein. Schließlich spielen schon Kinder. Aber auch hier liegen bei näherer Betrachtung die Dinge anders. Einige Profis widmen ihr ganzes Leben Spielen wie Schach oder dem asiatischen Spiel Go [2]. Es gibt viel mehr denkbare Go-Stellungen (ca. 10^170) als Atome im Universum (ca. 10^80). Das ist alles andere als trivial.
Softwareentwicklungsprojekte als Spiele zu betrachten, führt zu einigen Erkenntnissen:
Spiele haben Gewinnbedingungen. Jede Aktivität sollte auf die Gewinnbedingungen einzahlen und man muss kollaborieren. Das hilft auch bei Softwareentwicklung.
Vielen Dank an meine Kolleginnen und Kollegen Hanna Prinz, Tobias Erdle und Sonja Scheungrab für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4659442
Links in diesem Artikel:[1] https://de.wikipedia.org/wiki/Spieltheorie[2] https://de.wikipedia.org/wiki/Go_(Spiel)[3] https://www.heise.de/developer/artikel/Ueber-die-optimale-Softwarearchitektur-3785166.html[4] https://de.wikipedia.org/wiki/Pandemie_(Spiel).
Copyright © 2020 Heise Medien
Progressive Web Apps lassen sich auf allen relevanten Plattformen installieren. In manchen Punkten hakt die Integration allerdings noch. So lassen sich aus dem Browser heraus installierte PWAs unter Windows nicht über die Systemsteuerung deinstallieren oder automatisch mit dem Betriebssystem starten. Hier bessert Microsoft nun nach.
Seitdem Microsoft die eigene Entwicklung seiner eigenen Browser-Engine zugunsten von Chromium aufgegeben hat, [1] beteiligt sich das Unternehmen an der Entwicklung des quelloffenen Unterbaus der Webbrowser Google Chrome, Samsung Internet, Brave oder Microsoft Edge. Die Chromium-Kontributoren Google, Microsoft und Intel haben sich darüber hinaus zur Initiative Project Fugu [2] zusammengeschlossen, die Progressive Web Apps leistungsfähiger machen möchte. Als Teil dieser Initiative kümmert sich Microsoft um die Verbesserung der PWA-Integration ins Betriebssystem.
Auf vielen Desktop-Betriebssystemen können Benutzer ihre Anwendungen mit dem Start des Betriebssystems beziehungsweise der Benutzersession direkt ausführen lassen. Unter Windows kennt man diese Funktionalität unter dem Namen Autostart, unter macOS nennt man diese Programme auch Login Items. PWAs sollen bei der Installation vorschlagen können, sich automatisch mit dem System starten zu lassen [3]. Dazu muss die Funktionalität im Web App Manifest [4] angefordert werden. Außerdem ist ein Kontrollkästchen geplant, das Anwender aktivieren müssen, wenn die App in den Autostart gelegt werden soll.
Bei der Installation einer PWA aus dem Browser wird auf Desktop-Systemen eine Verknüpfung in der Programmliste des Betriebssystems hinterlegt. Unter Windows erhalten Anwender im Startmenü per Rechtsklick eine Option zum Deinstallieren von Anwendungen, die zur Liste installierter Programme in der Einstellungen-App führt. In dieser Liste sind PWAs aber noch nicht eingetragen, insofern läuft die Aktion ins Leere. Die Deinstallation funktioniert aktuell etwa nur über das Drei-Punkte-Menü des PWA-Fensters. Microsoft kümmert sich darum [5], dass diese Anwendungen in Zukunft auch aus der Einstellungen-App oder der Systemsteuerung entfernt werden können.
Das Web kann schon heute das Schließen einer Website verhindern, wenn noch offene Aktionen (zum Beispiel ein nicht abgeschicktes Formular oder nicht synchronisierte Änderungen) ausstehen. Die Beschriftung des Dialogs verrät aber nicht, was genau noch offen ist. Produktivitätsanwendungen erlauben Anwendern beim Schließen außerdem oftmals auch eine komplexere Auswahl, etwa das Speichern eines geöffneten Dokuments, das bewusste Verwerfen der Änderungen oder das Abbrechen des Schließvorgangs. Für installierte PWAs möchte Microsoft diese Funktionalität ebenfalls nachreichen [6].
Visual Studio macht es, Spotify macht es, Microsoft Teams macht es auch: Diese Anwendungen erweitern die Titelzeile des Fensters um eigene Steuerelemente, um den verfügbaren Platz effizienter zu nutzen. Auch diese Funktionalität soll installierten Progressive Web Apps bald offenstehen [7]. Die PWA darf sich dabei bis in die Titelzeile erweitern. Nur die Fenstersteuerelemente des Betriebssystems und des Webbrowsers legen sich dann noch über die Anwendung.
Die hier gezeigten Vorschläge verbessern die Benutzererfahrung von Progressive Web Apps besonders auf Desktop-Systemen. An allen Vorschlägen wird derzeit aktiv gearbeitet, ein Zieldatum gibt es derzeit allerdings noch nicht. Die Arbeit von Microsoft zeigt, dass die Lücke zwischen nativen Anwendungen und Progressive Web Apps kontinuierlich schmilzt und Entwickler auch weiterhin einen immer größer werdenden Funktionsumfang erwarten dürfen.
URL dieses Artikels:https://www.heise.de/-4653366
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Analyse-Da-waren-s-nur-noch-drei-4244599.html[2] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[3] https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/RunOnLogin/Explainer.md[4] https://www.heise.de/developer/artikel/Progressive-Web-Apps-Teil-3-Wie-die-Web-App-zur-App-App-wird-3464603.html[5] https://bugs.chromium.org/p/chromium/issues/detail?id=957043[6] https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/CustomDialogOnClose/explainer.md[7] https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/TitleBarCustomization/explainer.md
Copyright © 2020 Heise Medien
Progressive Web Apps sind in aller Munde. Mit der ersten PWAConf will die Community nun alle PWA-Beteiligten in London zusammenbringen. Auf der Bühne stehen Vertreter der Browserhersteller, Mitglieder der Standardisierungsorganisationen und Webentwickler aus der Community.
Die erste Ausgabe der PWAConf findet am Sonntag, den 19. April 2020, im Victoria Park Plaza Hotel in London statt. An einem ganzen Tag voller technischer Sessions wird zusammengefasst, was das Web als Anwendungsplattform schon heute leisten kann, welche Best Practices es zur Entwicklung nativ erscheinender Webanwendungen gibt und welche zukünftigen Features PWA-Entwickler erwarten. Die PWAConf soll Browserhersteller, Mitglieder der Standardisierungsgremien, Webentwickler und weitere PWA-Enthusiasten in den gemeinsamen Austausch bringen.
Das Programm wird von der PWA-Community zusammengestellt, vertreten durch Majid Hajian, Christian Liebel (Thinktecture), Laura Morinigo (Samsung Internet) und Maxim Salnikov (Microsoft). Gastgeber der Veranstaltung ist die International JavaScript Conference, die ihre Infrastruktur freundlicherweise für die Community-Konferenz bereitstellt. Die iJS schließt sich vom 20. bis 22. April 2020 im selben Hotel an. Tickets sind für 89 GBP zzgl. VAT erhältlich. Zehn kostenfreie Diversity-Tickets werden an Teilnehmer unterrepräsentierter Gruppen in der IT vergeben. Weitere Informationen sind unter PWAConf.io [1] zu finden.
URL dieses Artikels:https://www.heise.de/-4653876
Links in diesem Artikel:[1] https://pwaconf.io
Copyright © 2020 Heise Medien
Cross-Platform-Entwickler, die auf Webtechniken setzen, haben die Qual der Wahl: Verpackt man Web-Apps auf altbewährte Weise mit Apache Cordova und GitHub Electron? Oder greift man lieber auf Progressive Web Apps zurück, bei denen das Leben der Anwendung im Browser beginnt?
Optisch unterscheiden sich beide Methoden kaum: Am Ende läuft die eigene Web-App auf Desktopsystemen in einem eigenen Fenster, auf Mobilgeräten vollflächig – wie alle anderen Apps auch. Unterschiede gibt es jedoch in der Art der Verteilung und im Funktionsumfang.
Bei Cordova und Electron wird eine Webanwendung in einem nativen Anwendungsrahmen verpackt. Über ihn lassen sich sämtliche Funktionen und APIs aufrufen, die die jeweilige Plattform zur Verfügung stellt. Insgesamt stehen diese Anwendungen ihren nativen Gegenstücken in nichts nach. Daher können sie auch über alle Vertriebswege verteilt werden, typischerweise App-Stores im mobilen Umfeld oder als Executable für den Desktop.
Problematisch bei diesem Ansatz ist aber, dass nicht nur die Anwendung selbst zu warten ist, sondern auch der Container. Bei Electron sind neben der eigentlichen App darüber hinaus noch Node.js und Chromium Teil des Anwendungsbündels, die regelmäßig aktualisiert werden sollten. Im Falle von Cordova ist festzustellen, dass die bereitgestellten Plug-ins, die Zugriff auf native Funktionen erlauben, zunehmend altern und die Weiterentwicklung oftmals an einer überschaubaren Anzahl an Community-Mitgliedern hängt.
Progressive Web Apps kommen komplett ohne diesen Wrapper aus. Stattdessen beginnt das Leben der Anwendung im Browser, von dort kann sie auf dem jeweiligen Gerät installiert werden. Somit fallen auch keine Kosten für App-Stores an, Verkäufe oder Abogebühren sind ebenfalls nicht mehr zwingend mit dem Plattformanbieter zu teilen. Das heißt aber nicht, dass sich diese Anwendungen nicht später doch wieder in einen Store einstellen lassen. Der Microsoft Store und Google Play nehmen so auch Progressive Web Apps auf.
Allerdings können Progressive Web Apps nicht auf sämtliche nativen Schnittstellen zugreifen, sondern nur auf diejenigen, für die es auch eine Webschnittstelle gibt. Das Web hat in den vergangenen Jahren viele APIs mit nativer Power erhalten, etwa Browserdatenbanken, Zugriff auf Geolocation, Mikrofon und Kamera, doch es bleibt noch ein gewisser Versatz zum kompletten nativen Funktionsumfang. Dank Initiativen wie Project Fugu [1] schwindet dieser Abstand aber zusehends.
Webanwendungen sollten zunächst immer mit dem Ziel entwickelt werden, eine Progressive Web App zu sein. Niemand hindert Entwickler später daran, diese doch noch in einem nativen Anwendungscontainer zu verpacken. Wer zu sehr auf native APIs baut, kann seine Anwendung umgekehrt nicht so einfach als PWA bereitstellen. Nur dann, wenn Entwickler auf eine kritische Funktion stoßen, für die es keine Webschnittstelle gibt oder zwingend ein Executable oder eine Präsenz im Apple App Store gebraucht wird, sollten sie ergänzend oder alternativ auf Wrapper-Ansätze wie Cordova und Electron zurückgreifen.
Ausführlich beleuchten Christian Liebel und Thorsten Hans von Thinktecture dieses Thema am 27. Februar 2020 im Rahmen der BASTA! Spring in Frankfurt [2].
URL dieses Artikels:https://www.heise.de/-4634262
Links in diesem Artikel:[1] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html[2] https://basta.net/web-development/electron-cordova-pwa-was-wann-wie-und-warum/
Copyright © 2020 Heise Medien
Zum Jahreswechsel sprechen wir in richtig großer Runde über 2019 und wagen uns an die Predictions für 2020. Und die Zuschauer/-hörer sind ebenfalls gefragt.
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Pünktlich zum Jahreswechsel ist das Team von c't uplink noch einmal überkomplett: Zwar haben Fabian Scherschel und Hannes Czerulla den Verlag verlassen, aber für unsere Jahresendfolge sind die beiden extra wieder einmal nach Hannover gekommen. Mit ihnen sprechen Merlin Schumacher, Michael Wieczorek, Achim Barczok, Jan-Keno Janssen, Johannes Maurer und Martin Holland diesmal in einer sehr großen Runde über das abgelaufene Jahr. Außerdem wagen wir und unsere Leser uns einmal mehr an Vorhersagen für das beginnende und prüfen die für das abgelaufene Jahr.
Bevor wir nach vorne blicken, sprechen wir aber noch einmal darüber, dass wieder Meldungen über Sicherheitslücken oder Datenabgriffe das Jahr dominiert haben. Außerdem ging es auf heise online und in c't im vergangenen Jahr natürlich um das Vorgehen der US-Regierung gegen Huawei, Hacker, die einfach mal zurück hacken, FIDO2 und Hacking-Gadgets – aber auch ganz analog ums Schlösserknacken. Bevor wir dann einmal mehr versuchen, Vorhersagen für das beginnende Jahr zu treffen, darf jeder noch seinen Lieblingsfilm, seine Lieblingsserie, sein Lieblingsbuch und sein Lieblingsspiel aus 2019 kurz (!) vorstellen.
Diesmal mit dabei: Jan-Keno Janssen, Hannes Czerulla, Achim Barczok, Fabian Scherschel, Merlin Schumacher, Martin Holland, Johannes Börnsen und Michael Wieczorek
Die komplette Episode 30.8 zum Nachhören und Herunterladen:
Bei Problemen mit der Wiedergabe des Videos aktivieren Sie bitte JavaScript
Die c't 2/2020 [8] gibt's am Kiosk, im Browser [9] und in der c't-App [10] für iOS [11] und Android [12].
Alle früheren Episoden unseres Podcasts findet ihr unter www.ct.de/uplink [13].
()
URL dieses Artikels:https://www.heise.de/-4627361
Links in diesem Artikel:[1] https://ct.de/uplink[2] https://www.youtube.com/playlist?list=PLUoWfXKEShjdcawz_wBJVqkv0pVIakmSP[3] https://itunes.apple.com/de/podcast/ct-uplink/id835717958[4] https://itunes.apple.com/de/podcast/ct-uplink-video/id927435923?mt=2[5] https://podcasts.google.com/?feed=aHR0cHM6Ly93d3cuaGVpc2UuZGUvY3QvdXBsaW5rL2N0dXBsaW5rLnJzcw[6] https://blog.ct.de/ctuplink/ctuplink.rss[7] https://blog.ct.de/ctuplink/ctuplinkvideohd.rss[8] https://www.heise.de/select/ct/2020/2[9] https://www.heise.de/select/ct[10] https://www.heise.de/ct/Das-digitale-Abo-1818298.html[11] https://apps.apple.com/de/app/ct-magazin/id380266921[12] https://play.google.com/store/apps/details?id=de.heise.android.ct.magazin[13] http://www.ct.de/uplink[14] mailto:mho@heise.de
Copyright © 2020 Heise Medien
Große komplexe Projekte sind schwer zu handhaben. Software-Release-Trains sind eine Lösung zur Koordination. Aber der Ansatz läuft Selbstorganisation und modernen Management-Konzepten zuwider.
Ein Release Train [1] dient zur Koordination mehrerer abhängiger Projekte. Im Rahmen dessen entwickeln alle Projekte aufeinander abgestimmte Versionen, die Phasen wie Beta-Testing, Release oder Updates gemeinsam durchlaufen. Die Idee hat sich in vielen großen Projekte wie Eclipse, Ubuntu, dem Spring Framework oder LibreOffice bewährt.
Das Scaled Agile Framework (SAFe) schlägt einen Agile Release Train [2] vor, um die Arbeit mehrerer agiler Teams zu koordinieren. Sie haben einen festen Zeitpunkt, zu dem sie liefern, und bieten alle zwei Wochen ein neues Systeminkrement mit einer System-Demo. Der Agile Release Train koordiniert die Entwicklung der Software und dann das Release, nach dem Nutzer die neuen Features verwenden können. Also geht es darum, die Entwicklung eines oder mehrerer größeren Features über mehrere Teams zu koordinieren. Das Ziel ist es, dass nicht nur die einzelnen Teams, sondern auch das gesamte System regelmäßig neue Features ausrollt. So sollen mögliche Probleme bei den größeren Features offenbar werden. Natürlich gibt es für einen Agile Release Train diverse Rollen für eine zentrale Koordination.
Koordination ist für eine Zusammenarbeit immer notwendig, aber es erzeugt auch einen Overhead. Eine zentrale Koordination steht in einem Widerspruch dazu, möglichst viel Verantwortung zu delegieren. Moderne Organisationen sollten möglichst wenig Hierarchien haben und die Teams sollten selbstorganisiert arbeiten, statt auf die zentrale Koordination und ein Command & Control angewiesen zu sein. Ohne eine zentrale Kontrolle skaliert die Organisation außerdem besser.
Übermäßige Koordination ist zwar ein organisatorisches Problem, aber die Ursache kann ein Architektur-Problem sein: Wenn Änderungen, die für einen Kunden einen Wert darstellen, die Koordination mehrerer Teams und Komponenten erfordern, kann ein besserer fachlicher Schnitt die Anzahl der beteiligten Komponenten und damit der Teams reduzieren. Domain-driven Design [3] schlägt dafür einige Maßnahmen vor. Wenn die Koordination in einem Agile Release Train sehr kompliziert ist, dann lohnt es sich auf jeden Fall, einen Blick auf die Architektur zu werfen und zu schauen, ob dort Optimierungspotenziale vorliegen.
Aber auch wenn die Softwarearchitektur perfekt ist, können für ein Feature natürlich Änderungen notwendig sein, die mehrere Teams betreffen. Schließlich arbeiten die Teams gemeinsam an einem System, und Features können daher immer auf mehrere Teams verteilt sein. Dafür schlägt Domain-driven Design auch verschiedene Pattern vor. Bei dem Pattern "Customer/Supplier" (Kunde/Lieferant) kann das Customer-Team bei dem Supplier-Team die Implementierung von Features anfordern. Die Alternative ist "Conformist": Dann muss das Team nehmen, was es bekommt, und kann keine Implementierung von Features anfordern.
Also kann ein DDD-Team auch dann ein Feature implementieren, wenn es dazu auf Zulieferungen angewiesen ist. Dazu müssen lediglich die "Spielregeln" zwischen Teams wie Customer/Supplier festgelegt sein. Natürlich kann es gegebenenfalls notwendig sein, noch eine Eskalationsinstanz für Streitigkeiten zu definieren, aber unter normalen Umständen können die Teams so ohne zentrale Koordination arbeiten und sich untereinander dezentral koordinieren.
Die kollaborative Entwicklung von Features ähnlich wie bei einem Agile Release Train gibt es bei DDD auch. DDD beschreibt es als "Partnership". Nun ist eine Partnerschaft eigentlich positiv besetzt. Die englische Ausgabe der DDD-Referenz [4] nutzt zur Illustration von Partnership ein Drei-Bein-Rennen, also ein Rennen, bei dem die Teilnehmer an einem Bein zusammengefesselt sind. Eine solche Partnerschaft und die damit verbundene enge Koordination führen eher zu einem Problem, so wie es bei einem Agile Release Train auch zu erwarten ist.
Eine enge zentralen Koordination, wie sie Agile Release Trains umsetzen, sollte bei einer guten Softwarearchitektur nicht unbedingt notwendig sein und kann mit anderen Mitteln umgangen werden. Vielleicht ist die wahrgenommene Sicherheit ein Grund dafür, dass Ansätze wie SAFe erfolgreich sind. Durch die Koordination wird eine Kontrolle des Fortschritts auf der Ebene des Gesamtprojekts möglich und notwendig. Das kann eine höhere Sicherheit vermitteln. Zuständigkeiten wirklich an Teams zu delegieren erfordert hingegen ein hohes Maß an Vertrauen.
Release Trains koordinieren die Zusammenarbeit verschiedener Teams. Ansätze aus dem Domain-driven Design hingegen delegieren noch mehr Zuständigkeit in die Teams und benötigen daher weniger Koordination
Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer, Martin Kühl, Torsten Mandry, Sebastian Schwaiger und Benjamin Wolf für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4598765
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/Software_release_train[2] https://www.scaledagileframework.com/agile-release-train/[3] https://ddd-referenz.de/[4] https://domainlanguage.com/ddd/reference/
Copyright © 2019 Heise Medien
Agilität in der Softwareentwicklung wird oft unzureichend umgesetzt und gelebt. Hilft sie trotzdem?
Softwareentwicklung ist kompliziert und komplex. Deswegen führen viele Projekte zu Fehlschlägen. Es ist schon schwer genug festzustellen, ob ein Projekt erfolgreich war oder nicht. Die Ziele sind gegebenenfalls nicht klar definiert, aus politischen Gründen können Fehlschläge zu Erfolgen umdefiniert werden und schließlich gibt es verschiedene Parameter, nach denen Erfolg bewertet werden kann. Subjektiv scheint der Anteil der Projekte, die eines oder mehrere der Projektziele nicht erreichen, durchaus signifikant zu sein.
Eine schon lange etablierte Untersuchung über den Erfolg von Projekten ist der Chaos-Report der Standish Group [1]. Er stellt seit 1994 Erkenntnisse über IT-Projekte zusammen. Er verfügt über eine Datenbasis von über 20 Jahren und über 50.000 Projekten. Die Analysten bewerten die Projekte, sodass die Bewertung als Erfolg oder Misserfolg nicht auf den subjektiven Eindrücken der am Projekt Beteiligten basiert. Der Report aus dem Jahr 2015 ist kostenlos erhältlich. Er zeigt, dass schon seit mehreren Jahren circa 20 Prozent der Projekte Fehlschläge sind. Etwa 40 Prozent haben nicht alle Ziele erreicht und weitere 40 Prozent sind erfolgreich. In Kategorien wie Einhalten des Zeitplans, der Kosten oder der Termine erreichen zwischen 40 und 60 Prozent die Ziele nicht. Laut dem Report reduziert Agilität diese Zahlen erheblich, teilweise auf die Hälfte.
Diese Zahlen kann man sicherlich kritisieren: Erfolg ist kaum objektivierbar. Lange hat der Chaos-Report als Erfolgskriterien Budget, Scope und Zeit definiert. Agile Projekte können aber vorab keinen vollständigen Scope definieren, sondern planen nur das nächste Inkrement. Also können echte agile Projekte einen Scope nicht erfolgreich einhalten, weil er am Anfang des Projekts unbekannt ist. Das wirft die Frage auf, wie sich die Einhaltung des Scopes dann überhaupt bewerten lässt, wenn die Projekte tatsächlich agil sind.
Wegen dieser Widersprüche kann es gut sein, dass die "agilen" Projekte aus dem Chaos-Report zwar einige Praktiken umsetzen, aber nicht alle. Aber auch aus anderen Gründen sind Zweifel daran angebracht, ob die "agilen" Projekte wirklich agil sind. So gibt es viele Missverständnisse [2] in diesem Bereich. Viele Projekte nennen sich agil, obwohl sie in Wirklichkeit teilweise fundamentale Konzepte nicht umsetzen. Die agilen Projekte aus dem Chaos-Report sind also wahrscheinlich eher Projekte, die eine "kaputte" Version von Agilität umsetzen. Positiv ausgedrückt: Sie haben angefangen, Agilität zu adaptieren, aber haben noch lange nicht alles Wichtige umgesetzt. Da Agilität ein kontinuierlicher Verbesserungsprozess sein sollte, ist die Adaption von Agilität eigentlich nie vollständig abgeschlossen, aber auch dieser wichtige Aspekt wird oft nicht befolgt.
Wenn es tatsächlich so sein sollte, dass die "kaputte" Umsetzung agiler Mechanismen bereits erhebliche Verbesserungen bei den Projektergebnissen ergibt, dann ist dieser Weg wirtschaftlich auf jeden Fall sinnvoll. Man könnte sogar die Frage stellen, welchen weiteren wirtschaftlichen Vorteil die vollständige und korrekte Umsetzung von Agilität ergibt. Für solche wirtschaftlichen Vorteile gibt es aber durchaus gute Indizien [3]. Aber die Umsetzung vollständiger Agilität – und vor allem der agilen Werte – könnte aufwendig sein, ohne dass es dafür einen entsprechenden wirtschaftlichen Vorteil gibt. Dann könnten die teilweise sehr schlecht umgesetzten agilen Prozessen bezüglich der Kosten-Nutzen-Abwägung wirtschaftlich nahezu optimal sein, weil sie relativ leicht zu erreichen sind und bereits erhebliche Vorteile bieten.
Um es mit Voltaire zu sagen: Das Bessere – also "echte" Agilität – ist eben der Feind des Guten – also "kaputte" Agilität. Man wird also eine weitere Verbesserung nur erreichen, wenn man sich nicht mit etwas zufrieden gibt, das bereits ausreichend gut ist. In der Folge könnten kaputte agile Prozesse ein Dauerzustand werden. Das mag zwar wirtschaftlich sinnvoll sein. Aber es sind nur bedingt positive Aussichten, weil "kaputte" Prozesse demotivieren und oft gerade Werte und Kultur leiden – und darunter leiden dann oft auch Menschen. Hoffen wir also, dass es nicht so ist.
Wenn "kaputte" Agilität schon deutliche Vorteile bringt, erklärt das, warum die Prozesse oft kaputt sind und warum sie nicht noch weiter verbessert werden.
Vielen Dank an meine Kolleginnen und Kollegen Anja Kammer, Martin Kühl und Hanna Prinz für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels:https://www.heise.de/-4599441
Links in diesem Artikel:[1] https://www.standishgroup.com/[2] https://www.heise.de/developer/artikel/Die-Perversion-agiler-Metaphern-4466436.html[3] https://www.heise.de/developer/artikel/Das-Problem-mit-der-Agilitaet-4140080.html
Copyright © 2019 Heise Medien
rel=self feed redirections when WebSub is disabled #2659
Bei der c't startet Weihnachten dieses Jahr schon im November – mit Geschenketipps der Redaktion für alle Lebenslagen und kleine wie große Geldbeutel.
Den Geschenkemarathon schon im November zu starten, ist aus unserer Sicht eine gute Idee: Kaum ein Geschenk ist ausverkauft, die Schlangen in den Geschäften sind kurz und in der Packstation ist noch genug Platz. Wenn alle Geschenke Anfang Dezember bereitliegen, können Sie die anschließende Adventszeit ohne Stress bei einem Glas Glühwein und mit gutem Gewissen genießen.
50 Redakteurinnen und Redakteure der c't haben ihre persönlichen Favoriten für Geschenke aus dem laufenden Jahr zusammengetragen. Dabei ist Originelles, Lustiges und Nützliches für jeden Geldbeutel zusammengekommen: Die Spanne reicht bei den Geschenkideen von unter 10 bis über 500 Euro.
Für eine bessere Übersicht haben wir unsere Geschenkvorschläge in fünf Kategorien unterteilt. In "Safer Christmas" [1] finden Sie alles, was Ihre Daten oder Ihr Zuhause sicherer macht, vom verschlüsselten Speicherstick bis zum Kellerschloss mit Fingerabdrucksensor.
Bei den Sachen für die Kindsköpfe [2] haben wir alles gesammelt, was Kindern und Kindgebliebenen Spaß macht, beispielsweise ein VR_Headset zum Selberbasteln für die Nintendo Switch oder programmierbare Roboter von Lego. Bei "Schöner arbeiten" [3] finden Sie Nützliches fürs Homeoffice, unter anderem mit ausgefallenen Tipps für eine mobile Bluetooth-Tastatur und eine handschonende Maus.
Geschenkideen für Feld, Wald und Flur gibt es in der Abteilung "Draußen im Walde ..." [4]. Dort finden Sie Geschenkideen wie einen Rucksack mit großem LED-Panel oder kabellose In-Ears, die richtig was taugen.
Ideen fürs intelligente Zuhause gibt es zu guter Letzt bei der "Smarten Weihnacht" [5]. Ihre Lieben können Sie mit stylishen Lautsprechern überraschen oder einem fleißigen Roboter, der die Wohnung nicht nur saugt, sondern gleich noch nass wischt.
URL dieses Artikels:https://www.heise.de/-4583006
Links in diesem Artikel:[1] https://www.heise.de/ct/ausgabe/2019-24-Sechs-Tipps-fuer-eine-sichere-Weihnacht-4574100.html[2] https://www.heise.de/ct/ausgabe/2019-24-Sechs-Tipps-fuer-Kinder-und-Junggebliebene-4574081.html[3] https://www.heise.de/ct/ausgabe/2019-24-Sechs-Tipps-fuers-festliche-Homeoffice-4574075.html[4] https://www.heise.de/ct/ausgabe/2019-24-Sechs-Tipps-fuers-offene-Gelaende-4574059.html[5] https://www.heise.de/ct/ausgabe/2019-24-Sechs-Tipps-fuer-Smart-Home-Freunde-4574038.html
Copyright © 2019 Heise Medien
SameSite=Lax #2630
Rechtzeitig zu Halloween erschienen ist das First-Person-Horror-Game The Beast Inside. Der Gruselspaß mit spannender Story und düsterer Atmosphäre ist allerdings nichts für schwache Nerven.
Als der Kryptoanalytiker Adam und seine Frau Ende der 1970er Jahre aus der Großstadt aufs Land ziehen, wirkt alles noch recht idyllisch. Das Haus steht mitten in der Natur, ist umgeben von Bäumen und Bächen und liegt weitab der Zivilisation. Alles in allem also ein friedlicher Ort. Doch natürlich ist längst nicht alles so, wie es scheint.
Auf der Suche nach Farbe stößt Adam auf das mysteriöse Tagebuch von Nicolas Hyde, der das Haus früher bewohnte. Das ist dann auch der Auftakt zu einem Alptraum. Versetzt ins 19. Jahrhundert spielt man nun aus der Sicht des Tagebuchautors. Auf der Suche nach dessen Familie begegnen diesem seltsame, gefährliche Kreaturen.
Das Spiel The Beast Inside des polnischen Studios Illusion Ray ist nichts für schwache Nerven. Mit dem Sprung in die Vergangenheit ändert sich die Atmosphäre schlagartig. Im Gegensatz zur ruhigen und einladenden Umgebung des Jahres 1979 wirkt das Jahr 1864 sehr düster. In der First-Person-Perspektive läuft man nun durchs Spiel, löst Rätsel und sammelt und verschiebt Gegenstände, um voran zu kommen. Doch kaum versucht man, das Haus mit Kerzen zu beleuchten, tauchen erste ungeladene Gäste auf. Das ist der Startschuss für eine ganze Reihe an Schreckmomenten, die noch folgen werden.
Das Horror-Spiel The Beast Inside punktet mit einer fesselnden Story, aber auch mit vielen Interaktionsmöglichkeiten. Besonders die Ausarbeitung der Gegenstände ist gelungen. Man kann mit fast jedem Gegenstand interagieren, man kann vieles werfen, beiseiteschieben oder anheben. Die Art, wie man mit den Dingen umgeht, beeinflusst dabei auch das Spielgeschehen. Beeindruckend ist die mit Hilfe von Photogrammetrie erschaffene, sehr detailreiche Grafik des Spiels.
Die düstere Atmosphäre und die häufigen Schreckmomente machen The Beast Inside zu einem wunderbar grusligen Spiel. Aktuell gibt es das Horror-Game The Beast Inside für 20,99 Euro auf Steam [3].
()
URL dieses Artikels:http://www.heise.de/-4576718
Links in diesem Artikel:[1] [2] [3] https://store.steampowered.com/app/792300/The_Beast_Inside/[4] mailto:lmd@heise.de
Copyright © 2019 Heise Medien
