2

So here's the deal. I recently started using AFNetworking to download a few files on start using the following code:

NSMutableURLRequest* rq = [api requestWithMethod:@"GET" path:@"YOUR/URL/TO/FILE"     parameters:nil];
AFHTTPRequestOperation *operation = [[[AFHTTPRequestOperation alloc] initWithRequest:rq] autorelease];

NSString* path=[@"/PATH/TO/APP" stringByAppendingPathComponent: imageNameToDisk];
operation.outputStream = [NSOutputStream outputStreamToFileAtPath:path append:NO];

[operation setCompletionBlockWithSuccess:^(AFHTTPRequestOperation *operation, id responseObject) {

    NSLog(@"SUCCCESSFULL IMG RETRIEVE to %@!",path)

} failure:^(AFHTTPRequestOperation *operation, NSError *error) {

    // Deal with failure
}];

With my path actually plugged into the path variable (Sorry, not on the right computer right now to actually copy pasta the text, but it's exactly the same as the above with different path stuffs)

And everything is working great! I'm getting the file successfully downloaded and everything. My current issue is that I'm trying to get caching to work, but I'm having a lot of difficulties. Basically, I'm not sure what I actually have to do client side as of AFNetworking 2.0. Do I still need to set up the NSURlCache? Do I need to set the caching type header on the request operation differently? I thought that maybe it was just entirely built in, but I'm receiving a status of 200 every time the code runs, even with no changes in the file. If I do have to use the NSUrlCache, do I have to manually save the e-tag on the success blocks requestoperation myself and then feed that back in? Any help on how to progress would be much appreciated. Thanks guys!

Alex Sullivan
  • 562
  • 7
  • 20
  • the default url request's cachePolicy should work AFAIK -- you're sure the server is allowing caching? – Daij-Djan Nov 11 '13 at 12:02
  • try setting the caching policy explicitly of your request operation – amar Nov 11 '13 at 12:16
  • So if I'm understanding you guys correctly, it should cache with 0 extra from what I put in above, yeah? And obviously I should get a 304 on the success blocks operation yeah? – Alex Sullivan Nov 11 '13 at 12:18
  • @AlexSullivan I think the cached object is returned in the success block, so you won't see the 304, you'll see the 200 returned on the original request that was cached. – Aaron Brager Nov 11 '13 at 20:45
  • 304 is considered a "success" in the HTTP world, but I have been getting a 304 in the failure block. – Chris Jan 29 '14 at 20:10
  • This should work. If you need to determine if response was returned from the server or from cache, you can try this: http://stackoverflow.com/a/21556002/514181 – Darrarski Feb 04 '14 at 15:32

1 Answers1

4

AFNetworking uses NSURLCache for caching by default. From the FAQ:

AFNetworking takes advantage of the caching functionality already provided by NSURLCache and any of its subclasses. So long as your NSURLRequest objects have the correct cache policy, and your server response contains a valid Cache-Control header, responses will be automatically cached for subsequent requests.

Note that this mechanism caches NSData, so every time you retrieve from this cache you need to perform a somewhat expensive NSData-to-UIImage operation. This is not performant enough for rapid display, for example if you're showing images in a UITableView or UICollectionView.

If this is the case, look at UIImageView+AFNetworking, which adds downloads and caching of UIImage objects to UIImageView. For some applications you can just use the out-of-the-box implementation, but it is very basic. You may want to look at the source code for this class (it's not very long) and use it as a starting point for your own caching mechanism.

Aaron Brager
  • 65,323
  • 19
  • 161
  • 287
  • 1
    Also: SDWebImage is a more robust image downloading, caching, and display library, but it doesn't integrate with AFNetworking: https://github.com/rs/SDWebImage – Aaron Brager Nov 11 '13 at 20:47