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.
Related
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.
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.
The IMDB app for iPhone seems to allow infinite drill downs and explorations from a movie detail page to a detail page of an actor who was in that movie, to that actor's first movie to that movie's director, etc.
What is the best way to build this in Xcode?
Be sure to check out Apple's UINavigationController documentation/sample code here. You can learn a lot about iOS development from looking at the sample apps.
The "infinite drill down" you're referring to is the act of "pushing" a controller onto the current stack of controllers. As you go back, you "pop" a controller off the stack to get back to the previous controller. If implemented properly, UINavigationController will handle things like making sure the Back button contains the title of the previous screen, keeping the screens in order, and the sliding motion.
Good luck!
You can create by using a UINavigationController and push the view one by one as you want.
I'm hoping someone can tell me if it's possible to put a separate navigation stack on the detail view for a split view controller. I've been banging my head against this problem for a while and now am wondering if it's even possible.
I'm developing a universal application that allows users to browse a conference schedule. On the iphone this is simply a a table view where users:
-->selects a session topic from a list of topics (plain table)
---->selects a session title from a list of topics(plain table)
------>sees details about the session including papers to be presented and can selected a individual table (grouped table)
-------->sees details about the paper (grouped table)
What I'd like to do for the ipad version is something like this:
-->selects a session topic from a list of topics (root controller, plain table)
---->selects a session title from a list of topics(root controller, plain table)
------>sees details about the session including papers to be presented and can selected a individual table (detail controller, grouped table)
-------->sees details about the paper (detail controller, grouped table)
That's the goal, but everything I've tried in terms of getting the detail controller to have a separate navigation stack has screwed up the split view controller. I can get everything up to the last step working fine. But as soon as I push a the details about the paper onto the detail controller stack, the splitview controller goes crazy.
Has anyone accomplished something like what I'm describing above?
I could simply replace the session details controller with the papers detail controller instead of trying to push it onto the stack. But then I lose all the benefits of the nav stack, lose all the free transition animations, and have to maintain a substantially altered version of the same table for the iPhone and iPad.
Thanks in advance for any suggestions.
I swear, sometimes I think stack overflows greatest benefit is how often publicly posting a problem spurs me to solve it myself.
So what I describe is definitely possible. Simply look at the settings app. It does exactly what I describe.
The problem I had was that some of my detail view controllers, because they were inherietend from the iPhone version, did not implement "shouldAutoRotate". Once I added that, everything fell into place.
If anyone else if facing a similar problem, I might also suggest you start with Matt Long's walkthrough of adding a navigation stack to the splitViewController here:http://www.cimgf.com/2010/05/24/fixing-the-uisplitviewcontroller-template/