Appdelegate vs. UIViewcontroller - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: iPhone, iPad & iPod Game Development (/forum-11.html)
+--- Thread: Appdelegate vs. UIViewcontroller (/thread-8861.html)
Appdelegate vs. UIViewcontroller - Mattonaise - Apr 18, 2011 08:59 PM
I was wondering whether it would be better to use the appdelegate or a viewcontroller as the state manager for my game. I'm having trouble deciding because both have their advantages. The appdelegate would be much more easily accessible as you can get a reference to it anywhere, and that would be useful inside the game state classes when you wanted to tell the state manager to change states. However, using a viewcontroller would also have some advantages. I am most likely going to also use viewcontrollers as my game states, so if I used another viewcontroller as my state manager I may be able to present game states in a modal transition which would be useful. I also noticed that the flipside project template in xcode uses a rootviewcontroller as its state manager, so is there any reason why that is used instead of the appdelegate? However, one problem with a viewcontroller state manager is that the game states would need a reference to the state manager in order to tell it to change states (or is this when I should use delegation?). I am leaning towards using the appdelegate as the state manager as that would be a lot easier to change states with from inside a state itself, and if I created some transitions by using Core Animation then modal transitions wouldn't be needed that much. However, I would very much like some input from you guys on which would offer advantages, or any other ideas.
BTW, I hope the post was easy to follow, it's kinda messy.
RE: Appdelegate vs. UIViewcontroller - OneSadCookie - Apr 18, 2011 09:21 PM
didn't we just go through this? neither, a new class.
RE: Appdelegate vs. UIViewcontroller - SethWillits - Apr 18, 2011 09:27 PM
There really are a zillion different ways you can do this. The advantages between several approaches can be completely subjective.
If you made the topmost view controller the "state manager", there's no reason you can't access it from anywhere in the project either. At the simplest, the app delegate would have a reference to it and object in the class can get a reference through it that way. Use a macro to make access prettier if you want.
You can also use a third object, a singleton whose only job is to manage the states, their modality etc. You could have the state manager know about the topmost view controller, or not. In one approach, the state manager would push the states/view controllers into the top one as part of switching states, or you could use one of the delegate/notification/KVO approaches and have the topmost vc do the push/popping based on those messages.
Lots of different ways. If what you're doing feels really wrong, then it probably is. If it seems slightly awkward but so would every other approach, you're fine.
RE: Appdelegate vs. UIViewcontroller - Mattonaise - Apr 19, 2011 04:21 PM
OneSadCookie: I suppose, it's just that I thought you were more talking about the game logic than the state management. Sorry though.
SethWillits: Okay, thanks. What I have in mind right now seems like a good way to go about it, so I'm going to stick to it. Like you said, it's probably a lot more subjective than I thought, and there are too many ways to really have a best method. And really, whatever works, works.
Thanks for your input, that brings me one step closer.
RE: Appdelegate vs. UIViewcontroller - aerospaceman - Apr 25, 2011 11:27 AM
I would totally endorse using Cocos2D, it takes care of a lot of things for you.
RE: Appdelegate vs. UIViewcontroller - Skorche - Apr 25, 2011 01:03 PM
State management is not really one of those things however.
RE: Appdelegate vs. UIViewcontroller - aerospaceman - Apr 28, 2011 07:43 AM
I guess my game is just so simple that I haven't run into any issues...I just used one if statement for game running/not running. Everything else is handled by scenes and data is passed between scenes via NS User defaults.