Contexte dans Jetpack Compose : Guide complet avec exemples de code

Introduction : Pourquoi le Context dans Jetpack Compose est un casse-tête pour les débutants ?

Si vous avez déjà développé sur Android en utilisant XML, vous savez que le Context est littéralement la « clé » de tout : de l'accès aux ressources au lancement de nouvelles Activity. Mais lorsque vous passez à Jetpack Compose, tout change. Les fonctions composables n'ont pas d'accès direct au Context, et cela devient souvent une pierre d'achoppement pour les développeurs, en particulier ceux qui commencent tout juste à adopter l'approche déclarative.

La question « How to get Context in Jetpack Compose » sur Stack Overflow a recueilli des milliers de vues et des dizaines de réponses. Ce n'est pas un hasard. Dans cet article, nous allons passer en revue toutes les façons possibles d'obtenir un Context dans Compose, des plus simples aux plus avancées, avec des exemples de code réels en Kotlin. Vous apprendrez quand utiliser LocalContext.current, comment éviter les fuites de mémoire et quelles pratiques sont considérées comme des « best practices » en 2025.

1. La méthode la plus simple : LocalContext.current

Si vous avez besoin d'obtenir un Context à l'intérieur d'une fonction composable, la manière la plus directe est d'utiliser LocalContext.current. C'est un composable-local qui fournit le Context actuel (généralement une Activity ou un ContextWrapper).

@Composable\nfun MyScreen() {\n    val context = LocalContext.current\n    \n    Button(onClick = {\n        Toast.makeText(context, "Bonjour depuis Compose!", Toast.LENGTH_SHORT).show()\n    }) {\n        Text("Afficher un Toast")\n    }\n}

Ce code fonctionne, mais il y a un détail : LocalContext.current vous donne un Context qui est lié au CompositionLocal actuel. Dans la plupart des cas, c'est ce qu'il vous faut. Cependant, rappelez-vous qu'un tel Context ne doit pas être transmis à un ViewModel ou conservé dans des objets à longue durée de vie — cela pourrait entraîner des fuites de mémoire.

Quand l'utiliser ?

\n
• Pour des actions ponctuelles dans l'interface utilisateur : Toast, Snackbar, lancement d'Activity.
\n
• Pour accéder aux ressources : context.getString(R.string.app_name).
\n
• Pour travailler avec des services système : context.getSystemService().
\n

2. Context dans ViewModel : L'approche correcte

L'une des erreurs les plus fréquentes est de transmettre directement le Context à un ViewModel. Dans Android Architecture Components, cela est considéré comme un anti-patron, car le ViewModel peut survivre à l'Activity, et le Context deviendrait obsolète. Utilisez plutôt AndroidViewModel.

class MyViewModel(application: Application) : AndroidViewModel(application) {\n    \n    private val context = getApplication<Application>().applicationContext\n    \n    fun loadData() {\n        // Utilisation de applicationContext, qui est sûr\n        val prefs = context.getSharedPreferences("my_prefs", Context.MODE_PRIVATE)\n    }\n}

Dans Compose, vous pouvez obtenir une instance d'un tel ViewModel de manière standard :

@Composable\nfun MyScreen() {\n    val viewModel: MyViewModel = viewModel()\n    // Le Context est déjà à l'intérieur du ViewModel, pas besoin de le transmettre depuis l'interface utilisateur\n}

Avantage : applicationContext vit tant que le processus est vivant et ne dépend pas du cycle de vie de l'Activity. C'est sûr et recommandé par Google.

3. Context dans CompositionLocal : Fournisseurs personnalisés

Parfois, vous devez transmettre un Context spécifique (par exemple, pour les tests ou pour un module avec une bibliothèque). Dans ces cas, vous pouvez créer votre propre CompositionLocal.

val LocalCustomContext = staticCompositionLocalOf<Context> {\n    error("Aucun contexte personnalisé fourni")\n}\n\n@Composable\nfun CustomContextProvider(context: Context, content: @Composable () -> Unit) {\n    CompositionLocalProvider(LocalCustomContext provides context) {\n        content()\n    }\n}\n\n// Utilisation :\n@Composable\nfun MyScreen() {\n    val customContext = LocalCus