1

My Initial View Controller of the storyboard load another view controller using performSegue:withIdentifier method which in turn loads some other controller using same performSegue:withIdentifier method.

However, neither the initial view controller nor the second view controller are deallocating. They both tend to have a reference count of 1 as seen via instruments.

I need to send user back to first controller when he logs out of application. The only way I have figured so far is to use performSegue:withIdentifier method and send the user back to initial controller.

However, it concerns me that previous controllers will not have been deallocated thus, resulting in re-creation same view controllers.

Since I need to logout a user back to first screen, I want to make sure that all previous view controllers have been deallocated.

atastrophic
  • 3,153
  • 3
  • 31
  • 50

3 Answers3

4

When you perform a push or modal segue, it will not (and should not) release the view controller from which you're seguing. It needs to keep it so that when you pop/dismiss back to it, it will still be there. The exception to this rule is when using a split view controller and you use a replace segue. But that's a special case.

If you want to go back to the first scene, if you're using a navigation controller and using only push segues, you can use popToRootViewControllerAnimated. (For iOS 5 targets, I'll always use navigation controller, and hide the navigation bar if I don't want it visible, for that reason. It's convenient to be able to pop back multiple levels. It's cumbersome to achieve the same effect with modal segues.) In iOS 6, you can use an unwind segue, in which you can pop/dismiss back an arbitrary number level of scenes, for example, to return to your initial scene.

Community
  • 1
  • 1
Rob
  • 415,655
  • 72
  • 787
  • 1,044
3

Looping with performSegue is not a good idea..

If you have to go back in your VC hierarchy, you should either use a UINavigationController with pushing/poping VCs, or presenting/dismissing a modal VC. You can combine both by modally presenting a UINavigationController.

rdurand
  • 7,342
  • 3
  • 39
  • 72
  • +1 Agreed. At least two exceptions: First, in iOS 6, you can do a `performSegue` of an unwind segue. Second, if using the split view controller's replace segue, it similarly doesn't matter. But you're absolutely right that you never want a circular set of push/modal segues. – Rob Mar 21 '13 at 14:52
  • Thanks for confirming my idea. Your answer is more complete though, so +1 for that. I didn't hear of unwind segue before, and it looks pretty good. Quick question on your answer you linked to : in step 3, you say "Implement the action in the .m for view controller A", shouldn't it be B instead of A ? – rdurand Mar 21 '13 at 15:12
  • No. With unwind segues, you define the unwind action in the view controller to which you want to unwind (otherwise, if you have a dozen prior scenes, how would it know which one?). It really is quite cool that IB figures out all the prior scenes and their associated view controllers, scanning the .m files for unwind actions, grabs those names, and presents a list of those in that final scene that you're trying to add the unwind segue. Incidentally, that's also why I like to give my unwind actions meaningful names so that when you use them, you can clearly know to which scene you're unwinding. – Rob Mar 21 '13 at 15:18
  • 1
    Thanks for the info. I'll have to look into that ! – rdurand Mar 21 '13 at 15:21
0

Prior to iOS 6 A UIViewController will stay alive but its more expensive UIView will be deallocated to save memory. The UIViewController itself is pretty light compared to a UIView. Since iOS 6 you should according to the documentation override didReceiveMemoryWarning

Docs for UIViewController:

Memory Management

Memory is a critical resource in iOS, and view controllers provide built-in support for reducing their memory footprint at critical times. The UIViewController class provides some automatic handling of low-memory conditions through its didReceiveMemoryWarning method, which releases unneeded memory.

Prior to iOS 6, when a low-memory warning occurred, the UIViewController class purged its views if it knew it could reload or recreate them again later. If this happens, it also calls the viewWillUnload and viewDidUnload methods to give your code a chance to relinquish ownership of any objects that are associated with your view hierarchy, including objects loaded from the nib file, objects created in your viewDidLoad method, and objects created lazily at runtime and added to the view hierarchy. On iOS 6, views are never purged and these methods are never called. If your view controller needs to perform specific tasks when memory is low, it should override the didReceiveMemoryWarning method.

As long as you manage you correctly react (depends on the iOS Version) and dealloc the view I see no problems here.

Pfitz
  • 7,336
  • 4
  • 38
  • 51