How to avoid block retains in Objective-C - ios

Question

I have a queue of blocks which perform a webservice call. The problem is that the downloaded data is not freed after the block's end. I read a lot about retains but I can't make ARC dealloc the memory.
Here's the code:
Create the queue of blocks which download the data
- (void)syncData
{
dispatch_semaphore_t sema = dispatch_semaphore_create(0);
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,0);
dispatch_async(queue, ^{
[Model syncAziende:^(id response, NSError *error) {
dispatch_semaphore_signal(sema);
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
[Model syncContatti:^(id response, NSError *error) {
dispatch_semaphore_signal(sema);
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
[Model syncDestinazioni:^(id response, NSError *error) {
dispatch_semaphore_signal(sema);
}];
dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
and so on...
});
}
On Model.m
+ (void)syncAziende:(RequestFinishBlock)completation
{
__weak typeof(self)selfObject = self;
[selfObject syncData:^(id response, NSError *error) {
completation(response,error);
} wsEndPoint:kCDCEndPointGetAziende tableName:kCDCDBAziendeTableName];
}
+ (void)syncContatti:(RequestFinishBlock)completation
{
__weak typeof(self)selfObject = self;
[selfObject syncData:^(id response, NSError *error) {
completation(response,error);
} wsEndPoint:kCDCEndPointGetContatti tableName:kCDCDBContattiTableName];
}
// and so on...
Where syncData is:
+ (void)syncData:(RequestFinishBlock)completation wsEndPoint:(NSString*) url tableName:(NSString *)table
{
__weak typeof(self)selfObject = self;
[selfObject getDataFromWS:^(id WSresponse, NSError* WSError)
{
completation(nil,nil);
}WSUrl:url];
}
Where getDataFromWS is:
+ (void)getDataFromWS:(RequestFinishBlock)completation WSUrl:(NSString *)svcUrl
{
__weak typeof(self)selfObject = self;
[selfObject getJsonDataFromURL:^(id response, NSError *error)
{
completation(response,error);
}url:svcUrl];
}
Where getJsonDataFromURL is:
+(void)getJsonDataFromURL:(RequestFinishBlock)completation url:(NSString*)url
{
__weak typeof(self)selfObject = self;
__weak AFHTTPRequestOperationManager *manager = [selfObject getAuthorizedRequestionOperationManager];
[manager.requestSerializer setValue:#"application/json" forHTTPHeaderField:#"Accept"];
[manager.requestSerializer setValue:#"application/json" forHTTPHeaderField:#"Content-Type"];
[manager.requestSerializer setValue:#"gzip" forHTTPHeaderField:#"Accept-Encoding"];
[manager GET:url parameters:nil success:^(AFHTTPRequestOperation *operation, __weak id responseObject) {
completation([responseObject objectForKey:#"d"],nil);
} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
completation(nil,error);
}];
}

Answer 1

These __weak references don't really make sense within the context of a class method. It only makes sense to use the weak-self pattern when dealing with instance methods.
So, this begs the question as to which object you're concerned about not getting released. I don't see anything here that would cause the object that has syncData as an instance method to be retained.
Having said that, this routine with the series of network requests that you have made synchronous through the use of the semaphores would (a) retain any autorelease objects that were instantiated throughout the process (notably, the operations themselves); (b) not allow you to cancel the process once it starts; and (c) run the requests serially (for which you'll pay a serious performance penalty and should be avoided unless you absolutely have to).
I'd suggest a simplification of the code. I'd eliminate the dispatch code with the semaphores. I'd also get rid of all of those weak references to self in class methods.
You should simply issue your GET requests. If you really need them to run serially (as implied by your use of the semaphore), then just set the maxConcurrentOperationCount to 1 for the operationQueue of the AFHTTPRequestOperationManager instance. But don't make them run serially unless you absolutely have to, because you pay a significant performance penalty by doing that. But avail yourself of the NSOperationQueue that AFNetworking provides, rather than also doing your own GCD code (and worse, using semaphores within that GCD code).
But this way, if you want to cancel the requests, you can just call cancelAllOperations for the operationQueue of the AFHTTPRequestOperationManager. You can also control the degree of concurrency with maxConcurrentOperationCount.

Answer 2

Given your description and based on the comments, a naive - but still insufficient -
solution may look as follows:
// A generic completion handler:
typedef void (^completion_t)(id result, NSError* error);
- (void) fetchJSONFromURL:(NSURL*)url completion:(completion_t)completion;
- (void) syncAziendeWithInput:(id)input completion:(completion_t)completion;
- (void) syncContattiWithInput:(id)input completion:(completion_t)completion;
- (void) syncDestinazioniWithInput:(id)input completion:(completion_t)completion;
- (void) syncData
{
dispatch_queue_t sync_queue = dispatch_queue_create("sync_queue", 0); // serial queue
NSURL* url = ...;
[self fetchJSONFromURL:url completion:^(id result, NSError*error){
dispatch_async(sync_queue, ^{
[self syncAziendeWithInput:result completion:^(id result, NSError* error){
...
}];
});
}];
url = ...;
[self fetchJSONFromURL:url completion:^(id result, NSError*error){
dispatch_async(sync_queue, ^{
[self syncContattiWithInput:result completion:^(id result, NSError* error){
...
}];
});
}];
url = ...;
[self fetchJSONFromURL:url completion:^(id result, NSError*error){
dispatch_async(sync_queue, ^{
[self syncDestinazioniWithInput:result completion:^(id result, NSError* error){
...
}];
});
}];
...
}
Caveats:
Oversimplification. A practical solution becomes far more elaborated:
No error handling yet.
No way to cancel the asynchronous tasks.
syncData is asynchronous, but has no completion handler. That is, we don't know when it's complete. We could utilize dispatch_group in order to implement an approach to signal the completion of a number of asynchronous methods.
With the help of a third party library we could implement a solution which does all that above, and looks basically even simpler.