Hook for receiving background URLSession events queued for app relaunch or by app extensions
@michalkcloudinay 已經在處理了。
開始於 2021年2月22日。
評估
這個 Issue 還沒有評估資料。
描述
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.
- 主要語言
- Swift
- 星號
- 169
- 分支
- 107
- PR 合併指標
- 30 天內沒有已合併 PR
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 沒有貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
cloudinary/cloudinary_ios 的其他 Issue
-
Memory Leaks and Retain Cycles while using Upload with Cloudinary SDK可能重新可做 @adimiz1 於 713 天前認領，目前沒有進行中的 PR。 未關閉
cloudinary/cloudinary_ios#441 · 1 則留言 · 已指派 1 人 ·
-
難度 5/5 一週以上 新手友好度 20/100
cloudinary/cloudinary_ios#439 ·
-
Add MD5-Header option to CLDUploadRequestParams可能重新可做 @adimiz1 於 1458 天前認領，目前沒有進行中的 PR。 未關閉
cloudinary/cloudinary_ios#390 · 1 則留言 · 已指派 1 人 ·
-
Unable to upload photo, uploadPrefix, unrecognized selector可能重新可做 @adimiz1 於 1266 天前認領，目前沒有進行中的 PR。 未關閉bug
cloudinary/cloudinary_ios#369 · 2 則留言 · 已指派 1 人 ·
-
Does not compile for tvOS可能重新可做 @GiniAppsPartners 於 2026 天前認領，目前沒有進行中的 PR。 未關閉
cloudinary/cloudinary_ios#337 · 1 則留言 · 已指派 2 人 ·
查看 cloudinary/cloudinary_ios 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 72/100
vorssaint/vorssaint-utils#4162 ·
維護者通常 2 天內回覆
-
cua-driver diagnose: one-line help says "install and permission report", which is macOS-specific未關閉
難度 1/5 1 小時以內 新手友好度 78/100
維護者通常 1 天內回覆
-
Opening PortKiller force-kills every cloudflared quick tunnel on the machine, not just its own可能已有人在做 @widechaos 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 62/100
productdevbook/port-killer#131 ·
-
難度 2/5 1-3 小時 新手友好度 72/100
維護者通常 1 天內回覆
-
easy
難度 2/5 1-3 小時 新手友好度 62/100
維護者通常 5 天內回覆