getsentry / getsentry/sentry-java

Nav3: Multipane support

未關閉
#5,649 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
Android Feature Google I/O 2026 Platform: Java Spans
主要語言
Kotlin
星號
1.4k
分支
478
平均合併
3 天 4 小時
30 天內合併 PR
72

描述

### Problem Statement

[Nav3]() introduces a scene/strategy system that allows multiple `NavEntry` objects to be composed simultaneously – for example, list-detail layouts on tablets using `ListDetailSceneStrategy` or custom `SceneStrategy` implementations. The Stage 1 integration (single-stack, single-pane parity with Nav2, getsentry/sentry-java#5000) doesn't account for this: when multiple panes are visible, the SDK needs to report which screens are on-screen, choose a "primary" pane for `scope.screen` and the active transaction, and include all visible routes in crash context.

### Solution Brainstorm

Build on the `SentryNavEntryDecorator` from getsentry/sentry-java#5000 to track entry composition lifecycle:

* **Visible pane tracking.** Use `NavEntryDecorator` (or `DisposableEffect`) to detect when entries enter and leave composition. Maintain a set of currently-visible panes.
* **Primary pane selection.** When multiple panes are visible, pick the "most specific" as primary – detail over list, using Nav3's `NavEntry.metadata` (e.g. the `listDetailPane` key from `ListDetailSceneStrategy`). Fall back to recency or stack position when metadata is absent.
* `scope.screen` – set to the primary pane's route name.
* `contexts.app.view_names` – set to the full list of visible route names when more than one pane is composed (e.g. `["/ProductList", "/ProductDetail"]`).
* **Breadcrumbs** – include a `visible` field listing all visible routes at the time of the navigation event, only when multipane is active.
* **Crash context (**`contexts.navigation.visible`**)** – a list of visible-pane entries (route + args), updated on visibility changes, separate from the backstack list.
* **Active transaction** – targets the primary pane only; named after the detail route when a list-detail scene is active.

Open questions:

* Should we detect multipane purely from metadata, or also offer an explicit API for custom `SceneStrategy` implementations that don't use standard metadata keys?
* Should `view_names` include panes from all strategies (e.g. a two-pane + dialog simultaneously), or only the "main" scene's entries?

### Existing Nav2 support

The current Nav2 integration (`sentry-android-navigation`) does not support multipane layouts. Nav2's `NavController` exposes a single current destination at a time, so `scope.screen` and the active transaction always reflect one screen. There is no `view_names` array or visible-pane tracking. Apps using Nav2 with multipane patterns (e.g. `SlidingPaneLayout` or manual fragment transactions alongside navigation) get no multipane-aware telemetry from the SDK.

貢獻指南

開啟貢獻指南

研究方向

從 Nav3 Stage 1 整合中的 SentryNavEntryDecorator 開始,閱讀 issue 中描述的 NavEntryDecorator 或 DisposableEffect 生命週期節點。追蹤目前如何處理可見項目、scope.screen、交易、麵包屑和當機內容,然後與現有的 Nav2 整合進行比較。完成的標準是多窗格項目回報可見路由和引數、選取一個主要窗格,並一致地更新所列的遙測資料。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
android, kotlin
領域
mobile, observability
Issue 類型
功能
難度
5/5
預估耗時
一週以上
活躍度
冷清
描述清晰度
基本清楚
新手友好度
35/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。