I have a view controller that just shows progress during calculations. I put the method calls
in viewDidLoad but the problem is the view only appears once the calculations are done! How
could I automatically launch the calculations after the view has appeared on screen?
You may use GCD. Here is Raywenderlich tutorial
- (void)viewDidAppear:(BOOL)animated
{
[super viewDidAppear:animated];
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
//Calculations
dispatch_async(dispatch_get_main_queue(), ^{
//Update UI must be here
});
});
}
viewDidLoad: triggers when the view is loaded. This is different from when the view is displayed.
Try starting the calculations in the - (void)viewDidAppear:(BOOL)animated callback method on UIViewController instead.
If these calculations take a while, considering running them on a background thread. This will prevent the UI from locking up while the calculations are running. This has the bonus of not only allowing the view to show, but it can be interacted with while the user waits.
[self performSelectorInBackground:#selector(doCalc)
withObject:nil];
From that doCalc method you would call back to the main thread with the result.
[self performSelectorOnMainThread:#selector(didCalcValue:)
withObject:result
waitUntilDone:NO];
As others have correctly pointed out, viewDidAppear let's you know when the view has appeared on screen. *Also, don't forget to call super when you use these event methods.
Example:
// Tells the view controller that its view was added to the view hierarchy.
- (void)viewDidAppear:(BOOL)animated
{
// makes sure it's also called on the superclass
// because your superclass may have it's own code
// needing to be called here
[super viewDidAppear:animated];
// do your calculations here
}
Commonly used UIViewController events:
– (void)viewDidLoad
Called when your view first loads in memory.
– (void)viewDidAppear:
Called after your view has appeared on screen.
– (void)viewWillDisappear:
Called before your view will disappear from the screen.
See the full list on the UIViewController Class Reference page.
Related
When the user switches to another program and then back again., the original program's view will be replaced by a new view from another program. So when the user switches back to the original program, would viewDidLoad be called the second time ?
Am asking this because if this is the case, then the initialization code placed inside viewDidLoad would be executed every time the user switches the screen back and forth. And this could result in reseting views and loosing unfinished works of the user ...
Don't do view controller initialisation in viewDidLoad. This is a common mistake.
For stuff that should only happen once when the view controller is loaded, do it in the controller's init method, like this:
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)bundleOrNil
{
if ((self = [super initWithNibName:nibNameOrNil bundle:bundleOrNil]))
{
//do your initialisation here
}
return self;
}
The initWithNibName:bundle: method is called before the view is loaded from the nib, and is only called once in the lifespan of the view controller.
The controller's view can be loaded and unloaded multiple times during the lifespan of the controller and viewDidLoad will be called every time. It may be unloaded whenever it's not on screen, usually if memory is low.
If you do set stuff up in viewDidLoad (e.g. adding subviews programmatically) you should always unset them again in viewDidUnload.
Think of viewDidLoad and viewDidUnload as being like the init/dealloc for the view property of the view controller. For stuff that relates to the views, create and release it in those methods. For stuff that relates to the controller itself, create and release it in initWithNibName and dealloc.
UPDATE: On iOS 6 and later, viewDidUnload is never called any more (unless the view is explicitly set to nil in the code), and so viewDidLoad will typically only be called once in the life of a view controller. This makes the advice above less critical, but it's still best practice, and still necessary if you need to support iOS 5 and earlier.
UPDATE 2: If you are loading your view controller from a Storyboard (which is now the recommended practice) instead of creating it programmatically then initWithNibName:bundle: will not be called. Use initWithCoder: or awakeFromNib to initialize your controller instead.
#Nick Lockwood provides excellent information, but there are a few more things to remember.
First, initWithNibName:bundle: is not called if the view controller is instantiated from a nib file or storyboard. In that case, initWithCoder: and awakeFromNib are called instead. This situation used to be somewhat uncommon on iOS, but with the addition of storyboards it is now much more common for view controllers to bypass initWithNibName:bundle:.
I recommend putting non-UI initialization code in a separate method (I call mine setup) and call it from both initWithNibName:bundle: and awakeFromNib. But I only do this if it's important that that initialization only run once. Otherwise I put it in viewWillAppear: to be as lazy-load as possible.
Second, you should not do anything that references self.view in init... or awakeFromNib. You should never reference self.view until viewDidLoad is called (otherwise you will force the nib file to be loaded sooner than it is needed). UI-related things should go in viewDidLoad if they're related to setting up the views, or viewWillAppear: if they're related to configuring the views (i.e. loading them with data).
So the way I usually set these things up:
#implementation
- (void)setup {
// Non-UI initialization goes here. It will only ever be called once.
}
- (id)initWithNibName:(NSString *)nibName bundle:(NSBundle *)bundle {
if ((self = [super initWithNibName:nibName bundle:bundle])) {
[self setup];
}
return self;
}
- (void)awakeFromNib {
[self setup];
}
- (void)viewDidLoad {
// Any UI-related configuration goes here. It may be called multiple times,
// but each time it is called, `self.view` will be freshly loaded from the nib
// file.
}
- (void)viewDidUnload {
[super viewDidUnload];
// Set all IBOutlets to `nil` here.
// Drop any lazy-load data that you didn't drop in viewWillDisappear:
}
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
// Most data loading should go here to make sure the view matches the model
// every time it's put on the screen. This is also a good place to observe
// notifications and KVO, and to setup timers.
}
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
// Unregister from notifications and KVO here (balancing viewWillAppear:).
// Stop timers.
// This is a good place to tidy things up, free memory, save things to
// the model, etc.
}
- (void)dealloc {
// standard release stuff if non-ARC
[[NSNotificationCenter defaultCenter] removeObvserver:self]; // If you observed anything
// Stop timers.
// Don't unregister KVO here. Observe and remove KVO in viewWill(Dis)appear.
}
#end
-viewDidLoad will be called once whenever the view controller needs to load its view hierarchy. Obviously, that'll happen the first time that the controller accesses its view. If the view controller later unloads its view, then -viewDidLoad will be called again the next time the view is loaded. A view controller won't unload its view just because the view is hidden, but it might do so if memory starts to run low.
A view controller should know the state of its views and be able to set them up as necessary in its -viewDidLoad method. Views shouldn't be used to store state -- nothing should be irrevocably lost just because the view is unloaded.
So when the user switches back to the original program, would
viewDidLoad be called the second time ?
(Above is from the op)
In those cases there are two methods to be called:
- (void)applicationWillEnterForeground:(UIApplication *)application;
reopening a backgrounded app (from task manager or from springboard again)
unlocking device which is locked when the app is active.
- (void)applicationDidBecomeActive:(UIApplication *)application
after phone calls
notification center dismissal
task manager dismissal (double tap home button & double tap again)
From the docs:
This method is called after the view controller has loaded its associated views into memory.
So, it is called whenever the view controller has its views loaded into memory. This could be the first time the view is loaded and never again, or every time the view is made visible if your view unloads constantly (viewDidUnload due to memory constraints, etc.)
I'm stuck! I can't see why viewWillAppear doesn't run in my code but viewDidLoad runs. If I understand it correctly viewDidLoad runs once on the first instance and viewWillAppear runs every time a view is added to the stack of views to display.
I see others have had this issue but some how their solutions of calling viewWillAppear directly causes my app to crash. Other solutions were related to Navigation Controller and pushingView's but thats not what i'm using either! What am I missing?
Thanks in advance for your help! :)
See below:
View Controller #1 - Currently being displayed on screen
-(IBAction)someButtonPressed:(id)sender{
NSLog(#"FirstViewController - someButtonPressed");
SecondViewController *secondViewController = [[SecondViewController alloc] initWithNibName:#"SecondViewController" bundle:nil];
secondViewController.myLocation = self.myLocation;
secondViewController.myDatabase = self.myDatabase;
[self.view addSubview:secondViewController.view];
//[secondViewController viewWillAppear:YES];
}
SecondViewController:
- (void)viewWillAppear:(BOOL)animated {
NSLog(#"SecondViewController - viewWillAppear");
[super viewWillAppear:animated];
// updating ivars with data
}
// Implement viewDidLoad to do additional setup after loading the view, typically from a nib.
- (void)viewDidLoad {
NSLog(#"SecondViewController - viewDidLoad");
[super viewDidLoad];
}
If I understand it correctly viewDidLoad runs once on the first instance and viewWillAppear runs every time a view is added to the stack of views to display.
-viewDidLoad is called every time a UIViewController's view is loaded. That may be many times during a single controller's life as the view may be unloaded to free up memory when it is not visible and reloaded, triggering another call to -viewDidLoad, when needed.
-viewWillAppear: is called when a UIViewController's view becomes visible. However UIKit assumes that UIViewController's views will fill their window. Nesting UIViewControllers' views is an example of abusing UIViewControllers and will result in unexpected behavior. As you have seen.
See About Custom View Controllers in the View Controller Programming Guide for iOS:
Each custom view controller object you create is responsible for managing all of the views in a single view hierarchy. In iPhone applications, the views in a view hierarchy traditionally cover the entire screen, but in iPad applications they may cover only a portion of the screen. The one-to-one correspondence between a view controller and the views in its view hierarchy is the key design consideration. You should not use multiple custom view controllers to manage different portions of the same view hierarchy. Similarly, you should not use a single custom view controller object to manage multiple screens worth of content.
If you wrote a custom UIViewController Container you might have overwritten the following method, which leads to your described behavior.
- (BOOL)shouldAutomaticallyForwardAppearanceMethods{
return NO;
}
In this case you have to manually handle beginAppearanceTransition/endAppearanceTransition.
See Apples View Controller Containment article
viewWillAppear: is called when a view controller is displayed in one of the normal ways (e.g. by selecting a tab in a UITabBarController, by pushing onto a UINavigationController, by being popped back to in a UINavigationController, by being presented with presentModalViewController:animated, by being uncovered after dismissModalViewControllerAnimated:, etc). Just displaying a view with addSubview: does not call the method.
It is possible to correctly call viewWillAppear: manually, but in general it's better to use one of the normal ways mentioned above.
Just try this.. I got it working :)
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
NSLog(#"SecondViewController - viewWillAppear");
// updating ivars with data
}
When you push view or present a view controller by pushViewController:animated or presentModelViewController:animated:, they will call viewWillAppear:animated:, and else method for you. But if you addSubview: manually, you need to call those method by self.
I have A UINavigationController with a table view. As it's standard behaviour when an item in the list is selected I push a customViewController to the UINavigationController. The CustomView Appears and I see my back button in the title bar.
My question is, when I hit the back button in the title bar to navigate back to my list what function do I implement to make sure that everything that was created in the customViewController is completely destroyed and removed from memory?
I tried putting my cleanup code in the viewdidunload method of the custom controller but that doesnt even get entered when I hit the back button.
(Also I wasnt really sure how to phrase this question so suggestions are welcome)
Apple explains everything very clearly in their documenation (with pretty pictures and everything!). Basically, when you show the view you use pushViewController:animated: and when you go back you use popViewControllerAnimated:.
Use something like this to go to the new screen:
- (IBAction)goSomewhereButtonPressed:(id)sender {
SomewhereViewController *vc = [[SomewhereViewController alloc] initWithNibName:#"SomewhereView" bundle:nil];
[self.navigationController pushViewController:vc animated:YES];
[vc release];
}
When the BACK button is pressed, it will clean-up your screen. Apple recommends you use UINavigationControllerDelegate for additional setup & cleanup if needed.
Put the cleanup for the screen in its controller (SomewhereViewController).
- (void)viewDidUnload
{
[super viewDidUnload];
// Release any retained subviews of the main view.
// e.g. self.myOutlet = nil;
NSLog(#"Somewhere's viewDidUnload called");
}
- (void)dealloc
{
[super dealloc];
NSLog(#"Somewhere's dealloc called");
}
I always put my cleanup code in dealloc:
-(void)dealloc {
// cleanup code here
[super dealloc];
}
The allocated controllers inside a UINAvigationController will be removed automatically. If you need to let just one live, create the detail controller globally in your navigation controller instead every time you need to go to the detail view, so you will use always the same controller. You can clean it when the back button is pressed through the method viewDidDisappear.
The viewDidUnload method of UIViewController seems to be a good place to do memory cleanup, i.e. release all objects that can be easily recreated in viewDidLoad or later.
But it's not guaranteed that the view controller itself will be dealloc'ed. The UINavigationController may cache the object internally.
I have an application where I was using buttons on a toolbar to call up the views, but I am switching it over to using a tab bar.
When using the buttons I was using the following code in MainViewController.m to update the values on the page and it was working just fine:
-(IBAction) loadSummaryView:(id) sender {
[self clearView];
[self.view insertSubview:summaryViewController.view atIndex:0];
//Update the values on the Summary view
[summaryViewController updateSummaryData];
[summaryViewController calculateData];
}
However, with the Tab Bar I can not figure out how to do this. I tried putting all of the necessary code in the Summary Views viewDidLoad and it loads the initial values, but it will not update the values when I change them in another view.
Any help is appreciated. I am a bit new at this, so please don't be cryptic as I may not understand the response.
Thank you.
By placing your code in viewDidLoad, it will only be called when the view is loaded from the nib. Unless you're running low on memory, this view will remain loaded for the duration of the life of your app.
So if you need to update values every time the view will appear, consider moving that code to an override of viewWillAppear
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
// your stuff goes here...
[self updateSummaryData];
[self calculateData];
}
You can update your current view in the viewWillAppear:animated message of the view:
If you have everything setup correctly, there is nothing to do, the UITabBarController will show your view, an your UIViewController will receive a viewWillAppear message, where you can do your update:
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
[self updateSummaryData];
[self calculateData];
}
I strongly recommend reading the View Controller Programming Guide for iOS which describes in detail the main interface paradigms supported by the iPhone.
I'm trying to detect a shake on the iPhone device, so for what i've read I need to set my view controller as first responder on the viewDidAppear method. This method is supposed to be called automatically, but for some reason this method is never called. Only viewDidLoad is called.
this is my code (I put only the relevant parts):
BuildHouseViewController.h:
#interface BuildHouseViewController : UIViewController {
BuildHouseViewController.m:
- (void)viewDidLoad {
[super viewDidLoad];
[self.view becomeFirstResponder];}
-(void)viewDidAppear:(BOOL)animated{
[self becomeFirstResponder];
[super viewDidAppear:animated];}
-(BOOL)canBecomeFirstResponder {
return YES;}
- (void)motionEnded:(UIEventSubtype)motion withEvent:(UIEvent *)event{
NSLog(#"shake");
if ( event.subtype == UIEventSubtypeMotionShake )
{ }
if ( [super respondsToSelector:#selector(motionEnded:withEvent:)] )
[super motionEnded:motion withEvent:event];
}
I added breakpoints on the viewDidAppear method and it is never called. Shakes are never detected, I suppose it is because as this methods are never called, so the view controller can never become first responder. I don't understand why this is happening.
Any help will be appreciated.
Edit:
I call the view from another view using:
[self.view addSubview:nextScreen.view];
The view is displayed on screen
Thanks for the quick answers.
I've found something interesting. I tried loading the same view I'm having problems with in different ways and I'm getting different results
-As I said before if I call it from another view using:
[self.view addSubview:nextScreen.view];
viewDidLoad is never called and I cannot detect shakes.
-Now if I call it from the AppDelegate using:
[window addSubview:nextScreen.view];
viewDidLoad is called!! and I am able to detect shakes, however this solution is not possible, I should be able to call it from another view
-If I call it from another view using:
[self presentModalViewController:nextScreen animated:YES];
viewDidLoad is called!! However I don't want to use a modal view controller, but it appears to be the only solution to my problem, shakes are detected.
It is strange that the first method doesn't load the view correctly, is it a bug??
The [self becomeFirstResponder] and the like don't actually make that become the first responder. The method gets called when the view is going to become the first responder. So that's not doing what you think it is.
Secondly, the viewDidAppear will only be called when the view, well, did appear. Is it showing up on the screen? Where are you telling it to be displayed? You need to either add the view controller's view as a subview of another view, or pushed onto a navigation controller stack, or pushed as a modal view.
viewDidAppear:(BOOL)animated only gets called when the view is shown by UINavigationController or UITabBarController. If you add a view controller's view to a subview (such as a scrollview or what have you), it won't get called. You would think it would but you'd be wrong. Just got bit by this myself.
Further to #Genericrich's comments, you can manually call viewDidAppear after you put the subview in yourself.
[self.view addSubview:theViewController.view];
[theViewController viewDidAppear:FALSE];
This worked for me. Hope it helps someone else.