-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Update device selection to wait for wireless devices to load #122932
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 selection to wait for wireless devices to load #122932
Conversation
| } | ||
|
|
||
| @visibleForTesting | ||
| class MacOSTargetDevices extends TargetDevices { |
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 name seems like it's deploying a macOS desktop app?
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 changed it to TargetDevicesWithExtendedWirelessDeviceDiscovery. I changed the one in the devices command too to DevicesCommandOutputWithExtendedWirelessDeviceDiscovery. Let me know if you think that's better
| final RegExp pattern = RegExp(r'\d+$|q', caseSensitive: false); | ||
| final String prompt = userMessages.flutterChooseOne; | ||
| String? choice; | ||
| globals.terminal.singleCharMode = true; |
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.
Can you use promptForCharInput instead?
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.
👍
Looks like you'll have to check first if the user is in an interactive session (unless the callers of readUserInput already guard that).
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.
Not without changing it extensively. promptForCharInput requires a list of acceptable characters and then only displays and allows input of those characters. With the new process, more devices might be loaded while promptForCharInput is still waiting for user input and it can't be updated to use a new list of acceptable characters.
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 is fine
| setUp(() { | ||
| cache = Cache.test(processManager: FakeProcessManager.any()); | ||
| platform = FakePlatform(); | ||
| testUsingContext('Ensure factory returns MacOSTargetDevices on MacOS', () async { |
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.
Does this and the next test actually rely on the context, or can they be invoked with testWithoutContext()? And if they do rely on the context, should we be overriding those values with fake objects?
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.
It doesn't need the context, good catch. Fixed.
Follow up question, though. Sometimes when it does need the context to be overridden but it doesn't need anything more custom than the default overrides (see below), is it okay to use testUsingContext without extra overrides or is it better practice to always add the overrides it needs to the test?
flutter/packages/flutter_tools/test/src/context.dart
Lines 104 to 122 in b42e8db
| AnsiTerminal: () => AnsiTerminal(platform: globals.platform, stdio: globals.stdio), | |
| Config: () => buildConfig(globals.fs), | |
| DeviceManager: () => FakeDeviceManager(), | |
| Doctor: () => FakeDoctor(globals.logger), | |
| FlutterVersion: () => FakeFlutterVersion(), | |
| HttpClient: () => FakeHttpClient.any(), | |
| IOSSimulatorUtils: () => const NoopIOSSimulatorUtils(), | |
| OutputPreferences: () => OutputPreferences.test(), | |
| Logger: () => BufferLogger.test(), | |
| OperatingSystemUtils: () => FakeOperatingSystemUtils(), | |
| PersistentToolState: () => buildPersistentToolState(globals.fs), | |
| Usage: () => TestUsage(), | |
| XcodeProjectInterpreter: () => FakeXcodeProjectInterpreter(), | |
| FileSystem: () => LocalFileSystemBlockingSetCurrentDirectory(), | |
| PlistParser: () => FakePlistParser(), | |
| Signals: () => FakeSignals(), | |
| Pub: () => ThrowingPub(), // prevent accidentally using pub. | |
| CrashReporter: () => const NoopCrashReporter(), | |
| TemplateRenderer: () => const MustacheTemplateRenderer(), |
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 is a good question. In answer to your question, it's fine to rely on the default (in contradiction of my earlier suggestion). In terms of improving explicitness and readability, the real fix is migrating completely to testWithoutContext.
| _slowWarning = slowWarningCallback!(); | ||
| final SlowWarningCallback? callback = slowWarningCallback; | ||
| if (_slowWarning.isEmpty && callback != null) { | ||
| final TerminalColor? color = warningColor; |
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'm not familiar with how we handle colors in the tool. Is there a reason why we can't make this a global color? Is it because some warnings are red and some the normal text color? Or is it a difference of host platforms?
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.
It's because some are normal text color. Before this change, all were normal text color. I added this so that the warning could be red
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.
SGTM
… extended discovery when discovery timeout is set
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.
LGTM
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!
|
@XilaiZhang @CaseyHillers do you know why FRoB says "Do not test" for this PR? And why |
This PR has failures with Google Testing. For some unknown reason, the state changed from "Failed" to "Pending" after ~12 hours. Please do not skip the Google Testing check on this PR, as this is causing real failures. |
|
@jmagman So I'm fairly confident the issue with g3 was that flutter/packages/flutter_tools/lib/src/android/android_device_discovery.dart Lines 75 to 78 in e50e99d
So I updated the flow of things a bit so only iOS discovery runs simultaneously. Can you review the newest commit? |
…#122932) Update device selection to wait for wireless devices to load
This PR updates the device selection flow to allow more time for wireless devices to load.
If the terminal has stdin and supports ANSI, a message is displayed while wireless devices are loading and other devices can be selected. After they are done loading, it will clear out the message and update with the device list
After done loading:
Fixes #118109.
Part 4 in breakdown of #121262.
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.