Cas pratiques Android (Java)

Contexte : L’application tente de récupérer du contenu depuis une URL distante. Le Problème : L’application se bloque ou génère une NetworkOnMainThreadException. Extrait logique actuelle : String result = new URL(apiUrl).openStream().toString(); textView.setText(result); Contraintes : Exécuter appel réseau dans un thread secondaire. Mettre à jour l’UI uniquement depuis le thread principal. Livrable attendu : Corriger l’implémentation afin d’éviter blocage du thread principal et garantir fluidité de l’interface.

Contexte : Une application Android contient un bouton censé afficher un message Toast. Le Problème : Le clic sur le bouton ne produit aucun effet visible. Extrait logique actuelle : Button button = findViewById(R.id.myButton); button.setOnClickListener; { showMessage(); } Contraintes : Corriger la syntaxe du listener. Vérifier que setContentView est appelé avant findViewById. Tester comportement au clic. Livrable attendu : Corriger l’implémentation afin que le bouton déclenche correctement l’action prévue.

Contexte : L’application plante immédiatement au lancement. Le Problème : Une vue est référencée mais n’est pas présente dans le layout chargé. Extrait logique actuelle : TextView title = findViewById(R.id.titleText); title.setText("Bienvenue"); Contraintes : Vérifier que le bon layout est chargé via setContentView. S’assurer que l’ID existe dans le XML correspondant. Livrable attendu : Identifier la cause du crash et corriger le code pour éviter toute NullPointerException.

Contexte : Un message Toast doit s’afficher après une action utilisateur. Le Problème : Le Toast n’apparaît pas ou génère une erreur. Extrait logique actuelle : Toast.makeText(this, "Action réussie", Toast.LENGTH_SHORT); Contraintes : Appeler correctement la méthode show(). Utiliser contexte valide. Livrable attendu : Corriger l’implémentation afin que le Toast soit affiché correctement après l’action.

Contexte : Une RecyclerView est déclarée dans le layout mais aucun élément n’apparaît. Le Problème : Le LayoutManager ou l’adapter n’est pas correctement configuré. Extrait logique actuelle : recyclerView.setAdapter(adapter); Sans setLayoutManager. Contraintes : Définir un LayoutManager adapté. Vérifier données transmises à l’adapter. Livrable attendu : Corriger la configuration afin que la liste soit correctement affichée à l’écran.

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

Contexte : L’application doit 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. Charger valeur au démarrage de l’Activity. Livrable attendu : Implémenter une solution simple de persistance locale en Java permettant sauvegarde et récupération d’une donnée utilisateur.

Contexte : Une équipe démarre une application Android native en Java et souhaite valider la configuration du projet avec un premier écran interactif. Le Problème : Aucun écran fonctionnel n’est encore implémenté et il faut vérifier que les interactions UI sont correctement gérées. Contraintes : Créer une Activity utilisant setContentView et findViewById. Ajouter un Button et un TextView dans le layout XML. Au clic sur le bouton, modifier dynamiquement le texte affiché. Ne pas utiliser de librairie externe. Livrable attendu : Implémenter une Activity Java complète avec gestion d’événement via OnClickListener et mise à jour correcte de l’interface.

Contexte : L’application doit comporter un écran principal et un écran de détail. Le Problème : Aucun mécanisme de navigation n’est encore mis en place. Contraintes : Utiliser Intent explicite. Déclarer la seconde Activity dans AndroidManifest.xml. Ajouter un bouton permettant navigation. Livrable attendu : Implémenter deux Activities en Java 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 : Mettre en place RecyclerView avec LayoutManager. Créer Adapter et ViewHolder en Java. Afficher liste simple de chaînes. Livrable attendu : Implémenter une RecyclerView fonctionnelle permettant affichage efficace d’une liste.

Contexte : Une application utilise AsyncTask pour effectuer un appel réseau. Le Problème : Après rotation de l’écran, l’Activity reste référencée et provoque fuite mémoire. Extrait logique actuelle : private class FetchTask extends AsyncTask<Void, Void, String> { protected String doInBackground(Void... params) { return fetchData(); } } Contraintes : Éviter référence implicite à l’Activity. Rendre classe statique ou utiliser alternative moderne. Respecter cycle de vie. Livrable attendu : Corriger l’implémentation afin d’éliminer fuite mémoire et améliorer robustesse.

