In the previous post, I’ve introduced a way to add Flutter to your existing project using git submodules — the reason why we’ve used this approach in our Groupon application is that there was no official approach from Flutter team.

Thankfully Flutter team introduced flutter attach approach. In this article, I won’t explain the integration steps as the documentation is self-explanatory — instead, I will point out the pros and cons of using this approach versus the submodule solution.

Disclaimer: I’ve tested flutter attach approach on my project — your native project might be more or less complex than mine and you might have more or fewer issues with using flutter attach.

Pros

Easy Integration

Flutter team made sure that integration is straightforward — you basically change five lines in settings.gradle file and one in build.gradle .

No git submodules

Next positive aspect is that you do not need to use git submodules — you just need to have your native project [1] and a Flutter project [2] in the same root folder.

└── MyProjects

├── AndroidApplication [1]

├── FlutterApplication [2]

│ └── .android [3]

└── Flutter

No renaming

You don’t need to rename your project’s files and folder.

Build time

Flutter’s hot reload and restart can really improve the speed of development, Unfortunately, it does no speed up rebuild of the entire application. If you have a large native project, the native part still needs to be built.

With flutter attach approach you can build and test the Flutter part separately. During the development process, you will be pointing to a small Android folder .android [3] — just execute flutter run from FlutterApplication [2] .

Only when trying to test it together with your native code you would need to compile the entire thing. Even with long native compilation, you do not need to worry as you only need to do it once — after that, you just use hot restart and reload.

Cons

Dependency Injection

When you are integrating Flutter into an existing application you want to reuse some code and data that your application already have.

An example would be access-tokens and user data that your native application already stored.

The way how you pass the data is to inject it into your Activity and then pass it to Flutter via BasicMessageChannel or MethodChannel .

With flutter attach approach the majority of the time you will be using Android project from .android [3] folder as the build time is much shorter.

In that case, you would need to prepare mocks/stubs for all the data that you would like to exchange between Flutter and the native code.

IDE integration

The beauty of hot reload is to write some code, press save and see the updated application on your screen after a second.

When running your native code together with Flutter code, you would need to attach via the console. At this point, Flutter won’t detect changes in code automatically.

To trigger hot restart/reload you need to press r (hot reload) or R (hot restart) on your console every time you want the code to be updated.

This is definitely not a deal breaker but for someone who got used to automagical code reload, it might be a tad annoying.

“VM snapshot must be valid”

One issue I’ve struggled with was a crash when starting FlutterActivity or creating Flutter view:

[ERROR:flutter/runtime/dart_vm.cc(278)] VM snapshot must be valid.

[FATAL:flutter/shell/common/shell.cc(209)] Check failed: vm. Must be able

It comes from Flutter engine and happens when the Dart Virtual Machine snapshot was not initialized or is invalid.

For me, this issue came at random — on one machine I was not able to run successfully .android project, on another machine, there was no problem with it.

When trying this approach on Groupon Merchant project to see if that’s a feasible option for us, unless I performed full project clean every time, I would encounter the same issue.