I want to implement a wizard view that have to apply the following requirements:
several steps (configurable)
each step has to be a stand-alone UIView
back, previous, finish buttons
indicator that must show on each step we are
It must not be some navigation-style implementation (using UINavigationController) just view which I can place somewhere on the another UIView.
Any suggestions & best practices how to implement this task?
Sounds like you want a modal view. You should just configure a view as you like and display it modally from the view controller. It will then appear above the other views and trap all touches. If you need to create the illusion of various "pages" you would need to programmatically add buttons, text fields etc and then remove them as needed.
However, you might want to rethink this design. It's all good and well to have a wizard in a dialog view on a non-mobile screen with plenty of visual real estate but you really don't have that much space on a mobile screen. If you leave the backing view visible this will rob the wizard view of most of its area. If you expand the wizard view to a useful size, you might as well use a full screen view anyway.
Related
Hy everybody
I am a newbie ios programmer and I'm facing many doubts when I must switch the pages of my app.
With the term "page" I mean a UIView that fills the whole screen with some widgets (buttons, textboxes. tables..)
As far as I have understood what I've read I should use an UIViewController to manage each of these pages
since each page should be a screen’s worth of content.
My App starts with a ViewScroller with many buttons and when the user clicks one of these it opens a new page.
The first page is the UIView connected to the RootController Of the Window.
So far to open the new pages I add a child controller to the RootController and it's view as a child of the view of the RootController:
RicLocaliController = [[RicercaLocaliViewController alloc] initWithNibName:#"RicercaLocaliViewController" bundle:nil];
[self addChildViewController:RicLocaliController];
[RicLocaliController didMoveToParentViewController:self];
[self.view addSubview:RicLocaliController.view];
RicLocaliController.view.frame = self.view.bounds;
When the user clicks the "Back" Button I remove the child controller and the child view.
Going down this road I would get a dynamic tree of Controllers with their Views.
So far I have not encountered problems and my app can go up to a third level in the tree and come back. Each page behaves correctly when orientation changes.
But I'm afraid that adding, for each subpage, a child controller and a child view could be not the right thing to do.
I'm afraid that if I nest a lot of pages when the orientation changes the app could respond slowly since also the superviews will do something to manage this event.
So what I wonder is if what I am doing is completely senseless, if I should use Navigation controllers or some other way to manage my page changes.
Unfortunately my boss is not giving me enough time to study well the subject and so I would like an advice to follow the best solution possibly using the most standard and less complex component offered by the framework instead of the newest features.
I read a lot of web pages on the subject but it seems to me that there are many ways to manage the navigation beetwen pages and this makes me confused.
I apologize for my bad english but i'm tired and English it's not my first language.
You HAVE to do some studying. You will spend more time clearing up all your problems later otherwise... but, here are some tips.
Using nested ViewControllers leads to all kinds of trouble so if you are short of time, skip that.
Think of each "Page" as one ViewController. A ViewController has a property called View but that is actually just the top view of a whole hierarchy of views. A view is the base class for any visual object, like labels, buttons etc. All views can have subviews, so you can add an image under a label etc. and do really wierd stuff if you want to. I am just saying this to free your mind about how you can use views.
Now, ViewControllers are supposed to hold to code to ONE view hierarchy. That view hierarchy is for that View Controller only.
When the user wants to navigate to another page, you have a few alternatives:
NavigationViewController - that should be used when the user wants to delve down into data, like opening a detailed view of an item in a list etc. The NavigationViewController gives you help with back buttons, proper animation etc. You "pop" a viewcontroller to go back one level. If the user click the back-button, this is automatic.
TabBarViewController - use that if you want a tab bar at the bottom of the screen. Each tab is connected to a ViewController, that has it's own view hierarchy.
PushModal - If you are in a ViewController and just needs to get some data from the user, which is not part of the normal navigation of the app, you can push a new ViewController modally. This is the way you interact with iOS built in ViewControllers. This is also a good way to get a value back from the view controller.
There you have it. Go learn more. :)
It sounds like, for what you are using, you should be using a navigation controller. This will automatically handle pushing views onto the stack and then popping them off again later. This will also automatically create a back button (it is customizable) in the navigation bar.
If you are using iOS 5 or 6, I highly recommend trying out "storyboards" in Interface Builder. Storyboards allow you to graphically represent transitions (called "segues") between different views.
On top of being easier to design and implement, another advantage is that, if in the future you want to change the design of your application, you don't have to trawl through all your code and manually update each view connection.
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.
I'd like to display some small tutorial dialogs on top of my exiting views. I want to be able to see my existing views behind these smaller views.
Do I have to use view controllers in the same I way I would me normal views, and presentmodalviewcontroller etc ?
I haven't tried making a smaller view in interface builder before.
Also, say I want to move to another one of my existing views, full screen, while in my tutorial view. How would I close my tutorial view move to the next full screen view and launch another tutorial view ?
Example code or pseudo code would be welcome.
If your tutorial dialogs are just text, you could use UIAlertView to show the information to the user, so they can just read it and click the OK button when they're done. It's a very easy way to show some text to the user.
If you need to include images or other interactive items in your tutorial dialogs, the easiest way might be for you to just have your fullscreen view's view controller create a new view and put it up. So in this case, you'd create your view in Interface Builder, and when you want to show it, instantiate it using -[UIBundle loadNibNamed:owner:options:] and add it as a subview of your main view. Of course, it may even be easier to create the tutorial view programmatically from your view controller rather than using a nib for them at all.
Regarding the question of moving on to another fullscreen view, you would probably want to look into embedding your view controllers in a UINavigationController. This would allow you to push from the first controller to the second very easily, and the user would be able to just tap the Back button to get back to the first. If you're not looking for a navigation bar type of interface, you could present the second view controller as a modal view controller by calling -[UIViewController presentModalViewController:animated:] on your main view controller. This will pop up the second view controller fullscreen, and the user can dismiss it when they're done. Check out Apple's great documentation on UINavigationController to get a feel for how to use that:
http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/NavigationControllers/NavigationControllers.html%23//apple_ref/doc/uid/TP40007457-CH103-SW1
I would think that you could use existing UIViewController and simply add a new UIView that is of desired dimensions, that sits in front of other views and which is non-opaque and has alpha less than 1.
If you want a general purpose tutorial mechanism that can be placed atop any one of many UIViewControllers, then you would want to extract the navigation logic, etc.
Sorry, no code - just a few quick thoughts.
I have looked at the PageControl example from Apple and have an architectural requirement difference. In the example the scroll view and page control objects are at the app delegate level. This means the scroll view and page control appears on every view of the application.
However, I have a "settings" view toggled from an info button (for now) that should not have these controls displayed. Therefore, I need to move my scroll view, page control, and view controllers objects down a layer and I'm struggling with how to best do this.
For example, the primary application view consists of metals (periodic elements). From this view I need a scroll view, page control, and info button on every view descending from here. Each metal will have it's own subclass where different images, calculations, etc will be displayed but I believe I need each of these subclassed elements to share the same scroll view, page control, and viewControllers array, right? Do I need a singleton?
What you are describing is kind of like how the native Weather application works. Each time you swipe, the info light is rendered as part of the page you are viewing. However, no matter what info light you tap, when it flips over you still get the same settings. Obviously this is how Apple thinks the UI should work because they did it that way. There is no reason you can't do the same.
In this situation, you don't need to create a singleton, you can use [UIApplication sharedApplication] as your singleton to get to your custom application delegate via the delegate property.
Look at Crème where I do exactly what you describe. The main view is scrollview+pagecontrol. Upon triggering the app into settings mode, the settings panel comes up that does not have a page control.
The solution is simply that you have a simple top-level UIViewController, and you make both the scrollview and pageview children of that viewcontroller. And for settings, you animate the modal settings dialog with a flip animation into the top-level UIViewController.
What is the best approach to implement tabs that look like web applications on the iPhone, like the screenshot below (notice the "Checkin-Info-Friends" tabs)? These are not part of the UIKit standard library, but seems to be very common lately.
I've spent considerable time developing applications for the iPhone, but not developing controls like that one. What would be the best approach here:
create a new UIView for each tab content, and add the three subviews to the mainview straight away?
create new UIViews only when the user clicks on each of the tabs?
Put all the content in a UIScrollView, and just change the page as the user clicks on each tab?
Maybe there are open source controls for this out there? I couldn't find anything.
(source: foursquaregame.com)
My approach to a similar problem was to make all 4 (in my case) tab views, but respond to didReceiveMemoryWarning by releasing all but the current tab view. (Then, of course, you must make sure that you create the new view, if it doesn't exist, when the user chooses a new tab.)
I thought this was a good compromise - a speedy reaction to the user at first (and in my case memory footprint is at its lowest at this point in my app), and then a response to low memory to avoid being shot.
I think it best just to have three UIView* references to the subviews in the parent view or view controller, all initially null, then to have subroutine to hide the other two views if they are visible and either construct and show or just show the new view. Assuming no extraordinary memory requirements.
I think with such a small screen area load/unload concerns at the subview level are unlikely to be a concern, but if the parent views need to be loaded/unloaded, the subviews should all go (be both hidden and unloaded), and on reload, loadView should call the routine described in the last paragraph at startup.
If there is in fact a great deal of memory or resource use by any of the three subviews, then my advice is reversed and each of the subviews and/or any memory-intensive objects behind them should be not only hidden but unloaded whenever possible. I think with your use of Google maps there, a need to unload when hidden might apply to that.
Is this th right point to make? Is there some extra detail I'm missing?
You can have each tab be a real view controller with nib and everything. The only catch is that you must forward on the standard view controller calls you want to receive (viewWillAppear, etc) but it makes the coding much cleaner since you code just as you would for any other view (although for a smaller space).
You call each controllers "view" property to get out the view, which you add as a subview of a container view you have under the tabs.
If all three are table views, you might get away with using a single UITableViewController that changes contents based on the selected tab. Otherwise I second KHG's comment of using real view controllers to back up each of the subviews.
For the tabs themselves consider subclassing UISegmentedControl.