Understanding system logic for first responder

Question

I'm confused about severals first responder points:

1. If I call - becomeFirstResponder, does system call – canBecomeFirstResponder first? Why?
2. Why are there both - becomeFirstResponder and – canBecomeFirstResponder? In what situations they can return different values?
3. Does application have to have first responder in every time? If so, what is happening when I call – resignFirstResponder on some object? Does UIApplication become first responder immediately or is this "token" thrown on some point in the responder chain? Can I call - becomeFirstResponder on UIApplication object when I want to get rid of that pilgrim token?
4. ...

Please somebody explain me, how system manages its first responder. What is happening under the hood when some object becomes first responder, what when resigns first responder. What calls does system do... Thank you!

Trover

Answer 1

1. The default implementation of becomeFirstResponder does call canBecomeFirstResponder. This is because a responder that returns NO from canBecomeFirstResponder is not supposed to become the first responder.
2. becomeFirstResponder will make the receiver actually be the first responder if it succeeds. canBecomeFirstResponder just checks if the receiver is willing to be the first responder, without actually changing anything. It is possible that becomeFirstResponder could fail if the current first responder refuses to resign. There may be other situations where becomeFirstResponder could fail as well.
3. There doesn't have to be anything in your code that has the first responder status. Judging by the private UIResponder method firstResponder, the system does not assign any particular default in this case.

Basically, when something wants to become the first responder the current first responder (if any) is asked to resign, and then the new object becomes the first responder. This may cause the system to display the on-screen keyboard or take some other action. When the first responder resigns, this may similarly cause the system to hide the on-screen keyboard or take some other action.

When a non-touch event comes in, it is first delivered to the UIWindow. The UIWindow delivers it to the first responder. The documentation doesn't seem to specify whether or not UIWindow attempts to handle the event itself (and passes it to UIApplication as usual if it doesn't handle it itself) or just ignores the event if there is no first responder.

See the documentation for details.

Astir