Re: iOS Best Practice Question
Re: iOS Best Practice Question
- Subject: Re: iOS Best Practice Question
- From: Eeyore <email@hidden>
- Date: Tue, 26 Apr 2011 16:45:05 -0700
On Apr 26, 2011, at 2:51 PM, glenn andreas wrote:
>
> On Apr 26, 2011, at 4:36 PM, koko wrote:
>
>> So we have one vote for:
>>
>> 3. Use a view in a layer of the current view
>>
>> Any other views (no pun intended) ... going once going twice ....
>>
>> Any comments against :
>>
>> 1. Use UIAlert - easy but seems clunky
>>
>> -koko
>
>
> Adding additional content in UIAlert is not recommended, since it requires a high degree of care and verges on something that can get an app rejected from the App Store. (you've got to do special casing for different versions of the OS and make bad assumptions about the layout of the subviews, and will quite likely break when the next OS release happens).
>
> In general, if you can avoid making a UIPickerView "appear" as the result of an action, you'll be better off. Make it part of the UI, always available, or use a different mechanism (for example, in a table view, just push a second table view onto the navigation controller and let the user select the element from that table view, just like Settings.app does, etc...)
I agree that the UIAlert is not the way to go. However, I agree with koko that including a picker on the screen can feel clunky, in my case it made it feel like the date was more important than the other information in the much smaller UITextFields on the same screen.
My solution was to have the date displayed in a UITextField whose inputView is set to a UIDatePicker. Tapping the text field to edit the date results in the UIDatePicker popping up instead of a keyboard and I use the UITextField's inputAccessoryView to provide a toolbar with a "Set" button, and an "Undo" button. Implementing this didn't require a lot of code (I think most of my code is there to facilitate the "Undo" button). I believe it feels natural to users: it looks like a text field, and acts like a text field but has a slightly unusual "keyboard" that limits possible input. Based on the documentation, it does appear that this is the purpose of the inputView and the inputAccessoryView, so I don't think it will run afoul of Apple's guidelines.
I'm willing to provide code if requested, although the classes I'm using are tied into a larger collection of special purpose textfields so you'll need to disentangle the features you want.
Aaron_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden