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.
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.
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). "
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.
When you build a tab application, should each tab be a view or a window?
Many developers say your app should only have one window with many views. Other developers say use windows for each tab.
Which is correct practice?
The general rule with iOS apps is that you want one UIWindow instance per physical screen. Until iOS added better multiscreen support, and the newer hardware was able to natively support app mirroring, most apps used one window, unless it explicitly supported a second display.
It follows then, that you want one UITabBarController to show instances of UIViewController objects. This rule should hold true regardless of the SDK you're using to write your apps, assuming that titanium maps its classes back to their native Objective-C counterparts.
The window doesn't have many views in a normal app, its simply hosts views while being displayed. I have never heard of using windows in tab views, I have several apps out that use tabbarcontrollers and I always use UIViewController subclasses (or UINavigationController subclasses) with a view in its nib - all works perfectly fine.
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.