Homepage von Basti1012 = ,Hauptmenü
Hier im Forum bekommt ihr bei euren fragen schnelle hilfe.Hier geht es rund um das Web SeitenProgrammieren.Alles rund ums Javascript,Html,Php,Css und Sql.Auf fast allen Fragen haben wir eine Antwort.
Der Soforthilfe-chat verspricht das ,was sein Name sagt. Hier sind Leute Online die sofort ihre hilfe anbieten.Seht in der OnlineListe nach und wenn einer Online ist werdet ihr auch antwort bekommen. Admine ,Moderatoren und Helfer sind unsere Spezialisten in Sachen Web Programierung


PWAs auf iPhones waren schon immer schwierig und werden jetzt noch schwieriger umzusetzen. (Foto: Shutterstock)

Es klingt erstmal gut. Apples neuer Safari blockiert alle Dritt-Cookies konsequent. Aber, das ist nicht die ganze Wahrheit.

Apple hat sich in der Vergangenheit stets als Unternehmen positioniert, dass sich der Privatsphäre seiner Nutzer in besonderer Weise verpflichtet fühlt. Wer kennt nicht die jüngere Werbung, die versichert, dass alles, was auf einem iPhone passiert, auch auf dem iPhone bleibt?

Ebenso hat Apple schon seit Jahren die sogenannte Intelligent Tracking Protection in Betrieb, die eigentlich die Aufgabe hat, Cross-Site-Tracking über den Safari-Browser zu unterbinden. Das wird allgemein als positiv wahrgenommen und wurde mit der Ankündigung der vollständigen Cookie-Blockade nochmal verstärkt.

Aber, wie es so ist mit dem Framing, man kann Begriffe auch so definieren, dass sie nebenbei einer anderen Agenda zu dienen vermögen. So wissen wir seit geraumer Zeit, dass PWA, also progressive Web-Apps, Apple ein Dorn im Auge sind.

Das ist aus Unternehmenssicht verständlich. Immerhin lebt Apple in steigendem Maße von Einnahmen aus seinem App-Store. Der wiederum beinhaltet native Apps, die auf den Geräten der Apple-Kunden installiert werden. Viele dieser Apps könnten auch als PWA funktionieren, also als per HTML, Javascript und CSS umgesetzte Web-App. Sie müssten nicht installiert werden, stünden stets in der aktuellsten Version zur Verfügung und würden keinen Speicherplatz auf dem Gerät belegen.

Zur allgemeinen Sinnhaftigkeit einer PWA im Vergleich zu einer nativen App haben wir uns bereits geäußert. Mit dem Zustand der PWA-Entwicklung im Jahr 2020 haben wir uns ebenfalls bereits beschäftigt.

Progressive Web Apps: Zusammenstellung unter PWA Rocks

Apple führt Zwangslöschung für lokal beschreibbare Speicherfunktionen ein

Damit eine PWA vollwertig funktionieren kann, muss sie Zugriff auf die Geräte-APIs, sowie einige andere technische Strukturen wie Indexed DB, LocalStorage, Media-Keys, SessionStorage oder Service Workers haben. Nicht jede PWA braucht dabei Zugriff auf alle eben genannten Features, aber ohne alle dieser Features funktioniert keine PWA.

Mit dem jüngsten Update des Safari-Browsers führt Apple einen 7-Tage-Löschrhythmus für genau diese Funktionen ein. Nutzt eine PWA etwa LocalStorage zur Datenablage, zum Beispiel für eine einfache Listen-App, so stehen die darin gespeicherten Daten nur noch für sieben Tage zur Verfügung, bevor sie der Apple-Löschroutine zum Opfer fallen. Ebenso verhält es sich mit den anderen eben genannten script-beschreibbaren Funktionen. Dabei gilt der Fristbeginn als letzter Zeitpunkt, an dem ein Nutzer die Website benutzt hat und kann so natürlich durch rege Nutzung stetig nach vorne geschoben werden.

