getsentry / getsentry/sentry-java
Nav3: Multipane support
- 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
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