seltsames Verhalten mit cache.manifest / offline-Nutzung der web-app gespeichert, um home-Bildschirm auf dem ipad ios6

Ich gerade entdeckt, einige seltsame Verhaltensweisen auf dem iPad mit der neuen iOS 6. Ich Teste eine web-app für die offline-Nutzung. Die web-app ist nicht mehr als eine statische Webseite mit einer cache-manifest-Datei, so dass keine speziellen frameworks wie sencha touch oder tools wie phnoegap verwendet werden. Einfach nur HTML, CSS und JavaScript und einem cache.manifest.

Die App arbeitete fein vor: ich konnte speichern der website auf dem home-Bildschirm. Als ich Sie öffnete von dort aus die Daten heruntergeladen werden, die Zwischenspeicherung. Am Ende des download-pop-up kommen würde, zu Fragen, wenn ich wollte, um die cache von 50 MB – akzeptiert – alles war in Ordnung – eine offline-Nutzung gearbeitet.

Nun nach dem update auf iOS 6:
Ich habe ein paar änderungen an der app. Deinstallieren Sie die app aus dem home-Bildschirm. Öffnete Sie wieder im mobile safari. Gespeichert zum home-Bildschirm". Beim öffnen startet der download, wie soll. Aber dann friert bei 99%. Wenn ich sehe in der Konsole, erhalte ich die Fehlermeldung:
"Application Cache-update fehlgeschlagen ist, weil der Größe quota wurde überschritten".

Und hier kommt das seltsame: Wenn ich es öffnen im browser, der den download startet und am Ende habe ich gefragt, ob ich erhöhen wollen-cache-Größe auf 50 MB. Ich bestätige natürlich. Wenn ich nun suchen Sie in den Einstellungen von safari unter "website-Daten", sehe ich, dass alle zwischengespeicherten Daten für diese app ist über 33MB!! So gar nicht mehr als 50MB!

Ist das ein bug von iOS6? Hat jemand Erfahrung, Probleme beim Zwischenspeichern von Daten, die beim speichern einer Webseite auf dem home-Bildschirm seit dem update auf iOS 6? Thx für jede Hilfe, wie ich wirklich bin hier hängengeblieben... Konnte nicht finden, alles, was hilfreich auf dem web...

(Leider kann ich nicht posten Sie den link auf die web-app und/oder Dateien).

EDIT:

Fand ich einige weitere Informationen zu diesem Thema:

http://www.nsbasic.com/blog/?p=928

Anscheinend wep-apps gespeichert auf dem home-Bildschirm sind jetzt behandeln wie native apps, was bedeutet, dass jede Instanz der gleichen web-app gespeichert werden, um den home-Bildschirm kommt, ist es eigene "storage " sandbox". So werden die Daten unabhängig von den Daten gespeichert im mobile Safari. Dies bedeutet, wenn Sie löschen Sie alle von mobile safari die website-Daten, hat dies keine Auswirkung auf die web-app gespeichert werden, um den home-Bildschirm (vorher ios6 Sie teilten die gleichen Daten).

Ich auch gefunden:

iOS 6 bricht GeoLocation in webapps (apple-mobile-web-app-fähig)

Obwohl Sie nicht genau das gleiche Thema, es könnten verwandt sein. Offenbar web-apps gespeichert werden, um den home-Bildschirm mit

<meta content="yes" name="apple-mobile-web-app-capable" />

pflegt, kann sich nicht auf geo-location. Geo-Position funktioniert nur, wenn Sie entfernen Sie diesen meta-tag aus Ihrer web-app. Vielleicht ist das auch ein workaround für das caching-problem, ich konnte es noch nicht testen. Aber dann wieder: Vielleicht ist der cache.manifestieren ist nicht mehr erforderlich, wenn die web-apps gespeichert werden, um home-Bildschirm behandelt werden, mehr wie native apps? Ich werde mich hier wieder melden wenn ich mehr erfahren.

EDIT2:

Ok, nach einigen Tests und keine nützliche Hinweise aus weder das web-noch apple, fand ich heraus, wenigstens etwas: Wenn ich entfernen

<meta content="yes" name="apple-mobile-web-app-capable" />

aus der Website alles funktioniert natürlich gut, weil es ist einfach so öffnen Sie Safari und dort hatte ich kein problem bisher. Also mein Interesse ist es zu schaffen, ohne den browser Google chrome. Wie oben beschrieben, das caching geht nur bis 99% und dann bekomme ich die cache-Größe quota-überschreitung Fehler. Dann habe ich einfach geschlossen das home-screen-app und öffnete Sie wieder. Jetzt das caching von downloads erneut starten und komplett Prima! Kein einfrieren, kein Fehler! Und alles lokal gespeichert. Ich konnte nur testen Sie es auf der iPad-simulator heute, aber ich hoffe, ich kann dies bestätigen, sobald ich meine Hände bekommen auf unserem Gerät später.

So, wie es scheint, anstatt Sie gefragt, ob Sie möchten, erhöhen Sie die cache-Größe erhalten Sie die cache-Größe quota-überschreitung Fehler. Vielleicht, weil die Speicherung der Daten für home-Bildschirm apps-jetzt wird anders behandelt, Sie nicht haben, um manuell erhöhen Sie die cache-Größe nicht mehr (das ist natürlich Reine Spekulation). Immer, wenn dies der Fall war, sollte es keine Fehler. Also anstatt gefragt zu werden, Cachegröße erhöhen, öffnen Sie den home-Bildschirm app zweimal, das ist eine ziemlich lahme workaround btw...

EDIT3:

Ich nur bestätigen konnte dieses Verhalten auf einem realen Gerät gespeichert, um home-Bildschirm -> geöffnet vom home-Bildschirm -> download-zu-Cache-Dateien -> cache-Größe quota-überschreitung Fehler am Ende -> schließen-home-Bildschirm-app (drücken Sie home-Taste) -> öffnen Sie es erneut, wieder -> zu werden, die Cache-Dateien erneut herunterladen -> dieses mal ohne Fehler -> alles offline benutzbar.

Habe ich auch getestet, die es auf einem Gerät mit iOS 5 und es funktioniert wie erwartet ohne Fehler. Also das ist definitiv ein iOS 6 Problem.

Kann sonst jemand bestätigen dieses Verhalten oder bug?

EDIT4:

Ich gelegentlich die chance hatte, dies zu testen, unter iOS 6.1.3 – leider immer noch das gleiche Verhalten...

  • Ich kann nicht bestätigen, den Fehler für mich wird es wie erwartet funktioniert, aber erklären kann ich die 50 MB-Grenze. Safari hat Grenzen. Der Standard unter iOS 5 war 10MB, dann die nächste, eine war 25 MB und die nächsten 50 MB. Also, wenn Sie Ihre app ist weniger als 10 MB, keine Fragen gestellt. Wenn es 15 MB er gefragt wurde, an increaes das limit auf die nächste Ebene (25MB) und daher, wenn es 33, die nächste Stufe ist 50 MB, so werden Sie direkt gefragt, für diese 50 MB Grenze. Auf iOS 6 habe ich irgendwo gelesen, dass nun die erste Ebene ist 25 MB.
InformationsquelleAutor TimG | 2012-09-27
Schreibe einen Kommentar