views:

73

answers:

0

I've used the Activity Monitor and Object Allocations tools in xcode to check out my application and the sample facebook login app and what I've found is that they all of them eat about 6-10M (!) the first time the user visits the page. I assume the issue is page content being cached although I think that this code:

- (NSCachedURLResponse*)connection:(NSURLConnection*)connection
    willCacheResponse:(NSCachedURLResponse*)cachedResponse {
  return nil;
}

and the cache policy NSURLRequestReloadIgnoringLocalCacheData were supposed to keep it from caching anything. (Both of these things are in the Facebook library and were not written by me).

This wouldn't be a big deal but losing 10M for the duration of the application is too heavy a price to pay for my app. I tried setting up an autorelease pool around the FBLoginDialog (and draining it when the dialog is gone) but that didn't make any difference. I've also tried manually handling the lifetime of the FBLoginDialog with retain/release calls but that also fails. Its not the FBLoginDialog that sticks around... its some junk in UIView internals (the object does free about 1M of its allocations when released).

FYI, the sample app I profiled is mentioned in this thread, and linked to here. It fixes some key bugs in the aged facebook version.

For the record, I'm more suspicious of UIWebView and NSURLConnection then I am of the Facebook library so if there is a general web view workaround to circumvent memory hogging, that might help as well. Thanks...