I am wondering if it is possible to present a splitviewcontroller within a custom container controller (or a tabbar controller)? I have seen from this doc and other post:
A split view controller must always be the root of any interface you
create. In other words, you must always install the view from a
UISplitViewController object as the root view of your application’s
window. [...] Split view controllers cannot be presented modally.
I have a splash screen in my app that will lead me to this container controller which I would like to contain a splitview controller. Is it just impossible according to Apple Programming guide or is there any workaround?
It is technically possible, but you run the risk of violating Apple UX guidelines.
What you can do is embed a splitview controller as a child viewcontroller of an blank UIViewController instance, and then present that viewcontroller instead of presenting the UISplitViewController directly.
Related
I have an iPhone / iPad application that manages its numerous view controllers via a UINavigationController and UITabViewController. The UINavigationController handles the majority of the user interaction and the UITabViewController handles user settings/preferences.
My app delegate initializes the UINavigationController and pushes the first view controller. Settings (the UITabViewController) can be accessed via a button on the navigation controller's menu bar; the user can return to the main application (the UINavigationController) via a button on the UITabViewController.
My question is: what should I be doing with the UINavigationController (and its stack of view controllers) when I show the UITabViewController and vice-versa? Is there any reason to remove/release/recreate each parent controller as the user switches between the two, or should I be adding/removing each parent controller's view to my app's window?
It seems that the first option would be more mindful of memory/resources, however these benefits might get overshadowed by the processing cost to re-alloc/init the view controllers each time.
Thanks.
You do not have to manage the navigation controller's stack manually. What I would do is present your settings view controller as a modal view. You would do this at the navigation controller level.
Assume that settingsViewController is a property of your main view controller.
self.settingsViewController.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal
[self.navigationController presentModalViewController:self.settingsViewController animated:YES];
I assume you mean UITabBarController.
If your navigation view would show up in the tab view for a tab item, I would suggest let the tab bar controller to be the root view controller of your application (and therefore always seen in the app).
If your navigation view is the main view, and the user simply opens up the tab bar view for settings etc. and will return for the navigation view, then modally presenting the tab bar controller is the right way.
In the first case (the navigation controller IN the tab bar controller), you would not care for adding/removing or allocating/releasing views as the UIKit will manage it for you.
In the second case you may create a tab bar controller when you want to show it. presentModalViewController will retain the view controller so you can release it immediately after you send the message. If you want to hold the view controller then you create one when the application is loaded and retain it in the navigation controller (and the navigation controller will always remain in the memory).
i´ve created a UINavigationController in my appdelegate and initialized it with my "modelselectionViewController". This VC has different uibuttons and when touched, a new VC ("modelViewController") is pushed on the navigationstack.
This "modelViewController" acts as my template view and has a uitabbarcontroller with different tabs. The first VC is shown immediately but any changes on the navigationcontroller doesn´t work. I would like to set the name of the title but that navigationcontroller is null.
NSLog(#"navi: %#",
self.navigationController);
If i change my code to push the different VC when touching the different tabs, navigation works but only with a third level of navigation hierachy.
I want to know if it´s possible to use only one navigationcontroller for all my different tabs. Hope i made my setup clear. Appreciate all your help. thanks
I think you might want to read Combining ViewControllers.
In general, you should have the tabbar controller as a 'root' controller, not as a 'child' controller. A quick search in Apple's doc didn't yield a formal 'forbidden', but it might be.
If you create a UITabBarController from a view that's managed in a UINavigationController (ie: if you create a navigationcontroller first, and it's still around when you create the tabbarcontroller), you're starting a fight with the frameworks. Here's the admonishment from the docs on combining viewcontroller interfaces:
An application that uses a tab bar
controller can also use navigation
controllers in one or more tabs. When
combining these two types of view
controller in the same user interface,
the tab bar controller always acts as
the wrapper for the navigation
controllers. You never want to push a
tab bar controller onto the navigation
stack of a navigation controller.
Doing so creates an unusual situation
whereby the tab bar appears only while
a specific view controller is at the
top of the navigation stack. Tab bars
are designed to be persistent, and so
this transient approach can be
confusing to users.
I read that as "if it doesn't break something that we haven't thought of on the next update, we might reject the app anyway because it's 'confusing to users.'"
I suppose you could kill the whole navigation hierarchy and the navigationcontroller if you don't need to return there (like if you just used it for a one-time setup screen). Or you can look into other options for navigating within a viewcontroller that's managed by the navigationcontroller.
One thing to try might be to navigate to a UITableView, and use its cells to push a modal view onto the navigation stack. That would be familiar to users and also jive with the intent of the navigation classes.
I am trying to write an iPhone app that has both a UITabBar controller (and its associated views) and a plain vanilla view controller that is not part of the TabBar (i.e. an initial config page that only gets displayed the first time the app is run).
I am able to put a Tab Bar Controller and a View Controller in MainWindow.xib and shuffle between the two in the app delegate.
While this works I'm wondering if this is the best way to be implementing this.
It doesn't feel very "MVC-ish" to me but I think the two different controllers both need to be root (?)
I don't know how else I would do it.
If the config page is really only a "run once" affair, you could just pop it as a modal view from within the tab bar controller via the presentModalViewController:animated: method. (If on the other hand the config page is ever likely to be required in the future, I'd just add it as another option on the UITabBar.)
You would make the tabbarcontroller the default view. And present the viewcontroller modally in viewWillAppear or similar method. Then when you want to switch to the tabbar, you'd dismiss the modal view controller.
Is it possible to have a single iPhone screen with its view loaded from a xib by that screen's UIViewController, but then another UIView within that screen with content loaded from a separate xib file? If so, is it possible to have that nested view's events handled by a separate custom UIViewController subclass from the rest of the screen? If both of these things are possible, are they also advisable?
It is possible. Apple suggests against having more than one UIViewController active on screen at once, so they would advise against. I would suggest only doing it if the reason for the second view controller is navigation or modal.
A view controller with the purpose of loading other view controllers, like a navigation controller, needs some screen space for itself and uses the rest to load another view controller. That is fine. The criteria here is that only one controller is presenting content while the other is presenting navigation.
A view controller could load another view controller to perform some limited task like selecting an item from a list or entering some text. The second view controller might only fill part of the screen. The criteria here is that the one controller behaves modally and will only be displayed long enough to get some user input.
As for the general case of splitting the screen between two view controllers that are presenting content, the Apple suggestion is that you have a single class derived from UIViewController manage the views. If the view is complex enough to warrant other controllers, then derive them from NSObject and have the master view controller manage the child controllers along with the views. The child controllers would have the master controller as a delegate, and the master controller would pass views to the child controllers to manage but not own.
I'm starting an app where I'd like to have multiple view controllers. Some of the views will be displayed inside of a navigation controller. I can create a navigation controller and then add another instantiated view controller to it. But what I'd like to do, is just instantiate a view controller that has its own view and is the root view controller of a navigation view controller. So when I instantiate the view controller, I'd like for it create a navigation controller and push "self" on to it. When I do it my simulator crashes and the details don't really give a reason. The console does not display anything. Any ideas. My reason for this is to separate out logic without have a view controller that simply creates a navigation controller and then pushes another view controller on it as the root view controller.
I'm not entirely sure if I understand your question correctly. Why would it be preferable if the view controller pushed itself to the navigation controller? I mean, you have to instantiate your view controller at some point in code (either app delegate or another view controller) anyway. Why can't you just create the navigation controller there, instantiate your VC and then push it onto the nav controller? As far as I can see, this doesn't involve creating any additional view controllers.
Anyway, having a view controller decide by itself where it is used (ie. pushed onto), is not best practice. This way you lose the flexibility of using it in other contexts. Always try to couple your components as loosely as possible.