New to iOS, kindly bare if the question is very basic? When I press the tab button multiple times, it is not invoking viewWillAppear function? If I am wrong, then which function gets invoked, each time a tab button is pressed being on the same tabview?
You are correct, viewWillAppear is a little special, it is usually called automatically but in some cases including when you are adding a view controllers view manually (view addSubview:), and also when adding this as a view controller to a UITabViewController it doesn't get messaged.
This however is only for the root view, as you navigate (maybe with a navigation controller) back and forth, that root view's viewWillAppear will get triggered as some point.
In short, if you need to implement something in viewWillAppear in these cases, you should message it yourself when you know it's going to be presented. You can handle this case in your view controller, check out the following article about the matter:
http://www.touchthatfruit.com/viewwillappear-and-viewdidappear-not-being-ca
Good luck.
Related
In the view controller that has a UITabBarItem, i realized that viewDidLoad() method only gets called the first time when the tab bar item is clicked. So I dont know how to bring up the dynamic graphics when it's clicked the 2nd time. Can some guru help me on this? thanks in advance.
Should I conform to some kind of delegates or should i do it within didSelectViewController method on the root controller of all the tab bars? If i do the later one, it just seems to be weird since i think the controller that has the corresponding tab bar item should render itself instead of doing the rendering on root controller..
You want to put any code that should run every time the view controller appears in viewWillAppear: instead of viewDidLoad. viewDidLoad is designed for code that should run when the view backed by your UIViewController is created (and then possibly re-created after being thrown away during low-memory situations).
Actually i resolved this by using the parameter passed into the callback didSelectViewController(param).
I have a navigation controller with a UITableView which when goes to another view when a row is selected. When this loads the breakpoints get hit.
Good so far.
When I hit the back button, the table view appears fine, with data.
However, even though I have breakpoints enabled in the viewcontroller, none get hit like when it originally loaded! But yet, the data loads fine. The only breakpoint that registers now is when I click on a row (didSelectRowAtIndexPath).
Where are the breakpoints set that you are expecting it to break?
Perhaps you need to call the following in the viewWillAppear method...
[self.table reloadData];
It would depend on where your breakpoint is actually located. If you have a breakpoint in viewDidLoad method, then it will only be called once when the view is first created. When you go back from another view, the view is not loaded again. So the breakpoint will not hit. However, viewWillAppear method will be called.
You are using a navigation controller here. Navigation controller holds a navigation stack, which includes UIViews on top of each other, with the visible one on the top.
Now, let's say the table view was loaded, then you move to another (which is now the topmost view in the navigation stack). Note - the table view is not gone. It's there, just under the view you are currently presenting.
Thus, when you move back to the table view, it is not reloaded, because it was never gone (released), just hidden.
There are exceptions to the above, and sometimes a view which is not presented on screen will be released (low memory scenarios situations, for example), but you can't count on it.
The UINavigationController Class Referance explains this concept very well.
I'm trying to figure out what logic should go into the different UIViewController methods like viewDidLoad, viewDidAppear, viewWillAppear, ...
The structure of my app is that I have a root view controller that doesn't really have a view of its own, rather it has a tab view controller and loads other view controllers into it. But in the future, it may have to load other view controllers instead of the tab bar controller depending on app logic.
My main question is, what do people usually put into the viewDidLoad, .... methods.
Currently I:
viewDidLoad - setup the tab bar controller and set its view to the view controller's own view
viewDidAppear - check if user has stored login info
if not - present with login
if so, login and get app data for first tab
I'm trying to figure out now if my logic for setting up my tab bar controller should go into loadView rather than viewDidLoad.
Any help would be great. Small examples found on the web are great, but they don't go into detail on how larger apps should be structured.
You should not implement both -viewDidLoad and -loadView; they are for different purposes. If you load a NIB, you should implement -viewDidLoad to perform any functions that need to be done after loading the NIB. Wiring up the tabbar is appropriate there if you haven't already done it in the NIB.
-loadView should be implemented if you do not use a NIB, and should construct the view.
-viewWillAppear is called immediately before you come onscreen. This is a good place to set up notification observations, update your data based on model classes that have changed since you were last on screen, and otherwise get your act together before the user sees you. You should not perform any animations here. You're not on the screen; you can't animate. I see a lot of animation glitches due to this mistake. It kind of works, but it looks weird.
-viewDidAppear is called after you come onscreen. This is where you do any entry animations (sliding up a modal, for instance; not that you should do that very often, but I was just looking at some code that did).
-viewWillDisappear is called right before you go offscreen. This is where you can do any leaving animations (including unselecting tableview cells and the like).
-viewDidDisappar is called after you're offscreen (and the animations have finished). Tear down any observations here, free up memory if possible, go to sleep as best you can.
I touch on setting up and tearing down observations here. I go into that in more depth in View controllers and notifications.
viewDidLoad will be called once per lifetime of each UIViewController's view. You put stuff in there that needs to be set up and working before the user starts interacting with the view.
viewDidAppear is called whenever the view has appeared to the user. It could potentially be called more than once. An example would be the root screen of an app using a UINavigationController to push and pop a hierarchy of views. Put stuff in there that you'd want done every time. For example, you might want to hide the UINavigationBar of the root screen, but show it for all subscreens, so you'd do the hiding of the bar here.
Therefore, you'd put your logic for setting up your UITabBarController in viewDidLoad, since it only should be done once.
Regarding your app, is there a reason why you don't just make the UITabViewController be the controller loaded by your app delegate? It seems that you have a level of indirection in your app that you may or may not need. It's probably better to simplify it now, and refactor later if you need something more complex.
I'm starting to go a little crazy with this one.
I have an iphone application with a somewhat complex view structure it is a tabbed application with either a view controller or a navigation controller on each tab.
The main controller for one tab uses the viewDidAppear callback to reload any data that has been modified since the last time it was displayed and this behaves fine in most cases. The issue I have run into is that when I navigate in subviews(within the same tab) using the standard navigation controller push/pop mechanism the viewWillAppear and viewDidAppear on the main view always fire when I navigate back to it.
However if I load a modal view controller and then dismiss it, the viewWillAppear continues to fire but the viewDidAppear stops firing.
I am almost certain that this is tied to the need to manually call these callbacks on the modal controller but I cannot find the reference info on how to do this correctly. (I only see this viewDidAppear bug on the hardware, in the simulator it works as I'd expect)
If you need further clarification let me know and thanks for any input.
Yes, this is how it works. You are better off switching to using viewWillAppear.
This has the added advantage of updating the data before the screen is redrawn.
viewDidLoad should be used for one-time setup operations:
Setting titles
Instantiating subviews, content arrays
Anything else related to the infrastructure of the view in question
After that, use viewWillAppear: to do anything related to refreshing data. You shouldn't have to call any of the viewDid/viewWill methods manually – that's handled by the innards of UIView. viewDidLoad won't fire after you dismiss a modal view controller because, more than likely, the view never unloaded. viewDidLoad fires fine when you're navigating the a view controller stack since the new views need memory, requiring other views to unload, then be reloaded when they reappear.
So the the problem is that when someone touches the back button on the UINavigationControler, I would like to run some code to update the datasource.
The problem is that i cant seem to find the right delegate to do it. only these are available on the nav controller delegate, and i want the 'didfinishshowing' type method.
– navigationController:willShowViewController:animated: optional method
– navigationController:didShowViewController:animated: optional method
The next best place i thought was the nav bar but when i try that.
Terminating app due to uncaught
exception
'NSInternalInconsistencyException',
reason: 'Cannot manually set the
delegate on a UINavigationBar managed
by a controller
This makes sense retrospectively, as you don't want some hacker messing around with the internals of the nav controller and stopping it from working.
This must is a common problem, and i have missed something simple.
Just so we're clear: view A is the starting point. User taps something and you slide right to view B. User taps the back button and you're going from B back to A and you want to do something as a result of the 'back' action.
There are three ways to do it (and on neither do you have to go near the navigationController -- these apply to the underlying viewControllers themselves):
As dmercredi suggests override viewWillAppear on view controller A so when you're heading back to it, it refreshes itself. Problem is that viewWillAppear is also called when A is called the very first time. So you'll have to set some sort of flag to distinguish between the first viewWillAppear and any subsequent ones when returning from B.
Override viewWillDisappear on view controller B and do your refreshing there. This will only get called when B is about to go away. If there's something on B that goes one level deeper or brings up a modal dialog on top, viewWillDisappear is going to get called so again you'll have to distinguish between the coming and the going.
Decouple the various views and use the delegate pattern. View controller A sets itself as a delegate of B and when B updates something it invokes the delegate method, so A is notified of the change and can update whatever it needs to. You can invoke the delegate method any time the user makes a change inside B or override viewWillDisappear and just do it one time on the way out.
Add your refresh code to the viewWillAppear:(BOOL)animated method on the view controller that is about to be displayed. In your case, that is the view controller that's already on the navigation stack.