Change iOS device discovery from polling to long-running observation#58137
Change iOS device discovery from polling to long-running observation#58137fluttergithubbot merged 7 commits intoflutter:masterfrom
Conversation
There was a problem hiding this comment.
Learned this trick from https://github.com/flutter/flutter/pull/12079/files#diff-5a9a07600dceb28cbe887a5a64a24b0aR502-R504.
There was a problem hiding this comment.
g3 PollingDeviceDiscovery subclasses don't override startPolling or stopPolling.
6740b4a to
941b59c
Compare
There was a problem hiding this comment.
Renamed _items -> deviceNotifier
There was a problem hiding this comment.
So I'm understanding this correctly: since we're relying on a single long running process now, it needs to restart in case it goes down unexpectedly, otherwise IDEs wouldn't be able to discover new iOS devices without restarting - right?
There was a problem hiding this comment.
What if the device discovery exits immediately on start up (something is broken). Will this keep scheduling work in a loop? Likewise if this is killed as part of tear down.
There was a problem hiding this comment.
PollingDeviceDiscovery polling currently schedules a timer every 4 seconds to call device-specific discovery code, so that's the existing behavior. It depends what we want the behavior to be. If I killall xcdevice (exits 137), I would expect it to get rescheduled and the IDE not to need to be restarted. However if it just fails in some other way, rerunning it probably won't help? @zanderso What do you think?
Restarting after stopPolling is bad though...
There was a problem hiding this comment.
Its a bit of a tricky situation. How common is it for this process to go down during an IDE session? It might be less risky to log a message and move on
There was a problem hiding this comment.
I never saw it organically go down in my testing, but I also never saw my hard drive fill up with xcdevice caches described in #56826.
Good opportunity for metrics?
There was a problem hiding this comment.
yeah, if we're not sure lets measure
There was a problem hiding this comment.
It looks like close() on the StreamController for this Stream isn't called, so how does the 'onDone' callback get invoked?
There was a problem hiding this comment.
It looks like close() on the StreamController for this Stream isn't called, so how does the 'onDone' callback get invoked?
There was a problem hiding this comment.
This was the piece I was missing when I wasn't closing _deviceIdentifierByEvent on the last commit. I want polling to be able to be started, stopped, and re-started. Before, I was avoiding closing it so it could be re-listened to, but I guess it should be closed when no one is listening.
Really I want to be able to pause the subscription and resume it, but the pause() documentation says:
* To avoid buffering events on a broadcast stream, it is better to
* cancel this subscription, and start to listen again when events
* are needed, if the intermediate events are not important.
There was a problem hiding this comment.
I also changed this to --both to reflect what I just did in https://github.com/flutter/flutter/pull/58257/files#diff-8d108d6a887a4f5b74f7c7d77003e795R97. Wireless devices aren't being sufaced yet, so if one attaches it will kick off an unnecessary fetch. Should be rare.
zanderso
left a comment
There was a problem hiding this comment.
lgtm after addressing @jonahwilliams comments.
| return deviceNotifier.onRemoved; | ||
| } | ||
|
|
||
| void dispose() => stopPolling(); |
There was a problem hiding this comment.
Shouldn't this be async now?
|
|
||
| @override | ||
| void dispose() { | ||
| _observedDeviceEventsSubscription?.cancel(); |
There was a problem hiding this comment.
Should this not call super.dispose()?
There was a problem hiding this comment.
Also, if the super signature was async, this would just be await stopPolling()
Description
For daemon iOS device polling, change periodic
xcdevice listcalls to a long-runningxcdevice observecall.Related Issues
Fixes #56826
Tests
Checklist
///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change