fix(mobile): handle buzz:// links#1826
Conversation
buzz:// URLs previously did nothing on mobile — the scheme was only registered by the desktop Tauri app. Register CFBundleURLTypes on iOS and a VIEW intent-filter on Android, and add app_links-based handling that parses buzz://message?channel=<uuid>&id=<hex> (mirroring the desktop Rust handler's validation) and pushes the target channel view. Cold-start links are parked in a provider until auth completes and the channel list loads, then dispatched once. Unsupported hosts (e.g. buzz://connect, desktop-only) are ignored with a debug log; links to channels not in the workspace surface a snackbar instead of failing silently. Flutter's built-in deeplink handling is disabled on both platforms so app_links owns incoming URLs. Co-authored-by: Tom Brow <tomb@block.xyz> Signed-off-by: Tom Brow <tomb@block.xyz> Co-authored-by: Goose <opensource@block.xyz> Ai-assisted: true
|
@codex review |
|
@builderbot review |
|
To use Codex here, create a Codex account and connect to github. |
brow
changed the title
|
|
||
| Navigator.of(context).push( | ||
| MaterialPageRoute<void>( | ||
| builder: (_) => ChannelDetailPage(channel: channel), |
There was a problem hiding this comment.
This handles a message deep link as a channel link: link.messageId and link.threadRootId are never used, and ChannelDetailPage has no target-message argument. As a result, buzz://message?...&id=<hex> opens the channel at its normal timeline position rather than the linked message (and cannot open the linked thread). Please carry the parsed target into navigation and load/scroll/open that message, with a dispatcher-level test that proves the id/thread affects the destination.
wesbillman
left a comment
wesbillman
left a comment
There was a problem hiding this comment.
Blocking because the PR promises message deep-link routing, but the current dispatcher discards the parsed message/thread IDs and only opens the channel at its normal position. Please carry the target through navigation, verify the linked message/thread is opened, and add dispatcher-level coverage before merge.
3 participants
What changed?
buzz://URLs previously did nothing on mobile — the scheme was only registered by the desktop Tauri app. This registersCFBundleURLTypeson iOS and aVIEW/BROWSABLEintent-filter on Android, and addsapp_links-based handling that parsesbuzz://message?channel=<uuid>&id=<hex>(mirroring the desktop Rust handler's validation) and pushes the target channel view.buzz://connect, desktop-only) are ignored with a debug log; links to channels not in the current workspace surface a snackbar instead of failing silently.app_linksowns incoming URLs.Why?
Mobile users tapping
buzz://links (e.g. message links shared in channels) currently get no response at all. This closes that gap ahead of the Buzz mobile launch.How is it tested?
flutter analyzeclean; full mobile suite passes (451 tests).Added tests:
deep_link_test.dart— URL parsing/validation for supported and unsupported forms