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`.
Eliminates support for running directly from sources or script snapshots. In
debug mode, we run from a kernel snapshot; in profile and release modes, we
link in AOT-compiled code.
Renames --dart-non-checked-mode to --disable-dart-asserts since checked mode
does not make sense in Dart 2.
* Enforce clang-format on all files in commit
This re-enforces clang-format across all files changed in the commit.
In c10c417, we enabled checking only for the lines changed in the diff
in order to reduce the change of merge conflicts with the shell refactor
landed in 58e84c8.
* Reformat sources to match latest clang-format
As part of re-enabling clang-format across the codebase, reformat all
code to match the latest toolchain.
* Move the handling of delegating AppDelegate callback out of FlutterAppDelegate.
Also moves the plugin registry to FlutterViewController. So each view-controller will handle its
own plugins.
This is intended to simplify including one or more Flutter views in an existing iOS app and giving
more precise control of plugin registration.
Fixes: https://github.com/flutter/flutter/issues/16539
* formatting
* Update license golden file
* Fixed type error
* FREEZE.unindexed
* Fix Header types
* Revert "FREEZE.unindexed"
This reverts commit bebb70056c9bcb90b4321bdc2873896623ed6faa.
Adds --dynamic and --interpreter flags to
tools/gn. These flags result in engines with
properties as follows:
--dynamic:
- JIT targeting native code on Android and
DBC on iOS
--interpreter
- Target DBC even if running on Android.
For example:
gn --android --dynamic --interpreter --runtime-mode release
Will generate an engine:
- Without Dart asserts
- Without Observatory
- With JIT compililation to DBC
into out/android_dynamic_release_dbc
Eliminates the declaration that only arm64 is supported in
Flutter.framework's Info.plist. This causes Xcode's app thinning tools
to remove Flutter.framework in thinned archives for armv7 devices.
