Start DevTools server and pass address to run - #5176

I would start it when the user first runs an app. You can use ApplicationManager.getApplication().executeOnPooledThread() to move it off the EDT. Look at how we use executeOnPooledThread() for inspiration. You'd probably want to move the remainder of the launch code onto the pooled thread as well.

You'd probably want to move the remainder of the launch code onto the pooled thread as well.

Okay, this is the part I was worried about, wasn't sure if it would be okay to move a bunch of launch code into a thread. But I'll try and see if this is reasonable.

I would start it when the user first runs an app. You can use ApplicationManager.getApplication().executeOnPooledThread() to move it off the EDT.

I'd be worried about a race here between DevTools being spun up and the url being passed to flutter tools on run and attach. What if DevTools takes longer to start than the Flutter app? Then the devtools server uri missed the train to be passed into flutter tools on run or attach, and flutter tools may start up a different server because the uri is null when flutter tools looks for it. Seems like we'd have to wait for DevTools to start before we can run the flutter app.

The time to do this should be minimal if we are just pulling from pub, and I would think if the CLI workflow awaits DevTools start, then it would be fine to do this from IDEs as well. See this logic here for some checks I added in devtools_launcher.dart to use an already activated package if available and only attempt pub global activate every 12 hrs.

Seems like we'd have to wait for DevTools to start before we can run the flutter app.

Yes, that's a reasonable concern. I think if I move all/most of the app running code into a non-EDT thread, then it won't feel as clunky to have the app waiting for DevTools to start, particularly if it doesn't take too long. Good to know the CLI is waiting too.

I think I'm actually still starting the project DevTools server from pub global activate + pub global run directly instead of through a daemon, and I was planning to change to the latter method since the daemon DevTools should be the latest version now too. Sounds like this way may be a little faster since it'll skip activate a lot of the time.

The pub global activate step is probably fine to execute on project load while running the server should be avoided.
We should avoid a race condition by only launching flutter tools once devtools is running. That can be accomplished while keeping the work off the main thread.

Can we accept a 1-2 second delay in the start of running an application? (the first time someone runs their app on the project only) From running this a few times on my workbench system, this seems to be the time required to do the pub global run devtools part.

If this is an acceptable delay, we could keep it running on the UI thread for now, and I would move pub global activate to run once at project open (or maybe every 24 hours if a project is open for a long time, something like that). I'm looking into whether there are alternative APIs we could use to be able to run asynchronously, but if this is possible, it'll require a larger change anyway.

For this change I also need to enhance our versioning checks to distinguish between dev release versions too (e.g. 1.26.0-8.0.pre vs. 1.26.0-11.0.pre)

IMO that delay is acceptable. It already happens on the CLI, and if it is only paid on the first start, then I don't think the user will really feel the cost.

You can't have that long a delay on the UI thread. IntelliJ throws an error if something takes too long.