Repository navigation
Update device discovery to take current project into consideration. #30724
Description
If I have an android and iOS device connected and I flutter run in a project with no ios/ directory, I should only run on the iOS device. Likewise, if I flutter run on a macOS host machine with no macos/ desktop folder, the desktop device should not compete with whatever else I have connected.
Activity
stuartmorgan-g commentedon Apr 8, 2019
Do IDEs actually do
flutter deviceschecks within the context of a project currently? It seems like this might require changes to each IDE's Flutter support.jonahwilliams commentedon Apr 8, 2019
Good point, cc @DanTup and @devoncarew, @DaveShuckerow for IDE considerations.
We could add a new state to a device, call it "active" when it is contained in a project that has the right
device/or.devicesupport. A device in the normal "available" state would show up in flutter devices, but couldn't be used toflutter run.DanTup commentedon Apr 8, 2019
In VS Code we run
flutter daemonto get a list of devices and updates when they connect/disconnect. We let the user select between them (and automatically select any newly-connected device).Then, when running an app, if there is no current device, we'll use
getEmulatorsto get a list of emulators (Android + iOS Simulator) and ask the user which one to launch (or if they want to create a new one), and then pass the selected devices ID toflutter run.If
flutter daemonfiltered the devices it presented based on the project type, things will probably just work?devoncarew commentedon Apr 8, 2019
For IntelliJ, we'll have one
flutter daemondevice lister running for the life of an IDE window. That window can correspond to several flutter projects.I don't think filtering devices by project work work for us here. I think perhaps good feedback on a
flutter runcould work instead? We could fail with an error message -no ios/ support enabled for project; to enable it, run 'flutter create --foo-bar ....jonahwilliams commentedon Apr 8, 2019
Longer-term, the problem we'd like to avoid here command-line users having to always manually specify a device id for Android/iOS users when desktop & web are stable. It sounds like for the IDE use cases, this isn't really an issue since the user has a UI to select the device type.
Another approach would be to treat the devices as normal, but in the event of an ambiguous flutter run from the command line, automatically filter out desktop and web devices.
DanTup commentedon Apr 8, 2019
Oops, I totally forgot that the daemon isn't started in the context of a project. It's the same for VS Code - we have one per-window, but a window can have multiple Flutter projects in it (eg. multi-root workspace).
I think there needs to be a way for editors to filter a list of (all) devices to only those applicable for any given project. What if
flutter daemon/deviceshad a platform associated with each device (ios,android,desktop,web) and there was a way for editors to tell which platforms a project is able to launch on (either as a command, or some simple logic - like the presence of platform-specific folders)? That way we can filter the list of devices when launching to those that are valid for the project being launched, andflutter runcan just do what it is today, but filtering the devices in the same way?jonahwilliams commentedon Apr 8, 2019
Each device does have a target platform associated with it already, but there is no generic API for "does this project support X device type". It sounds like this is the missing feature for the IDE and command line.
DanTup commentedon Apr 10, 2019
Yeah, something like that would be good. It'd be nice if we could filter the full list for a given project too, so if the check is expensive, rather than repeatedly checking each device, we can just ask "what device types can this project run on?" and then filter the list we have from the device daemon.
Hixie commentedon Apr 22, 2019
Long term, I would expect
flutter run -d localhoston a macOS box in a project with only anandroidfolder to create amacos/directory and run it on the local host.Similarly,
flutter run -d iphonein a project with only anandroidfolder but with an iphone attached should create aniosdirectory and run it on the phone.IMHO running
flutter runwith no-dshould "do the right thing" given the history of the user's behaviour on this project and the currently available devices. One of those options might be to launch in a browser or launch a desktop build, even if that's never happened before.stuartmorgan-g commentedon Apr 23, 2019
Given the way the IDE device management works, it seems like deciding what options to provide, whether to use a heuristic and if so which one, etc. would all be up to each front-end, in which case the functionality of querying which targets a platform is currently configured for would still be useful, as that would be a likely input into the decision.
DaveShuckerow commentedon Apr 23, 2019
If we want to have a consistent experience across IntellIJ/AS, VSCode and other editors, then we want the device discovery API to suggest all the platforms you could run your app on.
ie, if the canonical way of adding iOS support to your project and running on iOS became
flutter run -d iphone, then we want the discovery API to provide the IDE with-d iphoneas an option for run configurations.For IDE usability, I agree with Devon that simply providing an error message when a platform is requested but has not been set up is the most failure-proof.
For CLI usability, Jonah, I think we need to scale back the scope of the problem and only solve the case where there is a
flutter runcall with no specified device. In that case, we can look at the project configuration and the device list and figure out the right way to try to run the app.jonahwilliams commentedon Apr 23, 2019
I agree with the above - we can leave more specific UX to the frontends. We can solve the ambiguous flutter run from the command line here and add support for the query "what devices does this project support" later
github-actions commentedon Aug 30, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.