Otherwise the callbacks may be called after FlutterNativeView is destroyed and is null.
Also defensively check for whether the texture is already released in the callback because the callback may be called from another thread by a stale reference (see the comment).
This closes https://github.com/flutter/flutter/issues/20951.
The following were previously marked as deprecated over a month ago:
* `FlutterStandardBigInteger`
* `-[FlutterDartProject initFromDefaultSourceForConfiguration]`
Remove their implementations and mark them as unavailable.
Add a `-[FlutterViewController splashScreenView]` property
Add a `-[FlutterViewController splashScreenView]` property that
clients can use to customize the launch view (issue #17140).
The default WindowManager implementation in Android's Presentation is
delegating addView/removeView/updateViewLayout calls to the global
WindowManager.
This can result in a crash when an embedded view is trying to e.g show a
PopupWindow.
This change adds a custom WindowManager that overrides
addView (and removeView/updateViewLayout) and adds the view to the
presentation's view tree.
Note that views might keep a reference to the window manager which
might be an issue when we move a view from one virtual display to
another (due to a resize). For this reason when re-sizing we are not
creating a new window manager for the new presentation, but updating the
window manager's references to be relevant for the new presentation and
re-use it.
If `FlutterDartProject` found an `FLTLibraryPath` entry in an iOS
application's `Info.plist`, it assumed that values that were valid
filesystem paths were paths to bundles. If the attempt to retrieve
the `NSBundle` fails, `FlutterDartProject` ignored the failure and
then would assign `nil` to a C++ `std::string`, resulting in a null
pointer dereference.
Add some failure checks to prevent this.
We'd like the ability to add Flutter to existing iOS applications
without requiring that they set `FLTLibraryPath` and `FLTAssetsPath`
in the main bundle's `Info.plist`.
1. Modify `-[FlutterDartProject initWithPrecompiledDartBundle:]` to
support setting the library and assets path from the specified
`NSBundle` instead.
2. If no `NSBundle` is explicitly specified, look for one with a
default bundle identifier ("io.flutter.flutter.app") before
falling back to the main NSBundle.
Also remove `+[FlutterDartProject pathForFlutterAssetsFromBundle:]`
because we don't use it internally, and it isn't exposed in the
header file.
When these delegate methods were initially added, it was expected that a single
shell would be able to own mutliple platform views, engines and animators. This
plan was abandoned in favor of creating multiple shells with their own platform
views, engines, etc.. The arguments were meant to ease the disambiguate the
instances of the variaous objects managed by the shell. This is no longer
necessary.
This change adds a delay before Animator::BeginFrame calls its
delegate's OnAnimatorNotifyIdle. This is because under certain
workloads, such as our parent view resizing us, which is communicated
via viewport change events, we won't have a frame scheduled yet in the
animator, despite the fact that we will go on to schedule a frame once
the viewport event arrives.
In Fuchsia's resizing performance test, on our reference high end x86-64
hardware, the previous logic was resulting in a ~45ms garbage collection
right after the first frame of an animation.
This allows the framework to know that a frame with the resized view is
ready and to behave deterministically to workaround the jank issue
described in flutter/flutter/19572
