5

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.

3
  • @moderators - Is this q more appropriate for stackoverflow?
    – Chazbot
    Commented Oct 2, 2011 at 1:44
  • Yes, this belongs on SO.
    – Moshe
    Commented Oct 2, 2011 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
    Commented Oct 2, 2011 at 5:51

1 Answer 1

3

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).

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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