Will using a popup view to present a comment submission form violate the HIGS? I may have one popup with selections that goes to the final popup. Two popups back to back. This is more similar to a modal type of view than an alert or action sheet as described by the HIGS: http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/ModalViews/ModalViews.html#//apple_ref/doc/uid/TP40006556-CH11-SW1 under the section 'Using Modal Views'. Basically the type of view I'm shooting for is a combination of an alert with a custom view. It's sort of a mini view since it will be centered in the middle of the screen but not take up all of the viewing area. I'm fairly sure that is a violation however, but I'm looking for a few opinions on it.
I believe what needs to happen is use a modal view, which will cover the entire view.
Can't really say if having two of popups like this back-to-back would be a HIG violation, but Apple doesn't seem to have any problems with alert views with embedded controls. I've successfully used an alert view with an embedded UITextField and rating stars/slider.
It probably depends on how much you want to diverge from the looks of a standard alert view.
Related
I was wondering what different things ppl have done for a EULA page? We have some legal disclosures to present and want the user to click a checkbox saying they agree to those terms. If they don't agree, don't let them use the app. I know in iOS 5, they added some new features to UIAlertView, but I don't see a checkbox option. I see they have the UIAlertViewStylePlainTextInput that maybe I could use to ask the user to put in their name, verify it, and then let them use the app if it matches the credentials on our webserver.
Or simply present a Modal popover with a checkbox button that has to be checked for the popover to disappear. This option seems easier to me, but I'm not sure what other ppl have done. Thanks.
A popover generally has to have a source (i.e. another UI element) that it’s being presented from, which wouldn’t be appropriate in this case, and an alert view is too small to reasonably display the wall-of-text that comprises most EULAs.
Your best option is probably a modal view controller containing a text view (or a web view if you want to be fancy), presented with its modalPresentationStyle set to UIModalPresentationFormSheet. Stick a “yes, I read this and accept” button that closes the view controller in there and you should be good to go.
Any advice/suggestions regarding the simplest way to throw up disclaimer text after user click on information icon? This is for iPhone/iPad development. Jumping across to a separate XIB/controller might be overkill? (although perhaps it is the simpliest to setup?)
Requirements then would be:
main screen has a small "info" button in one corner
clicking on this button should bring up a "modal" view of disclaimer text
should support scrolling (in case of a lot of text)
should allow the user to then somehow dismiss and get back to main page
The simplest way I think is to present the text in UITextView, which is scrollable, in a custom view controller that you present modally.
You can even store the the text in. Now adding a button to dismiss it, and you are done.
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 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.
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.