feat(ui): use Chrome Custom Tabs for explorer launches (#138)#148
feat(ui): use Chrome Custom Tabs for explorer launches (#138)#148
Conversation
Replaces Intent.ACTION_VIEW with CustomTabsIntent for every web URL the app launches, except the APK install intent in UpdateDownloader (which is a file:// URI, not a web URL). Why: Custom Tabs runs inside Pocket Node's task instead of starting Chrome's own task. The OS treats the round-trip as part of Pocket Node, so the auth gate doesn't re-engage on return and the user isn't bounced through a PIN re-entry. Process death by aggressive memory managers (Tecno / Infinix / MIUI) is also much less likely because the Custom Tab and host app share a task. Single helper at ui/util/CustomTabsLauncher.kt:openInBrowser handles the launch with a defensive fallback to plain ACTION_VIEW if the Custom Tabs launch crashes for any reason. Returns Boolean so callers can surface a 'no browser available' snackbar on the rare device with no web browser at all. Six explorer launch sites + one GitHub link swapped: - HomeScreen 'Look up on explorer' helper - HomeScreen tx detail bottom sheet - SettingsScreen sync explorer helper - SettingsScreen GitHub 'Open Source' link - ActivityScreen tx detail - SendScreen tx-confirmed explorer link The v1.5.2 SavedStateHandle backstop for the post-import sync sheet stays in place as defense-in-depth for any device that still kills the process despite Custom Tabs.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 39 minutes and 42 seconds.Comment |
1 participant
Closes #138.
Summary
Replaces `Intent.ACTION_VIEW` with `CustomTabsIntent` for every web URL the app launches. Six explorer launch sites + one GitHub link swapped. The APK install intent in `UpdateDownloader` is unchanged (file:// URI, not a web URL).
Why this matters
The smoke report on v1.5.2 confirmed: even with the SavedStateHandle persistence backstop, the round-trip itself feels jarring. User taps the explorer link, Chrome takes over its own task, the user copies a block height, returns to the app, the auth gate re-engages and forces PIN re-entry, then they land on Home. The `SavedStateHandle` fix means the sheet at least re-opens with their typed digits intact, but the unexpected lock screen mid-task is still bad UX.
Custom Tabs runs inside Pocket Node's task instead of starting Chrome's own task. The OS treats the round-trip as part of Pocket Node, so:
Implementation
Single helper at `ui/util/CustomTabsLauncher.kt:openInBrowser` handles the launch with a defensive fallback to plain `ACTION_VIEW` if the Custom Tabs launch crashes for any reason. Returns `Boolean` so callers can surface a "no browser available" snackbar on the rare device with no web browser at all.
```kotlin
fun openInBrowser(context: Context, url: String): Boolean {
val uri = Uri.parse(url)
return try {
CustomTabsIntent.Builder()
.setShowTitle(true)
.setUrlBarHidingEnabled(false)
.build()
.launchUrl(context, uri)
true
} catch (: ActivityNotFoundException) { false }
catch (: Throwable) {
try { context.startActivity(Intent(Intent.ACTION_VIEW, uri)); true }
catch (_: ActivityNotFoundException) { false }
}
}
```
Call sites swapped
Defense in depth
The `SavedStateHandle` persistence for `showSyncOptionsDialog` + `showPostImportSyncDialog` from v1.5.2 stays in place. If a device still kills the process despite Custom Tabs (unlikely but possible on the most aggressive ROMs), the sheet still re-opens via the prior fix.
Test plan
Related