executing NSOperations in another NSOperation - objective-c

I have an app that needs to synchronize multiple entity types with a backend using an API.
To do that I created a subclass of NSOperation for each HTTP method (GET/POST/PUT/DELETE => 4 operations). For a given entity these operations have to be run in a specific order, so I created a 5th operation subclass which contains the synchronization sequence (basically an operation that creates multiple GET/POST/PUT/DELETE operations in the appropriate order and adds these operations to a queue created by the operation.).
Since i want to be able to synchronize multiple kind of entities (for example 'Users' / 'Events' / 'Tasks') at the same time depending on the connection of the user and with dependencies between some types of entities (for example i need to finish the 'Users' synchronization before i can start concurrently the 'Events' and 'Tasks' synchronizations) I use a NSOperationQueue that contains only NSOperations of type synchronization.
So just to sum up, if I made 1 change of each type (1 create, 1 update, ...) on each type of object, and that i want to synchronize everything. I'll have 1 NSOperationQueue that will contain 3 NSOperations (1 for each type of object), and each NSOperation will have its own NSOperationQueue that should run 4 NSOperation (1 for each change type).
Now comes the problems :
1st/ The "sub-operations" are using async NSURLConnection, and I don't know how should the NSURLConnection be configured ?
Should i use something like this :
connection = [[NSURLConnection alloc] initWithRequest: theRequest delegate: self startImmediately: NO];
NSRunLoop * currentRunLoop = [NSRunLoop currentRunLoop];
[currentRunLoop addPort: [NSPort port] forMode: NSDefaultRunLoopMode];
[connection scheduleInRunLoop: currentRunLoop forMode: NSDefaultRunLoopMode];
[connection start];
[currentRunLoop run];
Or should i use that :
while (!finished)
{
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}
2nd/ At the moment i am overriding start for the operations because i want to be able to start them without using an NSOperationQueue when I have only 1 operation. Is it correct ? If yes, are there examples somewhere of start method implementations ?
3nd/ About the runloops and threads, each operation will always get a different runloop and thread ? And this thread / runloop management must be handled in the start method if i override it ?
4th/ is it a problem to use queue like I do (i think it's justified in my case) ?

1) I tend to use the synchronous request when running in the background. I find it's cleaner and you're in the background already anyways.
2) Subclassing NSOperation in my opinion is not flexible and creates sort of sloppy code. Instead I would suggest keeping some sort of services class that has an NSOperationQueue and from there use the [NSOperationQueue addOperationWithBlock:]. You can even take it a step further if you want and create an NSBlockOperation. The main thing you gain from this API is the ability to have a completion block. But i find that keeping the services layer and the operations (in this case in the form of blocks) easier to manage and understand. You can even create functions that return blocks so the blocks can be reused how ever you need. This may help you to have better code reuse than subclassing NSOperation
Example:
-(void)foo
{
__weak ClassName wself = self;
void(^opBlock)() = ^{ [wself doStuff]; };
[_queue addOperationWithBlock:opBlock]
}
3) Yes your queue will have its own run loop.
4) Maybe refer to the others

Related

Thread Handling with NSURLSessionDataTask

