I am designing a coperate iPad app. My app has 5 mini apps each completely separate in functionality, but all for the company.
I planned on having a full width top bar displaying the current mini-app name at the top, with a home button on the far left. This will be persistent throughout each mini-app. Then underneath have the custom app.
Each mini-app uses navigation bars, tab bars, and toolbars. So the above idea was my best guess on a way to go back to the home screen.
Would anyone recommend against this?
And, how can I make a persistent top bar?
I can come up with this part, but just in case someone knows the best way, I wanted to ask.
I was thinking of changing the frame for the navigation controller to start at y=20pt.
In the Human Interface Guidelines: Brand Appropriately it mentions having a second persistent top bar, but I don't know any other way.
Related
I need some help figuring out how to fix the layout of a navigation bar in an iOS app. When adding navigation to 'child' views of a given screen, my approach so far has been to add buttons to the 'leftBarButtonItems' collection of the UINavigation item. As long as the number of buttons doesn't exceed 3 or 4 everything works great.
Unfortunately, I now have a screen that requires additional buttons. Everything seemed to build fine, but when I actually run the application I end up with a jumbled mess like this:
Is there a better way to layout a UI with nav and toolbar buttons like this? If putting the buttons in the nav bar is actually the correct way, what do I need to do to make the layout handle cases where the content can't fit?
I wouldn't bother with adding any extra buttons. Users expect most apps to behave in similar ways, and (while this is technically possible) it's an unusual thing to do.
Apple's HIG states:
Avoid crowding a navigation bar with too many controls. In general, a navigation bar should contain no more than the view’s current title, a back button, and one control that manages the view’s contents.
And, even if you choose to ignore Apple's HIG, this will certainly won't be good for accessibility. Your users can (and will) change the text size with Dynamic Type - so your assertion that it's OK if the "number of buttons doesn't exceed 3 or 4" will be proven false by someone.
You'd be better to add a toolbar instead, or find some other way of providing those features.
The navigation bar often has the title of the previous view on the left side. The right side contains a control, like Edit or a done button, to manage content within the active view.
Navigation bar Example
Apple documentation recommends to avoid crowding a navigation bar with too many controls.
A navigation bar should contain no more than the view's current title, a back button, and one control that manages the view's contents.
For the back button you should use the standard one. As for the text-field it should have enough room. If items in the nav bar are crowded consider separation by inserting fixed space by using UIBarButtonSystemItemFixedSpace constant value in UIBarButtonItem.
For more information visit the following link.
The way to go when you need 3 or more items is by using either nav bar or toolbars. You can combine both nav bar and toolbars. For more information use apple documentation on toolbars.
I'm started to work at new place as iOS programmer. I joined existing project and got an assignment that i don't really know how to approach.
So my problem is this: when you press a button, next window has to have a tab bar with four icons, this means four different navigation stacks. Its not that hard to make, but in main screen i have more then four icons, and if i press any one of them next window always has to have a tab bar with four static icons, like shortcuts or something.
So what should I do? Does anyone had the same situation? I want to start with a good advice to save trouble later on.
You should probably rethink the app design. Tapping an item on the tab bar shouldn't result in a different number of tab bar items, as it leads to an unstable and unpredictable UI.
While not the most efficient in terms of visible content, you could introduce a segmented control (or a similar custom view) on top right under the navigation bar (if there is one), as seen in the Facebook app (though here it is used to perform actions, not changing views).
Your root view controller should be embedded in a navigation controller. Then push a view controller which contains any number of tab bar items not TabBarController. Then you can present each view controller either push or custom.
I am new to iphone development.I want to know about Tab Bar Controller's position. is it convention or a rule to place the tab bar controller at bottom?
I'm not certain about your implementation, but using a UITabBarController is the standard way to implement tabs. UITabBarController's tab bar is at the bottom of the view, and this is what iOS users are accustomed to. This will make your apps more consistent with the platform and because of this users will be able to navigate your app intuitively. There are definitely cases where tabs appear at the top (for example, if a view needs tabs but is already in a tab controller). Either way, you are free to put them where you like and Apple won't likely care as long as you are following the Human Interface Guidelines.
I am more after an opinion about user friendliness for an app I am making.
In the process of planning for my application, I find that some parts of the app will work better with a tab bar view, others with a plain view, and other parts again with navigation view, for tables etc.
I am able to figure out how to do this, but before I get to carried away, would you as a user recommend going with one type and modify the app so it is all the same, or would you as a user feel comfortable having to switch within the app if it is set up and a comfortable change for you?
Thanks in advance for the feedback:-)
Jeff
Tabs and Navigation+tables aren't mutually exclusive. However I would be worried about tabs in some parts and then have the tabs missing ("plain view") for other parts.
I highly recommend you spend time re-thinking your IA (Information Architecture). If tabs make sense, can you model all your app to fit within tabs? If some functionality works as a "plain view" couldn't this view be integrated into the tab model?
As for tabs + navigation, don't forget: it's a tab that contains a navigation controller.
Hope this helps.
Although you can put a tab bar in a navigation controller if you want, as described here: Tab bar controller inside a navigation controller, or sharing a navigation root view
A lot of apps have navigation controllers insides tab bars (think like twitter apps) so users are probably used to that sort of thing - however even when you're navigating inside the tab you can still see the tab bar at the bottom (even if it changes.)
Let me know which one should be used in what case.
What are differences among them?
What are the advantage and disadvantage of each component?
The UINavigationBar class implements a control for navigating hierarchical content. It’s a bar, typically displayed at the top of the screen, containing buttons for navigating up and down a hierarchy. The primary properties are a left (back) button, a center title, and an optional right button.
An instance of the UIToolbar class is a control for selecting one of many buttons, called toolbar items. A toolbar momentarily highlights or does not change the appearance of an item when tapped. Use the UITabBar class if you need a radio button style control.
The UITabBar class implements a control for selecting one of two or more buttons, called items. The most common use of a tab bar is to implement a modal interface where tapping an item changes the selection.
To quote big brother:
Tabbar
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
Toolbar
If your application provides a number
of actions users can take in the
current context, it might be
appropriate to provide a toolbar
However that doesn't give you a completely clear application-based decision. The best solution is to look at the iPhone inbuilt applications (Clock and iPod) along with Appstore-approved apps and stick to what is consistent, as that is what the Apple HIG guides and the appstore approval process boils down to.
You should take a look at the Mobile HIG (Human Interface Guidelines) for these questions.
As of June 2018, the Human Interface Guidelines (HIG) include the most current expectations for iOS, macOS, watchOS, and tvOS, including links to details for developers.
For iOS, the guideline summaries are:
Navigation Bars:
A navigation bar appears at the top of an app screen, below the status bar, and enables navigation through a series of hierarchical screens.
Toolbars:
A toolbar appears at the bottom of an app screen and contains buttons for performing actions relevant to the current view or content within it.
Tab Bars:
A tab bar appears at the bottom of an app screen and provides the ability to quickly switch between different sections of an app.
As far as advantages and disadvantages of each, one important aspect is whether you want the bar to appear at the top or bottom of a view. Navigation bars are supposed to appear at the top, while toolbars and tab bars are expected to appear at the bottom of the view.
Another is whether you want navigation functionality vs actions/tasks related to a view. Navigation Bars implement a button to return to the previous view in the stack, tab bars provide a more abrupt change (such as switching from an alarm view to a timer view, say), and toolbars are really intended for actions (such as sharing, say) rather than actual "navigation".
Note:
If you come here and find that any of the links are broken, just search on "Human Interface Guidelines" to find the current documentation.