Gute Möglichkeit zum Verwalten des Ordners Dokumente/Posteingang in einer iOS-App

Question

Wenn eine Datei vom Dokumentinteraktionssystem an eine iOS-Anwendung übergeben wird, wird eine Kopie der Datei im Ordner Documents/Inbox des Anwendungspakets gespeichert. Nachdem die Anwendung die Datei verarbeitet hat, muss sie offensichtlich die Datei von Documents/Inbox entfernen, andernfalls wird der Ordner weiter wachsen und Speicherplatz auf dem Gerät verschwenden.

Ich bin mit dieser einfachen Lösung (A) jedoch unwohl, da meine App mit dem Benutzer interagieren muss, bevor er die Verarbeitung beenden und die Datei entfernen kann. Wenn der Nutzer die App während dieses Interaktionszeitraums aussetzt und die App im Hintergrund beendet wird, wird die veraltete Datei beim nächsten Start der App nicht entfernt. Natürlich kann ich meine App verbessern, um dieses Szenario abzudecken, aber ich vermute, dass es immer einen anderen Grenzfall geben wird, der mich mit einem "unsauberen" Documents/Inbox-Ordner verlassen wird. Eine bevorzugte Lösung (B) wäre daher, den Ordner Documents/Inbox zu einem geeigneten Zeitpunkt zu entfernen (z. B. wenn die App normal startet, d. H. Nicht über eine Dokumenteninteraktion). Ich fühle mich immer noch unwohl dabei, weil ich auf einen Dateisystempfad zugreifen würde, dessen Speicherort nirgendwo offiziell dokumentiert ist. Zum Beispiel würde meine App brechen, wenn in einer zukünftigen Version von iOS das Dokumenteninteraktionssystem keine Dateien mehr in Document/Inbox platziert.

Also meine Fragen sind:

1. Möchten Sie die Lösung A oder B empfehlen?
2. Verwenden Sie einen anderen Ansatz und können Sie vielleicht einen Überblick darüber geben, wie Ihre App die Document/Inbox verwaltet?
3. Last but not least: Kennen Sie eine offizielle Apple-Dokumentation, die das Thema behandelt und die ich übersehen habe?

Answer 1

Da ich diese Frage gestellt habe, habe ich die folgende Lösung implementiert:

• Ich habe meine App neu gestaltet, so dass es jetzt sofort eine Datei, um es über Dokumentation Interaktion übergeben verarbeitet, ohne dass der Benutzer unter Beteiligung von alle. Es sei denn, die App stürzt ab, oder wird suspendiert und getötet, mitten in der Verarbeitung der Datei sollte dies immer mit einem sauberen Documents/Inbox verlassen werden.
• Um den (seltenen) Fall eines Absturzes oder Suspend/Kill zu decken, entfernt meine App den Ordner Documents/Inbox, wenn es normal gestartet wird (d. H. Ohne den Zweck der Dokument-Interaktion). Um dies zu erreichen, ist der Ordnerpfad Documents/Inbox notwendigerweise fest codiert.

Hier sind die Gedanken, die in die Lösung ging:

• die App neu gestalten
  • Zunächst es wie eine gute Idee schien dem Benutzer eine Wahl zu bieten, wie sie eine Datei sein wollte verarbeitet - schließlich würde das Angebot einer Auswahl die App flexibler machen und dem Nutzer mehr Freiheit bieten, oder?
  • Ich erkannte dann, dass ich versuchte, die Verantwortung für die Entscheidung, wie die Interaktion des Dokuments mit dem Benutzer behandelt werden sollte, zu verschieben. Also habe ich in den sauren Apfel gebissen, die harten Entscheidungen im Voraus getroffen und mich dann glücklich gemacht, ein einfaches und unkompliziertes Dokumenteninteraktionssystem in meiner App zu implementieren.
  • Wie sich herausstellt, bedeutet keine Benutzerinteraktion auch, dass die App einfacher zu bedienen ist. Hier ist also eine Win-Win-Situation, sowohl für mich als Entwickler als auch für die Nutzer meiner App.
