Repository navigation
Does even bubbling exist, or how to enable cancelsTouchesInView ? #30
Description
Activity
Can you describe your use case? Hard to give a good answer without knowing what you are trying to do
I'm doing something a little unconventional, which you saw me tweet about: throwing a UI on top of a game. It's primitive right now but looks like this:
Those are up/down buttons at the bottom. Problem is, you can touch the screen to move around the camera, but if you press and drag your finger on top of those buttons, it still moves the camera around.
My views are set up like this: one controller that has a normal UIView, the GL view as the first subview and the RCTRootView as the second subview.
We have a responder system to handle this, but we didn't have much time to explain how it works at the conference. There are a number of handles that we use to negotiate touch handling. These are working well on View, but not everything has full support for this yet. (I'm not sure what 3D view you're using here)
A view can become the touch responder by implementing the correct negotiation methods. There are two methods to ask the view if it wants to become responder:
View.props.onStartShouldSetResponder: (evt) => true,- Does this view want to become responder on the first touch-down?
View.props.onMoveShouldSetResponder: (evt) => true,- Called for every touch move on the View when not responder: does this view want to "claim" touch responsiveness?If the View returns true and attempts to become the responder, one of the following will happen:
View.props.onResponderGrant: (evt) => {}- The View is now responding for touch events. This would be a great time to highlight and show the user what is happening
View.props.onResponderReject: (evt) => {}- Something else is the responder right now and will not release itIf the view is responding, the following handlers are used:
View.props.onResponderMove: (moveEvt) => {}- The user is moving their finger
View.props.onResponderRelease: (releaseEvt) => {}- Fired at the end of the touch, ie "touchUp"
View.props.onResponderTerminationRequest: (evt) => true- Something else wants to become responder. Should this view release the responder? Returning true allows release
View.props.onResponderTerminate: (evt) => {}- The responder has been taken from the View. Might be taken by other views after a call toonResponderTerminationRequest, or might be taken by the OS without asking (happens with control center/ notification center on iOS)There are a few more features and facets to this system, which can be found in the highly documented
ResponderEventPlugin.jsReacted by Doney den OudenThanks for the explanation, @ericvicenti! After I posted this I did see the diagram in ResponderEventPlugin.js.
I believe, however, that is doesn't fix my use case. All of this is only happening within the views controlled by ReactKit, correct? I'm rendering everything from ReactKit into it's own subview, and rendering everything from OpenGLES into a different subview. So basically I can't control how I interact with anything outside of the ReactKit subview, right? By default, all touches are being handled by both of these views.
The right way to do it, it seems, is to implement my own custom GL view on the native side and expose that as a custom component. Then I can render the GL view within my component hierarchy, and I can control the interactions.
Where should I start to look at implementing my own native UIView subclass?
cc @jordwalke
Correct- responder negotiation happens in JS. The 3D view should be expressed in your React component hierarchy to use the responder system. (There currently isn't good responder negotiation between the top-level ReactKit component and external iOS components.)
I'll defer to @jordwalke, @sahrens, @frantic, and @nicklockwood to help explain the state-of-the-art when it comes to bridging new components.
I think I see how. I need to create a component with a
viewConfigproperty, which has auiViewClassNameproperty, which is the Obj-C class that it will instantiate when creating the backing iOS instance. And I need to implement my custom UIView class on the iOS side with this same class name. Theoretically it will instantiate my custom view class.I'll take it from here and file an issues I run into.
@jlongster Yes, that should work, but I don't know why your other view is receiving touches that started on the buttons. Are your touch handlers for the camera on the outermost view that contains everything? If so, you could put your touch handlers (or gesture recognizers) on just the part of the screen that has the teapot.
@jordwalke The 3d scene is actually rendered the full width/height of the phone, and the buttons are sitting on top of it. I do it this way because the UI will frequently change on top of the 3d scene; it's basically just a 2d overlay.
I could shrink the 3d scene, but there will be many other cases where I want an input on top of the scene.
I see. Then your approach of creating a custom 3d-scene component sounds good. (BTW, we're going to streamline making new bridged components, and we're also going to work on integrating the JS cross-platform responder system with each platform's gestures).
Also, where are your touch handlers? I think there's a way to make this work simply by making the buttons not under the place where your touch handlers are setup in iOS (regardless of geometry/how much space they take up).
Cool, I assumed the bridge was early work and that it'll be easier to make custom components in the future.
The touch handlers are on the view controller controlling the GL view. But I just realized that is the root view of the window. I add the RCTRootView as a subview on top of my GL view, but you're right, my touch handlers are still on the controller of the whole thing. I probably could try just having multiple controllers and make sure the UI is sitting on top of everything.
@jlongster that sounds like the right approach (make sure the UI is really sitting on top of everything).
- added a commit that references this issue
on Jul 6, 2016 - locked as resolved and limited conversation to collaborators
on May 29, 2018
I don't see a
stopPropagationmethod on the Event instance we get in a touch handler. Is there a way to do the equivalent of settingcancelsTouchesInView = YESon a view so that touch events do not go to parent views?We probably don't need something like
stopPropagationbecause you can't really do that on iOS, but some static property to set on aView.