review current best practice and add new one. move wip best practices on another branch

README.md

@@ -1,4 +1,4 @@
-# Bonne pratiques d'écoconception appliqué au mobile
+# Bonnes pratiques d'écoconception appliquées au mobile
 
 ## Contexte
 
@@ -18,8 +18,8 @@ N'hésitez pas à lire [le guide des contributeurs](CONTRIBUTING.md).
 * [Éliminer les fonctionnalités non essentielles](chapters/MBP_001_fr.md)
 * [Quantifier précisément le besoin](chapters/MBP_002_fr.md)
 * [Optimiser le parcours utilisateur](chapters/MBP_003_fr.md)
+* [Favoriser un design simple, épuré, adapté au mobile](chapters/MBP_005_fr.md)
 * [Préférer la saisie assistée à l'autocomplétion](chapters/MBP_004_fr.md)
-* [Favoriser un design simple, épuré, adapté au mobile](/chapters/MBP_005_fr.md)
 * [Optimiser la récupération en fonction du cycle de vie de l'application](chapters/MBP_006_fr.md)
 * [Libérer la mémoire des traitements consommateurs en fonction de l'état de l'application](chapters/MBP_007_fr.md)
 * [Déployer un Android App Bundle (AAB) plutôt qu'un APK](chapters/MBP_008_fr.md) // TODO a reformuler
@@ -44,39 +44,16 @@ N'hésitez pas à lire [le guide des contributeurs](CONTRIBUTING.md).
 * [Éviter les traitements trop complexes sur des données provenant d'un serveur](chapters/MBP_027_fr.md)
 * [Valider le code avec un Linter](chapters/MBP_028_fr.md)
 * [Supprimer les traductions non utilisées au sein des bibliothèques tierces (seulement pour les APK)](chapters/MBP_029_fr.md)
-* [avoriser les polices standards ou utiliser les "Downloadable font"](chapters/MBP_030_fr.md)
+* [Favoriser les polices standards ou utiliser les "Downloadable font"](chapters/MBP_030_fr.md)
 * [Éliminer les fonctionnalités non utilisées](chapters/MBP_031_fr.md)
 * [Limiter les outils d'analytics et les données collectées](/chapters/MBP_032_fr.md)
 * [Utiliser la version la plus récente du langage (Kotlin/Java) et du SDK Android](chapters/MBP_033_fr.md)
 * [Entretenir son application régulièrement](chapters/MBP_034_fr.md)
 * [Fournir une alternative textuelle aux contenus multimédias](chapters/MBP_035_fr.md)
-* [Éviter la lecture et le chargement automatique des vidéos et des sons](chapters/MBP_035_fr.md)
+* [Éviter la lecture et le chargement automatique des vidéos et des sons](chapters/MBP_036_fr.md)
-
+* [Adapter les sons/vidéo aux contextes d'écoute](chapters/MBP_037_fr.md)
-* // TODO : à écrire
+* [Optimiser les PDF](chapters/MBP_038_fr.md)
-
+* [Effectuer le téléchargement de fichiers volumineux via un réseau Wifi](chapters/MBP_039_fr.md)
-// MAIN/IO thread ?
-
-// Notifications
-
-//  ABI ??
-
-// Feature play store
-
-// Utiliser correctement implementation testImplementation debugImplementation pour ne pas packager des librairies utilisées uniquement pour les tests ou le debug
-
-// Reduce cost of inflation (ex ConstraintLayout instead of nested LinearLayout) https://developer.android.com/topic/performance/vitals/render#recyclerview_too_much_inflation_or_create_is_taking_too_long If your view types look good, look at reducing the cost of your inflation. Reducing unnecessary container and structural views can help. Consider building itemViews with ConstraintLayout, which can help reduce structural views.
-
-// TODO pas encore fait mais applicable au mobile
-
-* Monitorer la taille de l'application dans le temps (ex d'outil : https://github.com/JakeWharton/diffuse + le playstore)
-
-* [Utiliser la délégation d'évènements](/chapters/BP_044_fr.md)
-* [Optimiser les PDF](/chapters/BP_108_fr.md) // proposer le téléchargement de PDF plutôt que d'inclure un viewer de PDF (=> lib en moins, visibilité de toute façon inadaptée au mobile, peu accessible, personnes ont déjà une app permettant de lire les PDF)
-* [Adapter les sons/vidéo aux contextes d'écoute](/chapters/BP_112_fr.md) // et 114
-* [Mettre en place une politique d'expiration et suppression des données](/chapters/BP_4012_fr.md)
-* [Limiter le recours aux canvas](/chapters/BP_4013_fr.md)
-* [Coroutines / Scope / Lifecycle / annulation de traitement](/chapters/BP_4032_fr.md) // https://developer.android.com/topic/libraries/architecture/coroutines
-* [Préférer la pagination au défilement infini](/chapters/BP_4035_fr.md)
 
 
 ## Licence

chapters/BP_108_fr.md

@@ -1,45 +0,0 @@
-## Optimiser les PDF
-
-### Identifiants
-
-| GreenIT |  V2  |  V3  |  V4  |
-|:-------:|:----:|:----:|:----:|
-|   98   | 109  | 108  |      |
-
-### Catégories
-
-| Cycle de vie |  Tiers  |  Responsable  |
-|:---------:|:----:|:----:|
-| 5. Utilisation | Utilisateur/Terminal | Utilisateur |
-
-### Indications
-
-| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
-|:-------------------:|:-------------------------:|:---------------------:|
-| 3 | 3 | 3 |
-
-|Ressources Economisées                                      |
-|:----------------------------------------------------------:|
-|  Réseau / Stockage  |
-
-### Description
-
-S’assurer, avant leur mise en ligne, que les PDF sont réellement optimisés pour le Web : taux d’échantillonnage et de compression des images, polices incorporées, résolution…
-
-Le cas échéant, proposer le téléchargement des PDF chapitre par chapitre.
-
-Si vous souhaitez offrir à l’utilisateur de télécharger un lecteur PDF, préférer un logiciel léger tel que Sumatra (4,3 Mo) au lecteur d’Adobe (48 Mo), soit une bande passante divisée par 10 à chaque téléchargement et, surtout, une plus faible consommation de mémoire vive (ce qui permet de lutter contre la fracture numérique et l’obsolescence programmée).
-
-### Exemple
-
-Pour un rapport annuel en PDF :
- - vérifier que les images sont fortement compressées et à une résolution maximale de 72 dpi ;
- - n’inclure que les principales polices ;
- - découper le rapport en chapitres, afin de limiter les téléchargements inutiles.
-
-
-### Principe de validation
-
-| Le nombre ...     | est inférieur ou égal à   |  
-|-------------------|:-------------------------:|
-| de PDF non optimisés  |  0 |

chapters/MBP_001_fr.md

@@ -16,9 +16,9 @@ Bonne pratique originale : [BP_001](https://github.com/cnumr/best-practices/blob
 |:-------------------:|:-------------------------:|:---------------------:|
 | 5 | 4 | 5 |
 
-|Ressources Economisées                                      |
+|                 Ressources Economisées                  |
-|:----------------------------------------------------------:|
+|:-------------------------------------------------------:|
-|Processeur / Mémoire vive / Stockage / Réseau / Requêtes    |
+|      Processeur / Mémoire vive / Stockage / Réseau      |
 
 ### Description
 Plusieurs études (Cast Software et Standish Group, notamment) démontrent que 70 % des fonctionnalités demandées par les utilisateurs ne sont pas essentielles et que 45 % ne sont jamais utilisées. En réduisant la couverture et la profondeur fonctionnelle de l’application, on abaisse son coût de développement initial, sa dette technique et les impacts environnementaux associés.

chapters/MBP_004_fr.md

@@ -16,9 +16,9 @@
 |:-------------------:|:-------------------------:|:---------------------:|
 | 3 | 3 | 3 |
 
-|Ressources Economisées                                      |
+| Ressources Economisées |
-|:----------------------------------------------------------:|
+|:----------------------:|
-| Requêtes    |
+|         Réseau         |
 
 ### Description
 

chapters/MBP_010_fr.md

@@ -60,5 +60,6 @@ android {
 ### Principe de validation
 
 | Le nombre ...              | est inférieur ou égal à |  
-|-----------------------------------|:-----------------------:|
+|----------------------------|:-----------------------:|
 | de fichiers non minifiés   |           25%           |
+| de ressources inutilisées  |           25%           |

chapters/MBP_014_fr.md

@@ -40,12 +40,36 @@ A contrario, il faut éviter d'utiliser la fonction `notifyDataSetChanged()` qui
 2. Si le code pour déterminer la position des éléments à modifier est complexe, `ListAdapter` intègre directement un mécanisme calculant la différence entre deux listes via `DiffUtil` pour ne modifier que les éléments concernés. 
 
 
+Avec Jetpack Compose : 
+1. L'association du `key` unique a chaque élément d'une `LazyList` permet à Compose d'optimiser la réutilisation des cellules d'une liste en cas de réagencement des éléments de la liste.
+
+```kotlin
+LazyColumn {
+    items(
+        items = datas,
+        key = { data ->
+            data.id
+        }
+    ) { data ->
+        Cell(data)
+    }
+}
+
+```
+
+
+2. étant donné que les collections de type `List`, `Set` et `Map` sont considéré comme instable par le compilateur, une bonne pratique consiste à utiliser la bibliothèque Kotlinx immutable collections ou d'annoter les paramètres de type liste par `@Immutable` ou `@Stable`. Cela permet de garantir au compilateur de la stabilité des paramètres et ainsi de réduire le nombre de recomposition inutile.
+
+
 ### Exemple
 
 * [Article](https://medium.com/androiddevelopers/adapting-to-listadapter-341da4218f5b) expliquant la mise en place de `ListAdapter` 
+* [Lazy list keys - Jetpack Compose - Documentation](https://developer.android.com/develop/ui/compose/lists#item-keys)
+* [Stabilité - Jetpack Compose - Documentation](https://developer.android.com/develop/ui/compose/performance/stability#summary)
 
 ### Principe de validation
 
 | Le nombre ...                                                                             | est inférieur ou égal à   |  
-|---------------------------------------------------------------------------------------------|:-------------------------:|
+|-------------------------------------------------------------------------------------------|:-------------------------:|
 | d'écran utilisant la fonction `notifyDataSetChanged` pour recharger les données d'une liste |  0% |
+| de recomposition inutile d'une liste                                                      |  0% |

chapters/MBP_020_fr.md

@@ -22,8 +22,8 @@
 
 ### Description
 
-Un pixel a l'écran peut être dessiné ("Draw") plusieurs fois durant le processus chargé d'afficher l'interface exacte à l'écran. Le fait de redessiner plusieurs fois un pixel est appelé "Overdraw". Pour réduire le nombre de Redraw et ainsi soulager le processeur, il convient d'éviter ce genre de pratique : 
+Un pixel a l'écran peut être dessiné ("Draw") plusieurs fois durant le processus chargé d'afficher l'interface exacte à l'écran. Le fait de redessiner plusieurs fois un pixel est appelé "Overdraw". Pour réduire le nombre de Redraw et ainsi soulager le processeur, il convient d'appliquer ce genre de pratique : 
-* Ajouter un fond a un layout via la propriété `background` si celui-ci est ensuite recouvert complétement par ses enfants.
+* Ne pas ajouter un fond a un layout via la propriété `background` si celui-ci est ensuite recouvert complétement par ses enfants.
 * Réduire l'imbrication de layout. Par exemple utiliser un `ConstraintLayout` plutôt que plusieurs `LinearLayout` imbriqués permet d'éviter ce genre de situation.
 * Réduire le nombre de composants utilisant la transparence (propriété `alpha`). En effet, pour afficher un pixel en appliquant une valeur d'alpha, le processeur dessine d'abord le pixel sans alpha, avant de redessiner le pixel en appliquant le bon calcul pour la couleur.
 
@@ -33,8 +33,8 @@ Un pixel a l'écran peut être dessiné ("Draw") plusieurs fois durant le proces
 * Pour afficher un texte en gris, plutôt que de définir la couleur du composant `TextView` en noir, et de lui appliquer un niveau de transparence via le paramètre `alpha`, définir plutôt la couleur du texte en gris directement.
 
 Pour aller plus loin :
-https://developers.google.com/speed/articles/reflow
 
+[Overdraw - Documentation](https://developer.android.com/topic/performance/rendering/overdraw)
 
 ### Principe de validation
 

chapters/MBP_021_fr.md

@@ -8,7 +8,7 @@
 
 | Cycle de vie |  Tiers  |  Responsable  |
 |:---------:|:----:|:----:|
-| 2. Conception | Réseau | Architecte Logiciel/Développeur |
+| 3. Réalisation (fabrication / développement) | Utilisateur/Terminal | Architecte Logiciel/Développeur |
 
 ### Indications
 

chapters/MBP_023_fr.md

@@ -28,7 +28,9 @@ Réduire le volume de données stockées au nécessaire consiste à :
 
 ### Exemple
 
-Par exemple une application de streaming qui propose le téléchargement d'un film ou d'une série associe une durée de vie de 30 jours au contenu. Une tâche est programmée 30 jours plus tard grâce au [WorkManager](https://developer.android.com/topic/libraries/architecture/workmanager) afin de supprimer le fichier.
+Par exemple une application de streaming qui propose le téléchargement d'un film ou d'une série peut : 
+* Associer une durée de vie de 30 jours au contenu. Une tâche est programmée 30 jours plus tard grâce au [WorkManager](https://developer.android.com/topic/libraries/architecture/workmanager) afin de supprimer le fichier.
+* Supprimer le fichier une fois que le média a été visionné entièrement.
 
 ### Principe de validation
 

chapters/MBP_027_fr.md

@@ -7,7 +7,7 @@
 
 | Cycle de vie |  Tiers  |  Responsable  |
 |:---------:|:----:|:----:|
-| 2. Conception | Réseau | Architecte Logiciel/Développeur |
+| 3. Réalisation (fabrication / développement) | Utilisateur/Terminal | Architecte Logiciel/Développeur |
 
 ### Indications
 
@@ -36,7 +36,7 @@ Dans ce genre de situation, il peut être intéressant de développer côté ser
 // TODO
 
 ### Principe de validation
-
 | Le nombre ...                                                                       | est inférieur ou égal à   |  
 |-------------------------------------------------------------------------------------|:-------------------------:|
 | de traitements de données complexe exécutés en dehors du serveur |  1 |
+

chapters/MBP_035_fr.md

@@ -29,7 +29,6 @@ Si cette alternative textuelle a elle-même une taille importante, elle peut ne
 
 Cette pratique est également bénéfique pour l'accessibilité : les mal entendants pourront lire le contenu et y auront donc accès, de même pour les mal voyants, si le texte inclut une description des éléments des vidéos qui ne sont que visibles.
 
-Cette pratique est également bénéfique pour le référencement, les moteurs de recherche pouvant plus facilement analyser le texte que l'audio et la vidéo.
 
 Voir aussi sur le même sujet la pratique « Eviter la lecture automatique des vidéos et des sons »
 

chapters/MBP_037_fr.md

@@ -0,0 +1,45 @@
+## Adapter les sons aux contextes d'écoute
+
+### Identifiants
+
+| GreenIT |  V2  |  V3  |  V4  |
+|:-------:|:----:|:----:|:----:|
+|      |   |   |      |
+
+### Catégories
+
+| Cycle de vie |  Tiers  |  Responsable  |
+|:---------:|:----:|:----:|
+| 5. Utilisation | Utilisateur/Terminal | Utilisateur |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 2 | 2 | 3 |
+
+| Ressources Economisées |
+|:----------------------:|
+|    Réseau/Stockage     |
+
+### Description
+
+Les fichiers audio peuvent être volumineux et consommateurs d'espace disque s'ils sont stockés localement ou de bande passante s'ils sont fournis par un serveur. Aussi il est indispensable d’en optimiser le poids. Privilégier 3 formats couvrant les 3 grandes plates-formes (Windows, Mac OS X et Linux) :
+- MP3 (MPEG-1 Audio Layer 3) ;
+- AAC (Advanced Audio Coding) ;
+- OGG Vorbis.
+  Ces formats appliquent des algorithmes de compression très évolués permettant des gains de poids significatifs.
+
+### Exemple
+
+Des encodeurs comme LAME permettent de convertir au format MP3 des fichiers audio non compressés, mais également de jouer sur le taux d’échantillonnage, afin de gagner encore du poids, au détriment de la qualité audio. À tester sur chaque fichier sonore.
+
+Dans le cas d’un fichier de référence WAV son.wav de 63 128 octets, sa conversion en MP3 donne :
+- un fichier son-128.mp3 de 10 823 octets (128 kb/s), 6 fois plus léger ;
+- un fichier son-64.mp3 de 6 508 octets (64 kb/s), 10 fois plus léger.
+
+### Principe de validation
+
+| Le nombre ...     | est inférieur ou égal à   |  
+|-------------------|:-------------------------:|
+| de codecs audio propriétaires (non libres) et de pistes audio dont le ratio poids en mega octet/durée en minute est superieur a 1  | 0  |

chapters/MBP_038_fr.md

@@ -0,0 +1,40 @@
+## Optimiser les PDF
+
+### Identifiants
+
+| GreenIT |  V2  |  V3  |  V4  |
+|:-------:|:----:|:----:|:----:|
+|      |   |   |      |
+
+### Catégories
+
+| Cycle de vie |  Tiers  |  Responsable  |
+|:---------:|:----:|:----:|
+| 5. Utilisation | Utilisateur/Terminal | Utilisateur |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 3 | 3 | 3 |
+
+|Ressources Economisées                                      |
+|:----------------------------------------------------------:|
+|  Réseau / Stockage  |
+
+### Description
+
+S’assurer, que les PDF sont réellement optimisés pour le mobile : taux d’échantillonnage et de compression des images, polices incorporées, résolution…
+
+De plus, étant donné que la lecture d'un PDF sur un mobile est peu aisée, à choisir, préférez intégrer une fonctionnalité dans votre application qui permet de télécharger ce PDF plutôt que d'incorporer un lecteur de PDF au sein de votre application. Vous obtiendrez ainsi les bénéfices suivants : 
+* Vous n'aurait pas besoin d'inclure ce lecteur de PDF à votre application, réduisant ainsi sa taille,
+* L'utilisateur pourra choisir de l'ouvrir avec une application conçue spécialement pour la lecture,
+* Vous améliorerez l'accessibilité de votre application, car les bibliothèques permettant d'inclure un PDF dans une application le sont rarement, contrairement aux applications dédiées qui offrent des fonctionnalités qui adaptent par exemple la taille du texte pour être lisible à l'écran sans devoir zoomer.
+
+
+### Principe de validation
+
+| Le nombre ...                                       | est inférieur ou égal à   |  
+|-----------------------------------------------------|:-------------------------:|
+| de PDF non optimisés                                |  0 |
+| de visionneuse de PDF inclue directement dans l'app |  0 |

chapters/MBP_039_fr.md

@@ -0,0 +1,35 @@
+## Effectuer le téléchargement de fichiers volumineux via un réseau Wifi
+
+### Identifiants
+
+| GreenIT |  V2  |  V3  |  V4  |
+|:-------:|:----:|:----:|:----:|
+|      |   |   |      |
+
+### Catégories
+
+| Cycle de vie |  Tiers  |  Responsable  |
+|:---------:|:----:|:----:|
+| 5. Utilisation | Utilisateur/Terminal | Utilisateur |
+
+### Indications
+
+| Degré de priorité |      Mise en oeuvre       |  Impact écologique    |
+|:-------------------:|:-------------------------:|:---------------------:|
+| 3 | 3 | 3 |
+
+| Ressources Economisées |
+|:----------------------:|
+|        Batterie        |
+
+### Description
+
+Le téléchargement de données sur un réseau GSM consomme plus d'énergie que via un réseau Wi-fi. Cette énergie est fournie par la batterie du téléphone, qui selon la qualité du signal et la distance avec l'antenne émettrice doit parfois redoubler d'effort. Si votre application propose de télécharger depuis un serveur un contenu relativement volumineux (par exemple un fichier audio ou vidéo), il convient de laisser la possibilité à l'utilisateur d'effectuer cette action que s'il dispose d'une connexion Wi-fi
+
+[Article - Does mobile battery drain faster on mobile data or Wi-fi](https://www.scienceabc.com/innovation/does-mobile-battery-drain-faster-on-mobile-data-or-wi-fi.html)
+
+### Principe de validation
+
+| Le nombre ...                                                                                                                 | est inférieur ou égal à   |  
+|-------------------------------------------------------------------------------------------------------------------------------|:-------------------------:|
+| de fonctionnalité proposant le téléchargement de fichiers volumineux ne s'effectuant pas systématiquement via un réseau Wi-fi |  0 |