Hook for receiving background URLSession events queued for app relaunch or by app extensions

Offen
  • Stimmt etwas nicht?
#327 1 Kommentar 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

@michalkcloudinay arbeitet bereits daran.

Seit 22.2.2021.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

enhancement

Feature request for Cloudinary iOS SDK

Explain your use case

We have business logic to run in response to a upload task completion (success or failure), e.g., database write, backend API calls, file cleanup, etc. Most importantly, this has to be done for all uploads, regardless of whether it is started by the current application process or not.

This includes, e.g., an upload started by an earlier app invocation gracefully killed by the system, or an upload started by a Share Extension that dismisses the UI eagarly in anticipation of the app being woken up for the background transfer completion (e.g. this Apple Dev forum thread).

Describe the problem you’re trying to solve

The current Cloudinary SDK does not surface any hook for us to get notified about these events sent by sessionSendsLaunchEvents = true. This blocks us from implementing functional background uploads, especially for a Share Extension.

Having said that, it looks the SDK is already well-equipped to support processing and serving these events to the API. More specifically, it:

  • does not use the block/closure callback versions of the Upload/Download tasks; and
    (so delegate callbacks won't get suppressed)

  • already handles the completion handler for clients that have to handle URLSession events in their UIApplicationDelegate. (e.g., when the SDK user implemented it for other URLSessions)

Do you have a proposed solution?

In conjunction to setBackgroundCompletionHandler(_:), the Cloudinary SDK should provide an root-level API to register a callback for all task completions in the SDK instance. This will be backed by URLSession:task:didCompleteWithError: for certain.

The callback needs not provide a full CLDUploadRequest or CLDFetchImageRequest object* — the expectation is a minimal set of basic metadata, like unique file ID and resource type. These should sufficiently allow us to look up the associated operation log in our database, and resume the post-upload or post-download work as necessary.

[*] technically, this could be tough to implement anyway for little to no value. URLSession tasks received via the didCompleteWithError delegate message can be a task resurrected only for the message, and so have no associated CLD*Request in the current process.

Vorherrschende Sprache
Swift
Sterne
169
Forks
107
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cloudinary/cloudinary_ios

Alle Issues in cloudinary/cloudinary_ios

Ähnliche Issues

Weitere Issues zu Swift

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.