Hi, I'm interested in adding support for hot reload and debugging, but I don't know enough about flutter/dart ecosystem. Would implementing https://github.com/flutter/flutter/issues/5043 solve the problem or is it more complicated?
Something like flutter connect http://127.0.0.1:49278/ to completely bypass device detection, etc.
Did some research on this. Not sure if it will be useful to anyone
I added fake device and hardcoded executable path and Uri on both sides. flutter run would then launch the .app and correctly perform the 'r' reload. 'R' reload did not work.
full reload did not work because it is not handled in the embedder: https://github.com/flutter/engine/blob/master/shell/platform/embedder/platform_view_embedder.cc#L53. I could make it work by copying some code from the ios platform view. This made flutter run + R work.
VSCode extension uses daemon, which somehow performs hot reload and restart differently than the run command. Nor debugging nor reloading would work. Something about invalid UTF8 would appear when trying to reload.
I haven't looked at reload support yet, so I don't have any extra insight into what all is necessary. I think we'll need to discuss with Flutter developers how reloading should work in the embedding model though (e.g., it might make sense for it to be exposed as an embedding API). At a high level, I don't think we want people to have to launch applications with flutter run to get tooling support.
Thanks for the answer. I got it to work somehow. Perhaps by switching to flutter's master branch. For anyone interested these are the steps required:
[CommandLine.arguments[0], "--observatory-port=50300", "--start-paused"]I think I could improve the fork and prepare it for merge:
hi @szotp I got this error while using that hacks
NoSuchMethodError: Class 'AppDomain' has no instance method 'startApp' with matching arguments.
Receiver: Instance of 'AppDomain'
Tried calling: startApp(Instance of 'DesktopDevice', "/Users/wizard/Desktop/DEV/flutter-desktop-embedding/example_flutter", "lib/main.dart", null, Instance of 'DebuggingOptions', true, applicationBinary: null, dillOutputPath: null, ipv6: false, packagesFilePath: null, projectRootPath: null, trackWidgetCreation: false)
Found: startApp(Device, String, String, String, DebuggingOptions, bool, {String applicationBinary, bool trackWidgetCreation, String projectRootPath, String packagesFilePath, bool ipv6}) => Future<AppInstance>
Exited (1)
Now that attach mode has been added to Dart Code, adding hot reload should be doable without any hackery since it's exposed via the observatory's reloadSources command. Assuming that works as well as the daemon reloads (I haven't tested yet) it would just be a case of adding a Dart Code command to invoke it.
With IntelliJ I was able to attach the debugger using the "Dart Remote Debug" run configuration. However it looks like hot reload isn't supported yet when attaching in this way.
There is an open issue to implement this. See: https://github.com/flutter/flutter-intellij/issues/2250
Based on recent discussion in a Dart Code issue, hot reload via the observatory relies on a hook that's registered by flutter-tools, so just attaching to a desktop process won't allow hot reload after all.
It looks like we'll probably need either some kind of hook in the Flutter tools, or a desktop runner that provides the same functionality.
Is there a good news?
No, see my last comment.
I consider this a strong selling point for developers. Hot reload is frigging awesome!
I think this issue can be closed because hot reload have been implemented in flutter attach already.
The reason it's still open is that the current instructions still use the device-id hack rather than something supported. Most of the necessary work to move away from that is done now, but there's a bit more needed before the VS Code workflow that's currently documented can switch.
Moved to https://github.com/flutter/flutter/issues/30707 (solving the devices issues for run would address the attach case as well, so that issue covers both).
(Debugging.md will continue to be updated as the need for special handling changes.)
Most helpful comment
The reason it's still open is that the current instructions still use the
device-idhack rather than something supported. Most of the necessary work to move away from that is done now, but there's a bit more needed before the VS Code workflow that's currently documented can switch.