We might need to think about this experience when there may be multiple debug sessions in the IDE. For example I could launch my app on multiple devices at he same time, but we (presumably) only have one sidebar panel for each page.
VS Code's debug toolbar has a drop-down to select a debug session when there are multiple, and we can react to that - but I don't know if will be obvious enough if we use that (and it may be odd if the user triggers a breakpoint in one app - which changes the active debug session - and it automatically changes the embedded DevTools windows?)
VS Code's debug toolbar has a drop-down to select a debug session when there are multiple, and we can react to that - but I don't know if will be obvious enough if we use that (and it may be odd if the user triggers a breakpoint in one app - which changes the active debug session - and it automatically changes the embedded DevTools windows?)
Show more
This raises the question to me, should DevTools support debugging multiple app connections at the same time, with a similar app connection selector experience? If we were able to serialize the devtools state for later loading, we could restore data when a user is switching between app connections instead of destroying what they are currently looking at and connecting to a new app.
This would be non-trivial work, but could be worth considering. Another option is to assume that, if a user manually switches app connections, they are okay with their devtools state being changed as well. However for the breakpoint triggered case, I'm not sure what the best solution would be there. Maybe a little popup over their current tool that says "you are about to switch to another application - continue - do not switch".
This would be non-trivial work, but could be worth considering. Another option is to assume that, if a user manually switches app connections, they are okay with their devtools state being changed as well. However for the breakpoint triggered case, I'm not sure what the best solution would be there. Maybe a little popup over their current tool that says "you are about to switch to another application - continue - do not switch".
Show more
Yeah, that could work. So VS Code could tell DevTools whenever the active debug session changes, and DevTools can handle switching (or prompting the user, or whatever).
It might be useful for VS Code to provide DevTools with the debug session names because in the case of multiple devices these will likely have the device name in them. If a user is running their app on both Android and iOS, and chooses not to let DevTools switch (so that the embedded inspector is not showing the same debug session that VS Code has selected), having some visible label making that clear would be useful.
(right now, we don't actually have a way for VS Code to tell DevTools about a new debug session at all, because we'd open a new editor tab for it - so we'd need to define how we'd do this)
It might be useful for VS Code to provide DevTools with the debug session names because in the case of multiple devices these will likely have the device name in them. If a user is running their app on both Android and iOS, and chooses not to let DevTools switch (so that the embedded inspector is not showing the same debug session that VS Code has selected), having some visible label making that clear would be useful.
(right now, we don't actually have a way for VS Code to tell DevTools about a new debug session at all, because we'd open a new editor tab for it - so we'd need to define how we'd do this)
Show more
One big blocker here is how we'd support this if DevTools was started from Flutter tools, in which case it is tightly coupled to the app that Flutter tools launched with `flutter run`.
Show more
Isn't all of this only applicable when embedded in the IDE (in which case it would always be the IDEs standalone version)?
Show more
You're suggesting
