Basically, I am using UICollectionView and want to allow users to switch between 2 modes. The first, will allow users to tap each item and see more details about it. The second, will allow users to select multiple items and either delete them or share them. I want something similar that is possible to do in the standard "Photos" app.
The items on the navigation bar and on the tab bar will be changed based on the current mode.
My first idea is to use the same controller and just replace items in the navigation bar and the tab bar accordingly based on the current mode.
My second idea is to use 2 different controllers with different sets of buttons on both the navigation bar and the tab bar. The only thing I was planning to move the same UICollectionView back and forward dependently on the current mode so that the current scrolling state of the collection stay the same.
I may be wrong in both of my approaches. I am new in iOS and would appreciate any help in this regard.
You needn't use two separate view-controllers. In fact, the problem statement suggests that you shouldn't, because it's just two ways (modes) of presenting the same view.
The way I would solve this problem is:
Have an instance variable in the view-controller (either an enum or a boolean) that represents the current mode
Use a UIView transition, on change of the mode, to add/remove buttons from the UINavigationBar (at the top) and the UIToolBar (not UITabBar - Tab Bars are used specifically to switch between view-controllers in a UITabBarController) at the bottom.
Also, on change of the mode, reload the Collection View with or without animation.
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 have an application with a drop down menu as the titleView of my NavigationController. When a user selects an item of the drop down menu, the entire view should switch contents, however, the NavigationBar should remain the same. The NavigationBar should not have to reload any data and the titleView should remain a drop down menu.
The original view upon opening the app:
The view upon touching the dropdown menu:
I currently see a few ways of going about this:
Set up a UIViewController for each option, perform the segue, and reload the data.
Why this is bad: I will have to set up a segue identifier for each ViewController, meaning if I have 15 options in my drop down menu, I will have 210 segue identifiers laying around. I will also have to reload all of my NavigationBar data.
Why this is good: I will have a clear area to set up each individual view.
Programmatically add and remove UIButtons, UILabels, and UIWhatevers as I need them.
Why this is bad: This will create a lot of code inside just one ViewController and things could get difficult to debug.
Why this is good: The NavigationBar never gets reloaded.
Add a container and embed a unique ViewController for each item as I need it.
Why this is bad: All of my work would still be in the main ViewController and I'd have to manage the logic of the embedded ViewController inside one Controller.
Why this is good: The NavigationBar never gets reloaded.
A completely different method suggested by someone else because I don't know the most efficient way of doing this.
So, in conclusion, what is the most efficient way to maintain state of my NavigationBar when switching my main content in my View?
Option 3 is the best out of the three you listed. Options 1 and 2 will get more and more complicated the more view controllers you want to add. Compare that to UINavigationController, UITabBarController, or UIPageViewController which do not need to be more complicated in order to handle 10 screens vs. 100 screens.
I would suggest creating a custom container view controller (Apple's Reference)
I see 2 immediate approaches to implementing this:
Subclassing UIViewController - this is how Apple's container view controllers are implemented
Subclass UITabBarController - I have done this successfully, subclassing UITabBarController to show a custom tab bar at the top instead of along the bottom.
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 can reproduce the following navigation bar for one view:
However, once I move to the next view after clicking a button, I lose the top two rightmost icons(Search, Profile). I understand that setting up navigation item from a storyboard is usually per view. I can replicate those items for each view but I was wondering if there was a better way to do it once.
Is there a tutorial that explains how to maintain a custom navigation bar across many views?
You need to set it up for every view. You should probably create a superclass and implement it there, so you only need to actually write the code once.
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.