In a nutshell, I am trying to display data from a publicly available JSON file on the WEB. The process is the following:
I initiate the download with an NSURLSessionDataTask, then I parse and display the JSON or handle errors if they occur. Here is my relevant code:
- (void) initiateDownload {
NSURLSessionConfiguration *sessionConfig = [NSURLSessionConfiguration defaultSessionConfiguration];
sessionConfig.timeoutIntervalForRequest = 5.0f;
sessionConfig.timeoutIntervalForResource = 20.0f;
NSURLSessionDataTask *downloadWeatherTask = [urlSession dataTaskWithRequest:urlRequest
completionHandler:^(NSData *data, NSURLResponse *response, NSError *downloadError) {
if (downloadError) {
dispatch_sync(dispatch_get_main_queue(), ^{
[self errorReceived:downloadError];
});
} else if (data) {
dispatch_sync(dispatch_get_main_queue(), ^{
[self parseWeatherJSON:data];
});
}
}];
[downloadWeatherTask resume];
}
I have a couple of questions about this:
I am not all that familiar with thread handling. Although I added the
dispatch_sync(dispatch_get_main_queue(), ...)
to both completion blocks, and it seems to work, I am not sure this is the best way to be thread safe (before, I received all kinds of error messages and displaying the data took 10 seconds after the download has already finished). Is there a better way to handle the download and the threads or mine is an acceptable solution?
I would like the user to be able to initiate the download process manually any time he/she wants to refresh the data displayed. At first, I initialized the NSURLSessionDataTask once and made it available anywhere within the class; so I could just call resume every time a refresh is called. However, I could not find a command to re-do the download process. Once I called [downloadWeatherTask resume], I was unable to start the task from the beginning.
So, I added the task to a separate function (the one you see above) and initialize it there every time the function is called. This works fine, but I am not sure it is the best way to go. For example, is it memory safe or am I creating a new task every time the user initiates a refresh call and will eventually run out of memory?
Thank you for the answers!
A little more info: I use the latest XCode 11 and target iOS 9 and up.
NSURLSession will, by default, use a dedicated background serial queue for completion blocks (and delegate methods, should you do that). But you really want to make sure you trigger UI updates from the main queue (retrieved via dispatch_get_main_queue()). And you generally want to avoid updating properties and ivars from multiple threads (unless, they have some thread-safety built in to them, which is unusual), so dispatching the updates to those properties/ivars back to the main queue is a nice simple way to achieve thread safety.
So, bottom line, what you’re doing here is fine.
However, I could not find a command to re-do the download process.
You perform (resume) a given task only once. If you want to perform a similar request again, instantiate a new NSURLSessionDataTask.

how to wait perform tasks in objective-c

I have a question how to wait perform several tasks that are in some method even that method is called few times in different threads;
For example:
When I call method:
1:
2:
I want to see the following:
1:
STEP 1, STEP 2;
2:
STEP 1, STEP 2;
but often I see the following:
1:
2:
STEP 1, STEP 1,
STEP 2, STEP 2,
See code below, maybe it helps to understand the problem better;
//many times per second
- (void)update:(UpdateObjectClass *)updateObject {
//step 1:
//update common data(for example array)
//long process(about 1-2 seconds)
[self updateData:updateObject];
//step 2:
//update table
[self updateTableView];
}
I have tried to use dispatch_barrier_async, but I don't understand how to use this in proper way;
Thank you for any help ;)
I'm borrowing from #remus's answer.
Assuming that -[update:] is being called on the same instance of an object (and not a whole bunch of objects), you can use #synchronized to enforce that your code is only performed one-at-a-time.
dispatch_async(dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void){
#synchronized(self) {
// Run your updates
// [self updateData:updateObject];
dispatch_async(dispatch_get_main_queue(), ^(void){
// Async thread callback:
[self updateTableView];
});
}
});
However
I am going to go out on a limb, and guess that the reason you need this code to be performed synchronously is because your -[updateData:] method is doing something that is not thread safe, such as modifying a NSMutableDictionary or NSMutableArray. If this is the case, you should really use that #synchronized trick on the mutable thing itself.
I highly recommend that you post the code to -[updateData:] if it is not too long.
You are trying to solve the problem at the wrong level and with the information in the question it is unlikely that any solution can be provided.
Given the output reported we know that updateData and updateTableView are asynchronous and use one or more tasks. We don't know anything about what queue(s) they use, how many tasks they spawn, whether they have an outer task which does not complete until sub tasks have, etc., etc.
If you look at the standard APIs you will see async methods often take a completion block. Internally such methods may use multiple tasks on multiple queues, but they are written such that all such tasks are completed before they call the completion block. Can you redesign updateData so it takes a completion block (which you will then use to invoke updateTableView)?
The completion block model doesn't by itself address all the ways you might need to schedule a task based on the completion of other task(s), there are other mechanisms including: serial queues, dispatch groups and dispatch barriers.
Serial queues enable a task to be scheduled after the completion of all other tasks previously added to the queue. Dispatch groups enable multiple tasks scheduled on multiple queues to be tagged as belonging to a group, and a task scheduled to run after all tasks in a group have completed. Dispatch barriers enable a task to be scheduled after all previous tasks scheduled on a concurrent queue.
You need to study these methods and then embed the appropriate ones for your needs into your design of updateData, updateTableView and ultimately update itself. You can use a bottom up approach, essentially the opposite of what your question is attempting. Start at the lowest level and ask whether one or more tasks should be a group, have a barrier, be sequential, and might need a completion block. Then move " upward".
Probably not the answer you were hoping for! HTH
Consider using dispatch_async to run the array updates and then update your tableView. You can do this inside of a single method:
dispatch_async(dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void){
// Run your updates
// [self updateData:updateObject];
dispatch_async(dispatch_get_main_queue(), ^(void){
// Async thread callback:
[self updateTableView];
});
});
Edit
I'd consider modifying your updateData method to run inside the async queue; when it is done, call [self updateTableView]; directly from that method. If it's not too long, can you add the [self updateData:updateObject] code (or a portion of) to your question?

