getsentry / getsentry/sentry-java

Nav3: Multipane support

オープン
#5,649 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る
Android Feature Google I/O 2026 Platform: Java Spans
主要言語
Kotlin
スター
1.4k
フォーク
478
平均マージ
2日 23時間
マージ済み PR(30日)
67

説明

### 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.

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

Start with the SentryNavEntryDecorator from the Nav3 Stage 1 integration and read the NavEntryDecorator or DisposableEffect lifecycle points described in the issue. Trace how visible entries, scope.screen, transactions, breadcrumbs, and crash context are currently handled, then compare the existing Nav2 integration. Done means multipane entries report visible routes and arguments, select a primary pane, and update the listed telemetry consistently.

索引モデルが issue の本文から書いたものです。

評価

技術スタック
android, kotlin
領域
mobile, observability
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。