Cas pratiques Android (Kotlin)

Contexte : Une application récupère des données depuis une API distante. Le Problème : L’application se fige ou affiche une erreur NetworkOnMainThreadException. Extrait logique actuelle : val result = URL(apiUrl).readText() textView.text = result Contraintes : Exécuter appel réseau hors thread principal. Utiliser coroutine ou thread secondaire. Mettre à jour UI sur thread principal. Livrable attendu : Corriger l’implémentation pour éviter blocage de l’interface utilisateur.

Contexte : Une application Android comporte un bouton censé afficher un message. Le Problème : Le clic sur le bouton ne produit aucun effet. Extrait logique actuelle : val button = findViewById<Button>(R.id.myButton) button.setOnClickListener { showMessage() } Contraintes : Vérifier syntaxe du listener. S’assurer que la vue est correctement initialisée après setContentView. Tester comportement. Livrable attendu : Corriger le code afin que le bouton déclenche correctement l’action attendue.

Contexte : L’application plante au lancement avec une NullPointerException. Le Problème : Une vue est référencée mais n’existe pas dans le layout courant. Extrait logique actuelle : val textView = findViewById<TextView>(R.id.titleText) textView.text = "Bienvenue" Contraintes : Vérifier correspondance layout et ID. S’assurer que setContentView charge le bon fichier XML. Livrable attendu : Identifier et corriger l’erreur afin d’éviter crash au démarrage.

Contexte : Un message Toast doit être affiché lors d’une action utilisateur. Le Problème : Le Toast ne s’affiche pas ou provoque une erreur de contexte. Extrait logique actuelle : Toast.makeText(this, "Action réussie", Toast.LENGTH_SHORT) Sans appel à show(). Contraintes : Utiliser contexte valide. Appeler méthode show(). Tester affichage. Livrable attendu : Corriger l’implémentation afin que le Toast s’affiche correctement.

Contexte : Une RecyclerView est déclarée mais aucun élément n’apparaît à l’écran. Le Problème : L’adapter ou le LayoutManager n’est pas correctement configuré. Extrait logique actuelle : recyclerView.adapter = myAdapter Sans LayoutManager défini. Contraintes : Définir LayoutManager approprié. Vérifier données transmises à l’adapter. Livrable attendu : Corriger la configuration afin que la liste s’affiche correctement.

Contexte : Une application doit permettre saisie d’un email et d’un mot de passe. Le Problème : Aucun mécanisme de validation n’est implémenté. Contraintes : Utiliser EditText. Vérifier que l’email n’est pas vide et que le mot de passe contient au moins 6 caractères. Afficher message d’erreur via Toast ou TextView. Livrable attendu : Implémenter un formulaire fonctionnel avec validation simple et retour utilisateur clair.

Contexte : Une application souhaite mémoriser un nom utilisateur entre deux sessions. Le Problème : Les données saisies sont perdues après fermeture de l’application. Contraintes : Utiliser SharedPreferences. Enregistrer une chaîne de caractères. Récupérer valeur au démarrage de l’Activity. Livrable attendu : Implémenter un système simple de persistance locale permettant sauvegarde et récupération d’un paramètre utilisateur.

Contexte : Une startup lance une application Android native et souhaite créer son premier écran en Kotlin. Le Problème : Aucun écran interactif n’est encore implémenté et l’équipe veut valider la configuration du projet. Contraintes : Créer une Activity utilisant ViewBinding ou findViewById. Ajouter un Button et un TextView. Au clic sur le bouton, modifier dynamiquement le texte affiché. Ne pas utiliser de librairie externe. Livrable attendu : Implémenter une Activity fonctionnelle en Kotlin avec gestion simple d’événement et mise à jour de l’interface.

Contexte : Une application nécessite un écran d’accueil et un écran détail. Le Problème : Aucun mécanisme de navigation n’est encore configuré. Contraintes : Utiliser Intent explicite. Déclarer la seconde Activity dans AndroidManifest.xml. Implémenter bouton permettant navigation. Livrable attendu : Créer deux Activities en Kotlin avec navigation fonctionnelle et retour arrière standard Android.

Contexte : Une application doit afficher une liste dynamique d’éléments. Le Problème : Aucun composant de liste performant n’est encore utilisé. Contraintes : Implémenter RecyclerView avec Adapter et ViewHolder. Afficher une liste de chaînes simples. Gérer layout vertical. Livrable attendu : Mettre en place une RecyclerView fonctionnelle en Kotlin avec adapter minimal.

