Tab Bar Controller with seven tabs, Five tabs lead to Split View Controllers - ios

I've done a lot of research and read a lot about the use of Tab Bar Controllers with Split View Controllers but cannot seem to find any hint of how to solve my problem...
The following post in the Apple Developer Forum for Cocoa Touch under the heading "Place SplitViewController inside TabBarController" has so far given me the greatest lead.
As of iOS 8, embedding a Split View Controller in a tab bar controller
(or your own container view controller) is supported and expected to
'just work'. Pushing a split view controller onto a navigation stack
remains unsupported.
This appears to go against Apple Documentation including this article titled "Combined View Controller Interfaces" dated November 2014.
You can use the view controllers that the UIKit framework provides by
themselves or in conjunction with other view controllers to create
even more sophisticated interfaces. When combining view controllers,
however, the order of containment is important; only certain
arrangements are valid. The order of containment, from child to
parent, is as follows:
Content view controllers, and container view controllers that have
flexible bounds (such as the page view controller)
Navigation view controller
Tab bar controller
Split view controller
I have a UITabBarController with seven tabs. Of these, five tabs lead to UISplitViewControllers and two tabs lead to UINavigationControllers.
Here is a screenshot of some of the storyboard the shows the tab bar controller leading to three of the five split view controllers...
No problem when I run for target with self.traitCollection.horizontalSizeClass = UIUserInterfaceSizeClassRegular - where the horizontal (width) dimension of the device screen is Regular (not Compact) -> running on an iPad. All seven tabs appear across the bottom tab bar and all view controllers, including split view controllers, work perfectly.
My problem?
Xcode spits an error and freezes app operation when I run for target with self.traitCollection.horizontalSizeClass = UIUserInterfaceSizeClassCompact - where the horizontal (width) dimension of the device screen is Compact -> running on iPhone or iPhone Plus. Same outcome, as expected, for both IB and on iOS device.
Error Message: Split View Controllers cannot be pushed to a Navigation Controller <UIMoreNavigationController: 0x7ffda38b0200>
I know why I've received the error. Where the horizontal size class is "Compact", the seven tabs drops to five on screen, including one (specially prepared by iOS) "More" tab. The remaining three tabs are relegated to the "More" tab that is its own navigation controller and table view controller. My storyboard is attempting to push the split view controller onto this navigation stack.
Any thoughts on a legitimate solution?

I would recommend using a custom tab bar controller with a "More" section that does not push view controllers into a navigation controller. Preferably, one that is a subclass of UITabBarController, so you can use it with Interface Builder.
My approach would be to replace the current "More" table view controller with a view controller of your own that shows a list of overflowing tabs, but does not push their corresponding view controllers into the navigation bar when displayed.
One possible strategy is to become the delegate of the UITabBarController's more navigation controller (found in the tab bar controller's moreNavigationController property). Then use a delegate method, such as navigationController:willShowViewController:animated:, to replace the content of the navigation controller's viewControllers array if the view controller to be displayed is anything but your custom "More" view controller.
I haven't tried this, but it seems like a good place to start and does not require too much knowledge of the tabview controller's internals.

Related

What's the best practices on UItabBars in navigationControllers?

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.

Back Navigation from Embedded UISplitViewController Using Single Navigation Bar

