I'm using an NSOperationQueue to manage HTTP connections (using ASI-HTTPRequest). Since I have multiple views and the need to have these different views requesting HTTP connections, should I try to create a global NSOperationQueue in the app delegate, or should I have one in each of the views? I'm not familiar with NSOperationQueue.
I'd like to know a) what the best practice is and b) if there is no best practice, what the tradeoffs are if any.
I did try to put the operation queue in the class (as a property) where I handle the server connections but the task never fired. Couldnt figure it out but [queue operations] = 0. If someone knows a solution to this, I presume this would be the best place to put it.
I have solved this by adding a class method on NSOperationQueue that I think Apple has missed; a shared operation queue. I add this as a category on NSOperationQueue as this:
// NSOperationQueue+SharedQueue.h
#interface NSOperationQueue (SharedQueue)
+(NSOperationQueue*)sharedOperationQueue;
#end
// NSOperationQueue+SharedQueue.m
#implementation NSOperationQueue (SharedQueue)
+(NSOperationQueue*)sharedOperationQueue;
{
static NSOperationQueue* sharedQueue = nil;
if (sharedQueue == nil) {
sharedQueue = [[NSOperationQueue alloc] init];
}
return sharedQueue;
}
#end
This way I do not need to manage a whole bunch of queues unless I really need to. I have easy access to a shared queue from all my view controllers.
I have even added a category to NSObject to make it even easier to add new operations on this shared queue:
// NSObject+SharedQueue.h
#interface NSObject (SharedQueue)
-(void)performSelectorOnBackgroundQueue:(SEL)aSelector withObject:(id)anObject;
#end
// NSObject+SharedQueue.m
#implementation NSObject (SharedQueue)
-(void)performSelectorOnBackgroundQueue:(SEL)aSelector withObject:(id)anObject;
{
NSOperation* operation = [[NSInvocationOperation alloc] initWithTarget:self
selector:aSelector
object:anObject];
[[NSOperationQueue sharedOperationQueue] addOperation:operation];
[operation release];
}
#end
My personal preference for this is to have a singleton that manages all http requests. Each view would then ask the singleton to make the http call, passing itself as a delegate for that call then the singleton hands that delegate and call off to an NSOperation and then NSOperation calls back once the call is done.
If you already have a pointer to a class that handles connections in each view/view controller, there's no reason you would also need to have a pointer to the operation queue.
I suppose what you want to do is something like: a) view(Controller) hands url(+data) to server handling object, b) server handling objects creates operation and puts it in a queue that it and only it has a pointer to.
It's hard to figure out why that didn't work if you don't provide more detail.
I highly recommend taking a look at ASIHTTPRequest which provides a NetworkQueue class to handle this kind of task. It has several convenient delegate fields that lets you register to keep track of progress, know when a download or upload finished etc.
Related
I want to connect to some arbitrary device via wifi from a "connection" view. When pressing "back" and returning to the main menu, I want the connection I created to still exist(so that other views of the app can send/recive messages through it like ssh or telnet). Is it a good idea to create a connection (with say CFNetwork or such) in a separate thread or NSOperation and pass a reference to this thread to the main menu view controller?
You need to design your app in such a way that each separate group of functions are in a separate class. For example, as mentioned above, use a separate class for connections. You can use the Singleton pattern in order to create 1 instance only for your app to use from anywhere.
Also instead of worrying about NSOperations...which would be calls within your class, you can use a well-tested framework and off you go. You'll find it here with examples...
https://github.com/AFNetworking/AFNetworking
#interface NetworkConnections: NSObject
#end
#implementation NetworkConnections
(id)sharedInstance
{
// structure used to test whether the block has completed or not
static dispatch_once_t p = 0;
// initialize sharedObject as nil (first call only)
__strong static id _sharedObject = nil;
// executes a block object once and only once for the lifetime of an application
dispatch_once(&p, ^{
_sharedObject = [[self alloc] init];
});
// returns the same object each time
return _sharedObject;
}
(void) doSomething {
}
#end
Anytime you want to use that class:
[[NetworkConnections sharedInstance] doSomething];
I have a library project that uses ASIHTTPRequest to make URL requests and parse the responses. The library will be used by a separate iPhone app project.
If my iPhone controller code responds to a touch event, then calls into the library to make URL requests, how do I best perform the requests asynchronously?
In the library, if I use the delegate pattern for asynchronous requests as shown in the ASIHTTPRequest sample code, how do I return data from the library back to the calling code in the iPhone controller?
If I instead make synchronous URL requests with ASIHTTPRequest inside the library, what's the easiest way to put the calls to the library from the iPhone controller on a separate thread to avoid tying up the UI thread?
I'm no ASIHTTPRequest expert (NSURLRequest has always done me fine), but from a quick poke at the code, it looks like you'd use its delegate and didFinishSelector properties to give it someone to tell when the URL request is finished. So, for example:
- (void)startURLRequest
{
ASIHTTPRequest *myRequest;
/* code to set the request up with your target URL, etc here */
myRequest.delegate = self;
myRequest.didFinishSelector = #selector(HTTPRequestDidFinish:);
/* ... */
[myRequest startAsynchronous];
}
- (void)HTTPRequestDidFinish:(ASIHTTPRequest *)request
{
NSLog(#"Request %# did finish, got data: %#", request, request.data);
[myTargetForData didReceiveData:request.data fromURL:request.originalURL];
}
Apple explicitly recommend that you use the built-in runloop style mechanisms for asynchronous HTTP fetching, not separate threads. Using separate threads is likely to result in worse performance — at least in terms of battery life and/or device heat, even if it's still fast enough.
That said, as a learning point, by far the quickest way to switch something onto a separate thread and have it report back to the main thread (remember: UIKit objects may be messaged only from the main thread) is by changing this:
- (void)postResult:(NSString *)result
{
instanceOfUILabel.text = result;
}
- (void)doExpensiveOperationOn:(NSString *)source
{
/* lots of expensive processing here, and then... */
[self postResult:result];
}
- (IBAction)userWantsOperationDone:(id)sender
{
[self doExpensiveOperationOn:#"some value or another"];
}
Into this:
- (void)postResult:(NSString *)result
{
instanceOfUILabel.text = result;
}
- (void)doExpensiveOperationOn:(NSString *)source
{
/* we're on a thread without an autorelease pool now, probably we'll want one */
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
/* lots of expensive processing here, and then... */
/* in this simplified example, we assume that ownership of 'result' is here on this thread, possibly on the autorelease pool, so wait until postResult has definitely finished before doing anything that might release result */
[self performSelectorOnMainThread:#selector(postResult:) withObject:result waitUntilDone:YES];
[pool release];
}
- (IBAction)userWantsOperationDone:(id)sender
{
[self performSelectorOnBackgroundThread:#selector(doExpensiveOperationOn:) withObject:#"some value or another"];
}
There's about a million possible concurrency errors you can make by just going threaded without thinking about it though, and in that example an obvious problem is that whatever triggered the IBAction can [probably] trigger it several more times before doExpensiveOperationOn has finished. Multithreading is not something to be dashed into lightly.
For anyone's future reference, the easiest approach I found is to use the async request functionality built into ASIHTTPRequest, setting my library object as the delegate and setting the didFinishSelector: and didFailSelector: values to different methods inside my library for each request.
At the end of processing each response, I assign the parsed response (an NSString* or NSArray*) to a property of my library object instead of returning a value.
When my iOS view controller delegate is loaded, I add a change observer to each of the properties in the library using Key-Value Observing. When the response is parsed and assigned to the property in the library, the observeValueForKeyPath:ofObject:change:context: method is called in the code of my view controller delegate, and from there I can figure out which property was changed and therefore what UI needs to be updated.
I'm trying to create a class which will let me get requested data from a web service. I'm stuck on how to return the values.
// FooClass.m
// DataGrabber is the class which is supposed to get values
dataGrabber = [[DataGrabber alloc] init];
xmlString = [dataGrabber getData:[NSDictionary dictionaryWithObjectsAndKeys:#"news", #"instruction", #"sport", #"section", nil]];
In this example, it's supposed to get the sports news. The problem is that the DataGrabber gets the data asynchronously and ends up hopping from several NSURLConnection delegate methods. How do know in FooClass when data has been received?
The delegate pattern used with a strict protocol is very useful for this (that's how DataGrabber would find out when NSURLConnection is done, right?). I have written a number of Web APIs that consume XML and JSON information this way.
// In my view controller
- (void) viewDidLoad
{
[super viewDidLoad];
DataGrabber *dataGrabber = [[DataGrabber alloc] init];
dataGrabber.delegate = self;
[dataGrabber getData:[NSDictionary dictionaryWithObjectsAndKeys:#"news", #"instruction", #"sport", #"section", nil]];
}
Then in your DataGrabber.h file:
#protocol DataGrabberDelegate
#required
- (void) dataGrabberFinished:(DataGrabber*)dataGrabber;
- (void) dataGrabber:(DataGrabber*)dataGrabber failedWithError:(NSError*)error;
#end
And in DataGrabber.m:
- (void) getData:(NSDictionary*)dict
{
// ... Some code to process "dict" here and create an NSURLRequest ...
NSURLConnection *connection = [NSURLConnection connectionWithRequest:req delegate:self];
}
- (void) connectionDidFinishLoading:(NSURLConnection*)connection
{
// ... Do any processing with the returned data ...
// Tell our view controller we are done
[self.delegate dataGrabberFinished:self];
}
Then make sure that Foo is implements the DataGrabberDelegate protocol methods to handle each case.
Finally, your DataGrabber has a delegate property (make sure you use assign, not retain to avoid retain cycles):
#property (nonatomic, assign) id<DataGrabberDelegate> delegate;
And when the NSURLConnection asynchronous loads are finished inside of DataGrabber, they call back to your UIViewController in the protocol laid out above so that you can update the UI. If it's ONE request, you could theoretically get rid of DataGrabber and put it inside your view controller, but I like to "separate my concerns" - API and View Controller stay separate. It generates an extra layer, but it keeps "text processing code" out of the view controllers (specifically for JSON and XML parsing code).
I've done this many times with success - one other key is that it's good to provide the user with some feedback that a page is loading - turn on the activity indicator in the status bar, show them a UIActivityIndicator, etc., and then when your delegate callback comes back with either success or failure, you get rid of it.
Finally, I've written a more detailed blog post about this: Consuming Web APIs on the iPhone
you could implement notifications for your DataGrabber class that go off any time you receive a certain amount of data (or when the download is finished if you want) and then the notified method (read about Notifications in the documentation) can do any handling you might want.
Note: it'd be helpful if FooClass was the delegate of DataGrabber
I also use notifications for this. Here is a good detailed explanation of how to set this up.
How can I create a new file containing just it's own delegate so that I can make an ASIHTTPRequest with its own asynchronous ending, and something easy enough where I just need to set [request setDelegate:self]; to something like [request setDelegate:AlternateDelegate]; and just add an include at the begining of the document to reference the AlternateDelegate delegate
I know this question is old, but in case anyone comes across it:
#Hankweb seemes to be talking about using a request as its own delegate. There are certainly situations where this works. For example, I'm working on a project that uses ASIHTTPRequest to fetch JSON from a remote source and import it into a Core Data store.
This operation (literally, as ASIHTTPRequest is a subclass of NSOperation) is almost entirely self-contained; I have a custom request on a background thread using a streaming JSON parser to import objects into a NSManagedObjectContext, which, when saved, triggers a notification that I catch internally and pass to the main thread's context using performSelectorOnMainThread:waitUntilDone:.
I'm using ASIHTTPRequest's block support to accomplish this; in my custom initWithURL: method, I set up the relevant callbacks (dataReceivedBlock, completionBlock, failureBlock, etc.). The traditional delegation pattern (using the ASIHTTPRequestDelegate protocol) should also work, though.
One gotcha: you should make sure the request doesn't retain itself too many times, or else you'll end up with a memory leak. This can be easy to miss when using multiple threads, and especially when using blocks. Instead of:
- (id)initWithURL:(NSURL *aURL) {
//...
[self setCompletionBlock:^{
[self doSomething];
}];
//...
return self;
}
Use the __weak attribute (or __block if you're not using ARC) when referencing self within the blocks:
- (id)initWithURL:(NSURL *aURL) {
//...
__weak id blockSelf = self;
[self setCompletionBlock:^{
[blockSelf doSomething];
}];
//...
return self;
}
If you don't know why this is important, make sure to read Apple's guide to blocks in Objective-C, and the ASIHTTPRequest block API documentation.
A delegate for ASIHTTPRequest is just a standard objective C object. Just create a new class, include it's header, create/get the object and set the delegate to be that object.
Have you tried this and run into a problem? If so what is the problem?
I have some iPhone SDK 4.0 code which initializes an NSOperationQueue and then adds three classes (ClassA, ClassB, and ClassC) to run one after the other. ClassA, ClassB, and ClassC are all sub-classes of NSOperation.
The relevant code is included below.
ClassA *classA = [[ClassA alloc] init];
ClassB *classB = [[ClassB alloc] init];
ClassC *classC = [[ClassC alloc] init];
[classB addDependency:classA];
[classC addDependency:classB];
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
[queue addOperation:classA];
[queue addOperation:classB];
[queue addOperation:classC];
[classA release];
[classB release];
[classC release];
[queue release];
The reason for the dependencies is because classB should only run if classA completes its operation successfully. Likewise, classC should only run if classB completes successfully.
At the moment I am having difficulty figuring out how to prevent, for example, classB from running if classA does not complete successfully. Continuing with this example, I was thinking of somehow evoking [NSOperationQueue cancelAllOperations] from within classA but I don't know how to get a handle on the parent NSOperationQueue from within classA (which is an NSOperation sub-class). This was just my initial thought, so I would be open to any other better suggestions for achieving the same outcome!
There is conditional code within each of the classes to determine whether they have completed properly - at the moment they are just NSLogging "Success" or "Fail" to the Console for debugging purposes. In a perfect world I would just like to be able to replace the NSLog(#"Fail") statement in each class with some code which will stop all of the other classes in the NSOperationQueue from running.
Any suggestions would be most welcome (and appreciated).
You could set a property in classA :
#property (readonly) BOOL completedSucessfully;
and set this to YES at the end of classA's main method.
Then, just check it at the start of classB.
- (void)main {
if (NO == [[dependencies objectAtIndex:0] completedSucessfully])
return;
Now, classB will just stop if classA reports failure.
NB You will probably need more error checking that in the example above i.e. making sure that you have dependencies, checking that it's the correct class etc.
- (void)main {
for (id *temp in [self dependencies])
if ([temp isKindOfClass:[ClassA class]])
if (NO == [(ClassA *)temp finishedSucessfully])
return;
I would suggest, if speed is not an issue, you can work synchronously. Else you can use:
[selector:#selctor(StartB) waitUntilTaskComplete:YES];
After viewing the WWDC 2015 session on advanced NSOperation techniques (highly recommended) I started using them in-depth in my own code. Here are some suggestions to achieve this
From within an NSOperation you can call [self currentQueue] to get "The operation queue that started the operation or nil if the queue could not be determined." You could then call cancelAllOperations on the returned queue. Empirically I have had difficulty using this approach because if you explicitly run code on the main queue, have code in a closures/block, or call a third party library, then the queue returned may not be the initial queue at all. In that situation calling cancelAllOperations will not result in the expected behavior - instead you are canceling the operations on a different queue.
Subclass NSOperation to include a property for the initial NSOperationQueue and subclass NSOperationQueue to set the property when the operation is added to the queue. Then call cancelAllOperations on self.initialQueue. This is the approach I'm using and works across all the scenarios mentioned above.
Instead of canceling all operations at the queue level, you can call the operation "cancel" method and finish your operation. If your operations have been written to conform to Apple's operation guidelines, they all check isCancelled when starting, and abort processing if true. It's a subtle difference: when you cancel the queue operations, any operations that haven't been started will not be started at all. When you set the operations to isCancelled, subsequent operations are started but (should) finish shortly there after. This allows scenarios where later operations might perform some cleanup, error handling, or user notification.