According to the iOS docs, implementing
`- (id)insertDictationResultPlaceholder`
```Implementation of this method is optional but can be done when you want to provide a specific rectangle for the placeholder animation while the dictation results are being processed. ```
If you do not implement this method, UIKit will insert a default placeholder of 10 whitespace characters. By overriding this, no placeholder text will be inserted. If you implement the `insertDictationResultPlaceholder`, you must implement
`- (void)removeDictationResultPlaceholder:(id)placeholder willInsertResult:(BOOL)willInsertResult`
Add a `-[FlutterViewController setFlutterViewDidRenderCallback:]`
method on iOS so client applications can be notified when the Flutter
view has rendered. This can be used for add2app cases to determine
when to take an initial screenshot for comparisons in automated
tests.
The callback is expected to be an Objective-C block (or Swift
closure). I chose to support only a single callback because it's
much simpler (especially since it does not require a separate method
to unregister the callback), and it's not clear that there are use
cases that would justify additional complexity. Clients have the
flexibility to make their callback invoke other callbacks anyway.
I alternatively considered adding a `-[FlutterViewController
viewDidRenderFirstFlutterFrame]` method that clients could override
in a subclass, but using an Objective-C block seems more flexible and
less of a burden.
Fixes https://github.com/flutter/flutter/issues/20665
The touch mapper was a relic of a time when the pointer IDs had to be less
than 16. Not respecting the touch phase is getting in the way of clients that
fake their own touches. Turns out the AppDelegate also like to fake touches to
simulate status bar events. Now, except in cases where there is a specific
override in place, the UI touch phase is respected.
* Change FlutterDartProject to keep precedence when looking for the assets bundle
* Change assetsPath to fallback to mainBundle when the defined bundle does not contain assets
* Make FlutterStandardCodec handle writing NSData
iOS developers can accidentally pass an `NSData` object directly to
`FlutterStandardCodec` and forget to wrap it in
`FlutterStandardTypedData`. This failure won't be caught until
runtime.
Let's make `FlutterStandardCodec` more tolerant by making it assume
that `NSData` should be treated as a binary blob and by wrapping it
automatically.
Fixes https://github.com/flutter/flutter/issues/17449
Testing Done:
* Made a sample Flutter iOS application that created a
`FlutterMethodChannel` and invoked a method using an `NSData*`
argument. Verified that the Flutter method handler received the
message and that the `MethodCall.arguments` was a `UInt8Array` that
preserved the original byte order.
* Verified that without this change, the same sample application
crashed when run in debug mode.
* Add a unit test for encoding raw NSData
* Formatting adjustments
* Revert "Add logging if FlutterDartProject fails to load the application kernel snapshot (#6257)"
This reverts commit d29c7db769d1a0d45f579b76ee3a43f38dc7318d.
* Revert "Update deprecated subtags from language subtag registry. (#6280)"
This reverts commit 2a1debfccfe2cc00e596607ac7cb1d29d2af8834.
* Revert "Add Xib splashscreen support (#6289)"
This reverts commit 540cd96262ed87bb6cd26ac18ad5468e70c3af63.
* Revert "Fix a compilation problem when using iPhoneOS12.0sdk(Xcode10) && clang version 7.0.0. (#6279)"
This reverts commit 05f21e63a115db2db161c8265be8e8349f3d7df0.
To make "Engine run configuration was invalid." failures (e.g.
https://github.com/flutter/flutter/issues/20777) a bit easier to
diagnose, add some more logging to `FlutterDartProject` to verify
that snapshot assets were properly bundled.
On the iPhone X, raising the keyboard sets a bottom physical inset equal
to the keyboard height, however we previously did not zero out the bottom
physical padding. This was incorrect; when a soft keyboard is present,
it 'consumes' the safe area inset for the home indicator widget,
eliminating the need for the app to handle this at all.
- Switch core snapshot to Dart 2 and remove support for loading platform.dill.
- Remove support for loading script snapshots.
- Remove support for loading source.
- Remove settings and fix names to reflect the above.
- Remove support for loading the service isolate from source.
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).
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.
* Add an explicit `-[FlutterViewController init]` implementation
`-[FlutterViewController init]` currently works because it inherits
the `-[UIViewController init]` convenience initializer that invokes
the `-[UIViewController initWithNibName:bundle:]` designated
initializer that `FlutterViewController` overrides.
However, this doesn't seem to be explicitly documented, so it's a bit
confusing (or at least non-obvious), and it seems potentially
brittle. Add an explicit implementation of `-[FlutterViewController
init]` instead.
* Deprecate -[FlutterDartProject initFromDefaultSourceForConfiguration] (#18886)
`-[FlutterDartProject initFromDefaultSourceForConfiguration]` no
longer seems very useful. It calls `-initWithPrecompiledDartBundle:`
or `-initWithFlutterAssets:dartMain:packages:`, but since it now
passes `nil` for all arguments, both paths end up doing the same
thing.
Additionally, `-initFromDefaultSourceForConfiguration` is awkward to
use in Swift. The automatically generated Swift interface is:
public convenience init!(fromDefaultSourceForConfiguration: ())
and it's not obvious how to call that.
Let's deprecate `-initFromDefaultSourceForConfiguration` and instead
expect callers to use the existing `-init` method. (We can make
`-init` do different things for different build configurations later
if necessary.)
Bonus: Rename some parameters to make it more obvious when they may
be `nil`.