• Entfernen Documents/Inbox Ordner während app startet
  • die Documents/Inbox Ordner während App-Starts Entfernen ist nur ein nachträglicher Einfall, keine wesentlicher Teil davon, wie mein app behandelt Dokument Interaktion
  • Deshalb bin ich durchaus bereit, das Risiko eingehen, dass Apple den Dateisystempfad des Posteingangs zu einem späteren Zeitpunkt ändert. Das Schlimmste, was passieren kann, ist, dass meine App ein paar Dateien anhäuft, die Reste von Absturz- oder Suspend/Kill-Szenarien sind.

Und schließlich, ein paar Gedanken für die weitere Entwicklung:

• Wenn es stellt sich immer heraus, dass es wirklich sollte mehr als eine Art und Weise sein, wie die App Dokument Interaktion behandeln kann, ich würde eine Benutzereinstellung hinzufügen, so dass der Benutzer eine Entscheidung im Voraus treffen muss und die App ihre Verarbeitung nicht anhalten muss, um den Benutzer nach einer Auswahl zu fragen.
• Wenn sich herausstellt, dass Benutzerinteraktion mitten in der Verarbeitung der Dokumentinteraktion absolut unvermeidlich ist, würde ich diesen Ansatz betrachten: 1) Bevor der Benutzer interagieren darf, verschiebe die Datei von Documents/Inbox auf eine Art "Staging" -Ordner; 2) Lassen Sie die Benutzerinteraktion stattfinden; 3) Verarbeiten Sie die Datei im "Staging" -Ordner auf die vom Benutzer gewählte Weise. Wichtig dabei ist, dass der Ordner "staging" an einem bekannten Ort ist und vollständig von der App verwaltet wird. Sollte der Benutzer die App während des Benutzerinteraktionsschritts anhalten und dann beenden, kann einfach eine entsprechende Aktion ausgeführt werden, wenn die App das nächste Mal gestartet wird.

---

EDIT

In iOS 7 nicht mehr möglich ist Documents/Inbox zu entfernen, sobald sie erstellt wurde. Die NSFileManager Methode removeItemAtPath:error: gibt Cocoa-Fehler 513 zurück, der in NSFileWriteNoPermissionError aufgelöst wird (cf. this list of Foundation constants). Der Fehler scheint nicht auf POSIX-Berechtigungen bezogen zu sein, es sieht jedoch eher so aus, als ob das System selbst den Löschversuch stört (möglicherweise Schutz der App-Bundle-Struktur?).

Ebenfalls bemerkenswert ist, dass Apple heute explizit Documents/Inbox in der Dokumentation der UIApplicationDelegate Methode application:openURL:sourceApplication:annotation: nennt. Sie sagen auch, dass

[...] Ihre App verfügt über die Berechtigung zum Lesen und Löschen von Dateien in diesem Verzeichnis, aber keine Berechtigung zum Schreiben an sie. Wenn Sie eine Datei ändern möchten, müssen Sie sie zuerst in ein anderes Verzeichnis verschieben.

Es gibt mehr Sachen über mögliche Verschlüsselung der Dateien in the docs, aber Sie sollten selbst darüber nachlesen.

Answer 2

Ich bin gerade mit dem gleichen Problem konfrontiert. Wie Sie habe ich keine gute Lösung, aber als Antwort auf Ihre Fragen lehne ich Option A über Option B ab, weil mir die Idee, ein Problem mit zukünftigen Versionen des Betriebssystems zu haben, nicht gefällt. Da es in meinem Fall keine Benutzerinteraktion gibt, nachdem ich die Vorschau des Dokuments angezeigt habe, kann ich fortfahren und sie löschen, wenn ich den Delegiertenrückruf –documentInteractionControllerDidEndPreview: erhalte. Dies ist insofern theoretisch, als ich dies noch nicht programmiert habe und es für eine Weile nicht erreichen werde, da es sich um einen Gegenstand mit niedriger Priorität handelt. Wenn es nicht funktioniert oder es andere Probleme gibt, melde ich mich hier zurück. Die Google-Suche, die ich eingegeben habe, um die Dokumentation von Apple zu finden, zeigte auf diesen StackOverflow-Beitrag. Ich habe keine anderen nützlichen Informationen von Apple oder irgendjemand anderem zu diesem Thema gesehen.