Das bestätigt Apple im Beitrag ?Full Third-Party Cookie Blocking and More? unter dem Zusatz ?and More? und hofft dabei möglicherweise, dass es nicht so sehr auffällt. Immerhin klingt der Titel ansonsten überaus zustimmungswürdig.

Apple beschwichtigt: Homescreen-Web-Apps nicht betroffen

In einem weiteren Absatz versucht Apple klarzustellen, dass Web-Apps, die Nutzer zu ihrem Homescreen hinzugefügt haben, nicht in gleicher Weise von dieser 7-Tage-Regel betroffen sein sollen. Damit meint Apple natürlich die PWA, die der Konzern konsequent lieber als ?Home Screen Web Apps? oder ?HTML5 Apps? bezeichnet.

Wie PWA nun aber betroffen sind, lässt Apple offen und orakelt stattdessen, dass Websites auf Homescreens nicht Teil von Safari seien und insofern ihre eigenen Lösch-Timer hätten, die wiederum von der konkreten Nutzung dieser Web-App abhängig wären. Man ginge nicht davon aus, dass es zu Löschungen bei solchen Apps käme und sei es doch der Fall, sollten sich die Entwickler an Apple wenden, denn das würde als ?ernster Fehler? betrachtet.

Ohne Schwurbelei: Apple lehnt das Konzept der PWA ab

Dem PWA-Entwickler nutzt diese blumige Umschreibung nichts. Hier wären klare Aussagen wertvoller gewesen. Ein weiteres Problem, neben der Unsicherheit, was nun mit den ?Home Screen Web Apps? nach X Tagen passiert, stellt der Fokus darauf dar, dass es sich um ?Home Screen Web Apps? handeln muss, um eine gewisse, wenn auch unklare Verschonung von Apples rigidem Lösch-Regime für sich erwarten zu dürfen.

Immerhin definiert sich eine PWA nicht dadurch, dass sie irgendwer auf seinem Homescreen ablegt. Sie definiert sich vielmehr technisch durch ganz andere Features. Am Ende all dessen kann sich der Nutzer entscheiden, eine PWA auch auf seinem Homescreen abzulegen, muss es aber nicht. Tut er es künftig unter Safari weiterhin nicht, wird er in jedem Fall mit der 7-Tage-Löschung konfrontiert. Das bringt PWA-Entwickler wie Andre Garzia zu Recht auf.

Garzia sieht darin ? und in der Beschränkung aller Browser unter iOS auf die Webkit-Engine ? den transparenten Wunsch Apples, Entwickler ins System nativer Apps und damit den eigenen App-Store zu zwingen. Man kann es ihm nicht verdenken?

Passend dazu:



PHP WTF #9

html_entity_decode verwandelt bekanntlicherweise Entities wie ü oder & in ihre Pendandts ü / &.

var_dump(html_entity_decode("&")); //string(1) "&"

Soviel also dazu, soweit erwartungsgemäß. Enter the weirdness:

<meta charset="utf8">
<?php
var_dump(trim(html_entity_decode(" "))); //string(2) " "

Das Manual sagt dazu:

Sie wundern sich vielleicht, warum trim(html_entity_decode(‚ ‚)); den String nicht zu einem leeren Sting reduziert. Der Grund dafür ist, dass ‚ ‚ in der Standard-Kodierung nicht dem Zeichen mit ASCII-Code 32 entspricht (dieses wird von trim() entfernt), sondern dem Zeichen mit ASCII-Code 160 (0xa0).

Genaugenommen verhält sich hier PHP vollkommen korrekt, denn ein Non-Breaking-Space entspricht eben dem ASCII-Code 160. Und der wird leider nicht von trim in der Standardkonfiguration entfernt (siehe 2. Parameter). Auf Stackoverflow wurde das auch diskutiert und zu solch barbarischen Methoden wie str_replace geraten.

Umwetter Warnumgen und Wetter vorschau