Contexte : Une Activity enregistre dynamiquement un BroadcastReceiver. Le Problème : Après navigation répétée, l’application consomme davantage de mémoire. Extrait logique actuelle : registerReceiver(receiver, filter); Sans appel à unregisterReceiver. Contraintes : Désenregistrer receiver dans onPause ou onDestroy. Respecter cycle de vie Android. Livrable attendu : Corriger la gestion du BroadcastReceiver afin d’éviter fuite mémoire et comportement imprévisible.

Contexte : Une Activity charge des données distantes et affiche une liste. Le Problème : Lors d’une rotation d’écran, l’application perd l’état ou plante. Extrait logique actuelle : List<String> dataList = new ArrayList<>(); Contraintes : Conserver état via ViewModel ou onSaveInstanceState. Éviter rechargement inutile. Livrable attendu : Corriger l’implémentation afin d’assurer persistance des données au changement de configuration.

Contexte : Plusieurs requêtes réseau sont déclenchées simultanément dans l’Activity. Le Problème : Les réponses arrivent dans un ordre imprévisible et écrasent certaines données. Extrait logique actuelle : new Thread(() -> fetchUser()).start(); new Thread(() -> fetchOrders()).start(); Contraintes : Synchroniser mises à jour UI. Gérer cohérence de l’état final. Éviter écrasement de données. Livrable attendu : Corriger la gestion concurrente afin de garantir cohérence des informations affichées.

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 : adapter.notifyDataSetChanged(); Utilisé après chaque modification. Contraintes : Implémenter DiffUtil ou mise à jour ciblée. Optimiser ViewHolder. Éviter recalcul inutile. Livrable attendu : Optimiser la RecyclerView afin d’améliorer fluidité et performance globale.

Contexte : L’application consulte régulièrement 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 : Créer base SQLite locale. Stocker données récupérées. Lire depuis cache si disponible. Livrable attendu : Mettre en place un système de cache local structuré améliorant performance et résilience réseau.

Contexte : Une application Android en Java commence à inclure plusieurs écrans avec logique métier et appels réseau. Le Problème : Toute la logique est actuellement dans les Activities, ce qui rend le code difficile à tester et à maintenir. Contraintes : Mettre en place architecture MVVM. Créer ViewModel séparé. Exposer données via LiveData. Déplacer logique métier hors de l’Activity. Livrable attendu : Proposer une structure MVVM complète en Java incluant Activity, ViewModel et Repository avec flux de données clair et testable.

Contexte : L’application comporte plusieurs sections nécessitant navigation interne. Le Problème : Les transactions de fragments sont gérées manuellement et deviennent difficiles à maintenir. Contraintes : Utiliser FragmentManager proprement. Ajouter fragments au back stack. Gérer transitions correctement. Livrable attendu : Mettre en place navigation claire et maintenable entre fragments.

Contexte : L’application affiche une liste d’éléments récupérés depuis une API. Le Problème : Tous les éléments sont chargés en une seule fois, ralentissant l’interface. Contraintes : Mettre en place pagination côté client. Détecter fin de liste via RecyclerView.OnScrollListener. Charger données par page. Afficher indicateur de chargement. Livrable attendu : Implémenter un système de pagination performant améliorant fluidité et consommation réseau.

Contexte : Une application nécessite authentification utilisateur via token simulé. Le Problème : Le token n’est pas conservé correctement entre les sessions. Contraintes : Stocker token via SharedPreferences. Vérifier validité au démarrage. Rediriger vers écran login si token absent. Livrable attendu : Implémenter une gestion de session cohérente avec persistance locale et redirection conditionnelle.

Contexte : L’application consulte fréquemment des données depuis API distante. Le Problème : Les données ne sont pas cohérentes entre cache local et serveur. Contraintes : Définir stratégie de cache prioritaire (mémoire + SQLite). Implémenter invalidation automatique. Assurer cohérence lors mise à jour distante. Livrable attendu : Concevoir un système de cache robuste garantissant performance et cohérence des données.

