I am building an app where I need to add a TabBarController on a particular screen, Lets assume maybe on second or third screen.
I have gone through several blogs but everyone says UITabBarController can be added as an initial view controller only.
But I want it for some few screens only. How can I accomplish it?
Need guidance!
The answer is "you shouldn't."
From the Human Interface Guidelines:
"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). "
Related
Until XCode 6.2 beta 3 I was able to navigate in the hierarchy and push new interfaces from a button on any of my two pages relationated interfaces controllers.
Such as this:
This used to make such a weird result as stated here
But now, this appears to be a no go. Xcode doesn't state anything on this matter to alert, it just do nothing when you tap on the button that push the new interface.
I can only change that push for a modal to get it work.
But that is limiting my navigation stack as modal are final nodes of the navigation tree.
Also, this is a no go too:
XCode is forcing me to obtain this result only if that push is changed for a modal!!!!
Any workaround please!
This is tying my hands at my back.
You can't do what you are describing, and it is by design. If you were able to do it in a previous Xcode beta, Apple presumably saw that as a bug. They have been quite explicit that you can choose either page-based or hierarchical-interfaces, and that these are mutually exclusive. Both have the ability to present a modal view at any time.
From the Apple Watch Programming Guide:
Interface Navigation
For WatchKit apps with more than one screen of content, you must choose a technique for navigating between those screens. WatchKit apps support two navigation styles, which are mutually exclusive:
Page-based. This style is suited for apps with simple data models where the data on each page is not closely related to the data on any other page. A page-based interface contains two or more independent interface controllers, only one of which is displayed at any given time. At runtime, the user navigates between interface controllers by swiping left or right on the screen. A dot indicator control at the bottom of the screen indicates the user’s current position among the pages.
Hierarchical. This style is suited for apps with more complex data models or apps whose data is more hierarchical. A hierarchical interface always starts with a single root interface controller. In that interface controller, you provide controls that, when tapped, push new interface controllers onto the screen.
Apps can use modal presentations to supplement their base navigation style. Modal presentations are a way to interrupt the current user workflow to request input or display information. You can present interface controllers modally from both page-based and hierarchical apps. The modal presentation itself can consist of a single screen or multiple screens arranged in a page-based layout.
Since Apple developer account is down, I can take the chance of later submiting and getting rejected since I will then run out of time.
Suppose I have 9-11 menu items in main window navigation. It is a bit too much, but that is what customer explicitly requested.
The Android version uses a listview and it works and looks good. It does so on iOS. However, I can see most iOS apps use a tabcontrol at bottom with extra tabs at (...) Is that a strict requirement in all cases? (I can't really say one of the menu items are more important that the other.)
No, using a tab bar controller is not a requirement, that's a design choice. Whether to use a tab bar controller or a list view depends on how you navigate around in your app, and what you want the user experience to be. If you want the user to be able to switch easily and quickly between different modes of the app, or different views of the same data, then probably a tab bar controller would be appropriate. On the other hand, if the choices you're making initially, are not made often, and you have a large number of choices (like you do), then a table view is probably more appropriate.
I am trying to implement a tab-style navigation system in my app (similar to the iOS UITabBarController). The functionality I am trying to create is that each tab holds it's own stack of screens, so that if one switches tabs the user changes to a different stack and can navigate back and forth independently of the other tabs, all the while showing a single tab bar at the top or bottom of the screen.
I have seen this functionality in apps such as Dropbox, but I am not sure if its possible to have multiple stacks or the behaviour is simply clever management of a single stack.
Any thoughts would be very much appreciated.
No, there is only one stack of screens and RIM OS does not support multiple screen stacks.
And you should follow some rules to work with this single stack. For instance, to show previous screen, you need to pop (close) topmost one.
If you do not pop screens, but create more and more new ones, without closing old screens, then you will get OutOfMemoryException.
You will need to redesign your app, use custom Manager class instances and compose your own interface to implement the way of appearance you need.
EDIT: You can have as many in-memory lists of screen objects as you wish, or until they fit to the device memory. But RIM OS allows only one stack of visible screens.
I have developed an app that has work successfully for the last 4 months using iOS 4.3 and under. Since iOS 5 however the tightening of view hierarchy has left my app dead in the water. The app starts with a tab bar as its main view with 5 tabs. When the user selects a row on a tableview on the first tab it pushes onto another tabbar with 3 tabs which gives specific information about that selection. This structure worked fine but obviously broke when testing on iOS 5.
My question is: Is it bad design to utilize 2 or more tab bars in one application? I don't mean "bad design" in the grand scheme of things because that is subjective. I mean in a practical sense where it is specifically forbidden or not recommended.
have a look at this:
iOs Human Interface Guideline
Yes, I think that it's not recommended.
For example:
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. When you use a tab bar, follow these guidelines:
Don’t use a tab bar to give users controls that act on elements in the current mode or screen. If you need to provide controls for your users, use a toolbar instead (for usage guidelines, see “Toolbar”).
In general, use a tab bar to organize information at the application 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.
I am new to Iphone programming. So please don't mind if I ask some basic questions. :mad:
I want to develop an application where the landing screen will be a login screen and after login application should display a new screen with the list of available categories. And on selecting any category a new screen should appear with the information related to the selected category.
Basically I want to display different screens in the applications and my confusion is how can I make different screens with one .xib file? or should I use different .xib files for each screen. If I use different .xib files for each screen then how should I navigate to different screens.
Please help in solving this confusion.
Thanks in advance
Gaurav
You should definitely use different .xib's for each view. You will end up having a standard view, a table view (probably programatically wrapped in a navigation controller) and a standard view, respectively. Each will also have their own class.
You navigate to different screens by programmatically initializing them. The condition on which they are created varies from screen to screen. For example, your login screen will only create and load a table view for the categories after a successful login. The category screen will only create a detail screen when the user touches a category in the table.
I think your best bet is to pick up an iPhone programming book and do the first few chapters until you feel comfortable with the basics of XCode. The Apple documentation usually contains more than you really need to know and by the sounds of it, you just want to jump in and make a few simple apps.
After that, you can look at the Apple sample code here: http://developer.apple.com/iphone/library/navigation/index.html#section=Resource%20Types&topic=Sample%20Code