Contexte : Une Activity contient des données dynamiques chargées depuis une API. Le Problème : Lors d’un changement d’orientation, l’application recrée l’Activity et perd l’état. Extrait logique actuelle : var dataList: List<String> = emptyList() Contraintes : Utiliser ViewModel pour conserver état. Éviter perte de données lors rotation. Livrable attendu : Corriger l’implémentation afin d’assurer persistance des données au changement de configuration.

Contexte : Plusieurs appels API sont déclenchés simultanément dans un ViewModel. Le Problème : Les réponses arrivent dans un ordre imprévisible et écrasent certaines données. Extrait logique actuelle : viewModelScope.launch { fetchUser() fetchOrders() } Contraintes : Gérer appels asynchrones correctement. Synchroniser si nécessaire. Garantir cohérence de l’état final. Livrable attendu : Corriger la logique afin d’éviter incohérences liées à la concurrence.

Contexte : Une application effectue un appel réseau via coroutine dans une Activity. Le Problème : Lors d’un changement d’orientation, la coroutine continue de s’exécuter et provoque un crash. Extrait logique actuelle : GlobalScope.launch { val data = repository.fetchData() } Contraintes : Éviter GlobalScope. Utiliser lifecycleScope ou viewModelScope. Respecter cycle de vie Android. Livrable attendu : Corriger l’implémentation afin que la coroutine soit correctement liée au cycle de vie et évite fuites ou crashes.

Contexte : Une Activity enregistre un listener sur un capteur ou un BroadcastReceiver. Le Problème : Après navigation répétée, l’application consomme de plus en plus de mémoire. Extrait logique actuelle : registerReceiver(receiver, intentFilter) Sans désenregistrement. Contraintes : Implémenter unregisterReceiver dans le bon callback du cycle de vie. Vérifier absence de fuite mémoire. Livrable attendu : Corriger la gestion du listener afin d’assurer stabilité mémoire.

Contexte : Une RecyclerView affiche des éléments avec images et données dynamiques. Le Problème : Le défilement est saccadé sur appareils milieu de gamme. Extrait logique actuelle : notifyDataSetChanged() Utilisé systématiquement après chaque modification. Contraintes : Utiliser DiffUtil. Éviter rechargement complet inutile. Optimiser binding des données. Livrable attendu : Optimiser la RecyclerView afin d’améliorer fluidité et performance globale.

Contexte : L’application récupère fréquemment des données depuis une API distante. Le Problème : Les requêtes répétées ralentissent l’application et consomment du réseau. Contraintes : Intégrer Room Database. Stocker données localement. Mettre à jour cache lors nouvelle synchronisation. Livrable attendu : Concevoir un système de cache local structuré améliorant performance et disponibilité hors ligne partielle.

Contexte : L’application comporte plusieurs fragments et la navigation devient complexe. Le Problème : Les transactions de fragments sont gérées manuellement et deviennent difficiles à maintenir. Contraintes : Utiliser Navigation Component. Définir graphe de navigation XML. Gérer arguments sécurisés. Livrable attendu : Mettre en place navigation structurée et maintenable via Navigation Component.

Contexte : Une application Android commence à inclure plusieurs écrans avec logique métier complexe et appels réseau. Le Problème : La logique est actuellement directement dans les Activities, rendant le code difficile à tester et maintenir. Contraintes : Mettre en place architecture MVVM. Utiliser ViewModel pour gérer les données. Exposer données via LiveData ou StateFlow. Éviter toute logique métier dans l’Activity. Livrable attendu : Proposer une structure MVVM claire avec séparation des responsabilités et exemple complet de flux UI → ViewModel → Repository.

Contexte : Une application affiche une liste d’articles provenant d’une API. Le Problème : Tous les éléments sont chargés en une seule requête, causant lenteur et surcharge mémoire. Contraintes : Mettre en place pagination côté client. Détecter fin de liste via RecyclerView. Charger données par page. Gérer indicateur de chargement. Livrable attendu : Implémenter un système de pagination performant améliorant expérience utilisateur et consommation réseau.

Contexte : Une application nécessite gestion de session utilisateur avec token JWT simulé. Le Problème : Le token n’est pas correctement persisté et l’utilisateur doit se reconnecter à chaque redémarrage. Contraintes : Stocker token via SharedPreferences ou DataStore. Vérifier validité au lancement. Rediriger vers écran login si nécessaire. Livrable attendu : Implémenter un système de gestion de session cohérent et persistant.

