I'm a bit stumped with this one...
Consider this app:
The app has a tab bar navigation at the bottom with buttons recipes, favourites and settings
Recipes can be shown in two ways - either as a list, or as an grid of images.
The user can toggle between the list and grid views by pressing the toggle button and the app should remember the previous setting.
So...
I boot the app and press the Recipes button.
I'm looking at the recipes as a list and I press toggle
The screen flips (via UIModalTransitionStyleFlipHorizontal) and now I can see the recipes arranged as a grid.
I press settings to change some settings.
When I press Recipes again the recipes should still be listed as a grid.
When I press the toggle button, the recipes are shown as a list again etc.
The Problem...
Assuming the list view is the default, how do I tell the newly instantiated grid view that it should use the same TabBar as the list view?
How can I make this transition look seamless?
I understand that I shouldn't use one controller for multiple views, or one view across multiple controllers... Should I use a separate view/controller for each screen here or use the same and show/hide subviews as required?
All advice appreciated
You need two separate ViewControllers for both screens.
If you want to make it as you show, take Xcode template called "Utility application" as a base.
I believe better to use here UITabBarController.
I recommend you also to read Human Interface Guidelines from Apple.
Related
I have an application with a maybe-strange navigation scenario. I'll try to explain:
1) first scene: select an available item from a list
1.1) once selected, you navigate to a tab view allowing you to view/edit the various attributes
2) if the desired item isn't available, you may create a new one (by selecting a "+" bar button) which navigates to an alternate scene
2.1) there may be multiple scenes required to create the item, all scenes are simply pushed on the stack to allow the user to go back, select different options, etc.
2.2) once all scenes have been displayed and all attributes have been collected, the new "item" will be created and saved.
2.3) now, I want to automatically act as though the user selected this item from the beginning, that is, I want to pop all previous views off the stack and navigate directly into the tabs (step 1.1).
Does this make sense? Easy to do? Is there a better way to go about this? I'm using xCode 4.2 with storyboards.
Any guidance would be appreciated.
If you want (+) button on TabBar you should subclass UITabBar: Fo ex. TabBarPlus and set this class in storyboard.
But easier place (+) button on navigation bar.
The max number of displaying tabsart is 5 for iphone and 8 for ipad. If the there > number of tabs the last is "More" tab thet displaing list of other tubs in tableview. I you want displaying more tabs on tabbar then you should subclass UITabBar :)
If you want by back button on naigation bar switching beetwing Views that references with TabBar buttons you must create stack in code and hide backbutton of navigationbar and use castom left button of navigationbar.
The other navigation can be easy done in storyboard
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.
XCode: "This template provides a starting point for an application that uses a single view. It provides a view controller to manage the view, and a nib file that contains the view."
What does that even mean? (ie what does Single view actually mean)
1) This means that your application will only have a single view screen that is active
2) This means that your application will be able to have as many screens as you like using a single view controller.
Ok now what if your application has multiple screens? not a single view screen, is still suitable under a view based application template?
Example
Screen1(main): on this screen you have 3 buttons, "Open Form1", "Open Form2", "Open Form3"
When the button is clicked it opens up the associated screen,
Press the "Open Form1" button opens up "Form1" screen2
Press the "Open Form2" button opens up "Form2" screen3
Press the "Open Form3" button opens up "Form3" screen4
When the user completes the form and submits it, a thank you screen is displayed
therefore in this example there would be a total of 5 screens.
Each form screen contains is different, textfield inputs, and information, is this considered as a view based application?
View-based app is just a template to say that your app will be view-based. That means that you can have any number of views you want, as this template comes with a view controller (that, as the name says, can be used to control the views... show/hide them with animation, for example).
The template starts with ONE VIEW that is added to the app view controller. You can add any number of views to that controller.
So, yes to your questions. You can use this to create the app you mention, where any of the "screens" you mention would be a view, for example and you can show each one using, for instance, the app view controller to animate each view showing or hiding.
That means the template will create one view and corresponding view controller along with app delegate, main window. That will also do the necessary things to add this view to main windows, and load when app runs. This is just a template. Then you can crate any number of views and view controllers as you want.
This means that the template you are starting the project with provides a single ViewController, and associated XIB for the View. As the first answer says you could use this template to build the application mentioned.
HOWEVER you may wish to think about how the user is going to interact with your app. Will you allow stepping back and forwards through the screens, in which case you may want to consider the Navigation Based app where you push/pop screens onto a stack to allow easy movement between then.
You might also have a concept of allowing the user to jump at will between each of the screen pages in which case you might want to implement a TabBar application.
Or you could just implement it all yourself. At the end of the day it will be your application design, and the template is only a starting point to get you going. I would suggest that if you are starting out with iOS development however to go with 1 ViewController matched a XIB for each screen you wish to implement to keep things simple.
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.
Suppose that I want to create and application and that application will have two windows and a menu mechanism. How do I accomplish this on iPhone? I know how to create a single view and have that displayed but what I want is this ability:
a.) Upon loading app, show a navigation mechanism. The choices are Item A or Item B.
b.) If Item A is chosen, view A should be loaded.
c.) It Item B is chosen, view B should be loaded.
Thanks in advance.
To me, what you're describing sounds like three views.
1. Root View
This view has two buttons (or other controls) that allow the user to select where they would like to go.
2. View A
A view with the necessary controls and data.
3. View B
A view with the necessary controls and data.
The actual transition between the views could involve a UINavigationController. If so, the root view would be pushed onto the UINavigationController's stack initially, and clicking the buttons would push either view A or B onto the stack. Otherwise, views A and B could be presented modally when the appropriate button is clicked by calling [rootView.presentModalViewController:animated].
Is that what you're looking for?
Since you mention a "menu", is it possible the user may like to go back and change their selection (A or B) at some stage?
In that case you may like to also investigate if a Tab Bar Controller based application fits your needs (similiar to the built in Clock application)
This would always display two buttons at the bottom of the screen which the user could use at any point in time to switch between the two modes. it would automatically handle the switching of views "A" and "B" within the main part of the screen.
The real answer probably depends upon what your two views need to do, and what kind of UI they present.