We'll now have a more in-depth understanding of user's gestures based on which
we can trigger different BrowserToolbar behaviors depending on if the user is
scrolling or zooming.
The ConstraintLayout parent will still inform us about when the scroll begins
and when the scroll ends but then actually incrementally updating the toolbar's
translation will be done in response to GestureDetector callbacks.
This also allows us to easily differentiate between horizontal and vertical
scrolls and only react for the latter.
If the user's gestures as inferred as zoom gestures (multi-finger scale or
quick-scale) the toolbar should not be animated.
This scenario is though affected by the fact that normally scroll gestures have
a much higher sensitivity (a 1 pixel movement is enough for a gesture to be
considered a scroll gesture) and so it is possible that even in the case of a
desired zoom gesture the scroll callbacks will be fired first.
When the gesture is identified as a zoom gesture we will immediately snap the
toolbar up/down but there might be a minor visual glitch because of this.
In an effort to reduce such races between scroll and zoom gestures I've lowered
the sensitivity of the ScaleDetector, this having the other effect that
multi-finger scrolls must now be more precise. Pinching while zooming will now
more often mean a zoom gesture and not animate the toolbar.
There are currently 3 Views interested in handling user's MotionEvents:
- GeckoView which renders web content
- SwipeRefreshLayout which handles pull down to refresh
- BrowserToolbar which can be dynamically hidden
Each of them have different behaviours based on different conditions so I
- removed the coupling of BrowserToolbar and Geckoview from `NestedGeckoView`.
It's `onTouchEventForResult` will now only set behaviour for GeckoView.
- created a new EngineView enum to expose the `PanZoomController` possible
result of how a specific user touch was handled to any components that have a
reference to an instance of EngineView without the need to have
`concept-engine` as a dependency.
- implemented specific behaviour in `SwipeRefreshFeature` for the pull down to
refresh functionality and in the `BrowserToolbarBottomBehavior` for the dynamic
navigation bar functionality.
Mapped PanZoomController's INPUT_RESULT to a new enum in order to not enforce
the need of including geckoview as a dependency in all components interested in
how a user's `MotionEvent` was handled and also because webview doesn't expose
such values so we needed a wrapper for it's handled or not boolean return.
This change takes into account all four possible scenarios:
Legend:
X button = X
ActionContainer = A
UrlView = U
1. (X GONE) (A GONE) <- 8dp -> (U)
2. (X GONE) (A) (U)
3. (X) (A) (U)
4. (X) (A GONE) (U)
So basically, this adds 8dp only when both views in it's anchoring chain
are GONE
