Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm building a very simple iOS game that doesn't require any fancy OpenGL; I'd like to stick with Core Graphics & Core Animation. I'd like to make this a fullscreen game, and my question is of ViewController hierarchy + management:

It seems as though I should have two types of ViewControllers: Basic VCs for navigating between menu screens (ie. Settings, Main Menu, Level Select, etc.), and Gameplay VCs for managing all my UIViews and CALayers.

What's a good way to manage these? Is it best practice to have one hierarchy of VCs like a traditional UINavigationController-based app, covering the NavBar when I'm displaying a Game ViewController? Or instead should I be removing all other ViewControllers from the stack when I enter "game mode", and setting it as my window.rootViewController property? Any alternatives / downsides to continually resetting window.rootViewController?

My gut tells me the latter is better on resources+performance, but advice + direction here would be appreciated.

share|improve this question
    
@moderators - Is this q more appropriate for stackoverflow? –  Chazbot Oct 2 '11 at 1:44
    
Yes, this belongs on SO. –  Moshe Oct 2 '11 at 5:16
    
Software design is on-topic here. He's asking for conceptual, best-practices stuff. If it was about a specific problem with code already written, that'd be Stack Overflow. –  user8 Oct 2 '11 at 5:51
add comment

1 Answer

up vote 3 down vote accepted

i've seen both done, but i prefer the latter for memory considerations. before you switch the rootViewController, you need to fade out and removefromsuperview the previous, then addSubview the new one and fade it in, then finally set as root. this will mess with orientation unless you have only one VC on screen that inherits from UIViewController.

so, i'd have one main VC for handling all menu stuff, and separate out its subviews into classes that inherit from NSObject (there should only be one class on screen at a time that inherits from UIViewController - just google search for apple's recommendations for splitting a single screen into separate IB files/classes). when you go into game-mode, you call back to your app delegate.

next, your app delegate can handle the switch from menu-mode to game-mode. it fades out the previous VC, alloc/inits the game VC, fades in and does the removefromsuperview, etc on the previous VC.

you really only need two classes at the top level that your app delegate switches between: one menu VC (with subviews) and one game VC (with subviews).

share|improve this answer
    
Thanks Greg! W00t. –  Chazbot Oct 2 '11 at 6:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.