I realized that people have been implementing their own UIButton derivates to create radio buttons on iPhone, as this blog post shows.
This question's accepted answer states you can use Picker Views or Grouped Table views with a check mark, but it seems like a poor man's solution to me. Hence, my question: what is Apple's likely reasoning?
Are radio buttons a bad UI solution for touch interfaces?
Is it so rarely used that it's not worth cluttering IB with?
Another reason I don't quite see, maybe? I believe it's important to find this out, because if Apple thinks radio buttons suck, I'd rather not use them, and rethink my interface whenever I "believe" I should use one...
Radio buttons are a bad UI solution if they are poorly implemented. i.e. too small to reliably work with touches - which is why it's usually better to either use a toolbar or segmented control of options or a tableview of options.
Actually seeing it with a different angle, Apple has neither provided Radio buttons or even Check Box and maybe not because they think that it is a bad UI solution. But instead they've empowered the UIButton control very much that we can configure it as a Radio button or a check box or a switch or anything else with few lines of code.
A UIButton object can be configured and designed in various ways. We've seen various apps using the UIButton very creatively. I personally like the versatility of UIButton rather than Apple directly providing the radio button and Check box to drag and drop it in the interface.
Related
Does anyone know how CNN is doing their top pull down menu?
It looks like a UITableView that is called with a touch drag event but wasn't sure. Googled various keywords but was not able to turn anything up. Just looking for some guidance on how to replicate this behavior.
I've no idea how it's actually done, but I know how I would do it: any view can sit completely or partially offscreen and be dragged onscreen by the user in the usual ways (e.g. a swipe or pan gesture recognizer). There's nothing special about that.
I guess they are doing something like https://github.com/mikefrederick/MFSideMenu
You have to customize "MFSideMenu" a lot though. If you dont want to show this menu on every view you need to disable UIGestureRecognizerDelegate on that view.
There is also something like https://www.cocoacontrols.com/controls/pullableview but you may need to add UIGestureRecognizer to this class.
What options do I have when creating menu with options (contextual menus). What is allowed and what does Apple provide?
I have a toolbar with buttons and a click of a button opens a menu with options:
Examples:
UIPopoverControllers are only available on iPads, but it's ok to create similar looking things for iPhone
What you see in the picture, is entirely custom. a UIView subclass likely. There are pretty much no limits to what you do with your UI, within reason, so no ugly highly contrasting primary/secondary colours, and it's best to keep it at least similar to the native UI. If you say use a windows 7 phone ui style in an iPhone app it's more likely to get rejected by Apple, than keeping to the style of iOS.
So make it look as "professional" as possible, using gradients and shadows, edge arrows, like in the above picture.
Apple provides pretty much nothing that your looking for,
Similar built-in widgets would be UIPopoverController (iPad-only) or UIActionSheet. I like your menu better though.
I would also recommend looking at the guidelines for such custom UI elements. I can not say what is 'allowed', but Apple is not shy about how your app should look/feel/function.
Towards the top of this link talks about toolbars, status bars, etc.
http://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/UIElementGuidelines/UIElementGuidelines.html#//apple_ref/doc/uid/TP40006556-CH13-SW1
I am pretty new to iPhone development and currently working on an application which includes a view that performs a simple numerical calculation. In particular, the user enters 3 or 4 values into text fields and the view displays the result. Something along the lines of http://www.moneychimp.com/calculator/compound_interest_calculator.htm
What is the nicest way to achieve this? I am currently using simple UITextFields and a UILabel for the result but it doesn't look nice or "native-like". What UI object would be best to use?
Thank you!
It's entirely up to you. You're using the right classes for actual input- it comes down to how you choose to style those classes. I'd suggest looking at the documentation for UIView and CALayer (youView.layer, and include QuartzCore framework in your project).
A good start might be to choose a color scheme, a background for your app, and the look and feel you're shooting for- this will inform your styling. Try looking for apps that you think are elegant and attractive, and boil down what they do and what you like about them.
I'd say;
use a grouped table style (with the white tables with round corners on a blueish striped background)
embed settings values directly in the cell (aligned to the right) as much as possible
you can show a relevant keyboard (text, numbers) or picker view to let the user pick values, directly when they tap the cell. Use sliders and switches where relevant.
You may want to take a look at http://www.inappsettingskit.com/, we are currently investigating it for the same purpose and it seems to do the job
You can use either a UISlider or a UIPickerView if some of your values have limits.
You can use UISwitch for toggles.
You can also switch the default keyboard for your textfields to be numeric.
Other than that you seem to be on the right track.
Also, sometimes putting a view inside a scrollview makes things seem cooler even if its only one page. The auto bounce on scrollviews is kind of cool.
When I've learned that I have to write some code to make the iphone keyboard go away. I was quite surprised. I was surprised even more when it become apperent that it is just the top of the iceberg.
What are the expected UI behaviors that aren't provided by system OOTB?
Is the list below complete?
The expected UI behaviors:
Focusing next text field when [done] is hit
Hiding the keyboard when background is hit
Using Touch Up Inside to fire a button action. (To give user opportunity to change his/her mind)
Supporting the screen rotation.
Some of that is silly, but some of it has uses as well.
Focusing next text field when [done] is hit
Which field is "next"? If you have a large form with fields both next to and above/below each other, next might not be so obvious. Even if they are in some linear layout, the iPhone would have to work to figure out which one is next. Do you want to wrap around at the end of the form, or dismiss the keyboard, or submit the form?
Hiding the keyboard when background is hit
I mostly agree with you here, though there are a few cases where this is useless. For example, adding a new phone number in the contact app.
Using Touch Up Inside to fire a button action
This one I really don't get. I can only guess that it's designed to allow you to use buttons instead of the touchesBegan/Moved/Ended methods. I guess it could be useful, but I've never used anything but Touch Up Inside.
Supporting the screen rotation
Many apps just don't work in any other orientation, such as games. If you want to use rotation, you only have to add two lines of code assuming you've done your layout well.
I hope this helps explain some of the strangeness. Aside from the keyboard dismissal, I've never really found anything too annoying. The one thing I wish they supported was using the highlight state of UIButtons for the set state. It would be a quick and easy toggle button, but I've taken to screenshotting a highlighted button and using that for the background image of a selected button.
Want a rounded rectangular button that isn't white? Since that one uses a background image, you can't just click something somewhere that makes it the color of your choice. You have to create your own image or you could even use CSS (WTF!?) to do it.
Unfortunately, the iPhone SDK lacks a lot of helpful things one would think would just be there. However, many people have taken the time to write wrappers for many of these kinds of things to help facilitate development - a quick google search into the functionality you are expecting may turn up a lot of useful answers!
For example, you could make the keyboard go away when you tap outside of it by creating a new view when it appears, and placing that view behind any user-interactable views on the screen. When that new view is tapped, it will become first responder and cause the keyboard to slide away (because the UITextField is no longer first responder).
Such a thing could be easily implemented as a drop-in fix for pretty much anything you'd need it for with very little code.
Still should have been included in the SDK in the first place, though!
I am developing a voting app, where the User will be presented with a question and multiple choices. In a typical HTML world the choice for this interface would be a Radio Box/Check box. What kind of view would I use in the iPhone SDK for a similar behavior?
Are there any sample apps which I can refer to?
Thanks,
Amy
Any time you're displaying repeating rows of data, UITableView is the natural choice. UITableViewCell provides various properties for you to customize the selected state which you can use to show the user's selected choice.
If your question has a few answer (3-4), then you can use an UIActionSheet. This is much quicker to code and provides a good looking user interface, with the sheet animating from then bottom of the iPhone and presenting to your user multiple button related to the possible choices/answers. It's a radio interface, in the iPhone Style.
Another possibility is to exploit an UISegmented control, a different type of radio interface.
If there are many answers, an UITableView is your best choice.