-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Use mDNS to discover the device port #26944
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
Conversation
|
To test locally:
|
packages/flutter_tools/pubspec.yaml
Outdated
| meta: 1.1.6 | ||
| multicast_dns: | ||
| git: | ||
| url: https://github.com/dnfield/flutter_packages |
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 assume this will change to flutter/packages or something once you migrate it?
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 can just come from pub. Or we could pull it from flutter/packages - I'm just doing it this way so it can run through the CI tests for now.
|
I'll look at adding a devicelab test for this. I could also try to mock out a socket responding with some mDNS packets, but an integration test for this would probably be more valuable. |
|
Currently, this will break IDEs in some cases becuase it will ask for user input. Need to figure that out. /cc @DanTup @devoncarew |
|
I'm going to roll back the user interactivity in this and we can track that as a follow up. It makes this patch much more complicated and risky and isn't really necessary. |
| 'debug-port', | ||
| help: 'Device port where the observatory is listening.', | ||
| )..addOption('pid-file', | ||
| )..addOption( |
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.
Could we also infer this from the device + applicationBundle?
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.
A device could have multiple applications running on it. I'm not familiar with how that's implemented though...
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.
What I mean is, we already have the concept of an ApplicationPackage which contains enough information (when combined with the proper Device subclass) to start the app. Presumably we could use this information gathered from the user's pubspec/project files (if present) to figure out the app id.
This doesn't necessarily help for google3, but maybe we can feed some more information through from blaze and the device information to skip it as well.
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.
Attach doesn't start an app though, it looks for started apps.
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.
but you know the device you are connecting to at this point, and you might be in the root of a directory which can infer the application package structure. That doesn't mean we can't allow a user to specify the id manually, but I don't understand why we couldn't infer which observatory to attach.
* Discover port over mDNS * opt in, only for iOS for now
* Revert f9e6242 * fix pubspec * finish pubspec upgrade
This will only be supported on iOS.
It would be entirely possible to implement this on Android and potentially Fuchsia as well.
Needs flutter/packages#7 to land (and then update the pubspec.yaml to point to that properly on pub).