Since UITextField inherits from UIControl we also can use addTarget: action: forControlEvents:
[_textField addTarget:self action:@selector(textDidChange) forControlEvents:UIControlEventEditingChanged];
문제
My colleagues and I prefer different approaches to solving one small task. We would like to know opinion of the community.
We have to process UITextField's text during editing. ( Text should be displayed in the view's title )
Two simplest approaches are:
1.Register for notifications:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(textFieldDidChangeNotification:)
name:UITextFieldTextDidChangeNotification
object:_titleTextField];
2.Use UITextFieldDelegate method
- (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string
{
NSMutableString *mutableString = [textField.text mutableCopy];
[mutableString replaceCharactersInRange:range withString:string];
// use mutableString for father processing
return YES;
}
Which approach is better and why? Is there any reason why some approach should be avoided in this situation?
UPDATE: ( Some clarifications )
We do not need any additional flexibility that is provided by delegate ( like possibility to disallow some editing) or notifications ( possibility to add several observers ). Our main question is "Is it a good practice to use NSNotifications if we can easily solve an issue with delegate?"
UPDATE2:
Thanks everyone who answered the question!
It seems that community's answer for question "is it a good practice to use NSNotifications if we can easily solve an issue with delegate?" is yes. But for our original issue we have found another (third) variant which is better than delegates and NSNotification (see accepted answer).
해결책 4
Since UITextField inherits from UIControl we also can use addTarget: action: forControlEvents:
[_textField addTarget:self action:@selector(textDidChange) forControlEvents:UIControlEventEditingChanged];
다른 팁
I have coded a lot of both and I disagree with Adam. Notifications prove much harder to debug and trace backward most of the time. I also suspect they add more performance overhead, but that's anecdotal for me and I have not benchmarked it. I lean toward notifications when there may be more than one observer that needs to act on an event, and/or when I want "loose coupling" where one part of the code shouldn't have specific knowledge of API's in another part. In your case, the text field already comes with the logic to have a delegate and make calls to the delegate on certain events so it's a no-brainer. If one or more delegate methods get called at the time you need with the data you need. that's the simpler, more appropriate path.
The main difference between delegate and notification is that notification will notify all classes, in case they have subscribed to it. While delegate is one to one.
Considering that there won't be any further changes in application work flow. This approaches a pretty much equal. But I still prefer to use delegate because of following reasons:
Methods of a UITextFieldDelegate
will return YES
or NO
depending on whether you want the user to be allowed to type certain things.
With this in mind, I'd use a notification. You don't care about the logic for changing the content of the UITextField
, all you want to do is, whenever the content is changed, change the title of your view.
This gives you the benefit of allowing any delegate
to still be able to return YES
or NO
if the content needs to be restricted and the notification will only be sent if the delegate has returned YES
(or if there is no delegate).
EDIT
In case I misunderstood the question, process the text in the UITextFieldDelegate
method and use the notification to update the view's title. Unless the UITextFieldDelegate
is the view, in which case I'd just update the view's title directly from the UITextFieldDelegate
method.
EDIT #2
Based on your further edit and requirements I would hands down use the delegate method. NSNotification
comes with issues that delegates don't - debugging and performance (as RobP mentioned) is one. Another is it's much easier to leave an NSNotification
hanging around after you have dealloc'd whatever it was attached to, resulting in a crash (good look debugging, see RobP's answer).
In your specific circumstances, delegate wins.