Like many other developers out there, I've created iPhone projects that use a UITabBarController as the root controller, with the tab views using UINavigationControllers to drill down from lists to detail views. And like many other developers out there, I need to migrate these apps to the iPad so they take advantage of the bigger screen (and more importantly, not forcing the user to use the ugly "doubling" visualization for iPhone-only apps).
Apple created the UISplitViewController for this exact scenario... seemingly. I say seemingly because although I see it used in Settings, iPod, iTunes, and so on, none of those applications use UISplitViewController inside a UITabBarController, because it's not only documented as not working, but apps can crash if those two are forced into a shotgun marriage.
Consider a hypothetical iPhone application all about Animals. It has three tabs: "Categories" (where animals are categorized by some simple method -- perhaps we have a two-level hierarchy with categories like "Birds" and "Fish"), "Search" (which uses a standard UITableView and a UISearchDisplayController), and "Stories", which are stories about animals (perhaps there is a story about frogs, and another about computer nerd horses that turned into l33t unicorns).
While "Categories" and "Search" are two tabs that could be merged, it's not clear that you could or should merge the list of animals with the stories about the animals. So while you might like to use a UISplitViewController on the iPad (with the search integrated in the "root", left, side of the split), how do you present the "Stories" view? Do you use a segmented controller? Top or Bottom? "Root" or "Detail" view of the split? Or perhaps you use a "home" screen (like WebMD's iPad app) which shows two buttons ("Categories" and "Stories") and then shows a split view for whichever the user taps? Or a toolbar at the top or bottom?
I tried looking at several other apps, including Settings, Mail, iPod, iTunes, Contacts, Maps and so on, but none of them present two "different" kinds of information in one application.
What's the general approach here? Are there any best practices? Any general patterns that the iPad programming community has adopted?
Or do I wait and cross my fingers that Apple somehow eventually allows UISplitViewController to work without requiring it to be the "root"? (That might never happen!)
You could use the UISplitViewController and have a UITabBarController as the master view controller (the left side pane that is usually a list).
That way you could still use the tabs and drill down approaches until you read the detail view for each animal (using your analogy) and then display the detail page in the detail view controller (the right side pane).
This would work and isn't forbidden by Apple or the HIG.
That's my idea anyway :)
Related
My project is setup so that a user will search for a particular item. This item has three different groups of detail information. What I wanted to do, is create a Master/Detail scenario and then on the Detail screen have a tab bar with three different views to match the three different groups of detail info. However, I'm having a lot of trouble getting it to work. I searched and found this stackoverflow question:
IOS - How can I add a tab bar to navigation controller (Master Detail template)?
Which seems to suggest that if I follow my plan, Apple will likely not accept my app because the tab bar should be persistent across the app. This seems ridiculous to me. There are plenty of scenarios where the tab bar shouldn't be on every view. For instance, the first view in my app is a login screen. I certainly don't want the tab bar there. Is this something anyone else has encountered? And if so, do you know of any tutorials that could help me get this working?
I work in xcode 4.4 and use the storyboard rather than the nib files. Right now I'm able to get my master view to navigate to the detail view and I can see the tab bar on the detail view. However, my views in the detail have table views with static cells and I can't see any of the information that is supposed to be in them.
There are rules and there are guidelines. Apple does not have a rule that if you have a tab bar, it must be present everywhere in your app. They have guidelines which state that tab bars should be consistent across views. Apple has rules like, don't use unpublished API calls. Those rules will get your app rejected, and they are in the app store submission guidelines. The user interface guidelines are really guidelines for how you should create your app, unless you have an overriding good reason to do otherwise.
Fellow stackers,
I am developing the interface for my iPhone application and I'm in doubt about an important paradigm that is present in almost every view I am making. I've read the Apple Human Interface Guidelines but I think that my question isn't answered there.
The problem is, e.g. in the "My Account" view I have to display all the kinds of content the user has created (Comments, Favorites, Notes, etc.). I am currently planning of displaying those as UITableViewCells in the main UITableView of "My Account": there will be a cell for Comments, that pushes the comment controller in the navigation controller, and so on for the other kinds.
One problem arises anyway: I've noticed that many applications use UISegmentedControls to accomplish the same task, and they seem to do so in a non coherent manner. Sometimes they use one method or sometime another. Is there a clear way of choosing one over the other? Or is it just personal preference?
I believe that there are situations where one is likely to be better than the other. As a personal rule of thumb, I avoid cluttering the current view with buttons that link to all the other available sections. I instead prefer an index where I can pick a section and have it load up that, then when I'm done, go back if need be.
So for example if you were using a tabcontroller to navigate between views like the "My Account" view, I would not use a UISegmentedControl. I would use a UITableView. This just allows for you to be more focused on the task at hand.
However, if you belive that your users will be flipping between sections in the account view more frequently, then maybe a semgented control would be the way to go for you.
I have a very specific application design that I'm trying to figure out how to create with iOS 4.
Here's how it works:
The user selects an installed data set, or triggers a data set download.
The user provides a key for decrypting the data set.
A tab bar is shown with different search options for looking at the data. There are more searches than fit on the tab bar, so there's a More item and an Edit button. (Thanks, Apple!)
The searches provide different options, some requiring an additional screen for setup.
Once a search result is tapped, the user sees details. They can usually tap deeper into the result.
The tab bar stays visible as users look at details, letting them start a different kind of search. Tapping a search takes them back to step 3.
If at any time the device goes to sleep, the data must be locked. This is a hard requirement, despite may efforts to remove it. So at the moment, I'm returning to step 2.
I've implemented this in iPhone OS 3.1 with a UINavigationController for steps 1 and 2. The app pushes a UITabBarController with each tab represented by a UINavigationController for step 3, hiding the navigation on the outer controller. The user then operates within this UITabBarController. For a lock, I just pop the tab controller off the navigation controller.
It mostly works in iPhone OS 3.1, but it's fragile and hackish. There was no good way to change the data set, but the user could just close the app. With iOS 4 this workaround is gone! The only option I see is returning to step 2 on a supsend/resume, which is going to be a terrible multitasking experience.
How should I be doing this?
The tabs don't make sense until the data set is opened and unlocked.
I (and my users) really like the single tap (no matter the depth) to start a new search.
i have recently started working on iPhone but i am completely confused which application is best for the programming.. i mean TabBar Application, Navigation based app or window based . As we generally need all tab bar and navigation bar in our application In that case which application i should use??? Please explain it.
Cheers
The need for a TabBar, NavBar, or Window based application is mostly subjective. This will depend on:
How you want the application to look
Whether or not you need the functionality of the nav and tab bars
Window only applications are typically the EASIEST to implement, at first, but do not provide the necessary functionality that many people are use to. Window/OpenGL based applications are ideal for games that require "full screen."
TabBar applications are perfect for applications that have several main "sections." Akin to a website that has "blog", "products", and "contact us", you can have many sections with the TabBar.
NavBar applications let you stack up additional views, one at a time, that you can transition to as necessary. A typical implementation of this is a "drill-down" menu.
Good luck!
-Kevin
If you are wondering which user interface element to use, I recommend reading the "Navigation Bars, Tab Bars, Toolbars, and the Status Bar" section of the iPhone Human Interface Guidelines.
If you're asking which application template to start from, it doesn't really matter. You won't be locked into a particular type of application if you start from a particular template. You can even start multiple templates, and copy across the relevant code and interface elements that Apple provides for you to combine functionality.
I have a tabController-based iPhone application. First tab is associated with a table view controller. When I select a table cell I want to show another table controller view, but with different tabs on the bottom. What is the best way to do it? Change dynamically tab entries, or do it through IB? Please advise.
Thanks,
Nava
The Apple Human Interface Guidelines really advise against this.
For example, on iPhone, iPod uses a tab bar to allow users to choose which part of their media collection to focus on, such as Podcasts, artists, videos, or playlists. The Clock application, on the other hand, uses a tab bar to give users access to the four functions of the application, namely, World Clock, Alarm, Stopwatch, and Timer. Figure 6-10 shows how selecting a tab in a tab bar changes the view in Clock. Notice how the tab bar remains visible in the different Clock modes shown in Figure 6-10. This makes it easy for users to see which mode they’re in, and allows them to access all Clock modes regardless of the current mode.
What you're thinking of doing might be possible with toolbars.
BTW, I found the best and the cleanest way to do that thanks to Rufus - iPhone Beta Dev Forum contributor: you can change the views of root tabbarcontroller anytime you want, also you can change tabbaritems title & icons. So actually I don't need 2 tabbarcontrollers, instead i change the existing one, setting its views & tabbaritems of views accordingly.