views:

62

answers:

5

I have an iphone3g with this function running in my ViewController

- (void)viewDidAppear:(BOOL)animated {

[super viewDidLoad];

}

I use a TabBar iphone app. But when I click from tab 1 to tab 2 and debug the secondView Controller it is stopped before the view is actually in the users view.

So there for when you click tab 2 until every function inside - (void)viewDidAppear:(BOOL)animated is complete the user gets to see the view.

Where is the function ViewDidShowToUser? Now I have a few functions running so it's sometimes slow and you're thinking the button is not working really..

+1  A: 

you are calling super on viewDidLoad: inside of viewDidAppear: ....change the line [super viewDidLoad]; to [super viewDidAppear:animated];

Jesse Naugher
Thanks guys. Yourright but the problem is also inside IB.Couse: When i debug my app.It triggers ViewDidLoad First after cellForRowAtIndexPath....i think thats couse of the files owner is a ViewController and added the protocols for delegate and datasource. In my other app viewDidload was trigger after the cellForRowAtIndex path thats couse my other app was a TableViewController...But at this time my view is some more complex so i use a small tableView inside the View.. Ok i will try option 2.Thanks
Michiel Ponjee
+3  A: 

First of all, you're calling [super viewDidLoad] instead of [super viewDidAppear:animated] inside your implementation of -viewDidAppear:

Secondly, using the debugger and breakpoints gives an artificial view of how your app behaves. In real world usage, users aren't going to notice that the -viewDidAppear: method returns before actually showing the view.

The real problem is your work that takes too long to complete and makes the app appear sluggish. You should consider performing the work asynchronously, and you have a couple of options to do that.

  1. In your viewDidAppear: implementation you could use performSelector:withObject:afterDelay: to queue up the work. This method will return immediately and schedule your selector to be called in whatever time period you specify. If you pass 0 as the delay, it'll be queued up to run on the next iteration of the run loop, effectively giving you a way to return from the method and keep the user interface responsive.

  2. You could use blocks, if you're not targeting anything below iOS4, and harness the power of Grand Central Dispatch to thread out your work nice and safely.

Jasarien
A: 

Jasarien do you have a tutorial about this option?

Michiel Ponjee
this post should be a comment, not its own answer...
iWasRobbed
A: 

There's no easy way to tell.

UIKit makes UIViews. UIViews draw to CALayers. CALayers are handled by CoreAnimation.

CoreAnimation decides when to ask UIView to draw the layers. It draws all the layers on screen and then composites them on the GPU. Only after they're composited does the screen display the updated UI. This decoupling happens in order to allow CoreAnimation to do the majority of the work independently of the UI thread, but it means that you can't easily tell what's "actually on screen".

There is no easy way to tell when the screen has actually displayed something (apart from the now-private UIGetScreenImage()). viewDidAppear: gets called after UIKit finishes constructing (and animating) the views/layers. At that point, they will be "seen" by CoreAnimation after the next run loop, and displayed shortly thereafter. If you do lots of processing in viewDidAppear:, then CoreAnimation will never see the updated "model tree".

tc.
A: 

tc you are smart :) But any extra idea's to solve it? If my view in IB was a tableView and my files owner was a TableViewController there would be no problem. But couse i added a UITableView to a UIView in IB i get this annoying feature.

Thanks

Michiel Ponjee