CODEWITHSUNDEEP
iphoneioscocoauiviewcontroller
gsach
gsach

Reputation: 5775

Architecture of view hierarchy - iPhone

I am making a multiplayer game. My First screen , should show a login form (not modally). When it finishes, it should call a delegate to my "root class" and the "root class" should remove this view controller and add another.Then when the game ends the "root class" will be called with another delegate method and it should show another screen etc..

I have 3 ideas about it and I would like to know which is going to work better.

a) My root class is a uiviewcontroller and it adds/removes subviews when the delegate methods are called.

b) My root class is NSObject subclass and it changes the window rootViewControoler when it has to.

c) Navigation controller without navigation bar. But how i manage view hiearchy?

What is better logic to manage my view hieararchy? Any other idea than a and b?

Upvotes: 0

Views: 385

Answers (2)

QED
QED

Reputation: 9913

Of the options you present, I like c) the best.

Option a) falls short because it ignores the primary rôle of view controllers - to manage full-page views of content. Using addSubview in situations like yours requires you to jump through a bunch of hurdles in order to manage the memory of all those objects in the view hierarchy, and you would just wind up reinventing the UIViewController wheel.

Option b) is ok, but somehow it never seems to satisfy me. Just swapping the root in and out willy-nilly seems risky - this is what UIViewController is made to do, and it will probably do it better than you or I could. At any rate, you lose any benefits of animation if you do this. Which brings us to...

Option c). UINavigationController is programmed to do the work required of your particular situation. You can manage the hierarchy using UINavigationController's - (void)setViewControllers:(NSArray *)viewControllers animated:(BOOL)animated. You could do a normal push, but this will keep the previous VC in memory while your main game VC sits in front and demands resources from the system. In short, I think your c) is easy and effective.

As as post script here, be aware that there are alternatives other than your a,b,c. You might get by with using a UIPageViewController, though I'm not recommending it. iOS 5 introduced UIStoryboard as a method to manage your app's UI, and UIStoryboardSegue to manage transitions. Check out the docs, if you're targeting iOS 5, they might help you as well. But it sounds like a simple nav controller will work for you.

Upvotes: 0

FluffulousChimp
FluffulousChimp

Reputation: 9185

Either a) or b) would work. The choice would depend on factors like the degree to which the model layer is used to determine the sequence of presentation of views. If the presentation sequence is dynamic, then the helper class design (your option b) may be purer in terms of MVC separation. Ultimately, the decision depends on the details and complexity of your application.

Generically, some of the questions I ask when making design decisions like this:

  • How does it affect memory management?
  • How will the design affect performance?
  • Does the design appropriately separate concerns?
  • Is the design flexible? Does it minimize dependencies?
  • Does the design take advantage of framework/platform design patterns?

Upvotes: 1

Related Questions