Combined with the above, it describes the transmission of events. Through the transmission of events, the best event responder is found, and then the responder needs to respond to the event and do relevant processing. Link above to answer supplementary questions:

First, whether the event exists, that is, in the process of the event, under what circumstances the event is discarded;

Second, according to the hitTest judgment to find the best responders to respond to the way to do investigation:

  • Whether interaction is allowed;
  • Transparency Settings;
  • Whether the view is hidden
  • Whether the child view exceeds the valid scope of the parent view;

That is, if the event can respond to precondition one: the event exists; Second, the best responders; The best responders must be found through the hitTest series;

Once you’ve solved the problem of event generation, delivery, and failure to respond, how does the event respond? Move on:

1. Response to events

Who is responding to the event, that must be the responder object. As stated above, every responder object must be an object that inherits from UIResponder. And the reason why an object that inherits from UIResponder can respond to an event is because UIResponder provides a corresponding event handler to respond to an event, which by default doesn’t do anything internally, just passes the event along the response chain. These methods need to be overridden if you want to intercept events as they pass through the response chain and do custom response processing on them.

// (void)touch began :(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {NSLog(@" touch started "); }// (void)touchesMoved:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {NSLog(@movemove@); }// (void)touches ended :(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {NSLog(@" touches ended "); }/// Event cancellation processing -- this method is interrupted during event processing; /// for example, a sudden call or process is killed; (void)touchesCancelled:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event { NSLog(@" Event cancelled when event unexpectedly interrupted "); }Copy the code

The system passes the event in the response chain through these ways. In this process, a method is rewritten, and the event will be processed according to the rewritten method in the response process.

2. Event transmission — response chain transmission

One thing to be clear about here is that the best responder is found in the delivery of the event, but the response of the event is not necessarily that responder. That is, all responders in the chain of events can respond to events, but ultimately who will respond to events depends on the processing in the chain;

The passing of an event in the response chain depends on the touchesBegan method, which is available to every responder object. The method functions as an event processing method for the responder, and as a passing method in the response chain.

The default action of this method is to pass events down the default response chain, but we can override this method to intercept events in one of three ways:

  • Pass along the default response chain, that is, do not intercept the event passing through the response chain;
  • Intercepting the event by overriding the method and then letting it continue down the response chain (requiring calling the method of the parent class);
  • Intercepting the event by overriding the method and then not letting it continue down the response chain (without calling the method of the parent class);

(Following: transmission of events: juejin.cn/post/690120…

In the first case above, that is, the final best responder is F. The response chain in the transfer chain is shown in Figure 2 below:

   

Figure 1 View hierarchy figure 2 Response chain

(I) Assuming that A ultimately responds to the event, then the transmission of the response chain is:

  1. F is the best responder, but F can’t handle the event, so it passes the event to its parent view, its superView C, using touchBegin;
  2. C can’t handle the event either, so it also passes the event to its superView A via touchBegin;
  3. A can process the event at this time, so the final event is handed over to A for processing; (If A handles the event, it does not continue upward by default; But if when A overrides the touchBegin method and calls it through [super], the event continues to be passed up);

(2) Assuming that the event response is ultimately done by UIApplication, the transmission of the response chain is:

  1. F is the best responder, but F can’t handle the event, so it passes the event to its parent view, its superView C, using touchBegin;
  2. C can’t handle the event either, so it also passes the event to its superView A via touchBegin;
  3. Now A can’t handle the event either, so it also passes the event to its controller, UIViewControllerView, using touchBegin;
  4. Now UIViewControllerView can’t handle the event either, and there’s no upward view, so pass the event to the main window, UIWindow, using touchBegin;
  5. UIWindow can’t handle the event either, so use touchBegin to pass the event to UIApplication for processing;
  6. UIApplication can now handle the event; So the final event handling is handled by UIApplication;

(III) Assuming that there is no responder who can handle the event, then:

It is still the same step as in (2), but at step 6, UIApplication can’t handle the event, so the event is discarded.

(c) Assume that multiple views respond to the event: F can respond, and A can respond to the event:

  1. As the best responder, F can handle the event. Since A is required to respond to the event, F overwrites the uchBegin method and calls it through super, passing the event up to C.
  2. C can’t handle the event, so it passes the event to its superView A via touchBegin as well;
  3. If A can process the event, A will process the event. And it doesn’t go up any further;

Summary: The response transfer chain for the event

Start from the best responder and work your way up until you find a view or view controller that can handle the event; When the response chain gets to UIApplication, UIApplication can’t handle the event yet, the event is discarded; When multiple objects that can handle the event are needed in a response chain, the touchBegin method is overridden in the corresponding processing object, and the super call passes the event upward.

Summary: mainly for the response of the event to do some related brief, how the event is transferred in the response chain and a response chain to do more than one object should do; Here, I have a preliminary understanding of the transmission and response of events, which can solve some problems that may be encountered in practical work. Of course, there’s more to this section than that;

Ask the following questions to communicate:

  1. When are user clicks discarded when the page freezes? (I have a shallow understanding of the event loop mechanism of RunLoop);
  2. Realize the transparent transmission of events; (Rewrite hitTest)
  3. Implementation of special requirements? D at the bottom is the button for the bottom TAB, and the bottom TAB is loaded in the root view of the controller. By default, if you click the D button beyond the bottom TAB, you’ll find that the button doesn’t respond. The requirement is to achieve the normal clicking of the D button. The diagram below:

Follow-up to do in-depth understanding of the supplement.