0

The app I am developing has five view controllers.

Lets call them A, B, C, D, and E, with A as root view controller.

A will have four buttons to navigate to each of the other view controllers. Similarly, B, C, D, and E will have four buttons each to navigate to all other view controllers.

Is it a good idea to to use presentViewController: to implement the navigation, since there is no clear hierarchy in the relationship of the view controllers? I don't think I clearly understand the presented vs presenter relationship.

Does the dismissal of the presented view controller have to be handled by the presenter?

Suppose A presents B, and B then presents C, and C then presents A. Are any of the controllers released/dismissed? Who is handling whose dismissal? When A is finally presented, is B still in the memory?

The other approach I thought of is to design and write a View Controller Container and manage all the view controllers. I have read this is not an easy territory to walk on.

Which of these makes more sense?

jscs
  • 63,694
  • 13
  • 151
  • 195
Ravi
  • 255
  • 3
  • 16
  • It sounds like you should use a tab bar controller. Apple has several container view controllers already available in Cocoa Touch. – jscs Mar 23 '14 at 00:40
  • @JoshCaswell I definitely don't want to show a tab bar and also want to place buttons at different places on the screen . I am sure UITabController can be customized. I will look into it. – Ravi Mar 23 '14 at 01:08

2 Answers2

1

if your situation is that you have 5 instances of view controllers and you use just the same, you have to use the container solution. If you use the same instance, you have in each time allocated just this 5 and so you haven't problem.

If instead, you need to navigate in depth with new instance, and after came back (like a navigation controller) the best solution is instantiate each time a new view controller and when you came back to the previous, the last is dismissed.

N.B. If you need to open many instance in depth but potentially without come back (like a navigation controller) you need to use the first solution, because you have to use 1 instance for each view controller.

Matteo Gobbi
  • 17,697
  • 3
  • 27
  • 41
1

You can use UINavigationController to push new controllers to the stack. If you don't want user to go back (it means not keeping the old view controllers in the stack) you can simply set the newly allocated view controller as the root vc:

-(void)buttonAPressed:(UIButton *)button {
    AViewController *vc = [[AViewController alloc] init];
    self.view.window.rootViewController = vc;
}
Ömer Faruk Gül
  • 965
  • 1
  • 10
  • 22
  • That seems like a viable solution except that every time we navigate to a controller it is allocated and probably released once we are done with it. I come from a C++ background, I am not sure if so many allocations is a good idea. Also what about the transition styles? Does setting the root view controller allows us to specify view transition styles? – Ravi Mar 23 '14 at 01:10
  • @Ravi you can have a look at this question for transition animations: http://stackoverflow.com/questions/8146253/animate-change-of-view-controllers-without-using-navigation-controller-stack-su – Ömer Faruk Gül Mar 23 '14 at 11:10
  • @Ravi also when you assign a new controller to rootViewController, the old one is deallocated if it is not referenced as strong from a singleton class, app delegate or somewhere else. – Ömer Faruk Gül Mar 23 '14 at 11:12
  • Thanks Omer. I eventually ended up writing my own container View controller. Given that the number of viewcontrollers is very less in my app i think its ok to allocate/deallocate view controllers as and when they are needed or not. I guess ARC is taking care of that. – Ravi Mar 27 '14 at 15:31