Contexte : L’application communique avec une API protégée par token d’authentification. Le Problème : À expiration du token, les requêtes échouent sans mécanisme de renouvellement automatique. Contraintes : Intercepter erreurs 401. Implémenter rafraîchissement automatique du token. Éviter requêtes simultanées multiples de renouvellement. Livrable attendu : Concevoir une stratégie robuste de gestion de session et de renouvellement automatique garantissant sécurité et cohérence.

Contexte : Une application Android en Java évolue rapidement avec plusieurs équipes travaillant sur différents modules fonctionnels. Le Problème : Le projet est devenu monolithique, les dépendances sont croisées et la maintenance devient complexe. Contraintes : Proposer une architecture modulaire séparant clairement presentation, domain et data. Éviter dépendances circulaires. Permettre testabilité indépendante de la couche UI. Maintenir compatibilité avec un projet Java existant. Livrable attendu : Concevoir une architecture modulaire complète avec structure des packages, responsabilités des couches et flux détaillé entre UI, ViewModel et Repository.

Contexte : L’application met à jour l’interface après un traitement en arrière-plan. Le Problème : Un crash intermittent apparaît lié à modification UI hors thread principal. Extrait logique actuelle : new Thread(() -> textView.setText("Updated")).start(); Contraintes : Mettre à jour UI uniquement sur thread principal via runOnUiThread. Respecter règles Android. Livrable attendu : Corriger le code afin d’assurer conformité aux règles de thread UI et éliminer crash intermittent.

Contexte : Une RecyclerView affiche plusieurs types d’éléments avec images et données dynamiques. Le Problème : Le défilement est saccadé et provoque pertes de frames sur appareils moyens. Extrait logique actuelle : adapter.notifyDataSetChanged(); Utilisé après chaque modification. Contraintes : Implémenter DiffUtil ou mise à jour ciblée. Optimiser ViewHolder. Éviter recalcul inutile dans onBindViewHolder. Livrable attendu : Optimiser la RecyclerView pour assurer fluidité même avec grand volume de données.

Contexte : Plusieurs threads modifient simultanément une structure de données partagée. Le Problème : Les résultats sont incohérents et certaines mises à jour sont perdues. Extrait logique actuelle : new Thread(() -> updateData()).start(); new Thread(() -> updateData()).start(); Contraintes : Synchroniser accès critique. Utiliser mécanismes thread-safe appropriés. Garantir cohérence des données. Livrable attendu : Corriger la gestion concurrente afin d’éliminer conditions de course et garantir intégrité des données.

Contexte : Une classe utilitaire conserve une référence statique vers une Activity pour accéder au contexte global. Le Problème : Après fermeture de l’écran, l’Activity reste en mémoire et provoque une fuite. Extrait logique actuelle : public static Context context; Initialisé avec une Activity. Contraintes : Éliminer toute référence statique vers Activity. Utiliser applicationContext lorsque pertinent. Respecter cycle de vie Android. Livrable attendu : Corriger la conception afin d’éliminer fuite mémoire et garantir gestion correcte du contexte.

Contexte : L’application utilise plusieurs fragments imbriqués avec transactions répétées. Le Problème : Certains fragments restent en mémoire et provoquent comportements inattendus. Extrait logique actuelle : fragmentManager.beginTransaction().replace(R.id.container, newFragment).commit(); Sans gestion du back stack. Contraintes : Analyser gestion du back stack. Utiliser addToBackStack correctement. Éviter duplication de fragments. Livrable attendu : Corriger la navigation afin d’éviter accumulation de fragments et garantir gestion propre du cycle de vie.

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

Contexte : Une application critique nécessite validation fiable avant chaque mise en production. Le Problème : Aucune stratégie de tests automatisés n’est en place pour la logique métier et les interactions UI. Contraintes : Séparer logique métier testable. Implémenter tests unitaires JUnit. Ajouter tests instrumentés pour scénarios UI clés. Livrable attendu : Proposer une stratégie complète de tests garantissant couverture des composants critiques.