UIViewController (ViewController) – This is a class derived from the standard UIViewController, which is the base controller of the MVC pattern that Apple recommends for iOS application development. The UIViewController entity is used to control the UIView
uiview (View / View) – Represents the screen or a significant part of the screen.
subview is the base class for widgets, which is used to create interactive user interface components (buttons, text fields, etc.). and if we insert a view inside another view, it will become a Subview.
Storyboards(storyboards) is an Xcode feature for lightweight development of application interfaces. Looks like a storyboard of application screens.
nib file is a description of a user interface fragment in a compiled format in a file with a . nib.
IBOutlet basically, it is the relationship of a UI element (button or label) with its link in the code.
IBAction is an action (or method, as it is more convenient) in the code that can be connected to some event (pressing a button, for example) in the developed interface.
Bounds – location and size of the view using its own coordinate system (important for positioning the contents of a View or subview inside it)
frames – the position and size of the view using the coordinate system of the parent view (important for placing the view in the superview).
· When invoked / When used:
View Controller is usually created from storyboards. In this case, the init(coder:) initializer is called, which must be redefined.
It provides an NSCoder instance as a parameter, which you only need if you are using the iOS serialization APIs. This is not used often, so you can ignore this setting. This serialization converts the object into a stream of bytes that you can store on disk or send over the network.
During the initialization phase of a ViewController, you typically allocate resources that the ViewController will need during its life cycle. These include model objects or other auxiliary controllers such as network controllers.
Previous controllers can also pass these objects to the current one, so you don’t always need to instantiate them in every controller.
Things to take care of:
Keep in mind that at the moment the ViewController’s view has not yet been created. If you try to access it through the ViewController’s property view, the loadView() method will be called. This can lead to unexpected behavior and bugs, so it’s safer to refer to the view at a later stage in the life cycle.
· When invoked / When used:
Sometimes you may decide to put your ViewController’s interface in a separate nib file instead of a storyboard. For example, when working in a large team, where different developers must change the ViewController’s interfaces without affecting each other’s work. You could also have a project that was created before storyboards existed, so each ViewController had its own nib file. Note that if your Main Storyboard gets too big, you can split it into multiple Storyboards. You don’t need to move each ViewController to a separate nib file.
If you create a ViewController from a nib file, this initializer is called instead of init(coder:).
This is the method that creates the view for the ViewController. You override this method only if you want to build the entire interface for the ViewController from code. Don’t use it unless there is a good reason.
If you are working with Stryboards or nibs you don’t need to do anything with this method and you can ignore it. Its implementation in UIVIewController loads the interface from a file and connects all the Outlets and Actions for you.
When this method is called, the ViewController’s view has been created, and you can be sure that all the Outlets are in place.
Typically this method is used to populate the ViewController’s user interface with data before the user sees it.
It’s also a good place to start some kind of background activity at the end of which you need to have the UI ready.
A common case is network calls that only need to be made once when the screen loads.
A good place to initialize and set up the objects used in the viewController.
viewDidLoad V/S viewDidAppear :
If you need to repeat them (background activity/UI changes/making network calls) to update the ViewController’s data, viewDidAppear(_:) is more suitable for that.
· Important to remember:
This method is called only once during the lifetime of the ViewController, so you use it for things that only need to happen once. If you need to perform some task every time the ViewController appears on the screen, you will need the following methods.
It should be noted that at this stage of the life cycle of the view, bounds (borders) are not final.
You override this method for tasks that you need to repeat every time the ViewController appears on the screen. This method can be called multiple times on the same ViewController instance.
Notifies the ViewController that its view will be added to the view hierarchy.
Typically, this method is used to update the user interface with data that may have changed while the ViewController was not displayed on the screen.
You can also prepare an interface for the animations you want to run when the ViewController appears.
viewDidLoad V/S viewDidAppear :
Code that you only need to execute once should go into an initializer or viewDidLoad().
At this point, the view bounds are defined, but no orientation is applied.
Called to notify the ViewController that its view is about to host its subviews.
This method is called every time the frame changes, such as when the screen is rotated or when it is marked as needing layout. This is the first step where the view’s bounds are final.
If you are not using autoresizingMask or constraintsand the view is resized, you probably want to update the subviews here.
Called to notify the ViewController that its view has just laid out its subviews.
Make additional changes here after the view has laid out its subviews.
This method is called after the ViewController appears on the screen.
You can use it to start an animation in the user interface, to play a video or sound, or to start collecting data from the network.
This method is called before the transition to the next View Controller occurs and the original ViewController is removed from the screen.
You rarely need to override this method as there are a few common tasks that need to be done at this point, but you may need it.
After the ViewController is removed from the screen, this method is called.
You typically override this method to stop tasks that should not be running while the ViewController is not on the screen.
For example, you can stop receiving notifications, observe the properties of other objects, monitor device sensors, or a network call that is no longer needed.
Like any other object, before the ViewController is removed from memory, it is deinitialized.
Typically you override deinit() to clean up resources allocated by the ViewController that are not freed by ARC (automatic reference counting).
You can also stop tasks that you didn’t stop in the previous method because you wanted to leave them running in the background.
· Beware of:
The ViewController disappears from the screen, but that doesn’t mean it will be released later. Many containers keep viewController in memory. For example, when you delve into the navigation controller, all previous viewControllers remain in memory. The navigation controller releases viewControllers only when moving up the hierarchy. Therefore, you should keep in mind that a viewController that is not on the screen still works fine and receives notifications. Sometimes this is desirable, sometimes not, so you need to keep this in mind when developing your application.
iOS devices have limited storage and power. When RAM starts to fill up, iOS doesn’t use extra hard drive space to move data around like a computer does. For this reason, you are responsible for how much RAM your app takes. If your app starts using too much memory, iOS will notify you.
Because viewControllers do resource management, these notifications are delivered to them using this method. Thus, you can take action to free up some of the memory. Be aware that if you ignore low memory warnings and the memory used by your app exceeds a certain threshold, iOS will terminate your app. This will look like a crash to the user and should be avoided.