NSOperationQueue callback before an operation is started?

Is there a way I can find out if/when an operation is about to start/execute on an NSOperationQueue?
I am using NSURLConnection's setDelegateQueue: and I need to know when it fires.
In your NSOperation subclass add a copy property for a willStartBlock. At the beginning of main - before any other actions - call this block if it is set.
This way you can set up the actions to perform when the operation starts at the same time when you create the operation and before you put it into the operation queue.
The problem in your specific question is that you don't create the operations that are created on your queue. You can try to subclass NSOperationQueue and override the three public addOperation* methods. If you're lucky then one of these is the one that the NSURLConnection uses to append the callback operation to your queue.
May i know what exactly you want to do.
I am not sure what you want to achieve as it is not clear from your question but you can do something like that:
currentConnection = [[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:NO];
if (self.operationQueue) {
[currentConnection setDelegateQueue:self.operationQueue];
}
[currentConnection start];
NSURLConnection gets invoked once start method gets called.
You can also subclass NSOperation and override start method.

how to run functions in order in objective c

i have a problem with queued functions. i want to run my function and when my first function finishes running, i want to start other one.
-(void)firstFunct
{
// sending and getting information from server.
// doing sth and creating data to use in my second function.
}
and my second function is:
-(void)secondFunct
{
// using data coming from first function
}
i am now using these 2 functions in like that
-(void)ThirdFunct
{
[self firstFunct];
[self performSelector:#selector(secondFunct) withObject:nil afterDelay:0.5];
}
but there is a problem that this method is not good to use. i want to learn if there is an efficient way to run the functions one after the other.
You can simply call one function after the other:
- (void) thirdFunct
{
[self firstFunct];
[self secondFunct];
}
If you want to run this whole block in the background, not blocking the UI thread, use Grand Central Dispatch:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_NORMAL, 0), ^{
[self firstFunct];
[self secondFunct];
});
And if the first function contains some asynchronous call, that call should offer some kind of interface to run code after the call finishes, like a delegate call or a completion block.
Well, yes, zoul's spot on for the normal case.
However, you mentioned a server was involved. In that case, you probably have an asynchronous request. What you want to do is read the documentation of the class you use to make the network request, and learn what callbacks it uses to notify you when it is complete.
Cocoa offers nice concurrency management classes like NSOperation and NSOperationQueue. You could use them to simplify the logic behind chaining your asynchronous calls without creating explicit connections in code to call method 3 after work 2 completes, and method 2 after work 1 completes, and so on. Using dependency management, you could easily specify those dependencies between your operations.
Here's a simple example of how you would use that code. Suppose you are downloading some data asynchronously in all those three methods, and you've created a NSOperation subclass called DownloadOperation.
First, create a NSOperationQueue.
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
Then, create the three download operations.
DownloadOperation *a = [[DownloadOperation alloc] init];
DownloadOperation *b = [[DownloadOperation alloc] init];
DownloadOperation *c = [[DownloadOperation alloc] init];
Then, specify the dependencies between your operations. Dependencies simply say that an operation can run only if all the operations it depends upon are complete. In your example, the dependencies look like c <- b <- a, which can be broken down into two steps:
[b addDependency:a];
[c addDependency:b];
Now add these operations to the queue.
[queue addOperations:#[ a, b, c ] waitUntilFinished:NO];
The queue will automatically start processing all operations at this point, but since we've creating this chaining sort of a dependency, they will be executed one after the other in our particular example.
I've created a sample project on github demonstrating it with a simple example at https://github.com/AnuragMishra/ChainedOperationQueue. It fakes an asynchronous operation by creating a timer, and when the timer finishes, the operation is marked complete. It's written using Xcode 4.5, so let me know if you have issues compiling it in older versions.
if you write your methode like this
-
(void)ThirdFunct
{
[self firstFunct];
[self secondFunct];
}
secondFunct is called after firstFunct. Your problem comes certainly from the network request which is asynchronous. To be sure that your secondFunct is executed after an asynchronous request you have to execute it from delegate or block.
Checkout NSURLConnectionDelegate if you NSURLConnection

NSURLConnection vs. NSData + GCD

NSData has always had a very convenient method called +dataWithContentsOfURL:options:error:. While convenient, it also blocks execution of the current thread, which meant it was basically useless for production code (Ignoring NSOperation). I used this method so infrequently, I completely forgot that it existed. Until recently.
The way I've been grabbing data from the tubes is the standard NSURLConnectionDelegate approach: Write a download class that handles the various NSURLConnectionDelegate methods, gradually build up some data, handle errors, etc. I'll usually make this generic enough to be reused for as many requests as possible.
Say my typical downloader class runs somewhere in the ballpark of 100 lines. That's 100 lines to do asynchronously what NSData can do synchronously in one line. For more complexity, that downloader class needs a delegate protocol of its own to communicate completion and errors to its owner, and the owner needs to implement that protocol in some fashion.
Now, enter Grand Central Dispatch, and I can do something as fantastically simple as:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
NSData* data = [NSData dataWithContentsOfURL:someURL];
// Process data, also async...
dispatch_async(dispatch_get_main_queue(), ^(void) {
// Back to the main thread for UI updates, etc.
});
});
And I can throw that sucker in anywhere I want, right in-line. No need for a download class, no need to handle connection delegate methods: Easy async data in just a few lines. The disparity between this approach and my pre-GCD approach is of a magnitude great enough to trigger the Too Good to be True Alarm.
Thus, my question: Are there any caveats to using NSData + GCD for simple data download tasks instead of NSURLConnection (Assuming I don't care about things like download progress)?
You are losing a lot of functionality here:
Can't follow the download progression
Can't cancel the download
Can't manage the possible authentication process
You can't handle errors easily, which is really important especially in mobile development like on iPhone of course (because you often lose your network in real conditions, so it is very important to track such network error cases when developing for iOS)
and there's probably more I guess.
The right approach for that is to create a class than manages the download.
See my own OHURLLoader class for example, which is simple and I made the API to be easy to use with blocks:
NSURL* url = ...
NSURLRequest* req = [NSURLRequest requestWithURL:url];
OHURLLoader* loader = [OHURLLoader URLLoaderWithRequest:req];
[loader startRequestWithCompletion:^(NSData* receivedData, NSInteger httpStatusCode) {
NSLog(#"Download of %# done (statusCode:%d)",url,httpStatusCode);
if (httpStatusCode == 200) {
NSLog(%#"Received string: %#", loader.receivedString); // receivedString is a commodity getter that interpret receivedData using the TextEncoding specified in the HTTP response
} else {
NSLog(#"HTTP Status code: %d",httpStatusCode); // Log unexpected status code
}
} errorHandler:^(NSError *error) {
NSLog(#"Error while downloading %#: %#",url,error);
}];
See the README file and sample project on github for more info.
This way:
you still rely on the asynchronous methods provided by NSURLConnection (and as the Apple's documentation says about Concurrency Programming if an API already exists to make asynchronous tasks, use it instead of relying on another threading technology if possible)
you keep advantages of NSURLConnection (error handlings, etc)
but you also have the advantages of the blocks syntax that makes your code more readable than when using delegate methods
WWDC 2010 Session Videos:
WWDC 2010 Session 207 - Network Apps for iPhone OS, Part 1
WWDC 2010 Session 208 - Network Apps for iPhone OS, Part 2
The lecturer said
"Threads Are Evil™".
For network programming, it is strongly recommended to use asynchronous API with RunLoop.
Because, if you use NSData + GCD like the following, it uses one thread per connection.
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
NSData* data = [NSData dataWithContentsOfURL:someURL];
And it's likely to use many connections and many threads. It is too easy to use GCD :-)
Then, many threads eats huge amount of memory for its stack.
Thus, you'd better to use asynchronous API as AliSoftware said.
As of OS X v10.9 and iOS 7 the preferred way is to use NSURLSession. It gives you a nice, block-based interface and features like canceling, suspending and background downloading.