getsentry / getsentry/sentry-java

Nav3: Multipane support

Offen
#5,649 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Android Feature Google I/O 2026 Platform: Java Spans
Vorherrschende Sprache
Kotlin
Sterne
1.4k
Forks
478
Ø Merge
2 T. 23 Std.
Gemergte PRs (30 T.)
67

Beschreibung

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

Beitragsleitfaden

Beitragsleitfaden öffnen

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
android, kotlin
Bereich
mobile, observability
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.