2

I'm having difficulty thinking through the design tradeoffs of changing the root view controller of an app vs. presenting the new view controller modally.

In which situations should I change the root and in which should I present modal? I'm looking for general app design guidelines. Should I always present modal and only establish the rootViewController once (in the appDelegate)?

bryanmac
  • 38,941
  • 11
  • 91
  • 99
toddbranch
  • 82
  • 6
  • This question should also consider when a `UINavigationController` would be more appropriate. It's also important to consider the memory implications of your design. In general, if you replace then your memory footprint is somewhat static, whereas pushing and presentingModal will increase your memory footprint. – ikuramedia Feb 17 '12 at 10:26

4 Answers4

4

One key aspect of presenting a modal view controller is when you dismiss the modal view controller, you return back to the view that presented it.

Changing a view (assuming you mean swapping out the view) doesn't necessarily imply the pattern of returning to that view that it replaced. It just replaced it.

bryanmac
  • 38,941
  • 11
  • 91
  • 99
  • In what contexts would a change of rootViewController be appropriate? From the perspective of a navigation-based app, it seems to me like there's always a single 'home' screen that is eventually returned to. From that perspective, it seems like presenting modal is almost always the preferable choice. – toddbranch Dec 10 '11 at 22:44
  • Not that common to replace root controller but the other pattern I was referring to was swapping out a view within that controller. Think of swiping left or right and navigating in another view. – bryanmac Dec 10 '11 at 22:48
  • The other common patterns are navigation controller. In that model you push another view onto the stack while keeping the nav bar above to pop back. That's opposed to present modal which adds a view over top taking the whole view and dismiss returns – bryanmac Dec 10 '11 at 22:50
  • Finally table view pattern of drilling and returning. All of these patterns have 1 thing in common- small real estate so you need to present, push, drill in and then dismiss, pop or return. All just variations – bryanmac Dec 10 '11 at 22:52
  • I recommend you observe other apps ( especially apples) to get a feel for the patterns. Also read the apple human interface design guidelines – bryanmac Dec 10 '11 at 22:54
2

Setting a root view controller and using Modal Controllers, Navigation Controllers, Tab Bar Controllers, etc., it's generally considered a better practice then just adding new views and its controllers over each other on the default window.

This is because the flow between controllers is done in a hierarchical, organized, "stacked" way. Just adding one view controller's view over another on the default window can really brake the correct "flow" of the app.

In short, it is almost always a better approach to use modal controllers, or to start with a Navigation Controller, or Tab Bar, etc.

Luiz Carlos Querino Filho
  • 765
  • 4
  • 12
2

Generally you use modal view controllers to focus the user's attention on a Task. When you push, the user is in some kind of navigation flow, but still has the total application at their fingertips. They might decide to go forward or backward, switch to a different tab in the middle, whatever. When they get a modal view controller, they can't do any of that until the task is completed or canceled out of (the modal view is dismissed).

Check out - why does this code use presentModalViewController? (not pushViewController) also

iOS Human Interface Guidelines reg. Modal View Controllers

Community
  • 1
  • 1
Srikar Appalaraju
  • 71,928
  • 54
  • 216
  • 264
0

It depends on your app. If you are making navigation based app then its a good idea to present modal. And main thing is that modal just replaces the root, not else. so in navigation based app , present modal will be very useful with the root to navigate the views.

Rohan
  • 2,939
  • 5
  • 36
  • 65