EnglishCommencer

La robustesse

Ce qui fait tomber une application mobile (exception, fil principal bloqué, mort du processus, rotation, mémoire, réponse inattendue), la lecture d'une trace de plantage, les tests et le suivi des plantages.

  • 28 cartes
  • 5 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation
  5. Comprendre

Quelques cartes du deck

  • Robustesse : de quoi s'agit-il ?

    Voir la réponse

    Capacité d'une application à continuer de fonctionner, ou à échouer proprement, face à des conditions imprévues : réseau coupé, donnée absente, mémoire insuffisante.

    Sur mobile, les conditions imprévues sont la norme : l'utilisateur tourne l'écran, perd le réseau, reçoit un appel. Un code qui ne marche que dans le cas heureux plante vite.

  • Dans cette trace, quelle ligne est la première à appartenir au code de l'application com.example.shop ?

    ```text
    FATAL EXCEPTION: main
    Process: com.example.shop, PID: 4821
    java.lang.IllegalStateException: Fragment ProfileFragment{8f3c2a1} not attached to a context.
    at androidx.fragment.app.Fragment.requireContext(Fragment.java)
    at com.example.shop.ProfileFragment.showError(ProfileFragment.kt:58)
    at com.example.shop.ProfileFragment.onResult(ProfileFragment.kt:41)
    at android.os.Handler.handleCallback(Handler.java)
    `

    • at com.example.shop.ProfileFragment.showError(ProfileFragment.kt:58)
    • java.lang.IllegalStateException: Fragment ProfileFragment{8f3c2a1} not attached …
    • at androidx.fragment.app.Fragment.requireContext(Fragment.java)
    • at com.example.shop.ProfileFragment.onResult(ProfileFragment.kt:41)
    Voir la réponse

    at com.example.shop.ProfileFragment.showError(ProfileFragment.kt:58)

    La première ligne donne l'exception, pas un endroit du code. requireContext est du framework : il lève parce que le fragment n'est plus attaché. La première ligne de l'application est ProfileFragment.kt:58, dans showError, qui l'a appelé trop tard ; onResult, plus bas, n'est que son appelant.

  • Pour éviter qu'une application ne réponde plus, tout accès au … ou au disque se fait hors du fil ….

    Voir la réponse

    Pour éviter qu'une application ne réponde plus, tout accès au réseau ou au disque se fait hors du fil principal.

    Android lève même NetworkOnMainThreadException pour un appel réseau fait sur le fil principal. Les coroutines Kotlin ou un exécuteur déplacent le travail ailleurs.

  • Plantage : de quoi s'agit-il ?

    Voir la réponse

    Fermeture brutale de l'application en cours d'usage, causée par une exception que rien n'a attrapée ou par une erreur fatale du code natif.

    Sous Android, le système signale que l'application s'est arrêtée et écrit une trace dans le journal (Logcat) : c'est la trace qu'il faut lire pour trouver la ligne fautive. Un processus tué en arrière-plan pour libérer la mémoire n'est pas un plantage.

  • Au clic sur « Importer », l'écran se fige 10 secondes puis Android propose de fermer l'application. Le code lit un fichier de 80 Mo dans le gestionnaire du clic. Quelle correction ?

    • Attraper l'exception avec un try/catch autour de la lecture du fichier dans le gestionnaire du clic
    • Lire le fichier dans une coroutine ou un thread de travail
    • Lire le fichier deux fois de suite pour s'assurer que son contenu est complet et valide
    • Demander à l'utilisateur la permission de stockage avant chaque lecture du fichier
    Voir la réponse

    Lire le fichier dans une coroutine ou un thread de travail

    Aucune exception n'est levée : le fil principal est simplement occupé. Un try/catch ne change rien à la durée. Le travail long doit quitter le fil principal, qui se contente d'afficher l'état et le résultat.

Réviser ce deck