Make ephemeral platform directories editable by default in add-to-app

@jmagman

The content of the .android and .ios directories cannot be modified since flutter pub get or any
build command will override the file changes.

This breaks flutter run on Android if a dependency requires to modify AndroidManifest.xml or build.gradle.
For example, adding webview to a module.

My suggestion is to make these directories editable, so there's no this one-off special case.

@jmagman any thoughts?

@xster

I think most of the discussion about this happened in #32989, you're suggesting we do @xster's number 3.

Fully materialize those folders and expect users to potentially edit them and source control them as well

We decided to keep it ephemeral (number 1), and the make-host-app-editable command was deprecated. There's lots of comments about "gotchas" in that issue.

See also flutter/website#7774

@GaryQian

I think the issue about out-of-date files is fixed by the migration tool that @GaryQian is working on.

I’m currently only able to test a webview in add-to-app if I modify the tool to avoid regenerating the .android directory. cc @xster

From #32989 (comment), we could make the module concept way smaller, and any changes outside the Flutter module and dependencies and would not be in the module.

Alternatively we could go the opposite way. If we get rid of the ephemeral concept, is there any point to actually having modules? What if we just make any flutter created app "add-to-app"-able embeddable? I actually did this for iOS for Options B and C in PR #70647 but it's not documented anywhere. It wouldn't be that hard (I think) to also support Option A. Maybe modules are adding something more for Android though...

My vote is moving a bit more towards http://flutter.dev/go/everything-builds-from-a-module. With Emmanuel's case being solved by wrapping the module you're trying to test in a blank wrapper Android app (with the appropriate manifest change).

Doing the complete opposite works too. But conceptually, someone (the tools team, the platform team, the user) has to make a mental separation between the things in the app that takes effect when embedded (such as dependencies in the gradle files) and things that are ignored when embedded (such as everything under https://developer.android.com/guide/topics/manifest/application-element). I think it's preferable to make this split explicit rather than implicit.

I’d like to use hot reload, or local engine with flutter run.

Currently this flow breaks as soon as you bring a plugin that requires manual changes to build.Gradle or an Android Manifest.

@xster

My vote is moving a bit more towards http://flutter.dev/go/everything-builds-from-a-module. With Emmanuel's case being solved by wrapping the module you're trying to test in a blank wrapper Android app (with the appropriate manifest change).

Just to copy #32989 (comment) @xster's previous thoughts here:

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_module type 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.

#32989 was closed because we settled on the current ephemeral model, with the user pretty easily able to make their own little wrapper project (just a new vanilla iOS or Android app, and follow the add-to-app instructions), where they could change whatever Gradle/configs/CocoaPods settings they wanted. Instead of changing the ephemerality we could just document that better, or make the suggested flutter create-wrapper-project/flutter create -t wrapper command do it for them.

Right. The need is a valid one. We just didn't hear it often enough to make it more convenient. We could make it more convenient in a tool. Otherwise, for the time being, you can manually create a vanilla Android app that consumes the module. You can do any gradle edits needed there. We could create that app through a tool. Your idea about operating against the add-to-app wrapper app with the Flutter tool is an interesting idea too. Flutter running an Android app rather than a Flutter app.

Another thought is to get rid of the ephemeral directories, and instead adopt a model like plugins and have an example directory containing non-ephemeral ios and android (plus future platform) directories, and maybe even light-weight host apps that do nothing but consume the module. Then, because it's in example, it would be explicit that this isn't your production code and you shouldn't ship it, but just like plugin examples you can modify it and check it into source control. And then tooling could be updated to handle flutter run from the top-level module directory to run the ios or android example, or flutter attach from the light-weight example host app.

that SGTM too. If we make it clear that example is explicitly orphaned the moment it's created. Flutter running the parent directory seems a bit magical though, unless we make it a global pattern somehow

I like the idea of an example directory similar to plugins. On Android, this could mean that the template generates examples using FlutterFragment, FlutterActivity + Native activities, FlutterView with other native activities, shared Flutter engine, etc...

This could help with:

integration tests
troubleshooting issues e.g. plugins being used in one of these scenarios or a new API level.

@blasten

@blasten @jmagman Hi, issue related to #104494, can I get current status about this? I need to configure miSdk and compileSdkVersion, targetSdkVersion of aar module, but currently it's not possible.. Are there any method to do this..?

@xster

@xster According to this document Integrate a Flutter module into your iOS project, using option A - Embed with CocoaPods and the Flutter SDK:

we have to modify the App's Podfile with the following

load File.join(flutter_application_path, '.ios', 'Flutter', 'podhelper.rb')

But podhelper.rb is deep inside .ios folder - the folder that doesn't exist 😀.

CI cloning repository from scratch needs to "trigger" it a bit, so the .ios and .android folders are created. e.g.:

cd flutter_module
flutter pub get
[rest of CI]

The same issue may be faced by other developers working in the same codebase, but specialising in iOS, not Flutter. Even if they have the .ios folder, because it was generated before, it content may be out of date.

@chris-rutkowski

@chris-rutkowski There is a note under https://docs.flutter.dev/development/add-to-app/ios/project-setup#module-organization

Do not source control the .ios/ directory since it’s autogenerated. Before building the module on a new machine, run flutter pub get in the my_flutter directory first to regenerate the .ios/ directory before building iOS project using the Flutter module.

Navigation Menu

Repository navigation

Make ephemeral platform directories editable by default in add-to-app #98077

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Make ephemeral platform directories editable by default in add-to-app #98077

Description

Activity

jmagman commented on Feb 9, 2022

blasten commented on Feb 9, 2022

jmagman commented on Feb 9, 2022

xster commented on Feb 9, 2022

blasten commented on Feb 9, 2022

jmagman commented on Feb 9, 2022

xster commented on Feb 9, 2022

jmagman commented on Feb 10, 2022

xster commented on Feb 10, 2022

blasten commented on Feb 10, 2022

wangmir commented on Jun 9, 2022

2 remaining items

chris-rutkowski commented on Nov 3, 2022

jmagman commented on Nov 3, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions