This will eventually be used as the main communication channel between
the widget preview scaffold, the Flutter tool, and other developer
tooling (e.g., IDEs).
Fixes#166417
This change reworks how users define previews in their code, expands the
number of valid 'functions' that can be used to create previews, and
allows for specifying a 'wrapper' function to wrap the previewed widget
with
The `WidgetPreview` class has been removed from the framework, with its
properties being added to the `Preview` annotation class instead to
remove some boilerplate from the preview declaration workflow.
Before:
```dart
@Preview()
List<WidgetPreview> previews() => <WidgetPreview>[
WidgetPreview(
name: 'Top-level preview',
child: Text('Foo'),
),
];
```
After:
```dart
@Preview(name: 'Top-level preview')
Widget previews() => Text('Foo');
```
Previews can now be defined using top-level functions, constructors and
factories which take no arguments, and static methods within classes:
Examples:
```dart
@Preview(name: 'Top-level preview')
Widget previews() => Text('Foo');
class MyWidget extends StatelessWidget {
@Preview(name: 'Constructor preview')
MyWidget.preview();
@Preview(name: 'Factory preview')
factory MyWidget.factoryPreview() => MyWidget.preview();
@Preview(name: 'Static preview')
static Widget previewStatic() => Text('Static');
@override
Widget build(BuildContext context) {
return Text('MyWidget');
}
}
```
Users can also provide a `wrapper` function with the signature `Widget
Function(Widget)` to easily wrap previewed widget with shared
bootstrapping logic.
Example:
```dart
Widget testWrapper(Widget child) {
return Provider<int>.value(
value: 42,
child: child,
);
}
@Preview(name: 'Preview with wrapper', wrapper: testWrapper)
Widget preview() {
return Text('Attributes');
}
```
Which is effectively the same as:
```dart
@Preview(name: 'Preview with wrapper')
Widget preview() {
return Provider<int>.value(
value: 42,
child: Text('Attributes'),
);
}
```
Finally, for situations where a `BuildContext` is needed, users can
return a `WidgetBuilder` from their preview function:
```dart
@Preview('Builder preview')
WidgetBuilder builderPreview() {
return (BuildContext context) {
// TODO: retrieve state from context.
return Text('Foo');
};
}
```
With this change, `flutter widget-preview start` will launch a working
widget preview environment that can render previews from a target
project.
Also fixes an issue where `--offline` wasn't being respected by some pub
operations.
This is the initial tooling work for Flutter Widget Previews, adding two
commands: `flutter widget-preview start` and `flutter widget-preview
clean`.
The `start` command currently only checks to see if
`.dart_tool/widget_preview_scaffold/` exists and creates a new Flutter
project using the widget_preview_scaffold template if one isn't found.
The widget_preview_scaffold template currently only contains some
placeholder files and will be updated to include additional code
required by the scaffold.
The `clean` command simply deletes `.dart_tool/widget_preview_scaffold/`
if it's found.
This change also includes some refactoring of the `create` command in
order to share some project creation logic without requiring `flutter
widget-preview start` to spawn a new process simply to run `flutter
create -t widget_preview .dart_tool/widget_preview_scaffold`.
Related issue: https://github.com/flutter/flutter/issues/115704
---------
Co-authored-by: Andrew Kolos <andrewrkolos@gmail.com>
Reverts: flutter/flutter#154061
Initiated by: QuncCccccc
Reason for reverting: might be the reason that cause Framework tree to red
Original PR Author: bartekpacia
Reviewed By: {gmackall, reidbaker}
This change reverts the following previous change:
This PR resolves#151166
Adds an empty privacy manifest, and commented out code to include it in the build, to the plugin template. This will make it much easier to explain how to add a privacy manifest in plugin docs, since instead of explaining the format of the file from scratch and providing example code to inculde it, we can just instruct people to add entries to an exisitng file and then uncomment a line or two. This will also make it much easier to figure out from the template output itself how to add support for people who don't find the documentation.
Part of https://github.com/flutter/flutter/issues/131940
Fixes https://github.com/flutter/flutter/issues/140013
When Swift Package Manager feature is enabled, create app and create plugin will have Swift Package Manager integration already added and will not need to undergo a migration.
Fixes https://github.com/flutter/flutter/issues/146371.
```
flutter config --enable-swift-package-manager
flutter create --ios-language swift --platforms ios,macos swift_app_name
flutter create --ios-language objc --platforms ios objc_app_name
flutter create --template=plugin --ios-language swift --platforms ios,macos swift_plugin_name
flutter create --template=plugin --ios-language objc --platforms ios objc_plugin_name
```
Support for FFI calls with `@Native external` functions through Native assets on MacOS and iOS. This enables bundling native code without any build-system boilerplate code.
For more info see:
* https://github.com/flutter/flutter/issues/129757
### Implementation details for MacOS and iOS.
Dylibs are bundled by (1) making them fat binaries if multiple architectures are targeted, (2) code signing these, and (3) copying them to the frameworks folder. These steps are done manual rather than via CocoaPods. CocoaPods would have done the same steps, but (a) needs the dylibs to be there before the `xcodebuild` invocation (we could trick it, by having a minimal dylib in the place and replace it during the build process, that works), and (b) can't deal with having no dylibs to be bundled (we'd have to bundle a dummy dylib or include some dummy C code in the build file).
The dylibs are build as a new target inside flutter assemble, as that is the moment we know what build-mode and architecture to target.
The mapping from asset id to dylib-path is passed in to every kernel compilation path. The interesting case is hot-restart where the initial kernel file is compiled by the "inner" flutter assemble, while after hot restart the "outer" flutter run compiled kernel file is pushed to the device. Both kernel files need to contain the mapping. The "inner" flutter assemble gets its mapping from the NativeAssets target which builds the native assets. The "outer" flutter run get its mapping from a dry-run invocation. Since this hot restart can be used for multiple target devices (`flutter run -d all`) it contains the mapping for all known targets.
### Example vs template
The PR includes a new template that uses the new native assets in a package and has an app importing that. Separate discussion in: https://github.com/flutter/flutter/issues/131209.
### Tests
This PR adds new tests to cover the various use cases.
* dev/devicelab/bin/tasks/native_assets_ios.dart
* Runs an example app with native assets in all build modes, doing hot reload and hot restart in debug mode.
* dev/devicelab/bin/tasks/native_assets_ios_simulator.dart
* Runs an example app with native assets, doing hot reload and hot restart.
* packages/flutter_tools/test/integration.shard/native_assets_test.dart
* Runs (incl hot reload/hot restart), builds, builds frameworks for iOS, MacOS and flutter-tester.
* packages/flutter_tools/test/general.shard/build_system/targets/native_assets_test.dart
* Unit tests the new Target in the backend.
* packages/flutter_tools/test/general.shard/ios/native_assets_test.dart
* packages/flutter_tools/test/general.shard/macos/native_assets_test.dart
* Unit tests the native assets being packaged on a iOS/MacOS build.
It also extends various existing tests:
* dev/devicelab/bin/tasks/module_test_ios.dart
* Exercises the add2app scenario.
* packages/flutter_tools/test/general.shard/features_test.dart
* Unit test the new feature flag.
This PR includes the following changes. These changes only apply to iOS 17 physical devices.
| Command | Change Description | Changes to User Experience |
| ------------- | ------------- | ------------- |
| `flutter run --release` | Uses `devicectl` to install and launch application in release mode. | No change. |
| `flutter run` | Uses Xcode via automation scripting to run application in debug and profile mode. | Xcode will be opened in the background. Errors/crashes may be caught in Xcode and therefore may not show in terminal. |
| `flutter run --use-application-binary=xxxx` | Creates temporary empty Xcode project and use Xcode to run via automation scripting in debug and profile. | Xcode will be opened in the background. Errors/crashes may be caught in Xcode and therefore may not show in terminal. |
| `flutter install` | Uses `devicectl` to check installed apps, install app, uninstall app. | No change. |
| `flutter screenshot` | Will return error. | Will return error. |
Other changes include:
* Using `devicectl` to get information about the device
* Using `idevicesyslog` and Dart VM logging for device logs
Note:
Xcode automation scripting (used in `flutter run` for debug and profile) does not work in a headless (without a UI) interface. No known workaround.
Fixes https://github.com/flutter/flutter/issues/128827, https://github.com/flutter/flutter/issues/128531.
* Add Linux unit tests to plugin template
Adds an example native unit test to the plugin template for Linux,
matching the structure we use for our 1P plugin unit tests. Once these
have been added for all platforms+languages, they will be documented on
a new plugin development page to explain their use.
While ideally we would adjust the engine APIs first to allow for testing
the method call handler directly, it's unclear when we will have time
for that work, and for a complex plugin most of the testing wouldn't be
at that layer anyway, so having the structure in place with the
limitations documented is still a significant improvement over having
nothing in the template.
Part of https://github.com/flutter/flutter/issues/82458
* Add creation test
* Add integration tests
* Missing newlines
* test owner
* Typo
* Add Windows unit tests to plugin template
Adds an example native unit test to the plugin template for Windows,
matching the format we use for our 1P plugin example app unit tests.
Once these have been added for all platforms+languages, they will be
documented on a new plugin development page to explain their use.
Since we don't appear to be running our current plugin e2e tests for
Windows, this adds a new configuration to run them. I haven't
`led`-tested this, so it may not work, but this will give a starting
point for getting them running.
Part of https://github.com/flutter/flutter/issues/82458
* Minor fix
* Add test owner
* Fix typo
* Fix test feature flag
* Add an integration test to plugin template example
Dart unit tests don't exercise host-side plugin code at all, so the
example tests in the plugin template currently have very little
meaningful coverage. This adds an integration test to the example app
when creating a plugin, so that there's an example of how to actually
test that a complete round-trip plugin call works.
This is done as a separate template that's currently only used by the
plugin template because I don't know what a good example for a
non-plugin case would be that isn't largely just a duplicate of the
widget tests. However, the integration test pre-includes conditionals
around the parts that are plugin-specific so that it can more easily be
expanded to other use cases later (e.g., in
https://github.com/flutter/flutter/issues/68818).
Part of https://github.com/flutter/flutter/issues/82458
* Add integration test to expected dependencies of a plugin app
* Test fixes
* Make an explicit test case
* Building shared C source code as part of the native build for platforms Android, iOS, Linux desktop, MacOS desktop, and Windows desktop.
* Sample code doing a synchronous FFI call.
* Sample code doing a long running synchronous FFI call on a helper isolate.
* Use of `package:ffigen` to generate the bindings.
