I'm building an iPhone app and I'm sort of confused about which approach should I choose for views and controllers.
I would like to have a tabbar at the bottom with three options. I would also like to have a main view displayed when the app shows (along with the tabbar) but I don't want this view to be part of the tabbar options.
So, when the app begins, the tabbar has no option selected but the main view displayed. When a tabbar options is selected, in its top bar it should display a back button to the main view. When the back button is pressed, the main view display again with no tabbar option selected.
Which approach should I choose?
Hope it makes sense.
Thanks.
I understand what you're trying to do, but you shouldn't do that. I don't like that design at all. You should have one navigation controller for each tab.
You should probably read Apple's Human Interface Guidelines as it's possible they would reject your App if they thought such an implementation with a TabBarController was confusing.
As an alternative, you could possibly have the "main view" as you call it accessible with a button in the Navigation bar at the top and then add that to all three tabs. Not necessarily a better design but you probably wouldn't be breaking the guidelines.
A better alternative might be to use a UIToolBar at the bottom instead of the Tab bar which has the three buttons spawning your views modally which can then be dismissed as you suggest.
Remember though, your App's users have built up a knowledge of how App's are generally supposed to navigate, feel and control so you should think carefully before deciding to go against that.
Firstly, I think you should reconsider giving your Main View it's own tab. That way it's a no-brainer for the user to return to that screen. BUT, if you STILL don't like that idea, read on...
The UITabBarController has the unfortunate side effect of not being able to be removed once created (even if you delay it's creation by instantiating it programmatically).
SO...
Option 1: Make your MainView a modalPresentation sub-view, displaying it ON TOP of one of the views in your tab bar (hiding the tabs until you're ready to show them again).
Option 2: Give a subview of your first tab a...
mySubViewController.hidesBottomBarWhenPushed=YES;
This will make the UITabBarController disappear temporarily (just on that view, until you're ready to show the tabs again).
Both options seem kinda messy to me, but they are possible. Depends on how well you execute them, I suppose.
Hope this helps!
You could add the main view as another tab.
OR
You present the main view modally when the app starts over the tab bar views.
The first option would be used more if the view holds the same kind of content as the tabs, for example if the app was an online store, the tabs would be Categories, Search and Recently Added, with what you call the "main view" being the Home page (showing offers or something). (So all the views/tabs would be showing products on the store)
The second option would be more if the content of the main view is different to the tabs.
Keeping with the online store example, if the tabs were Categories, Search and Recently added and what you call the "main view" being a login/logout screen. (so the tabs would be showing products, but the modal view ("main view") being more admin related, and it's main purpose not being to display products.
Related
I've yet to find an example that does this. A client wants a navigation-based app where two sections (one nav-screen each) need to have a few views, controlled by a tab bar. I'm having difficulty setting up the logic of connecting all of the elements and making sure the flow makes sense (ex. hitting the nav-bar's back button on any of the tabbed views will lead back to the same screen).
I answered a similiar question not long ago (if I understand your question right). This will add a tabbar as a rootcontroller and each tab has its own navigationcontroller.
Right design pattern for tabbed navigation views?
EDIT
From UITabBarController documentation
Because the UITabBarController class inherits from the
UIViewController class, tab bar controllers have their own view that
is accessible through the view property. When deploying a tab bar
interface, you must install this view as the root of your window.
Unlike other view controllers, a tab bar interface should never be
installed as a child of another view controller.
As #Jolly good has mentioned, Apple HIG suggests not to do such implementations.
The only other way I can suggest is to try implementing a custom view controller that looks/behaves like a tabbarcontroller and make use of that.
Another hack I can think of, not sure if it'll work or if its possible, create a tabbarcontrller the usual way and then set the hideBottomBar property, and make the bottom bar visible only when you want it to be visible.
It is possible, despite the documentation that #Jolly good cited.
As a real world example, let me describe a game of mine. It consists of a UITabBarController (UITBC) and UINavigationController (UINC). The "main" window of the game is the Root view of the UINC, and when the game is active, it hides both the tab bar and nav bar to maximize screen real estate (not as necessary for iPad, but still...).
When the game is idle (paused, between rounds, etc.), it pushes the UITBC onto the nav bar. It also tells the UITBC to make a particular VC selected. That allows access to the additional screens (About, Scores, Instructions, Settings, etc.), and the player can navigate using the tab bar. In addition to the additional views on the tab bar is the game controller that simply pops the UITBC from the nav bar to revert to the game view to un-pause, go to next round, etc. (Obviously, the UITBC is cached within the game VC so it can be pushed back when necessary.)
Using this sort of logic, it is possible to mix and match tab bar and nav bar controllers for complex navigation. You can get away with this for games; just make sure that any non-game app follows Apple's HIG so as not to confuse the user.
I hope this helps.
I'm wondering if it is possible to start my app with all my tabs in the "up" state and show a "landing" view to the user. Kind of like a welcome/quick start. When they select one of the tabs, it switches views as normal.
Will you point me in the right direction?
Kind of like this:
If you're using a UITabBar/UITabBarController, I think you must have the selectedIndex set to some legal value. I don't think this is possible, nor can I find an app on my iPhone or iPod that mimics the behaviour you're looking for.
(The App Store app is as close as it gets, where it looks like it has an empty tab bar before it loads data from the Internet, but it could very well be that they are just re-using the Default.png and superimposing an activity indicator during loading.)
Note that if you tried to submit your app to Apple, they could easily reject it for using non-standard UI.
The way I would probably do this is to create a new ViewController that's just for this screen, but make sure it's last in the viewControllers array managed by the UITabBarController. That way, when you show the tab bar on the screen, you get the 4 tabs and the more button, but the currently selected view controller is not in the bar, meaning that all of the other tabs are unselected.
Once the user has satisfied the condition for showing the screen, you can discretely remove the view controller from the tab bar, and the user will never be the wiser.
I've been able to incorporate all of Apple's code, delegation, etc related to iAds, in simple view based applications.
Tab bar type applications seem more difficult, perhaps I don't understand the overall architecture of those apps. It seems that, say, if there are 3 tabs and views corresponding to those tabs that the other tabs sort of inherit or are attached to the first tab.
When working in interface builder, it seems that dragging an adbanner into the windows actually replaces everything that is there and building some kind of view container to put the "tab infrastructure and associated views" and an iad doesn't seem to fly.
I'm able to code by hand the pop of an ad in my code, which shows up when running the app under the first tab, but it doesn't show on the subsequent tabs, I was doing this in viewDidLoad. It seems the tab bar apps want to sort of own the entire screen realestate to some extent. Any thoughts? There's a UIWindow and the TabBarController, the window seems largely "blank" and otherwise purposeless.
What I would do is create a separate custom view, which you push onto your enclosed view in each tab just as part of the viewDidLoad process.
I have a navigation app that has many screens the user navigates to. A handful of views manages these screens dynamically. What I want to try to do is add a button that will always show up on every screen the user views. I need to do this so that the user is always able to preform the action associated with the button regardless of where they are in the app.
Is it possible to achieve this by adding this button only once and having it passed between views like my navigation bar is? Or do I just have to man up and add this button and its functionality to every single view file I have?
Thanks
I would say it probably depends on what the button does. If the button is generic to all views, meaning it affects all views the same exact way so no customization for a given view is needed, then a way to do this would be to include the function in the App Delegate or as a subclass to your Navigation controller.
You can then use the rightBarButtonItem to always show the same button and just access that method. You would just have to add code for the rightBarButtonItem in each viewDidLoad (but they'd all be the same).
I did something similar to this with an "Upgrade" button on one project. Since all the button does is launch the AppStore to the paid version, it's independent of all views and I can place it anywhere.
You can put the button on the navigation bar if you want. Alternately, the more generic way to do this would be to split your single view into two views. One is small and only contains your button but always stays on the screen. The second is your workspace and you swap in and out the views that are displaying the current content. You'll note that this is the way the navigation controls and tab-bar controls work.
The last way to do this would be to put different buttons, in the same place, on each view and have them all trigger the same action. As far as the user is concerned this looks like the same button. Disadvantage here is that you can't alter the button across all views in a simple manner.
Would I violate the HIG by showing a tab bar on my first view only? The first view also has a tableview and navigation bar at the top. Once the user selects a row, it goes to another tableview and no tab bar. The navigation bar is still at the top and the user can go back. Clicking a row from here displays the detail view. In summary, the tab bar will only be available on the first view.
-- EDIT --
Technically, I know how to do this. But from the HIG and user point of views, I'm not sure about it. The tab bar is only needed on the first view to reach the in app purchase store. Guess this really constitutes a redesign where I have a new button on the first view? My navigation bar has just enough room for it in the top right.
I have done this too in my application and it has been approved without any issues. Besides, it is supported by UIKit, so I don't see any reason why it should be a problem. It's even perfectly logical to hide the tab bar when drilling down into a table.
I'd say go for it!
Yes, this can be done. Just push the tab bar controller on the nav bar and it will work like you described, though it might feel awkward to some users.
The iPod app does this, so I'd say it's okay.