I'm new to IOS development and I need some advice on when to hide main tabs.
I've been going through quite a few apps to figure out if there is a recommended approach, if the main tabs should be hidden or not once you are 2+ levels deep.
So my scenario is pretty standard, I have a tabbed interface aka "Apple Store" app.
Once I start navigating (pushing Controllers), should I hide the Tabs at the bottom and use only the NavigationBar?
Related
I'm using Appcelerator Titanium to build an iPhone app. I currently have a tabGroup control that links to the major sections of the app, including the home screen.
What I'd like to do is remove the "Home" tab only from the navigation, without removing it from the tabGroup object. So, for example, I'd still be able to call tabGroup.setActiveTab(0) and it would take me to the home screen, but the tabs at the bottom wouldn't have a "home" button.
Is this even possible? If so, how can I do it?
Notes: I do not want to hide the whole bar, just a single tab. I also do not want to remove the screen from the underlying object, just the navigation UI. Also, I'm only developing for iPhone and don't care if other platforms aren't supported, so iPhone-only solutions are acceptable.
take the home screen out of the tab group completely and manage displaying it and transitioning to it separately; in the end, it will be a cleaner solution.
Have you tried tab.hide() or when creating the tab setting it to visible: 0?
I want to use two different uitabbar control in the application. first UITABbar control i add in the starting windows. and in this after the navigation i want to show the other tab bar with 5 tabs. can any one suggest how i do this ?
Or we need to add a different window for add this and need to show this windows on the click or other?
Please suggest.
Thanks
The Human Interface Guidelines specifically recommend against having multiple tab bars in your application:
If your application provides different
perspectives on the same set of data,
or different subtasks related to the
overall function of the application,
you might want to use a tab bar. A tab
bar appears at the bottom edge of the
screen.
A tab bar gives users the ability to switch among different modes or
views in an application, and users
should be able to access these modes
from everywhere in the application.
However, a tab bar should never be
used as a toolbar, which contains
buttons that act on elements in the
current mode (see “Toolbars” for more
information on toolbars).
If you need to have context-specific actions, use a toolbar instead.
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 :)
I'm quite new in iPhone Programming, but I'm trying to do my best cause I have some skills in OOP.
I'm creating an iPhone app based on a four element Tabbar. I would like to use other functionalities already implemented by a friend of mine in his own iPhone app (a three elements TabBar app).
Since I would like my app's users could "switch" to old application (3 tabs) by pressing on one of my app's tab, my question is: is it possible to do this, maybe by "popping out my tabbar" (4 tabs) and "pushing in the old tabbar" (3 tabs)?
For a better problem description, we could say that I'm trying to implement a "new mode" and "old mode" in the same application.
Thank you in advance.
P.S. I'm using Xcode 3.2.2 on a Macbook Pro coreDuo and 3.1.3 iPhone simulator
Luca
Your question is a little bit vague, but if you want to be able to choose between two different tab bars, the easiest way to do it is to include both tab bars in the application, and simply hide the one you don't want active. You can still do this in Interface Builder. Just wire up both tab bars, and let your view controller hide the old one in -viewDidLoad. Then, when the "old mode" button is pressed, show the old tab bar and hide the new one.
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.