* some space formattings
* always use blocks in if-else if a block is used
* format spaces in for and while
* allow multiline if conditions
* fix missing space
When a touch event that is in the bounds of a RenderUiKitView is absorbed by another render object,
the RenderUiKitView's handleEvent is not called for that object. On the platform side, the touch event hits the FlutterTouchInterceptingView which is waiting for a framework decision that never arrived on whether to reject or accept the gesture.
This change fixes the issue by having RenderUiKitView register a global PointerRoute, that is used to reject absorbed touch events.
* add trailing commas on list/map/parameters
* add trailing commas on Invocation with nb of arg>1
* add commas for widget containing widgets
* add trailing commas if instantiation contains trailing comma
* revert bad change
flutter/engine#7307 changes the engine side of embedded UIView to only
reject gestures when the framework sends a `rejectGesture` message, so
that gesture resolution can done after a touch sequence has ended (see
PR description for flutter/engine#7307 for more details).
This change makes the framework send a `rejectGesture` message to the
engine when a UiKitView rejects a gesture.
I'm planning to land this PR before the engine side change, so right now
it swallows the exception thrown if there is no engine implementation
for `rejectGesture` (which keeps us with the current behavior). After
this change lands I'll land the engine PR, and then clean up the part
that swallows the exception.
Re-landing #23412 with a fix to the PlatformLayer's addToScene signature.
#23412 was broken by the change to Layer done in #23434.
It seemed green as the presubmits were done before #23434 was landed, and when #23412 landed it broke the build.
Reverts #23779
This PR adds the full framework stack (layer->render object->widget, and
service) for embedding iOS views with minimal functionality.
I allowed myself to throw the entire framework stack in one PR since we're mostly
mirroring the structure we already established for embedded Android views, so this PR
is a little bigger than usual. I'm happy to break it down to the
different pieces of the stack if reviewers prefer.
Specifically this PR adds:
* A UiKitView widget for embedding a UIView in the widget tree.
* A RenderUiKitView which is the render object for showing a
UIView.
* A PlatformViewLayer which denotes the position of a UIView in the
layer tree.
* The iOS platform_views system channel client code in services/platform_views.dart
* Splits the fake platform views controller to an Android and iOS
controllers.
TBD in following PRs:
* Plumb the layout direction all the way to the platform view (currently
there is still no engine support for it).
* Integrate with gesture arenas (engine support is still missing as
well).
Before this PR AndroidView's gestureRecognizers field was a list of
gesture recognizers. This was problematic as when the widget was rebuilt
with the same gesture recognizer instances we would try to re-join the
recognizers to a gesture arena team and crash (as a OneSeqeunceGestureRecognizer
team can only be set once).
With this change, we instead take a set of factories.
This allows AndroidView to create the gesture recognizers just before
adding them to the team, and thus be sure that they are only added once to a
team.
The factories are identified by the type of the object they create, this
allows AndroidView to know when it is given an equivalent set of gesture
recognizer factories, and do nothing in that case.
This was a bug, when e.g a LongPressGestureRecognizer was in the gesture
arena, the android view gesture team may not yet win the arena when the
last pointer was up. This change allows AndroidView to win the gesture
even after all pointers are up.
This re-lands commit c594696.
The original PR was breaking the integration test as while the
gesture was active the AndroidView's parent widget got rebuilt which
disposed the _AndroidViewGestureRecognizer and dropped pointer events
from that point on.
This change adds a unit test that reproduces the failure case, and
fixes it by not rebuilding the _AndroidViewGestureRecognizer if the
list of gesture recognizers did not change.
Pointer events are dispatched to the Android view only if it won
Flutter's gesture arena for the pointer.
Specific gestures that should be dispatched to the android view can be
specified with the gestureRecognizers parameter.
Resizing an AndroidView happens asynchronously (as it requires thread
hopping from the ui thread to the platform thread).
While waiting for the resize to complete the framework does exactly when
the embedded view has been resized. This leads to pretty bad jank as the
framework might paint the embedded view with a wrong size.
We're working around this by freezing the texture frame while resizing
until we are sure that the next frame has the new size. This is how it
looks with the workaround:
This is how it looks before and after the workaround:
Before (janky) | After (less janky)
:--------|---------:
 | 
This depends on flutter/engine#5938. Additionaly right now the engine completes
the resize call immediately, a following PR will change it to complete
after a frame with the new size is ready.
This PR adds 2 features to RenderAndroidView and AndroidView:
1. Hit testing behavior
Adds a `PlatformViewHitTestBehavior` which is similar to
`HitTestBehavior` without the `deferToChild` option (as platform views
don't have child render objects) and with a `transparent` option which
prevents it from forwarding any events to the Android view.
2. MotionEvent recomposing logic
FlutterView and the framework `converter.dart` are working together to
transform each Android MotionEvent object into one or more
`PointerEvent` objects.
This PR adds the reverse logic (in _MotionEventDispatcher which is used
by RenderAndroidView) which turns a stream of PointerEvent objects into
MotionEvent objects.
The correctness of the recomposing logic is tested in an integration
test which will land in a separate PR (the unit test PR is pretty big,
trying to keep as many bite-size PRs for reviewer's convenience)
RenderAndroidView is responsible for sizing and displaying an embedded
Android view.
AndroidView is responsible for creating and disposing the Android view
and is using RenderAndroidView to display it.
