I want to create my own container view controller, i.e. something like UINavigationController
or UITabBarController
. Docs say I should not do that, but why not? Navigation and tabbar containers are good examples that such thing is possible and works really well. Also I understand that iPhone has small screen and people shouldn't mess it up by navigation buttons, etc., but on an iPad there is a lot of space and splitting it to many view controllers would give us great opportunities.
I have a feeling Apple didn't add such API yet, but they will. Few days ago they've added docs about iPad-specific controllers (yeah, container ones) and they've modified texts to something less-forbidding.
Anyway... what problems may I have if I try t开发者_C百科o use two or more view controllers on one screen? I know only one of them will get events like orientation change or low memory warning, so I have to pass these events to contained VCs. I'm afraid about compatibility with future versions of iOS, cause if they'll add new events, then contained VCs won't execute default actions inherited from UIViewController
. Anything else? Do you think my app may be rejected by Apple? Maybe there is other way to have some view elements persistent on each screen without copying a lot of same code to every VC?
Thanks in advance.
This is now supported in iOS5. See this question for some example code: Container View Controller Examples
Subclassing UINavigationController or UITabBarController is an excellent way to handle device rotation issues, but I wouldn't recommend doing that specifically to share subviews from multiple view controllers.
Maybe subclassing UIViewController is what you're looking for. Then when the view has loaded, you can load your shared views from a nib and define the outlets in your UIViewController subclass, plus add any supporting code to your subclass for handling the events. I've done this myself for adding a status update message that I want to be able to appear on any of my view controllers' views.
精彩评论