I’d like to have split views in several places of my iOS app, none of them as the root view controller. I understand that split views are initially designed to sit at the root of the app and provide the root navigation controller, and that Apple’s guidelines initially did not allow any workarounds. Updated guidelines state
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.
Now the split view pattern would really benefit my app, and I don’t want to reinvent the wheel here, so I gave it a try using a container view, mainly using the following steps:
Create a scene with a regular UIViewController.
Add a UIContainerView covering the entire screen.
Add a UISplitViewController to the storyboard, which creates a split view controller, a navigation controller, a table view controller (for the master view), and a regular view controller (for the detail view).
Create an embed segue from the container view to the split view controller.
This has a few quirks, which I hope to iron out eventually (e.g. initially showing detail view, swiping in the table view from the left on an iPad apparently tries to also back nav on the main navigation), but it basically works. So far, so good.
Now, the problem is that I have two navigation controllers: the main navigation controller at the root of my app and the navigation controller in the embedded split view. This gives me two navigation bars with independent navigation, allowing me to:
navigate back to the root of the split view using the embedded navigation controller
navigate back from the container view in the enclosing navigation controller
Besides two navigation bars not being appealing, I don’t want iPhone users to perform the second directly from the detail view. So my next steps were:
hide the navigation bar in the outer view controller
add a back navigation button to the inner navigation bar to take over the role of the main navigation bar’s back button
Left to do is the implementation for that back button that pops the container's view controller of the main navigation stack. The question is: how can I access the main navigation controller from the embedded view that has its own navigation controller (using Swift)?
Accessing the navigation stack of the parent's (containing view controller's) navigation controller turned out to be straightforward:
#IBAction func backButtonTapped(_ sender: UIBarButtonItem) {
parent?.navigationController?.popViewController(animated: true)
}
I had to face a similar kind of problem while developing my app.
My problem was, I had to display navigation controller and splitviewcontroller on side bar. Again a problem was navigation controller form splitview to navigation controller. Below are the steps which i followed
1) While creating a split view controller, I hided the navigation controller of master and detail and set it to root view, please also keep the reference of your top level navigation controller.
2) I increased the 'y' of splitview.root.window and view to accommodate custom view.
3) I created a custom view with a back button and then handled the transition with animation.
Please let me know if you want code snippets. I would have shared it now. But i have to search for it.

UISplitViewController inside tab bar

I have an app which has a login screen and when the user logs in, a tab bar controller is pushed. I currently have some views that would benefit from the fact that apple now allows using the split view controller in all iOS devices, so I was preparing to implement this when I read that the UISplitViewController must always be the root view controller. So I was wondering if it is possible to make the view in one of the tabs become a master-detail view using a UISplitViewController or will I need to implement this manually?
In case it is not possible to show the split view as a tab, could it be pushed from the tab bar controller? (e.g. the user taps a row in a table view and the master-detail view appears).
UISplitViewController in iOS 14 gained new API including a new column style that behaves differently from the unspecified style which is the "classic" interface. Using the modern column-style API, if you try to embed a UISplitViewController in a UITabBarController, it may not behave as you'd expect. For example, at least as of iOS 15, only the secondary view controller may be visible when you'd expect the primary and secondary be shown side-by-side. The documentation does note the following:
When you build your app’s user interface, the split view controller is typically the root view controller of your app’s window. ... Although it’s possible to install a split view controller as a child in some other container view controllers, doing so is not recommended in most cases.
I have however shipped multiple apps that put a split view controller in a tab bar controller using that classic API (via storyboard and programmatically), and they continue to work as of iOS 15. But it may be wise to move away from this as it's seemingly not an officially supported configuration.
Original answer pre-iOS 14:
You can definitely embed a UISplitViewController inside a UITabBarController. I've done just that for an app I released on the App Store. It has 3 tabs and each one is a split view controller.
Just drag out a tab bar controller into your Storyboard, delete the two controllers it added, then drag out a split view controller. Control drag from the tab bar controller to the split view controller and select the "view controllers" relationship segue.
On Xcode versions less than Xcode 8, you may see black or white bars at the top and bottom of the split view controller in the Interface Builder canvas, but these will not appear when the app is run on a device.
Here is the app running to show the split view embedded inside the tab bar controller on iPhone 6s Plus:
When you put a UISplitViewController inside a UITabBarController and the tab bar is set to be opaque you have an issue where your UISplitViewController content is shifted up the size of the tab bar:
To fix this issue you have to check the Under Opaque Bars checkbox on your UISplitViewController in your storyboard:
And now the UISplitViewController view size is correctly computed:
There is also a problem using this approach in iPhone (>IOS8) where the splitviewcontroller is in collapsed mode. When we push the list view to the details view we cannot hide the tabbarcontroller using the conventional "hidesBottomBarWhenPushed". So I have added the TabBarcontroller as root viewcontroller of a navigationcontroller. Now when I push to details view, I send the message to the root navigation controller and push the view to the details view instance in collapsed mode whereas in regular mode I just push it using showDetailsViewController()
For me, this worked.
XCode 13.2.1
iOS 15.2
splitViewController.extendedLayoutIncludesOpaqueBars = true

