Background Transfers

[bonebox]

I see the README states that this supports background downloads, but it seems like it's not yet comprehensive? I'm assuming in order to get basic support, I need to create a new TCBlobDownloadManager with a custom NSURLSessionConfiguration using backgroundSessionConfigurationWithIdentifier:. That's fine, although it would be nice if the defaultSession singleton supported it.

The bigger issue is that the DownloadDelegate class doesn't implement the NSURLSessionDelegate methods, namely URLSessionDidFinishEventsForBackgroundURLSession:. It would also need some sort of background completion handler property in order to store it when it's passed in the application:handleEventsForBackgroundURLSession:completionHandler: method in the AppDelegate. (See the Background Transfer Considerations section of Apple's URL Loading System Programming Guide).

One way around this would be for a developer to subclass DownloadDelegate and add those methods, but unfortunately there is no way to set the TCBlobDownloadManager delegate to something else since it's marked private, and DownloadDelegate also can't be subclassed because it's not public.

So in short, do you have plans on adding this, or at the very least can the DownloadDelegate class be made public along with its corresponding delegate property on TCBlobDownloadManager so that other developers can more easily implement it?

[thibaultcha]

The default singleton should uses the defaultSessionConfiguration on purpose. One should be able to create a background downloader by giving it an NSURLSessionConfiguration and its own identifier.

The goal of the library is to make simple downloads effortless/brainless to developers hence why a lot of properties are not public. I am not sure which solution is the simplest from a usage perspective to support this. Implement them in the private DownloadDelegate and expose it to the user via the TCBlobDownloadDelegate protocol, or expose DownloadDelegate to allow it to be subclassed. I am not a fan of the 2nd solution as it goes against the simplicity of the library. I am not a fan of the first one either because it would mean implement most the protocol(s) to cover all the use cases and make everybody happy

About the application:handleEventsForBackgroundURLSession:completionHandler I do not know it as stopped working on iOS several years ago now, but I am wondering if your needs aren't too specific to use this library which aims at providing a solution to simple use cases. If I understand correctly, the completion handler needs to be called once the downloads are completed and the app has finished updating itself (UI etc)? I would be fine with a property storing this completion handler. But again, by supporting this it enforces the perception that this library is aimed at being a full wrapper around NSURLSession and co.

I do not plan on implementing these features as I do not have time to work on this project anymore, but I would welcome contributions.

[bonebox]

That's too bad that you won't be working on it any more, but understandable. I also understand the goal at keeping things as simple as possible. But I think having a default implementation that works "out-of-the-box" while still allowing flexibility for enhancement strikes a good balance. Also, for a library such as this that is aimed at downloading "blobs" (i.e. typically larger files), background downloading would be a fairly common scenario.

I don't have much extra time myself, but I'll see what I can do about further contributions, as this is the best Swift implementation for a download manager that I have found thus far.

[thibaultcha]

Thank you for the kind works, much appreciated. I might find some time to improve it because there is a lot to do still on it. I feel like the library still doesn't deserve to be in 1.0 as it is missing a better documentation, continuous integration testing, a better app example, better code examples etc... But I have other projects I'm working on that are taking my time away from it.

Background downloading was the original purpose of the original library (the iOS 5, Obj-C one) and this one should be aimed at it too.