docs: add guide for connecting to a running Flutter app#414
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Ortes
force-pushed
the
doc/flutter-driver-getting-started
branch
from
7163ab2 to
5f57813
Compare
|
Note that with the latest dev Dart SDK you no longer need |
| dtd(command: "connect", uri: "ws://127.0.0.1:<port>/<token>=") | ||
| ``` | ||
|
|
||
| ### Interact with the UI using Flutter Driver |
There was a problem hiding this comment.
This feels like it should be a skill, @jwren it might be similar to what you had going.
Whether or not it should also be in the readme is another question
There was a problem hiding this comment.
This should definitely be a skill, but I had a hard time setting it up and understanding the workflow. Going from trying to launch with the MCP launch_app tool and now changing back to the good old CLI tool — but still having to connect to it afterward with the MCP — does not feel obvious.
|
Yeah, I figured this manual step would eventually go away. From what I understood, it was initially going to be via mDNS but it's now going to use files with the process PID instead — either way, great news. I think there should still be some documentation around the connection workflow once it's settled though. For now I can just close this PR and open a new one when the process is stable — that way the doc will match the actual experience. Or I can keep it open and update it later, whatever works best. |
|
BTW it you have a any update on where the workflow is at now I would gladly give it a try even on flutter main branch :) |
Yes on the flutter main branch everything just works and the agent no longer needs to know DTD URIs. Basically the flow is: The |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a detailed guide to the README for connecting to running Flutter applications, covering mobile, desktop, and web platforms, along with troubleshooting tips and tool-specific notes. The review feedback identifies several critical issues: the use of non-existent or disabled commands like 'listDtdUris', 'set_semantics', and 'set_frame_sync' in examples and troubleshooting sections. Additionally, some code examples are missing the required 'command:' key, and the documentation for 'analyze_files' needs clarification regarding path parameters.
Document the workflow for launching a Flutter app with --print-dtd, connecting via the DTD, and using Flutter Driver commands for UI interaction.
After hands-on testing of the agent workflow on iOS + 2 web instances in parallel: - Drop --print-dtd everywhere; recent Flutter auto-registers DTD via DDS and dart tooling-daemon --list (and listDtdUris) discovers it. - Add a web-stub conditional import for projects that also build for web, so flutter_driver doesn't break dart2js compilation. - Restructure into Mobile / Web / Identifying instances / Troubleshooting, each with the gotcha-level details encountered in practice: - BySemanticsLabel needs set_semantics enabled first - TextField hint isn't a Text widget, ByText won't find it - ByType TextField is ambiguous when multiple fields are on screen - No pixel-coordinate clicks (iOS has no fallback; Android only via adb) - Web: -d chrome vs -d web-server trade-offs and DTD handshake timing - Multi-instance disambiguation (web name = "Unknown web app") - analyze_files runs custom_lint plugins, dart analyze does not - get_widget_tree size: prefer summaryOnly: true - Cleanup commands while a flutter run is live crash DDC
A second browser pointing at the same dev URL renders the app but is invisible to dwds — hot reload, runtime errors, and widget inspector keep targeting the Chrome Flutter spawned, so an agent driving the second browser silently reads and patches an invisible window. The Dart Debug Extension does not rescue this in -d chrome mode. Replace the pros/cons table with narrative paragraphs and add an explicit warning.
- Reference the Flutter Driver documentation from the body so the link reference at the end of the file is no longer dead. - Note that the `enabled` parameter for `set_semantics`, `set_frame_sync`, and `set_text_entry_emulation` is a string, not a bool — recurring footgun. - Tighten the second-browser trap warning: state print/runtime-error flow as a follow-on consequence of CDP attach rather than an independent claim. - Generalize the DDC-crash troubleshooting bullet (any deletion of `.dart_tool/` or `build/`, not a specific build_runner invocation).
- add `command:` key to inline `flutter_driver_command` examples (`set_semantics`, `set_frame_sync`) so they match the schema - clarify the `analyze_files` `paths`/`roots` wording — `paths` is a field on each `roots` entry, not a separate top-level argument
Ortes
force-pushed
the
doc/flutter-driver-getting-started
branch
2 times, most recently
from
a9a708f to
2171f64
Compare
2 participants
Summary
dart_mcp_serverREADME--print-dtd→dtd(connect)→ Flutter Driver workflowThis workflow is the primary way for agents to launch and connect to Flutter apps from the terminal since
launch_appwas disabled by default in #408, but was not documented anywhere.Related
--print-dtdset_frame_synccommandTest plan
🤖 Generated with Claude Code