Hallo zusammen,
vor kurzem bin ich über den
... wenn da nicht die "related items" wären: Meine App speichert manchmal Zusatzinformationen in gesonderten Dateien (gleicher Name, andere Erweiterung), ähnlich wie z. B. Subtitles zu Videostreams. Deren Ursprung liegt schon > 10 Jahre zurück und hat mir schon viel "Freude" bereitet: Schliesslich müssen z. B. alle o. g. Datei-Operationen wie Rename, Copy, Delete, ... auf diese Extra-Dateien achten. Oder der Umzug in den Mac App Store war erst möglich als Apple eine Erweiterung der Sandbox auf diese "related items" offiziell unterstützte. Auch im Finder sieht es ziemlich blöd aus, da sich die Dateienanzahl potentiell verdoppelt (und die Benutzer mit der Hälfte nichts anfangen können).
Alles doof und nun auch das noch: Der UIDocumentBrowserViewController setzt (natürlich) auf UIDocuments auf, und diese sollten entweder eine (!) Datei oder einen File-Wrapper schreiben. Zumindest nach meinem Verständnis, eine Frage in Apple's Developer Forum ist noch ohne Resonanz. Also aus der Traum, oder?
Wenn da nicht vor ein paar Tagen @MCDans Problem mit den Resource-Forks gewesen wäre: Gestern, bei der Diskussion der o. g. Problematik mit meinem Sohn schoss mir der Gedanke "extended attributes" durch den Kopf und das ganze Problem löste sich in Wohlgefallen auf: Ich nutze einfach - statt einer extra Datei - ein solches erweitertes Attribut. Aus Sicht der Anwendung gibt es nur eine Datei, das Filesystem bleibt clean und der Weg ist frei zur Nutzung des UIDocumentBrowserViewController. Nun muss ich mir nur noch etwas Gedanken über vernünftige Verfahren zur Migration machen, um die alten Dateien mit Meta-Daten möglichst elegant abzulösen. Im Moment denke ich unter iOS an einen Migrations-Job, der die Documents-Struktur durchläuft und unter macOS an eine "weiche" Migration, indem neu gespeicherte Dateien die Meta-Daten nur noch in den Dateiattributen sichern.
Sorry, das musste einfach von der Seele, ich bin so happy Schade, dass ich nicht schon vor 10 Jahren auf diese Idee kam, aber das nennt man wohl "lernen"...
Um noch schnell die Kurve zu einem interaktiven Forums-Beitrag zu bekommen: Setzt jemand von Euch schon UIDocumentBrowserViewController ein? Gibt es spezielle Dos und Don'ts ... oder auch nur etwas mehr Dokumentation (neben den WWDC Videos)?
Mattes
vor kurzem bin ich über den
UIDocumentBrowserViewController
gestolpert und war sehr angetan: Habe ich doch eine App, in der ich die UI für File-Browsing und Datei-Operationen selber entwickelt habe, und deren Deployment Target wurde gerade auf iOS 11 geändert. Gefühlt könnte ich 70% meines Codes inkl. iCloud-Drive-Integration ersetzen, würde dazu noch weitere Cloud-Storages unterstützen können (Dropbox hatte ich bei der damaligen API-Umstellung aufgegeben) und ein Standard-Interface nutzen. Klingt doch super...... wenn da nicht die "related items" wären: Meine App speichert manchmal Zusatzinformationen in gesonderten Dateien (gleicher Name, andere Erweiterung), ähnlich wie z. B. Subtitles zu Videostreams. Deren Ursprung liegt schon > 10 Jahre zurück und hat mir schon viel "Freude" bereitet: Schliesslich müssen z. B. alle o. g. Datei-Operationen wie Rename, Copy, Delete, ... auf diese Extra-Dateien achten. Oder der Umzug in den Mac App Store war erst möglich als Apple eine Erweiterung der Sandbox auf diese "related items" offiziell unterstützte. Auch im Finder sieht es ziemlich blöd aus, da sich die Dateienanzahl potentiell verdoppelt (und die Benutzer mit der Hälfte nichts anfangen können).
Alles doof und nun auch das noch: Der UIDocumentBrowserViewController setzt (natürlich) auf UIDocuments auf, und diese sollten entweder eine (!) Datei oder einen File-Wrapper schreiben. Zumindest nach meinem Verständnis, eine Frage in Apple's Developer Forum ist noch ohne Resonanz. Also aus der Traum, oder?
Wenn da nicht vor ein paar Tagen @MCDans Problem mit den Resource-Forks gewesen wäre: Gestern, bei der Diskussion der o. g. Problematik mit meinem Sohn schoss mir der Gedanke "extended attributes" durch den Kopf und das ganze Problem löste sich in Wohlgefallen auf: Ich nutze einfach - statt einer extra Datei - ein solches erweitertes Attribut. Aus Sicht der Anwendung gibt es nur eine Datei, das Filesystem bleibt clean und der Weg ist frei zur Nutzung des UIDocumentBrowserViewController. Nun muss ich mir nur noch etwas Gedanken über vernünftige Verfahren zur Migration machen, um die alten Dateien mit Meta-Daten möglichst elegant abzulösen. Im Moment denke ich unter iOS an einen Migrations-Job, der die Documents-Struktur durchläuft und unter macOS an eine "weiche" Migration, indem neu gespeicherte Dateien die Meta-Daten nur noch in den Dateiattributen sichern.
Sorry, das musste einfach von der Seele, ich bin so happy Schade, dass ich nicht schon vor 10 Jahren auf diese Idee kam, aber das nennt man wohl "lernen"...
Um noch schnell die Kurve zu einem interaktiven Forums-Beitrag zu bekommen: Setzt jemand von Euch schon UIDocumentBrowserViewController ein? Gibt es spezielle Dos und Don'ts ... oder auch nur etwas mehr Dokumentation (neben den WWDC Videos)?
Mattes
Diese Seite bleibt aus technischen Gründen unbedruckt.