UITextFieldDelegate vs UITextField control events

Question

If I want to handle changes to a UITextField, such as the user typing in it; it seems like this can be done either by assigning a delegate to that text field, and then having the delegate implement shouldChangeCharactersInRange, or by adding a target to the textField, and handling the UIControlEventEditingChanged event.

Aside from the fact that with the delegate method, you can return NO and therefor stop the user from making the edit, is there any difference between these 2 things?

Same question for handling the beginning of editing or the ending of editing. It could be done either with the appropriate delegate methods or with the appropriate events. What is the textField delegate actually for if the control events can do the necessary work?

Answer 1

You're right; you can essentially do the same thing via both, but UIControl is lower level and lets you siphon off each particular UIEvent to different targets via [UIControl addTarget:action:forControlEvents:] where as there is only a single delegate.

I would also say that the UITextField delegate protocol is simply there as a more convenient, higher level alternative to UIControl/UIEvent as a way to manage the behaviour of a UITextField.

The most common delegate pattern is UITableView DataSource and Delegate and I would say that using the UITextField delegate protocol is quite similar and therefore looks far more straight forward with more defined intentions than handing the messages from UIControl directly.

Answer 2

The delegation approach is the way to homogenize UITextField and UITextView behavior.

UITextView does not have control events. In contrast, UITextFieldDelegate and UITextviewDelegate provide parallel methods.

Answer 3

I have found out that shouldChangeCharactersInRange passes the same NSRange for insertion and deletion of text. You append a space and then delete it, and the parameters from shouldChangeCharactersInRange are indistinguishable from duplication of the text.

So shouldChangeCharactersInRange actually cannot predict the resulting text.

Answer 4

shouldChangeCharactersInRange is called before a change occurs, and gives you opportunity to 'cancel' the change. UIControlEventEditingChanged is called after the change occurred.

You can determine the resulting value of the textField in shouldChangeCharactersInRange, but you have to manually apply the replacementString to the existing text, using the supplied range. (via NSString stringByReplacingCharactersInRange). If you want to know the resulting text, it's easier and more efficient to use UIControlEventEditingChanged.

shouldChangeCharactersInRange is often used to implement validation checking of input - that is, you can filter characters/pasted text as it is entered. If a field is for phone numbers, for example, you can return FALSE if the user types a non numeric character, or attempts to paste in text that isn't numeric.

You might find a case where you can reuse code for multiple controls if you can stick with the UIControlEvent-methods.

Answer 5

One key difference I've found between the two approaches posed in the original question is that the delegate "shouldChangeCharactersInRange" gets called BEFORE the value in the UITextField changes. The target for UIControlEventEditingChanged gets called AFTER the value in the UITextField changes.

In the case that you're using these events to make sure (for example) that all fields in a dialog are completely filled in before enabling a "Done" button, the target approach may work better for you. It did for me.