-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Update device filtering and introduce isConnected and connectionInterface #121359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update device filtering and introduce isConnected and connectionInterface #121359
Conversation
…face, update device filtering to use a class, update some function names
| this.mustBeSupportedByFlutter = false, | ||
| this.mustBeSupportedForProject = false, | ||
| this.mustBeSupportedForAll = false, | ||
| }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In previous PR, @jmagman asked:
How about includeDevicesSupportedByFlutter, includeDevicesSupportedByProject, includeUnsupportedDevices or similar.
To which I responded:
Yeah I had a hard time picking variable names for this. So by default (if you don't set anything) it will include all devices and none will be filtered out. So I thought that using the word include was a bit confusing. For example, if everything is already included, what does includeDevicesSupportedByFlutter really mean? It really means exclude everything that's not supported by flutter. What do you think of excludeDevicesNotSupportedByFlutter, excludeDevicesNotSupportedByProject, excludeDevicesNotSupportedByAll?
Do the exclude names make more sense / more inline with our naming conventions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll defer to @jmagman on this one, I'm horrible at naming :)
| class DeviceDiscoverySupportFilter { | ||
| DeviceDiscoverySupportFilter({ | ||
| required this.flutterProject, | ||
| this.mustBeSupportedByFlutter = false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this ever false? It looks like it's always true in #121262.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, it's unnecessary, removed it.
| /// If [mustBeSupportedForAll] is true, only devices supported by Flutter, | ||
| /// supported for the provided [flutterProject], and supported for | ||
| /// `--device all` will be included. | ||
| class DeviceDiscoverySupportFilter { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These filter classes seem like they push a lot up to the call sites. It seems confusing that you could do excludeDevicesNotSupportedByProject: false, excludeDevicesNotSupportedByFlutter: true, what would you get? It's also not enforcing that flutterProject is nonnull if excludeDevicesNotSupportedByProject is true. I think we can be more defensive about not letting the caller shoot themselves in the foot?
christopherfujino
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM, though I'll leave final approval to Jenn
jmagman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This change introduces to devices the concept of
isConnectedandconnectionInterface(DeviceConnectionInterface). As it stands in this PR, all devices will haveisConnectedbe true andconnectionInterfacebeDeviceConnectionInterface.attached.This PR also changed the way target devices are filtered so it's more flexible to use and encapsulated. To accommodate these changes, I also updated some function names and made a getter into a function.
Lastly, this PR also fixes a potential race situation related to populating the device cache.
No user experience is changed in this PR.
Part 1 in breakdown of #121262.
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.