Good Afternoon/Evening/Morning Folks,
I recently encountered a discussion with another developer on dismissing a UIPickerView. We work on a legacy enterprise application that had a lot of issues and was written very poorly (among other things). Since then, we revamped and fixed a lot of bugs with this program, strictly adhering to Apple's Human Interface Guidelines as much as possible while keeping to original requirements.
We seem to have a difference in opinion as Human Interface Guidelines do not really go into any detail about picker views. We implemented our new UIPickerView with a "Done," Button to confirm a selected value to be placed in a UITextField. Screen's input would be locked until they selected a value or clicked done.
Legacy application prior to our changes allowed users to utilize a done button but also by way of tapping a value selected in a picker. In addition, legacy application would also show selected UIPickerView value in UITextField prior to selection, wiping out original contents , if any was selected prior to opening a UIPickerView.
So, What is correct way to implement a UIPickerView per common practice or Strict Apple Documentation (if any exists). What is common practice?
Sorry, I cannot post any screen shots or code snippets due to business process reasons. I will do my best to explain if any questions arise.
Thanks,
We can figure this out through apps designed by Apple. Here are two examples
1. Contacts
Find a contact person in the Contacts app and set birthday. The picker shows up. While you are dragging the pickers, it does not set value to the text field. It happens only when you release the wheel. There is no Done button to hide the picker it self. To dismiss it, you can either click on the done button on navigation bar to end editing for the whole page, or click on another text field which pops a different keyboard.
2.Setting - Date&Time
Basically the same as Contacts app. Here you cannot even dismiss the picker.
Related
I have experience in Android and currently started to learn iOS. I created a mechanism to Pick data in an Android App. When I click on Date button, a DatePicker pops up:
As you see It has Cancel and Set button.
My question is about my iphone App. I want to have the same mechanism. When I click on the button, Date picker pops up (that can have Set and cancel button like Android Date picker). How can I do that? I'm not sure that it is a good way in iPhone, Can you help me if we can design a better mechanism?
Here's a UX comparison between Android and iOS standard widgets, with links to the documentation on the relevant Apple / Android websites. It's a nice way to get started learning all the technical terms.
http://kintek.com.au/blog/portkit-ux-metaphor-equivalents-for-ios-6-and-android-4/
Hopefully that gets you started.
Apple has a sample project that demonstrates this. You'll have to adapt it slightly: instead of showing/hiding the date picker itself, you'll want to show/hide a view containing a date picker and a dismissal button.
It's called DateCell.
Basically, it treats the date picker as if it were the keyboard for a cell containing the date. You'll need to manage hiding it when the user enters a text field (and thus, needs the real keyboard) and scrolling to keep the date row in view, but all the bits you need are in this project one way or the other.
One way to do it would be add a custom buttons to the same view containing date picker and then pop it up when the users wants. Instead of using the date picker delegate use the buttons action to get the date picker value.
The contacts application of the iPhone is a good illustration of my problem. Apple uses one view to show and edit contacts at the same time. When a user wants to edit a contact he simply presses the edit button on the right side of the navcontroller. The 'show contact' interface changes to the 'edit contact' interface and the user is able to edit the contact. When the user is finished editing he presses the 'done' button.
My question is, what is the easiest way to achieve this behavior?
I believe the iPhone CoreData Recipes sample code has everything you need, they have a page that is exactly as you describe:
http://developer.apple.com/library/ios/#samplecode/iPhoneCoreDataRecipes/Listings/ReadMe_txt.html
The short answer is that you can achieve this by using to separate view xibs which you can swap in and out. Personally I prefer to simply use code to hide and show the controls that need to change between the two views.
I am writing an iPhone application. In one of my views the user will have to enter Canadian zip codes which alternate letters and numbers (e.g. V0E 5N0). I would like to have the default keyboard showing up, but additionally, I want to allow the user to be able to enter numbers without having to switch keyboards back and forth by pressing the ".?123" key, which makes the process tedious for this type of entry. Will my app violate apple guidelines if I add into my view 10 buttons with the digits to show right above the keyboard?
There are plenty of Apps that already exist on the App store with such functionality, so I don't see why your App would get rejected specifically for having a view above the keyboard. It may still get declined because of other things, but not a custom keyboard view.
Nebulous Notes - Approved and on the App store:
iSSH also has a custom keyboard with toolbar on iphone and ipad and is on the App store.
Normally incase of a zip code entry , users are provided with a UINumberKeyPad and it makes it easy for them (But in your case it would not help you). In your case, if you wish to add another UIToolbar right on top of the inputView, I would say go for it, but it is not the best practice !
This will not violate the apple guidelines, and you can implement in your view with a UIToolbar as an inputAccessoryView. Make sure to remove the Toolbar from the superView during the keyboard event resignFirstResponder.
After the right '+' button is pressed the item in that view is added to favorites and an UIAlertView is shown on screen saying "Added to Favorites". After it is added to favorites I make the '+' button disappear so the same item doesn't get added again to favorites. I am not sure if this ok with Apple's Human Interface Guidelines instead should the '+' remain there and if pressed again say "This item is already in favorites"?
Any help will be appreciated! Thanks
I wouldn't use the AlertView for this. By showing the alert, you force the user to confirm reading some confirmation message and taking action (by pressing the OK button). It is a good idea to provide feedback that the favorite was successfully added, but this should not be an intrusive alert. Perhaps you can use other design patterns for favorites, such as a star that lights up when pressed to indicate that the item is listed as a favorite, or perhaps an animation effect that 'moves' the selected item to a visible 'favorites' category.
The Human Interface Guidelines have this to say about the Alert view (in relation to your question):
Avoid creating unnecessary alerts.
These alerts are usually unnecessary
if they:
Merely increase the visibility of some
information, especially information
that is related to the standard
functioning of your application.
Instead, you should design an
eye-catching way to display the
information that harmonizes with your
app’s style.
Why not have two states for the button ? A "selected" state (for example negative contrast) showing the item is in favorites, and a "normal" state indicating it can be taped.
This way you can add/remove from favorite using the same button, and in a less obstructive way than with a UIAlertView.
I also suggest you use a ★ instead of a +
I have struggled and now I just need to see it in action. I have an info-button on my title page (UIViewController) and I want to bring up an About-view with a 'dismiss' button on the left and a 'detail disclosure on the right.' If one presses the 'detail disclosure', it brings up the PrivacyStatement-view with the same buttons. If one presses the 'detail disclosure', it will bring up a Credits-view. I should be able to continue this for additional Legal, etc.
According to the Apple doc's one dismiss will dismiss the entire sequence, regardless of where one is at the time.
I have been able to get the views to show, but they won't dismiss themselves. These leads me to think that I am not using the preferred approach but rather, I have developed an ad-hoc approach that leaves me with dangling structures.
Any suggestions? I have my thoughts, but I am only one two levels deep and the dismiss doesn't work! :( I have a total dead-end and have to Quit the app to get back on the real App view.
I got it! Basically, the code is cascaded along the 'workflow' of viewcontrollers. I devised a style where most of the technical class management is done by the tools and leaves me with book keeping and content. I will need some review for memory management, as I think my current code is probably leaking controllers up and down the path. Also, the fact that I can traverse back and forth leads me to think that I really just have a stack of views and not modal views. I will post the code sometime by the end of the week.