You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Let flutter attach survive past a single app session #2115
Since flutter/flutter#44637, the Flutter tools CLI now can attach to Android without additional parameters (you probably don't have to do #1189 anymore) and also stays always alive waiting for more connections if it ever disconnects. Here's a small video demonstrating it
I don't think keeping the session alive is enough - currently VS Code can't handle disconnecting from one VM service and connecting to another (and I'm not sure the JSON protocol covers this). There's a lot of state in the debugger, like tracking isolates, variables, etc., and some assumptions that a debug session will only ever have one VM service (for example we send this from the debug adapter back to the editor, and use it for things like spawning DevTools - we'd need to ensure the new VM service URI propagates throughout as well as handling in the debug adapter).
Another way could be to handle it in the editor entirely (this means it wouldn't use any of the new work in attach, but rather the IDE would just re-run attach when the initial session terminates from a non-user action, waiting for it to start again). This would be a whole new debug session, so it wouldn't have any of those complications. Not sure how the UX would work out though.
Is someone working on this for IntelliJ? (cc @devoncarew). It'd make sense to try and align the implementations (esp. if it's going to mean daemon protocol changes).
I don't think that will work here, since we don't know when the Android app is launched from VS Code (Android Studio has the advantage of handling both Android and Flutter).
@xster@devoncarew I'm wondering how much value there is in this. Since we can't detect the launch as AS does (because we're not launching the Android app), I think the best we can do here is if you attach to an existing Android app, when it disconnects, we go into a "Reconnecting..." state with a progress notification (and a cancel button) that just re-runs the Debug: Attach to Flutter on Device command.
That's not difficult to do, though it is only saving you from re-running that command once the app is running again (which could just be an F5 press if you've set up launch.json to attach). Do you think it's worth doing?
Sorry for the late answer. I didn't configure all my notification emails from different repos to the same email address :S
Your work-around sounds reasonable and useful.
though it is only saving you from re-running that command once the app is running again (which could just be an F5 press if you've set up launch.json to attach)
Did you mean re-binding F5 to the Debug: Attach to Flutter on device command?
I don't see why not. I'll do some testing and ensure it all works as easily as I've made out above, and then open a PR with some changes to that page (I'm OOO next week so it might be after).
Activity
DanTup commentedon Nov 20, 2019
I don't think keeping the session alive is enough - currently VS Code can't handle disconnecting from one VM service and connecting to another (and I'm not sure the JSON protocol covers this). There's a lot of state in the debugger, like tracking isolates, variables, etc., and some assumptions that a debug session will only ever have one VM service (for example we send this from the debug adapter back to the editor, and use it for things like spawning DevTools - we'd need to ensure the new VM service URI propagates throughout as well as handling in the debug adapter).
Another way could be to handle it in the editor entirely (this means it wouldn't use any of the new work in
attach, but rather the IDE would just re-run attach when the initial session terminates from a non-user action, waiting for it to start again). This would be a whole new debug session, so it wouldn't have any of those complications. Not sure how the UX would work out though.Is someone working on this for IntelliJ? (cc @devoncarew). It'd make sense to try and align the implementations (esp. if it's going to mean daemon protocol changes).
xster commentedon Nov 22, 2019
cc @stevemessick who is doing the actual work on IntelliJ (though I don't exactly know the details of how it works)
xster commentedon Dec 17, 2019
FYI @stevemessick went with this approach (flutter/flutter-intellij#4200) which is an interesting way of achieving the same goal.
DanTup commentedon Dec 17, 2019
I don't think that will work here, since we don't know when the Android app is launched from VS Code (Android Studio has the advantage of handling both Android and Flutter).
DanTup commentedon Aug 6, 2020
@xster @devoncarew I'm wondering how much value there is in this. Since we can't detect the launch as AS does (because we're not launching the Android app), I think the best we can do here is if you attach to an existing Android app, when it disconnects, we go into a "Reconnecting..." state with a progress notification (and a cancel button) that just re-runs the Debug: Attach to Flutter on Device command.
That's not difficult to do, though it is only saving you from re-running that command once the app is running again (which could just be an
F5press if you've set uplaunch.jsonto attach). Do you think it's worth doing?xster commentedon Aug 12, 2020
Sorry for the late answer. I didn't configure all my notification emails from different repos to the same email address :S
Your work-around sounds reasonable and useful.
Did you mean re-binding F5 to the
Debug: Attach to Flutter on devicecommand?DanTup commentedon Aug 12, 2020
Even easier.. All that command does is start a debug session with a hard-coded launch config:
Dart-Code/src/extension/commands/debug.ts
Lines 243 to 249 in b2244fe
If your
launch.jsonis the same as that, pressingF5will do the same thing!xster commentedon Aug 12, 2020
That's what I meant by 'binding'. e.g. the users have to manually tweak their launch.json file in their modules right? Could be something we document in https://flutter.dev/docs/development/add-to-app/debugging.
DanTup commentedon Aug 13, 2020
Ah, I thought you meant rebinding the F5 key specifically to that command (which would be a little weird 🙂).
I don't see why not. I'll do some testing and ensure it all works as easily as I've made out above, and then open a PR with some changes to that page (I'm OOO next week so it might be after).
DanTup commentedon Aug 24, 2020
I've opened a PR with some changes for review on the site here:
flutter/website#4522
I'll close this as I think this is a reasonable solution, but do shout if you think there's more we can do!