I have a part on my app that I show the users, the files they have created and have stored inside the app's directory. I want to allow the users to rename the files.
I am wondering of doing this:
The user selects a file
The user taps on the RENAME button.
An alertview pops showing the old name and having a textview where the user can type the new name.
My question is: is this blessed by Apple? This sounds like a hack to the alertview.
Will the app be approved?
I googled around and I saw mixed opinions about that.
thanks
Generally I think the correct HIG-happy UI would be a UITableView with the list of of files. The user taps and Edit button and the page rows become editable, allowing you to delete a row/file (with a verification alert) and a disclosure arrow that pushes a detail view where you can change the name.
An alternative, though not HIG-friendly, is displaying the file name in a UITextField where the borderStyle set to UITextBorderStyleNone and the enabled set to NO. When the user taps the Rename button you change the borderStyle to UITextBorderStyleRoundedRect and enabled set to YES, setting the firstResponder to the text field so the cursor is flashing inside the textField. You'd need OK and Cancel buttons.
Or you could add a text field to the UIAlertView, also against the HIG but perhaps better.
I don't know if the property alertViewStyle was available when you make this question but searching to resolve this problem for me, I found that setting this property with UIAlertViewStylePlainTextInput resolve your problem.
Yes it is in iPhone sdk alertBox, alertBox can have the textField in which you rename the file.
check this link
for making such kind of stuff. No problem in accepting your app
You could either subclass UIAletView and add your own initWithTitle:message:...etc. method, as outlined in this tutorial, or use the undocumented [alert addTextFieldWithValue:#"" label:nil]; method, which is easier but may cause Apple to reject your app.
Related
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.
I have a custom button in ABNewPersonViewController. I need to enable the button, only if any(at least) one of the fields in ABNewPersonViewController is edited. Is there any way in which I can check this condition, other than writing code to check all fields independently.
You'll need some code somewhere to do this, but I'd do it by coding the existing event listener on each field to enable the button when the field being listened to is edited.
All controls have events so you can link your code to it. Example: UITextField has the event Editing Did Begin. Every controls can be linked to the same IBAction and you can recognize wich control the user changed by checking the sender param.
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 want to keep the place holder text shown while it is focused (that is, while it is the first responder). It should stay that way only until something is typed and the field no longer blank.
Address Book app's Search bar behaves like this, as do the new contact entry fields.
Is there any way to do that?
I don't think this comes "built in" for you to activate it, but you can build it rather easily on your own: Create a UILabel you want to display and when the focus is set onto the TextField place the UILabel at the right spot (slightly after the cursor).
As soon as the user enters a character you hide the UILabel. You can see when the user starts the edit and starts to type by adding your class as delegate to the UISearchBar (see callbacks "searchBar:textDidChange:" and "searchBarTextDidBeginEditing:"): http://bit.ly/eQlvRz
I display a UITextView that I want the user to be able to copy from but not edit. There must be no keyboard present on the screen during the copy.
If I prevent first responder then the keyboard stays hidden. However this also prevents processing of events from touches that would allow a copy interaction. It also has to be editable to process touches as far as I know.
Is there an easy way to achieve this; a read-only, copy-only, no-keyboard UITextView? The docs are very terse on what "editable" guarantees, requires, and how is changes behavior.
Have you tried setEditable: NO? I know you say the docs don't describe it much, but they do say that it controls whether the receiver is editable. Did you try?
You've tried that, and the answer is to set editable to NO.