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.
Related
I am developing app that has multiple skins and I have a dilemma on how to implement this.
One of the solutions would be to have separate nib files for every skin, and load it depending on which skin is currently selected. Problem with this is that I can't edit navigation bar of navigation controller (which my app uses), and I have to change it's background image and back button image etc.. I came up with an idea to hide this navigation bar on every screen and replace it with custom UIView in Interface Builder which will act as navigation bar and custom back button with IBAction for popping current View Controller, so that user won't see any difference.
Is this approach acceptable and if I make it this way, will I have problems with rejection in App Store?
If you choose to hide & replace the UINavigationBar with your own UIView it's no problem as far as Apple goes.
However, I can tell you that you will have to spend some time trying to replicate some visual effects that come naturally with UINavigationBar.
For example, when you push/pop a new controller, you will see that the navigation bar title will slide & fade beautifully. The same applies for left and right bar items.
Personally I would not completely hide the UINavigationBar, but customize it. In the end it all depends on what you want, but by default the UINavigationBar is pretty customizable.
You can add your own buttons or even entire UIViews as left and right bar items. Also, you can add your own UIView as the title (with your own label, custom font or whatever) or change the background.
EDIT:
To easily customize the looks in your entire application, you can subclass UINavigationController and create your own CustomUINavigationController. Then, in viewDidLoad method you can change whatever you want to the navigation bar and this will be accessible in the entire application.
No way, what you are doing is perfect. This will work & no way it will get rejected from app store (just based on this approach). I too have explored several ways to provide skins & what you wrote seemed to be the least hassle-some. Plus its way more easier to create UI elements in Interface Builder hence the separate nib files for different skins.
I am saying this so confidently 'coz I have done the same thing & app store approved.
Best of luck.
I am making code for iPhone. My first screen has only one button with text Menu. When user will click on this button next screen is coming with multiple navigation bar.Each Navigation bar has their own Text information which are being selected after clicking on any Navigation bar.
How i should to design it for iPhone ? Please give me concept. Should i take multiple views ? If i have multiple views how will i hide and show on button click event ?
Thanks in advance.
You will have to adapt your user interface to comply to how Apple wants an app to work, look, and feel - or make your own custom viewcontrollers. Even then, you might not get the exact behavior you want.
My hottest tip is to look at similar apps on appstore and see how they are navigated.
I don't get a picture in my mind from your description, but it seems you want what is called "drill down". This is best done with tableViews.
You can't have multiple navigation controllers on the same "screen"; it doesn't work like that on the iPhone. Instead, what you have is one single Navigation controller, that controls the pushing of views. You decide which sub-view to push depending on which selection the user makes, and the Navigation controller handles the rest of the interaction with the user to let him or her navigate between the views.
Example structure:
Window-based app
+-MainWindow.xib
| +-First view with button
| +-UINavigationController
+-tableview1.xib
+-tableview2.xib
+-any more views you need.
Make the app delegate a <UINavigationControllerDelegate> and declare navCt *UINavigationController, and connect it in Interface Builder. You can then write a pushVC method, which takes as argument a UIViewController *vc. It does a [navCt pushViewController:vc animated:YES];
Connect the button to an IBAction, which then calls the method in the app delegate, [PushVC myVC], where myVC refers to any viewcontroller in your app, in this case table view 1.
In this table, on didSelectRow... event you can use the same method to push the sub-view table view 2.
I think this is minimum code if you are unsure about iPhone app design. Either way, I hope it gives some ideas.
You should read about UINavigationController, UITabBarController, UIViewController.
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html
You almost always make one view pr. viewcontroller.
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'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.