ios: storyboard + tabbar + more button (design)

I have a little app that shows a list of dvds, then you can drill down from the table view and get some details. It also has a tab bar at the bottom and you can switch from dvds to bluray as tab buttons. This all works fine.
In reading about tab bar apps, I saw a demo that once you added more than 5 tab bar buttons, "more" would show up and then you can drag-n-drop the buttons like in Apple's Music app, which is cool! I also noticed that each tab bar button controlled a separate navigation controller, which was a new technique to me.
When I created my app, it had a single navigation controller and I added a view controller with the top of the view being a table view and the bottom of the view a tab bar. I then drag buttons to the button bar and can add more than 5 buttons and "more" doesn't show up.
So, I figure, it needs to to be a different navigation controller design.
I am confused on if I can take my app and embed a tab view controller or if I can adapt what I have or not.
Right now, since all tabs are basically the same (a table that drills down to a detail view) I just reload the data from a different file when the tab is switched. Nice and clean.
If I switched to the tab view controller concept, it seems wasteful to create 5 navigation controllers with 5 table views that drill down to 5 detail views. Plus what if I wanted 7? or 9? (I do realize (or guess) that I can give each 5 views the same class name, but still the UI has lots of storyboards…)
This is a design question to better understand what my options are.
Tab bar controller must always be the root controller of an application. (Unless it's in a split view, in which case the different sides of the split can be a tab bar controller - but it still has to be the root.)
So, the correct design for your app is: tab bar controller as root, each tab containing a navigation controller, each navigation controller having your table view controller as the first view controller. It may seem wasteful but if you think about it, each tab really needs to have its own stack of controllers, so there's no other reasonable way to do it. If user on tab 1 is 2 deep in a nav stack but tab 2 is 7 deep you don't want to switch between tabs and lose your place.

IPad Split View Implement in Another View

I am creating a iPad App and it has several views to load data,but for one view i need to add split view. I dont need split views in other views. They are just detail pages. I search Through the net and found lots of tutorials based on iPad split view. But the problem is they all are creating a project as Split view project or they create a window base app and add slipt view to the delegate. I dont need to do that, I need to implement this split view only for one view. Is There any way to overcome this problem?
You can add the split view inside a Navigation Controller.
Even if the Split View is a container view controller and Apple recommends in the documentation that all containers should not be embedded in other containers, adding a split view inside a navigation controller works correctly and I never noticed any side effect in doing it.
Basically what you should do is:
- in the app delegate create a UINavigationController and use it as root view of your application window
- hide the navigation controller navigation bar if you don't want to see it (showing a split view with a main navbar on top is not nice looking...)
- then add your view controllers inside the navigation bar.
Example: imagine you have this application views sequence:
FIRST VIEW (full view = detail page)
SECOND VIEW (split view)
THIRD VIEW (full = detail page)
So you can represent FIRST and THIRD as standard view controllers (full screen), while SECOND will be a split view. Your app will be initialized by creating the main navigation controller, adding FIRST on it as top controller and using the main navigation controller as window's root view.
Than use the navigation controller push, pop methods to switch between these views or change the navigation controller "viewControllers" array directly if you don't want the recommended push/pop methods.
If you need to add special behavior to the navigation controller based on the type of view on top, just register your app delegate as navigation controller delegate (or a "main controller" object dedicated to this if you don't want to complicate your app delegate).
I am not 100% sure, but it seems to me that you can't use a SplitView just somewhere in your view hierarchy.
The Apple intended way is to use the SplitViewController as the top level controller. The left side of it can include a drill down mechanism with a navigation controller so you are ably to drill down hierarchies and the right side will present details for the item you select on the left side.
If you need a view with some kind of split mechanism in it, you probably have to code it yourself. Or even better: find some other mechanism you can use in your UI.
How are you switching your view hierarchies now? Maybe you could integrate your existing UI into a SplitViewController?

Resources