- When it is called / When it is used :
- Sometimes you might decide to put your view controller’s interface in a separate nib file instead of a storyboard. This might happen, for example, to work in a larger team where different members need to be change view controller interfaces without affecting the work of others. You also might have a project that was created when storyboards did not exist yet, so every view controller had its own nib file.Keep in mind that if your main storyboard starts getting too big, you can split it into more storyboards. You do not need to move every view controller in a separate nib file.
- If you create a view controller from a nib file, this initializer is called instead of init(coder:).
- This is the method that creates the view for the view controller. You override this method only in case you want to build the whole interface for the view controller from code. Don’t use this unless there is a valid reason.
- If you are working with storyboards or nib files you do not have to do anything with this method and you can ignore it. Its implementation in UIVIewController loads the interface from the interface file and connects all the outlets and actions for you.
- You override this method for tasks that need you need to repeat every time a view controller comes on screen. This method can be called multiple times for the same instance of a view controller.
- Notifies the view controller that its view is about to be added to a view hierarchy
- Application :
- Usually you use this method to update the user interface with data that might have changed while the view controller was not on the screen.
- You can also prepare the interface for animations you want to trigger when the view controller appears.
- viewDidLoad V/S viewDidAppear :
- Code you need to execute only once should go into an initializer or viewDidLoad().
- In this step the view has bounds defined but the orientation is not applied
- Called to notify the view controller that its view is about to layout its subviews.
- This method is called every time the frame changes like for example when rotate or it’s marked as needing layout. It’s the first step where the view bounds are final.
- If you are not using autoresizing masks or constraints and the view size changes you probably want to update the subviews here.
- Called to notify the view controller that its view has just laid out its subviews.
- Make additional changes here after the view lays out its subviews.
- This method gets called after the view controller appears on screen.
- You can use it to start animations in the user interface, to start playing a video or a sound, or to start collecting data from the network.
- Before the transition to the next view controller happens and the origin view controller gets removed from screen, this method gets called.
- You rarely need to override this method since there are few common tasks that need to be performed at this point, but you might need it.
- After a view controller gets removed from the screen, this method gets called.
- You usually override this method to stop tasks that are should not run while a view controller is not on screen.
- For example, you can stop listening to notifications, observing other objects properties, monitoring the device sensors or a network call that is not needed anymore.
- Like every other object, before a view controller is removed from memory, it gets deinitialized.
- You usually override deinit() to clean resources that the view controller has allocated that are not freed by ARC.
- You can also stop tasks you did not stop in the previous method because you wanted to keep them in the background.
- A view controller going out of the screen does not mean that it will be deallocated afterwards. Many containers keep view controllers in memory. For example, as you go deeper in a navigation controller, all the previous view controllers stay in memory. A navigation controller releases view controllers only when navigating back up the hierarchy. For this reason, you have to keep in mind that a view controller that is not on the screen still works normally and receives notifications. Sometimes this is desiderable, other times it isn’t, so you need to keep this in mind while developing your app.
iOS devices have a limited amount of memory and power. When the memory starts to fill up, iOS does not use its limited hard disk space to move data out of the memory like a computer does. For this reason you are responsible to keep the memory footprint of your app low. If your app starts using too much memory, iOS will notify it.
Since view controllers perform resource management, these notifications are delivered to them through this method. In this way you can take actions to free some memory. Keep in mind that if you ignore memory warnings and the memory used by your app goes over a certain threshold, iOS will end your app. This will look like a crash to the user and should be avoided.