getsentry / getsentry/sentry-java

Nav3: Multipane support

Aberta
#5,649 1 comentário 0 reações 0 responsáveis Ver no GitHub
Android Feature Google I/O 2026 Platform: Java Spans
Linguagem predominante
Kotlin
Estrelas
1.4k
Forks
478
Merge médio
3d 4h
PRs com merge (30d)
72

Descrição

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

Guia de contribuição

Abrir o guia de contribuição

Direção de pesquisa

Comece pelo SentryNavEntryDecorator da integração do Nav3 Stage 1 e leia os pontos do ciclo de vida de NavEntryDecorator ou DisposableEffect descritos na issue. Rastreie como as entradas visíveis, scope.screen, as transações, os breadcrumbs e o contexto de crash são tratados atualmente e, em seguida, compare com a integração existente do Nav2. A tarefa estará concluída quando as entradas de múltiplos painéis relatarem as rotas e os argumentos visíveis, selecionarem um painel primário e atualizarem a telemetria listada de forma consistente.

Escrita pelo modelo de indexação a partir do texto da issue.

Avaliação

Stack de tecnologia
android, kotlin
Domínio
mobile, observability
Tipo de issue
Funcionalidade
Dificuldade
5/5
Tempo estimado
Mais de uma semana
Status de atividade
Pouca atividade
Clareza
Razoavelmente clara
Facilidade para iniciantes
35/100

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.