I’m working on an app which combines a tab bar controller with a number of split views, so that each tab item shows a different master-detail view. I want the tab to be visible at all times so the user can switch directly between master-detail views.
I can achieve this by having a separate split view for each tab, but I'm not sure whether this is approved by Apple. The view controller catalogue for iOS says "A split view controller must always be the root of any interface you create." However the UISplitViewController API reference says "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."
As an alternative approach, I can have a split view as the root, with a tab controller on the primary. This means though that the tab is hidden on compact width devices when the detail view is shown. The user has to navigate back to the master view to switch tabs. This is not the behaviour I want and is not what happens with the Apple Music app for example.
So, a couple of questions:
Would Apple reject the app if it has a tab as the root and multiple split views?
Is there another way of achieving what I want?
Many thanks.
Your quote says "not recommended", not "your app will be rejected".
The only wishes you have expressed are "I want the tab to be visible at all times so the user can switch directly between master-detail views". That doesn't really leave room for alternatives. Also, you haven't described your app. It might be that your design choice is not suitable for its use cases.
It sounds like you want us — a third party — to speculate about whether Apple would reject your app. This is not the right forum to ask for that, but I say try, and you'll get a definite answer.
Related
I have two storyboards, and both contain a TabBarController. Let's call the first storyboard/TabBarController Groups and the second Users
When I segue from Groups to Users, the Users UI appears, but the Groups tab bar remains.
How can I segue from Groups to Users such that the UI and tabbar changes.
EDIT:
My goal
What you're asking to do is perfectly legal and easy. Simple do a present / modal segue from one UITabBarController to the other. This will completely replace the interface (the first tab bar controller and its tab bar) with a new interface (the second tab bar controller and its tab bar).
Don't use segue for this. It is impossible to let UIKit know what you are really want to do is switching the tab, it just think you want to create a viewController instantiate from storyboard and push it into nav stack.
Try this:
self.tabBarController?.selectedIndex = // the index of your dest tab, start from 0
What you're asking is against Apple's guideline regarding Tab Bar. That said, I'm sure you can do it if you really wanted to, but I'd suggest you rethink your design because:
Design perspective: Apple's HIG is pretty sensibly laid out for a smart phone environment, so following it is more helpful than outright ignoring it.
Practical perspective: Your app's chance of getting rejected at App Store will be higher.
From Apple's iOS Human Interface Guideline:
Use a tab bar to give users access to different perspectives on the
same set of data or different subtasks related to the overall function
of your app.
In general, use a tab bar to organize information at the app level. A
tab bar is well suited for use in the main app view because it’s a
good way to flatten your information hierarchy and provide access to
several peer information categories or modes at one time.
Don’t use a tab bar to give users controls that act on elements in the
current screen or app mode. If you need to provide controls, including
a control that displays a modal view, use a toolbar instead (for usage
guidelines, see Toolbar).
Link
I'm trying to build an app that has lots of similarities to the Facebook App in terms of the "Storyboard". I'm tempted to do everything in code as I know best but I'd really like to figure out how to storyboard these more complicated UI's.
The Facebook App starts with a login view. When you log in, you get a tab view. In the main tab view, you have a table view. Within each table view are a user, post, and comment buttons which push to a new view.
So the way I am understanding it is we have UINavigationController with the .navigationBarHidden set to false. The first view controller here is the loginViewController. When the login button is pressed and the user is logged in, we performSegueWithIdentifier to a UITabBarController. The first tab is a UINavigationController with a UITableViewController as the first view controller. Clicking user, post, or comment pushes the appropriate view controller onto the NavigationController.
This all begins to seems a bit more complicated than just writing this all out in code. I'm also not even sure this implementation is correct with all these nested view controllers. I'm not sure this is all possible with storyboard as well: for example a navigation controller for pushing to comment, user, or post views doesn't seem possible with storyboard.
I'd like to know the correct way of implementing this kind of UI design. And should / could this be implemented using Storyboards?
Your design team may layout the app using a "storyboard" (physical objects -- not the digital version). Large apps are hard to piece all the little things together on a storyboard. Just too many wires going every which way.
Look at the FB app without internet access and you can see their basic building blocks easier. Its built in units (post at a time) that are added to a scrolled view. Search bar and menus at the top and buttons at the bottom with the scrolled view in the middle. The posts probably have some common base class with various types derived from it (picture, video, links, etc).
There is some sort of background process monitoring the position of the scroll view to dynamically load new stories if you get down within 1/3 of the way to the bottom. Within each post you can see the components if you look closely and think about what sort of block that is.
i'm building app for cars ...
app first view is cars listed in table "UITableViewController", when user select a car "cell" the app navigates to "UITabBarController", because for each car there are a lot of infos and specification that need to be displayed in separate view, so i use here "UITabBarController"
so the tab bar controller is not in the top view level....
Question 1: is this correct usage of the UITabBarController? i'm afraid of getting rejected from apple app review ,i read in apple docs
"In general, use a tab bar to organize information at the app level. A
tab bar is well-suited for use in the main app view because it’s a
good way to flatten your information hierarchy and provide access to
several peer information categories or modes at one time."
http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/UIElementGuidelines/UIElementGuidelines.html#//apple_ref/doc/uid/TP40006556-CH13-SW41
Question 2: are there any apps in the market that don't put the tab bar controller in the top view level! plz give me links to them......
The key words here are "peer information categories". That means information which is related by a common theme, in this case a specific model of cars.
So a structure that had a tab for engine data, a tab for interior spec, a tab for fuel performance and so on would be perfectly fine. All the tabs display data that relates to the same car. What would make less sense is if you mixed things up by including a tab that wasn't related to the selected car.
Ideally you'd want to embed the UITabBarController in a UINavigationController so that the navigation bar would display the context (say the car name or something similar) and a back navigation button to provide access back to the table view.
Yes, it's, your app will not get rejected.
There are should be app using the tabbarcontroller like you are going to use, but I don't know them.
My application is for studying. It will have three screens, one for studying (reading), one for reviewing, and one which acts as the main menu (for managing documents and selecting study or review). The main menu will be the first screen when the app is loaded.
I am trying to decide on the best approach with regards to what view controllers and views I need.
Approach A:
(4 x View Controllers - root, menu, study, review)
This approach has a root view controller with no on-screen controls. It will always contain one of the other view controllers as a subview. For some reason I am attracted to this approach but I have seen no other examples of this so maybe I am being stupid. I am wondering if there is a reason why this is inherently wrong.
Approach B:
(3 x View controllers - root (menu), study, review)
In this approach the menu IS the root controller and the other controllers load in subviews of the menu. I think this is more of a standard way of doing things.
I would be grateful to hear any thoughts on which approach is best. I am a newbie to software development. I have worked through a number of books on iOS software development and messed around for a bit and now I am starting my first app for iPad.
Whenever you're determining how to layout your views and controllers, they're very often based on the application flow (from an end user's standpoint). So from your original question I'm not sure I exactly understand the flow- is the user forced to start at the main menu, and then from there is able to toggle between two mutually exclusive views (study & review)? If that's the case, I would recommend using a tab bar controller for the 'Study' and 'Review' views, as it allows for saving states of the views and switching between them without you having to do any extra work (from both of the approaches you described it sounds like you'd largely be recreating this behavior yourself). Then, for the main menu (which I assume is displayed when the app first starts?) You can simply open it modally (note you don't have to animate the opening, so it can instantly appear instead of sliding up from the bottom, and the user will never be the wiser). Once the user selects what they need to select in the main menu, dismiss the modal view and you're ready to go with your 2-tab controller.
The Flow of my application is
Application Starts -> TopMenuViewController ( Which Contains Several Buttons & navigation controller ) -> When particular button is clicked -> Load Split View Controller.
The user can go back to TopViewController. In short I want to load UISplitViewController on button click. How to do this? Thanx in advance.
In my experience, there's no good way to load a UISplitViewController on demand like that. It has to be the root of your entire user interface, or you will pull your hair out trying to make things work.
I've reworked several app designs to fit into this requirement, and it's generally not been difficult at all to come up with something functional and attractive which fits into the split-view-at-all-times paradigm. You can freely swap the views loaded into each side of the split with login panels, empty placeholders, etc. to make your flow work with the splitview.
There are third-party split view controllers that mimic Apple's and allow later loading (as well as master pane visibility in portrait, and other features). One is Matt Gemmell's MGSplitViewController. You could also come up with a different presentation altogether for your master-detail hierarchy.