about enqueuing by using completion blocks - ios

Question

So, after learning about completion blocks a while back, I like using completion blocks a lot. I like closure and I like the ability to pass just about anything anywhere I want.
As someone who's new to thread programming, I've been staying away from GCD and NSOperation--but lately I've had to program asynchronous updated to Core Data stuff and I am beginning to have doubts to my "all completion block all the time" approach.
So here's one example of what I'm questioning myself: I have a series of potentially rather large data (images, sound, video, what have you) to upload to a server somewhere. The metadata for these data is stored in Core Data, and I have a timestamp that I use to decide which objects should get uploaded. All these uploads should be done sequentially.
What I have coded is a essentially basically just a function with a completion block in it, that has a call to itself at the end of the block, like this:
(void)uploadAllAsynchronously {
... // First figure out what to upload based on core data
// Here comes the completion block in question
void(^blk)(BOOL) = ^(BOOL)uploadSuccess {
... // if upload successful, update core data to mark what has been uploaded
[self uploadAllAsynchronously]; // Recursively calls the function that contains this block. I actually have a weak self, or if that fails to break a retain cycle, I should be able to pass in a NSManagedObjectContext as an argument.
}
[NSURLConnection sendAsynchronousRequest:... queue:... completionHandler:blk];
}
This should work, right? Is there something here that is completely dangerous that suggests I have to use GCD and handling my own queue? I am asking this because I'm kind of having some trouble right now possibly with data in it would appear different threads not updating correctly because of asynchronous calls, though not sure which part of my code is the culprit.
Thanks in advance.

Answer 1

Your block is of the wrong type.
As the documentation for
+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse *, NSData *, NSError *))handler
shows, the type of the completion black is
void (^) (NSURLResponse *, NSData *, NSError *)
not
void (^) (BOOL)
You should change blk to be something like
void (^blk) (NSURLResponse *, NSData *, NSError *) = ^ (NSURLResponse *response, NSData *data, NSError *error) {
//...
};
It would be more stylish to write
[NSURLConnection sendAsynchronousRequest:theRequest queue:theQueue completionHandler:^ (NSURLResponse *response, NSData *data, NSError *error) {
//...
}];
with the completion block in-line with the method.
Regarding the question of performing operations on your NSManagedObjectContext in the completion handler: This is fine so long as the NSOperationQueue passed to sendAsynchronousRequest:queue:completionHandler: is the same as the one in which the managed object context is created. But as the documentation for NSManagedObjectContext states
Core Data uses thread (or serialized queue) confinement to protect managed objects and managed object contexts (see “Concurrency with Core Data”). A consequence of this is that a context assumes the default owner is the thread or queue that allocated it—this is determined by the thread that calls its init method. You should not, therefore, initialize a context on one thread then pass it to a different thread. Instead, you should pass a reference to a persistent store coordinator and have the receiving thread/queue create a new context derived from that.
If the queue that you pass is not the one on which you created the managed object context, you must do one of the following
Call -[NSOperationQueue addOperation:] on the queue where the managed object context was created.
Create a second managed object context (with the same persistent store coordinator) on the queue on which the core data operations are taking place.
Create a second managed object context and a second persistent store coordinator on the queue on which the core data operations are taking place.
Use locking.
The documentation on Concurrency with Core Data makes it clear that you must either use thread confinement (options 1-3 above) or use locking (option 4 above).
This is what the docs have to say about using locks:
If you choose not to use the thread containment pattern—that is, if you try to pass managed objects or contexts between threads, and so on—you must be extremely careful about locking, and as a consequence you are likely to negate any benefit you may otherwise derive from multi-threading.
This is what the docs have to say about having not just per-thread managed object contexts but also per-thread persistent store coordinators:
This approach provides for greater concurrency at the expense of greater complexity (particularly if you need to communicate changes between different contexts) and increased memory usage.

Answer 2

yes this code should work.. note: I'd rename the method then.. uploadIfNeeded maybe -- because it doesnt always blindly upload stuff...