Repository navigation
Settle on the module project's host project pattern: in flutter tools vs ephemeral vs materialized #32989
Description
Currently, when we flutter create -t module, we put a platform host project as .android and .ios in the flutter project.
However, the user is never expected to interact with that ephemeral, generated project. Moving forward, we can either
- Keep the ephemeral .ios, .android folders
- Remove those project and just let the platform host projects be in the flutter_tools. Since the consumers of those platform host projects are either flutter_tools or scripts such as include_flutter.groovy / xcode_backend.sh embed, the tools can automatically connect the dots.
- Fully materialize those folders and expect users to potentially edit them and source control them as well
The disadvantage of 2 is potentially missing very legitimate reasons why users would want to modify those projects. For instance, a user, in the future, wants to flutter build aar a flutter module but also needs to do it with a specific minSdkVersion or a java version. Since there are no longer any gradle files in the flutter module directory, it's no longe possible.
The disadvantage of 3 is leaving more potentially confusing and messy things for users to wrangle with even though the users likely won't want to ever touch them. And once they're materialized, they become very difficult to upgrade if we modify those host projects for future necessities.
I'm currently leaning towards leaving everything as 1.
If we discover in the future that there is indeed no reason for users to modify them, we can still modify the tools such that they're ignored and migrate everything into the tools. Those directories are ephemeral and never source controlled anyway.
If we discover in the future that users do need to tweak them, the migration step is simply to rename .android, .ios to android, ios and source control them. Flutter tools can always look out for android/ios first and .android/.ios second.
If we go with 1, that directory definitely needs a README.md to prevent people from accidentally losing code such as in #28135
Activity
xster commentedon May 19, 2019
cc @jonahwilliams @matthew-carroll, we all talked about this
@mit-mit who may have additional original design insights
xster commentedon May 19, 2019
Related: #23123 would be one way to make the migration from 1 to 3
matthew-carroll commentedon May 20, 2019
There is also the option that some number of project configurations be exposed via pubspec extensions per platform. I started down that path last year but gave it up because it seemed like eventually we'd have to expose everything. But, it's still technically an option. Also, if we ended up agreeing that this option is no good because it would require us to support all project configurations, then it seems equally likely that 1 and 2 are untenable, as well.
xster commentedon May 20, 2019
Right, configuration by abstraction via pubspec, flutter tools argument or some other flutter side API are likely all subcomponents of option 2. By not letting users touch the platform build system for the module, we translate some for them. Works for 1-2 things but not for 10-20 things. This is also against the backdrop that the user is likely to try to edit everything for an outer project but may not necessarily want to do so for an inner module project.
jonahwilliams commentedon May 20, 2019
I think that 1. and 2. essentially have the same drawback: If the user needs to "eject" because we have forgotten to configure something, we can't get them back into the system, and they become 3. The advantage of the ephemeral app is that we can eject, otherwise it is the same as 1.
xster commentedon May 24, 2019
This line is confusing. 1 is ephemeral.
Also to note as Matt pointed out, there's a bunch of java files presently in the .android folder under the io.flutter.facade namespace that's from an older solution which we should get rid of because it was highly confusing when I saw them and tried to understand what they do.
xster commentedon Jun 6, 2019
Is #22102 an argument for 3? Would those XML definitions come from flutter tools or from the wrapper/host project?
xster commentedon Jun 7, 2019
@blasten tentatively assigning it to you. We chatted about this. To put it on your list of things to think about at a high level while you perform the various gradle refactors.
rahulgurnani commentedon Jun 10, 2019
I wish to share my experiences with adding flutter to an existing andorid app,
Recently, I had to move my project androidx, so I ended up editing files in .android directory and checking them in.
Also, the initial setup process for existing apps is a bit long. Having a tool like the one described in #23123 would be useful.
xster commentedon Jul 17, 2019
@kangwang1988 @SupSaiYaJin, what do you guys think? Do you have any examples of why you might need to modify things in .android/.ios folders of the module and source control them?
xster commentedon Jul 18, 2019
p.s. whatever we do here should ideally be forward looking enough that it makes sense for other platforms as well
xster commentedon Jul 24, 2019
If we go for 1 + make-host-app-editable escape hatch, we have to make sure that the escape hatch works.
Currently there are some frictions on Android. i.e. the editable templates doesn't have any include_flutter.groovy files and using the .android/include_flutter.groovy file ends up with
Somewhat expected since include_flutter.groovy specifically points to
gradle.project(':flutter').projectDir = new File(flutterProjectRoot, '.android/Flutter')Just renaming .android into android actually works better once the various .android references are renamed.
IchordeDionysos commentedon Aug 7, 2019
May I add some additional experience here we had developing with a hybrid solution (native iOS/Android and some parts in Flutter).
It's sometimes super useful for us to build some screens directly from the Flutter module and run the module as if it was a standalone/Flutter-only app. This has lots of advantages compared to integrating the screen first in the iOS/Android apps and only then being able to develop that one screen in Flutter. First, this speeds up development time for us a lot as our Android/iOS devs only have to pull in the submodule for Flutter and build their project and second our Flutter devs don't have to worry about the actual integration in the iOS/Android apps. Also, the build process with gradle/Xcode build for our Flutter devs is way faster having to compile only Flutter.
To achieve this properly we have to modify the .ios and .android folders putting in config files for Firebase or stuff like that.
This creates some problems explained in here #37689.
And after reading this issue I totally understand why.
jonahwilliams commentedon Aug 7, 2019
This is a big issue with the autogenerated projects: As soon as you need to customize one tiny little thing you need to "eject".
If we want to support an "ephemeral/module/create" shared project, we'll need to be very thoughtful in how we expose configuration like the Activity class, firebase config, signing keys. Otherwise we'll just recreate the existing module problems
xster commentedon Aug 8, 2019
Thanks for sharing. We really want more data points from developers.
I think I understand the desired effect which totally makes sense. I'd argue though that it's probably a modularity problem from our side, in the sense that rather than trying to make it easier to tack on more and more responsibilities to the module, we should strip down the modules even more and make it easier to append modular components on top of the modules.
Currently, the modules have this weird dual role (#32992) where it both acts as a library but also an app project that lets you launch it with minimal bells and whistles.
Instead, the module should just be an unlaunchable module and the latter role should be accomplished by a
flutter create-wrapper-project my_test_launcher --from-module ../my_flutter_moduletype command.In other words, Java classes, firebase configs, keys, AndroidManifest tweaks, gradle tweaks should all not be in the module. The module just makes a platform artifact from Dart inputs. Everything else are in platform wrapper projects whether it's a normal full-Flutter-app case, whether it's in your own existing app or in these 'test wrappers' you're creating to quickly bootstrap modules.
By contrast though, #37689 (which you also pointed to) is a valid gradle tweak that seems to need to be in the module.
Hixie commentedon Oct 7, 2019
We should make sure we define the "owner" of every file involved.
If the owner is the user, then we can read the file but never write to it (except as part of a "migration" step, a la
dartfix).If the owner is us (the tool), then we can write to the file at any time and the user should expect any change they make to be destroyed arbitrarily.
IMHO we should never be in a place where a file is co-owned, i.e. where we both make changes and expect the user to make changes to the same file.
blasten commentedon Oct 7, 2019
great point. I like this mental model. It's very simple to understand/communicate.
[-]Settle on the module project's host project pattern: in flutter tools vs ephemeral vs materialized[/-][+]Settle on the module project's host project pattern: in flutter tools vs ephemeral vs materialized [/+]IchordeDionysos commentedon Jan 23, 2020
Are there any updates on this?
We are currently considering to build the Flutter module for App-to-app in advance for every Flutter module version and then implement it as a framework without using Cocoapods.
Unfortunately, this is not easily possible if for example the minimum deployment target in the Podfile gets overridden.
jmagman commentedon Jan 23, 2020
@IchordeDionysos You are talking about not having control of the Podfile in the module, and then integrating with
flutter build ios-framework, right?IchordeDionysos commentedon Jan 23, 2020
Yes exactly :)
jmagman commentedon Jan 23, 2020
@IchordeDionysos Interesting point. I think this could be mitigated by #49378 since you should be able to override whatever Xcode build settings you want via environment variables, like
IPHONEOS_DEPLOYMENT_TARGET(though it doesn't work for this particular command).github-actions commentedon Aug 20, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.