1

Assume we have one UIVewcontroller, call it A, in the viewdidload of that VC we add to it two UIViewcontrollers( B,C ). now to make the UI smooth in the Viewdidload of A we do some GCD work

  dispatch_queue_t queue = dispatch_queue_create("CustomQueue", NULL);
  dispatch_async(queue, ^{
  // Create views, do some setup here, etc etc
  // Perform on main thread/queue
   dispatch_async(dispatch_get_main_queue(), ^{
     // this always has to happen on the main thread
    [self.view addSubview:myview1];
    [self.view addSubview:myview2];
    [self.view addSubview:myview3];
   });
 });

Now based on this code, am I guaranteed that the views will be added in the same order? view 1 , then 2 , then 3?

I am noticing that arbitrarily some views shows up before others !!

Huang
  • 1,355
  • 2
  • 11
  • 28
  • Yes, `myview1` will be added first, then `myview2`, then `myview3`. – rmaddy Feb 25 '13 at 21:15
  • not really, I am noticing a random pattern, most of the time it goes by that order, but I do notice that other views are added out of order !! – Huang Feb 25 '13 at 21:27
  • 1
    As long as all calls to add subviews are done on the main thread, then it shouldn't be possible for subviews to be out of order. The methods inside a `dispatch_async` block are called in order, just like methods would be called normally. Are you saying these three views sometimes appear in a different order or are you saying that sometimes other views get mixed between these three? – rmaddy Feb 25 '13 at 21:30
  • You may be adding to the superview in the right order, but the superview may not be drawing it in the same order? – timthetoolman Feb 26 '13 at 01:42

1 Answers1

4

Your problem is almost certainly this part:

  dispatch_async(queue, ^{
  // Create views, do some setup here, etc etc

You cannot do anything view-related (or really anything UIKit-related) on a background thread. Period.

Lily Ballard
  • 182,031
  • 33
  • 381
  • 347
  • He is doing it correctly. Inside this background queue is dispatching a block to the main thread, so that is perfectly fine. The only way you cannot ensure the run order of a queue is in the case it is concurrent. If you need depencences (run these blocks, but this must run only if this other has already run) use the NSOperationQueue Class and NSOperation (and its subclasses like NSBlockOperation). These classes are an abstraction of Grand Central Dispatch that work object-oriented and are used by Apple Frameworks. – Lluís Feb 25 '13 at 21:43
  • 1
    No he isn't. He's creating views on the background queue – Catfish_Man Feb 25 '13 at 21:46
  • While you should do all your view hierarchy manipulation on the main thread, you can do some UIKit stuff on a background thread. For example, [UIGraphicsGetImageFromCurrentImageContext()](http://developer.apple.com/library/ios/documentation/uikit/reference/UIKitFunctionReference/Reference/reference.html#//apple_ref/c/func/UIGraphicsGetImageFromCurrentImageContext) can be run on a background thread as of iOS 4. The idea that UIKit is not thread-safe is not strictly true any more. – Zev Eisenberg Feb 25 '13 at 21:48
  • yes, I am creating views on the backgroundthread, the important thing is when you add them to the main view that ha to happen on the main thread, which I am doing already. From UIVIew reference : Threading Considerations Manipulations to your application’s user interface must occur on the main thread. Thus, you should always call the methods of the UIView class from code running in the main thread of your application. The only time this may not be strictly necessary is when creating the view object itself but all other manipulations should occur on the main thread. – Huang Feb 25 '13 at 21:49
  • @ZevEisenberg: UIImage manipulation is pretty much the only exception to the idea that UIKit is main-thread-only. And even that only came in with iOS 4.x. – Lily Ballard Feb 25 '13 at 22:21
  • @Huang: The bit about "may not be strictly necessary" surprises me. If I had to guess, I'd say that may apply to `UIView` but is not guaranteed to apply to subclasses of `UIView`. – Lily Ballard Feb 25 '13 at 22:32