31 lines
1.3 KiB
Markdown
31 lines
1.3 KiB
Markdown
---
|
||
issueRef: "#128"
|
||
version: 4
|
||
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
||
updatedAt: 1785670260985
|
||
---
|
||
## Problème
|
||
Le manifeste expose déjà des contributions `layouts`, mais la runtime publique ne formalise pas proprement l’enregistrement et le cycle de vie de ces layouts. L’exemple SDK actuel contourne la surface avec des casts ad hoc.
|
||
|
||
## Pourquoi c’est global
|
||
Ce n’est pas spécifique à Android: tout plugin de dev peut vouloir afficher un panneau d’état, un tableau, un viewer de logs, une vue de diagnostic, etc.
|
||
|
||
## Ce que ce ticket doit produire
|
||
Une runtime UI/layout publique stable permettant au minimum :
|
||
- enregistrement typé d’un layout
|
||
- props publiques documentées
|
||
- cycle de vie clair
|
||
- persistance/lecture de state si le host la supporte
|
||
- retrait propre via disposable
|
||
|
||
## Contraintes d’architecture
|
||
- Pas de dépendance à des détails runtime privés.
|
||
- Contrat explicite sur le rendu et la sérialisation du state plugin.
|
||
|
||
## Non-objectifs
|
||
- Pas d’imposer un design system plugin complet.
|
||
- Pas d’API spécifique aux vues Android.
|
||
|
||
## Critères d’acceptation
|
||
- L’exemple SDK n’a plus besoin de cast ad hoc pour enregistrer un layout.
|
||
- La surface publique suffit pour un panneau plugin de dev non trivial. |