GDataHTTPFetcher / NSData vs. Downloading large files

[Christoph Z.]

Hi,

I'm working on an iPhone app which allows users to synchronize notes
with pictures to Google Docs. One of the problems I've encountered so
far is that when exporting documents as ZIP (to extract the images),
the resulting files can be very large e.g. 13 MB, see this post:

http://www.google.com/support/forum/p/apps-apis/thread?tid=2d31499a679b4dd0&hl=en

Now, of course the download time / bandwidth used is itself a problem
here. But another problem is that GDataHTTPFetcher internally uses
NSMutableData and thus will require that much memory to be available.
On iPhone 4 we haven't run into any problems. But things get really
interesting on iPhone 3G running iOS 4.1 - under memory pressure, the
app will usually quit - but more interestingly - just by using
GDataHTTPFetcher to download a 13 MB document ZIP, I've managed to get
that old iPhone to reboot itself - something I've never seen in year
and half of iPhone development. I'm investigating why this happens
(I've managed to repro it a few times already), but regardless - the
root cause of the problem is that reading such huge files into memory
will not work. We'll need to write it to the local file in chunks.
What's the best way to do it using GData API ? Or perhaps a better way
to download document images?

Thank you!
-Christoph

[Greg Robbins]

We've talked a bit about allowing the fetcher to download directly to a file rather than to a mutable data object, but there's currently no support for that.

If you may be exporting large files, your best bet right now is probably to use NSURLConnection directly rather than GDataHTTPFetcher, and write out the file in pieces with each delegate callback. You should be able to use the same request that would work with GDataHTTPFetcher. I'm not sure why Apple does not support NSURLDownload on iOS.

[Christoph Z.]

Thanks! Using NSURLConnection or forking GDataHTTPFetcher and changing
it a bit to do it is pretty trivial - just wanted to make sure there
isn't a better way to do it.

-Christoph