Par Valentin Brosseau / @c4software
Un écran, des composants, un état qui pilote l'affichage.
Question : et quand l'application a plusieurs écrans ?
Un NavHost, et des Screen.
Chaque Screen est un composant comme les autres.
Chaque navigation empile un écran.
popBackStack() retire celui du dessus : c'est le bouton « retour ».
composable("screen1") {
Screen1(goToScreen2 = { name -> navController.navigate("screen2/$name") })
}L'écran ne sait pas où il va : il appelle l'action qu'on lui a donnée.
La structure de base d'un écran :
TopAppBar : la barre du haut.FloatingActionButton : le bouton flottant.BottomAppBar, Drawer…Chaque élément est optionnel.
Où ranger les données et la logique d'un écran ?
Dans le composant ?
data class).Le ViewModel ne connaît pas la vue.
class Screen3ViewModel: ViewModel() {
val listFlow = MutableStateFlow(listOf<String>())
fun addElement(element: String) {
listFlow.value += element
}
}Une donnée qui peut être modifiée, et observée.
Le ViewModel écrit dedans avec .value.
val list by viewModel.listFlow.collectAsStateWithLifecycle()Le flow change, le composant est recomposé. Automatiquement.
LazyColumn(modifier = Modifier.fillMaxSize()) {
items(list) { item ->
Text(item)
}
}Seuls les éléments visibles sont affichés : dix ou dix mille, peu importe.
Votre application veut utiliser le Bluetooth.
Qui décide ?
AndroidManifest.xml.Elles changent selon la version d'Android.
NavHost et une pile d'écrans.Scaffold pour structurer chaque écran.Flow modifié d'un côté, observé de l'autre.Place au TP 🚀