Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting up pipeline for use in both app and notification service extension #836

Open
JValldejuli opened this issue Mar 7, 2025 · 0 comments

Comments

@JValldejuli
Copy link

Hello, I'm using Nuke to load images in my app. I recently added a notification service extension which serves to load images and attach them to incoming remote notifications. Both the app and the notification service extension are in the same app group. I figured it would be nice if they could share the same disk cache to avoid downloading/processing the same images twice. So in both my app and notification service extension I setup a pipeline that points to the app group directory:

var configuration = ImagePipeline.Configuration()
configuration.dataLoader = {
    let config = URLSessionConfiguration.default
    config.urlCache = nil
    return DataLoader(configuration: config)
}()
configuration.dataCache = {
    guard let containerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: AppGroupIdentifier) else {
        Log.error("Failed to initialize image pipeline data cache: Could not locate container URL")
        return nil
    }
    let dataCachePath = containerURL.appendingPathComponent(ImageDataCacheName, isDirectory: true)
    return try? DataCache(path: dataCachePath)
}()

My estimation is that this is fine, but I'm wondering if there are any risks associated with doing this. Is there some chance of a crash due to the extension and the app attempting to write to the same spot? I'm guessing no given that I don't show notifications while the app is in the foreground (which is when the app image pipeline would be active). Basically I just wanted to get some feedback regarding whether this approach is reasonable or not. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant