Re: asynchronous nsurlconnection in nsoperation
Re: asynchronous nsurlconnection in nsoperation
- Subject: Re: asynchronous nsurlconnection in nsoperation
- From: Andreas Grosam <email@hidden>
- Date: Fri, 23 Mar 2012 16:48:15 +0100
On Mar 23, 2012, at 11:25 AM, Steve Sisak wrote:
> At 6:59 PM +0300 3/21/12, Ariel Feinerman wrote:
>> I wish to insert an asynchronous NSURLConnection into non-concurrent
>> NSOperation the reason is to allow necessarily unarchive actions on the streaming date so
>
> Look at (and steal code from) the LinkedImageFetcher sample:
>
> <http://developer.apple.com/library/mac/#samplecode/LinkedImageFetcher/>
>
> I'm pretty sure if you steal the Core Code directory, and subclass QHTTPOperation, that ought to do pretty much what you want.
>
> HTH,
>
> -Steve
The LinkedImageFetcher sample is quite a good example to look at when you are required to use NSOperation to wrap a download. For a sample, it is quite complex though.
So, basically, QHTTPOperation is a good but rather complex example which shows how to run a NSURLConnection on a secondary thread, and also how to wrap it into a NSOperation which can be canceled etc.
Still, the sample is not a good example to show how to *process* arbitrary data *during* the download process. The sample shows two ways to handle data:
- write the received data into an NSOutputStream, and
- store the content into an "accumulator" - which is a mutable NSData.
The latter disqualifies since the OP's data is about several MBytes large, too large for a mobile device.
And when the NSOutputStream is an ordinary file stream, we gain nothing than writing into a file directly, which can be accomplished much easier.
If you subclass the NSOutputStream in order to achieve a fancier processing, you will nevertheless run into issues which are completely orthogonal to using NSOperation.
Furthermore, using NSStreams is often unduly cumbersome and often not that easy as it sounds. You need a bound stream pair, and there have been various issues with this.
Still, any process that handles the data via NSStreams must be able to handle such data in **chunks**. If this is not possible, the solution with NSStream becomes even more complex - if feasible at all. See also, <https://devforums.apple.com/message/608213#608213>
If the data *can* be processed *partially*, then the simplest approach is just doing this in
- (void) connection:(NSURLConnection*)connection didReceiveData:(NSData*) data
{
[self processChunk:data];
}
where processChunk: must perform synchronously - that is, it shall block until after that chunk of data has been processed completely and has relinquished ownership from data.
If it would perform asynchronously, many NSData buffers may possibly queued - and this may consume too much memory.
Andreas
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden