Repository navigation
Add template for plugin projects. - #9076
Conversation
Plugin projects are created by running `flutter create --plugin <name>`. By default, an example app is also created in the plugin project. This can be disabled by adding `--no-example`. The example app is created using the normal 'create' template, which has been modified to allow for conditional plugin code. Modified the android package name to match package naming conventions (all lower-case, and must match the directory name).
|
Some initial thoughts:
Perhaps use
What about not having a |
|
Lately I've been putting "Plugin" at the end of the plugin class names on the native side, to make them more distinguishable from the native classes that plugins often wrap, e.g. FirebaseDatabasePlugin vs FirebaseDatabase, ImagePickerPlugin vs ImagePicker There are other available workarounds such as class prefixing (on iOS) and namespacing (on Android) but having "Plugin" the name makes it more clear what the class does, I think. |
|
Removed the --example flag, and added a Plugin suffix to the native classes. I prefer --plugin over --plugin-project since it's shorter, and what else would we be creating? --template= sounds nice, but there are really two templates involved in creating a plugin, 'plugin' and 'create' (for the example app). |
Yes, but it makes things a bit more explicit. Instead of slightly altering the mode for |
| super.initState(); | ||
| {{pluginDartClass}}.platformVersion.then((String platformVersion) { | ||
| setState(() { | ||
| _platformVersion = platformVersion; |
There was a problem hiding this comment.
This code is buggy. If the _MyHomePageState state has been disposed before the future completes, it'll assert.
Is there a way to cancel a pending platform request? We should do so in the state's dispose() function so that it doesn't unexpectedly complete here in that case.
There was a problem hiding this comment.
There is no way to cancel. Added mounted check in #9458.
| children: [ | ||
| new Text('Running on: $_platformVersion\n'), | ||
| new Text( | ||
| 'Button tapped $_counter time${ _counter == 1 ? '' : 's' }.'), |
There was a problem hiding this comment.
this doesn't match the style guide
| ), | ||
| body: new Center( | ||
| {{#withPluginHook}} | ||
| child: new Column( |
There was a problem hiding this comment.
If we're going to add Column here we need to add comments explaining what's going on, especially if we add mainAxisSize as well.
I'm worried about having multiple versions of this template. We have four now (normal, driver, plugin, driver+plugin). We have micromanaged the creation of this template based on the usability studies; the more versions we have the more studies we're going to need to actually test them all. This doesn't scale.
There was a problem hiding this comment.
I'm not sure what to do about the 'multiple versions' part. We deliberately did the conditional approach, as the alternative would have been to fork ALL ~60 files in /templates/create/ into /templates/plugin/ which would have been a lot less scalable.
Do you have a better idea than the conditional approach?
There was a problem hiding this comment.
My 0.02 is that we should have two templates, a normal app project and a plugin project. The normal project should include driver support, example unit tests, ... - things we think are best practice and that we'd like to lead users towards.
There was a problem hiding this comment.
We already have that. This is for the example app inside a plugin (the /example/ dir)
There was a problem hiding this comment.
Ah ok. I thought this was discussing the flutter create case, where we do have a matrix of options.
There was a problem hiding this comment.
What I mean is that right now the main.dart.tmpl file is effectively forked into four versions:
- the one generated by
flutter create - the one generated by
flutter create --driveror some such - the one generated by
flutter create --pluginor some such - the one hypothetically generated by
flutter create --plugin --driveror some such (I suspect we don't ever generate this today, I haven't checked)
We have carefully crafted the one generated by flutter create based on usability feedback to optimise for the first hour experience. The other versions haven't been tested and I'm worried about what will happen as the needs for these various versions diverge.
There was a problem hiding this comment.
To clarify, I'm not suggesting forking more. That wouldn't address my concerns (it would make in fact them worse, for the reasons discussed above by @mit-mit). My concerns are not concrete, they are merely fear for the future. :-)
There was a problem hiding this comment.
Take a look at the #9458 PR i just sent. I think the more clear separation in main.dart makes it a little more manageable.
6 participants
Plugin projects are created by running
flutter create --plugin <name>.By default, an example app is also created in the plugin project. This can be disabled by adding
--no-example. The example app is created using the normal 'create' template, which has been modified to allow for conditional plugin code.Modified the android package name to match package naming conventions (all lower-case, and must match the directory name).