Contexte : L’application récupère données depuis API distante mais doit également supporter mode dégradé. Le Problème : Les données ne sont pas cohérentes entre cache local et serveur. Contraintes : Définir stratégie de cache prioritaire. Gérer invalidation et rafraîchissement. Assurer cohérence entre Room et API. Livrable attendu : Concevoir un système de cache robuste garantissant performance et cohérence des données.

Contexte : L’application utilise des tokens JWT pour authentification API. Le Problème : À expiration du token, les requêtes échouent sans gestion automatique. Contraintes : Implémenter interceptor réseau pour détecter expiration. Rafraîchir token automatiquement. Empêcher requêtes simultanées multiples de rafraîchissement. Livrable attendu : Concevoir une stratégie robuste de gestion et renouvellement automatique des tokens garantissant sécurité et cohérence.

Contexte : Une application Android grandit rapidement avec plusieurs équipes travaillant en parallèle sur différents domaines fonctionnels. Le Problème : Le projet est monolithique, les dépendances sont croisées et les temps de compilation augmentent fortement. Contraintes : Proposer une architecture multi-modules (feature modules, core, data). Séparer clairement couches domain, data et presentation. Éviter dépendances circulaires. Garantir testabilité indépendante des modules. Livrable attendu : Concevoir une architecture modulaire complète incluant structure des modules, flux de dépendances et justification des choix techniques.

Contexte : Une application met à jour l’interface après un traitement en arrière-plan. Le Problème : Un crash apparaît sporadiquement lié à modification UI hors thread principal. Extrait logique actuelle : Thread { textView.text = "Updated" }.start() Contraintes : Mettre à jour UI uniquement sur thread principal. Utiliser coroutines ou runOnUiThread. Livrable attendu : Corriger le code afin d’assurer respect strict des règles de thread UI Android.

Contexte : Une classe utilitaire conserve une référence à une Activity pour afficher des messages. Le Problème : Après rotation ou fermeture, l’Activity reste en mémoire provoquant fuite mémoire. Extrait logique actuelle : class Helper(private val context: Context) Utilisé avec une Activity. Contraintes : Éviter référence forte vers Activity. Utiliser applicationContext si nécessaire. Respecter cycle de vie. Livrable attendu : Corriger la conception afin d’éliminer toute fuite mémoire liée aux références de contexte.

Contexte : Une RecyclerView affiche plusieurs types d’items complexes avec images et calculs dynamiques. Le Problème : Le défilement est saccadé et provoque pertes de frames. Extrait logique actuelle : notifyDataSetChanged() Utilisé après chaque modification. Contraintes : Implémenter DiffUtil. Optimiser ViewHolder. Éviter recalculs inutiles dans onBindViewHolder. Livrable attendu : Optimiser la RecyclerView pour garantir fluidité même avec grande quantité de données.

Contexte : Plusieurs actions utilisateur déclenchent mises à jour concurrentes dans le même ViewModel. Le Problème : Les états s’écrasent mutuellement et produisent des résultats incohérents. Extrait logique actuelle : viewModelScope.launch { repository.updateData() } Déclenché plusieurs fois rapidement. Contraintes : Synchroniser accès critique. Utiliser Mutex ou stratégie adaptée. Garantir cohérence d’état. Livrable attendu : Corriger la gestion concurrente afin d’éviter conditions de course et incohérences de données.

Contexte : L’application utilise plusieurs fragments imbriqués avec Navigation Component. Le Problème : Certains fragments restent en mémoire après navigation répétée. Extrait logique actuelle : findNavController().navigate(R.id.nextFragment) Sans gestion appropriée du back stack. Contraintes : Analyser gestion du back stack. Utiliser popUpTo si nécessaire. Vérifier cycle de vie des fragments. Livrable attendu : Corriger la navigation afin d’éviter accumulation de fragments et fuites mémoire associées.

Contexte : Une application terrain doit fonctionner sans connexion stable et synchroniser les données ultérieurement. Le Problème : Les modifications locales peuvent entrer en conflit avec les données serveur lors de la reconnexion. Contraintes : Utiliser Room pour stockage local. Implémenter file d’attente d’opérations. Gérer résolution basique de conflits. Assurer cohérence des données. Livrable attendu : Concevoir une architecture offline-first complète incluant persistance locale, synchronisation différée et stratégie de gestion des conflits.

Contexte : Une application critique nécessite couverture de tests fiable avant déploiement. Le Problème : La logique métier et les composants UI ne sont pas testés. Contraintes : Séparer logique métier testable. Implémenter tests unitaires pour ViewModel. Mettre en place tests instrumentés pour interactions UI. Livrable attendu : Proposer une stratégie complète de tests automatisés couvrant logique métier et scénarios UI principaux.