I have an app with UITabBarViewController as rootviewcontroller. On some tab item, I want to have a SplitViewController inside a UITabbarViewController.
So here my UISplitViewController will become a childViewController for TabbarVC.
Will this be allowed? Are there any Apple guidelines suggesting not to do this?
As I see, they are suggesting to put SplitVC as RootVC. But many applications have already done what we are doing now.
Answers here might help Apple recommends UISplitViewController should always be the rootviewcontroller
I had nearly same scenario of creating a UISplitViewController inside a view controller. So I created my own custom SplitViewController
Here is the note from apple
You cannot push a split view controller onto a navigation stack. Although it is possible to install a split view controller as a child in some other container view controllers, doing is not recommended in most cases. Split view controllers are normally installed at the root of your app’s window.
Apple HIG recommends to have tab bar as the root or split view controller as root. But I still achieved this by putting in a container for one of the tab bar's child view controller. And as a result, you can load split view controller into the container view of any view controller, irrespective of whether its tab bar or a normal view controller.
Related
I am creating an app using UItabBarController. I have 5 tabBar items at the bottom.
should I wrap navigationController in each item? Is that the best practice, and if not what's the best practice?
The tabs in a UITabBarController represent independent sections within an app. An example is Apple's Clock app. It has 4 tabs which are completely independent of each other.
A navigation controller represents a top-down hierarchy / stack of view controllers (meaning you start with a root view controller and then 'push' view controllers onto the stack. This almost inevitably means that it shows a 'logical flow'. You perform an action like selecting something on a view controller, which takes you into a more detailed view related to the action you performed. An example is Apple's Notes app which shows a list of folders of notes, selecting a folder pushes the screen with the list of notes in that folder onto the navigation stack, selecting a note in that list pushes the note that the user tapped on, onto the top of the list of notes.
Generally you should have tab bar controller as your app's root view controller and then each of the tabs could have a navigation controller as its root. It wouldn't usually have a tab-bar inside a navigation controller.
One case where a tab-bar could live inside a navigation controller is when a tabbed interface is presented modally.
To your question "should I wrap navigationController in each item", I think yes each tab should have a navigation controller as the root if a navigation hierarchy is required in that tab.
Hope this helps you.
The below is my Main.storyboard and it is having tab bar controller. I wish to show a split view controller in one of the tabs of it. The splitVC is in other storyboard as shown in second picture
This is second storyboard which has a split view controller.
I am unable to show it in main storyboard using following approaches:
• Using container view: I tried to show the splitVC in container view programatically but it is throwing error saying :ContainerView must have view controller at index 1 (I tried container view as shown in first picture.)
Can anyone suggest the best way to show it on tab bar ? Or if I am doing container approach not correctly?
Hi #Divjyot Answers here might help apple recommends UISplitViewController should always be the rootviewcontroller
Here is the note from apple
You cannot push a split view controller onto a navigation stack. Although it is possible to install a split view controller as a child in some other container view controllers, doing is not recommended in most cases. Split view controllers are normally installed at the root of your app’s window. For tips and guidance about ways to implement your interface,
i'm curious about what's the best way to plan the controllers for my app.
i want my main screen to have 3 button.
1) should open a nav controller with details view
2) should open a controller with other buttons that lead to others controllers
3) should open a tab bar with 2 pages ( or eventually use a switch to change page instead of the tab bar)
this is the schema of what i want
http://i59.tinypic.com/2rrvrd4.png
Is it a correct schema or i should use my controllers differently? will apple reject an apple with such schema?
thanks
As #Fogmeister pointed out in the comments, going for a UITabBarController as the main interface for your app actually seems to be a more appropriate solution here.
However, you can go with the interface that you described, but then you should keep in mind that with your current setup, you are not only using UINavigationController in the first case, but your whole navigation system is still built upon UINavigationController in the following way:
Your app has one instance of UINavigationController.
Your initial UIViewController (the one with the three buttons), is the rootViewController of your UINavigationController.
You can navigate to the other view controllers using [self.navigationController pushViewController:newViewController] (or performSegue if you prefer using Storyboards).
In the case of your third view controller, you are pushing a UITabBarController onto the navigation controller's view controller stack, this UITabBarController needs to be initialized with the two view controllers that it is going to display before it gets pushed onto the stack.
I apologize if this is simple or answered elsewhere, but I can't seem to find it.
I'm building a tabbed app in which some (but not all) tab views need navigation. Should I:
1) Use a UITabBarController root controller in which the navigation subviews are themselves UINavigationController instances.
2) Use a UINavigationController root controller, containing a TabBar instance, and hide the bar navigation when on a tab that doesn't need navigation services.
3) A totally different architecture.
?
If I understand your choices, you want to do #1. The view controllers that are connected to the tabs can be navigation controllers. In a storyboard, you can start with the tabbed application template, and delete the view controller that's given to you by default, drag in a UINavigationController, and reconnect it to the tabBarController with a relationship segue.
Interface builder does not allow you to add a UISplitViewController as the root controller of a UINavigationController.
I've also tried programmatically creating the UINavigationController and setting its root view controller to be the UISplitViewController.
The result is an empty window with just the nav bar.
I've also tried a split view controller replacement, MGSplitViewController. It mostly works, except that within the split view controller, the master view is another UINavigationController. Its nav bar shows up too thick. Changing orientation and back clears it up.
I've been trying all sorts of different approaches to having a view that looks like a split view and other views that I switch between. I've tried within a tab view controller, writing my own controller to manage subviews of the window and having the split view as a managed view, and now the navigation controller. All attempts have had some issues. The most consistent issue is regarding the orientation of the view. My app is running in landscape mode and typically the child views think its still portrait.
Any ideas appreciated.
No.
The bottom line: a UISplitViewController must be the root view of an app (or perhaps more specifically, a window). It can not live inside a UINavigationController or anything else.
This is the case with the current SDK, and there's no guarantee that will change in future SDKs.
It seems strange to add a split view to a navigation stack. The master pane of a split view controller is generally a navigation controller, so (without knowing more about your design), I'd probably use that to control your navigation hierarchy.