Toggle Sidebar   Previous Lesson Complete and Continue  

  Lecture 3. Add Sign Up Scene.

Homework to Make Sense of The Lecture and Dig Deeper

Exercise 1.

In the dismiss() method around 09:36:

(a) What if the animated parameter is set to false?

(b) Inside the completion block, print something out then test the app. What do you observe? What do you think this block do?

dismiss(animated: true, completion: { _ in
  // YOUR CODE HERE
})
	

Exercise 2.

Present Modally

In the lecture, we switch views by using a Present Modally segue from the Sign In View Controller to the Sign Up View Controller. In this exercise, we'll dig deeper on this concept.

(a) The Sign In View Controller is currently the Initial View Controller of our storyboard. This means it will display first when we open the app. In the viewDidLoad() method of the Sign In View Controller, print something out to signal when this view is loaded into the memory.

            
override func viewDidLoad() {
  super.viewDidLoad()
  // YOUR CODE HERE 
}
		

What do you observe?

(b) From the previous part, we know that when we see Sign In View displaying nicely on the screen, it was loaded into the memory. Due to the segue, when we hit the Don’t have an account button, the Sign In View disappears and the Sign Up View shows up. Does that mean the Sign In View Controller was released from the memory? To answer this question, we can utilize its deinitializer which is called automatically, just before the view is deallocated from the memory. Print something out to report when this is the case.

deinit {
  // YOUR CODE HERE
}
		

Run the code then switch view. What so you see now?

(c) In the viewDidLoad() method of the Sign Up View Controller, print something to signal when this view is instantiated.

override func viewDidLoad() {
  super.viewDidLoad()
  // YOUR CODE HERE
}
	

What is your conclusion?

Exercise 3.

Switch views: the good way

In the lecture, we switch back to the Sign In View Controller from the Sign Up View Controller by dismissing it instead of using another segue initiating from the Don’t have an account button to the Sign In View Controller. This method is recommended by Apple whenever the segue is Present Modally. To see why, let's do a quick experiment.

When the Sign Up View is dismissed, it disappears from the screen, and the Sign In View shows up. This suggests that the former might be released from the memory, while the latter might be loaded again into the memory. Keep everything from the previous exercise, and in the viewDidLoad() method of the Sign Up View Controller, print something out in its deinitializer to signal when this view is deallocated.

deinit {
  // YOUR CODE HERE
}
		

Run the app and switch views multiple times. What are printed in the console? What is your conclusion?

Exercise 4.

Switch views: the bad and ugly way

There is a popular iOS course on Udemy in which this view switching business is performed by two segues. In particular, if we applied that method in our setup, we'd create another segue from the Don't have an account button back to the Sign In View Controller instead of dismissing the Sign Up View.

To see if this is a good method, let's comment out the dismiss() method inside the dismiss_onClick() action, then create another Present Modally segue from the from the Don't have an account button to the Sign In View Controller.

Keep everything from the previous exercise, then run the app and switch views multiple times. What happens in this case? Is there any view being released?

Complete and Continue  
Discussion

3 comments