Pour ce deuxième épisode, Benjamin et Yannick se retrouvent pour discuter des bonnes pratiques en Android.
Show notes
0:38″ – Ne pas créer trop de petits objets : https://developer.android.com/training/articles/perf-tips.html
1:05″ – Garbage Collector de Dalvik : https://source.android.com/devices/tech/dalvik/gc-debug.html
1:52″ – Éviter de créer des objets dans OnDraw : https://developer.android.com/training/custom-views/custom-drawing.html
Creating objects ahead of time is an important optimization. Views are redrawn very frequently, and many drawing objects require expensive initialization. Creating drawing objects within your onDraw() method significantly reduces performance and can make your UI appear sluggish
3:18″ – Autoboxing en java : http://lroux.developpez.com/article/java/tiger/?page=page_2#Lautoboxing
4:25″ – SparseArray : https://developer.android.com/reference/android/util/SparseArray.html
8:49″ – SparseIntArray : https://developer.android.com/reference/android/util/SparseIntArray.html
9:25″ – SparseArrayCompat : https://developer.android.com/reference/android/support/v4/util/SparseArrayCompat.html
13:53″ – Les Enums en Java – https://openclassrooms.com/courses/apprenez-a-programmer-en-java/les-enumerations-1
15:28″ – La polémique autour des Enums – https://plus.google.com/+JakeWharton/posts/bTtjuFia5wm
16:11″ – ProGuard peut transformer les Enums en entier : http://proguard.sourceforge.net/manual/optimizations.html
16:27″ – IntDef : https://developer.android.com/reference/android/support/annotation/IntDef.html
20:19″ – « Discussion » avec Dan Lew sur les Enums : https://github.com/trello/navi/pull/52
28:17″ – Classes internes et anonymes : https://docs.oracle.com/javase/tutorial/java/javaOO/innerclasses.html
29:29″ – AsyncTask : https://developer.android.com/reference/android/os/AsyncTask.html
30:25″ – le mot clé static sur les classes internes : http://imss-www.upmf-grenoble.fr/prevert/Prog/Java/CoursJava/classes3.html
30:57″ – WeakReference : https://developer.android.com/reference/java/lang/ref/WeakReference.html
45:06″ – Notation hongroise : https://fr.wikipedia.org/wiki/Notation_hongroise
57:09″ – Package par feature ou component : https://www.javacodegeeks.com/2013/04/package-your-classes-by-feature-and-not-by-layers.html
57:59″ – Modèle Vue Contrôleur (MVC) : https://fr.wikipedia.org/wiki/Modèle-vue-contrôleur
59:53″ – Les modules en Zend Framework 1 : https://framework.zend.com/manual/1.12/fr/zend.controller.modular.html
1:04:53″ : Modèle Vue Présentateur (MVP) : https://fr.wikibooks.org/wiki/Patrons_de_conception/Modèle-Vue-Présentateur
1:05:17″ – Modèle Vue Vue Modèle (MVVM) : https://openclassrooms.com/courses/creez-des-applications-en-c-pour-windows-phone-8/mvvm
1:05:24″ – « Dragon je sais plus quoi » (VIPER) : https://www.objc.io/issues/13-architecture/viper/
1:08:44″ – Héritage vs Composition : http://gfx.developpez.com/tutoriel/java/composition/
1:12:53″ – SOLID : https://fr.wikipedia.org/wiki/SOLID_(informatique)
Glossaire
Automagique : (Par plaisanterie) Se dit de processus (surtout informatiques ou technologiques) qui sont automatiques et apparemment magiques (parce que le spectateur ne sait pas du tout comment procéder s’il avait à le faire lui-même) – http://fr.wiktionary.org/wiki/automagique
Bonus – Jeu à boire (18+)
- Boire un shot à chaque fois que Yannick dit : « En règle générale »
- Boire un shot à chaque fois que Benjamin dit : « Et-cetera«
Et rappelez-vous: L’abus d’alcool est dangereux pour la santé, consommez avec modération.
Encore un bon épisode. Belle découverte des SparseArray et l’autoboxing. C’était très clair et bien exprimé.
La partie SOLID mérite effectivement un épisode entier 🙂
Continuez les gars
Un tout grand merci pour tes commentaires, cela nous fait extrêmement plaisir de savoir que tu apprécies nos épisodes et qu’ils sont utiles 🙂
Merci à vous de prendre le temps de faire un podcast en Français !
Je pense que ça peut pas mal aider les plus jeunes qui débutent et qui n’auraient pas encore succombé à la suprématie de l’Anglais technique à entendre parler de principes et de bonnes méthodes qui les suivront tout au loin de travaux/passion.
Juste un point : Si vous pouviez indiquer plus clairement lorsque vos propos tiennent de vos opinions ou d’explications objectives. Pour ceux qui découvrent les points que vous énoncez, je trouve qu’on passe un peu vite de la présentation/explication à « moi j’aime/j’utilise parce que » ou « sur mon projet, il ne faut pas le faire ». Ça pourrait rebuter certains d’approfondir lessujets parce qu’ils paraîtraient mauvais alors qu’ils ne sont justes peut-être pas adaptés à une/votre situation donnée. Mais bon, je dis ça pour chipoter 😉
Bonjour et merci pour ton commentaire 🙂
Nous espérons pouvoir aider autant les débutant que les personnes plus avancées mais il est vrai que nous ne sommes pas encore beaucoup rentrés dans des détails plus techniques. Cependant, nous avons des épisodes un peu plus « touffus » qui devraient bientôt arriver 🙂
Ta remarque est très juste, nous manquons encore un peu de structure et il est vrai que notre format est beaucoup plus proche de la discussion que de l’enseignement. Malgré tout, c’est le format que je pense que nous allons garder mais en essayant d’être plus structurés. De plus, nous essayons à travers le show note assez complet de donner des liens et des pistes aux gens qui ne seraient pas familiers avec nos propos de découvrir plus par eux même.
Enfin, je serais très intéressé d’entendre ta vision des choses sur les points que nous avons jugés mauvais ou mal adaptés. Cela nous permettra, mais aussi aux autres auditeurs, d’avoir un autre son de cloche. En effet, ce podcast est une occasion d’apprendre pour nous tous 🙂
En tout cas, encore merci de prendre la peine de nous écrire pour nous donner ton avis, c’est réellement très apprécié 🙂
Bonjour,
Je pense que le format « discussion » est aussi l’une des forces du podcast. Ça évite d’avoir à écouter un cours magistral et rend l’émission plus dynamique.
Je ne saurais redire les points en question (j’ai écouté le podcast en voiture il y a plusieurs jours déjà) mais de mémoire tout ce qui concernait l’usage des inner classes et anonymous classes sans aborder les raisons de leurs existences (SPI dans le cas des listeners, mais pas seulement). Ou même l’héritage versus la délégation qui peut faire débat dès l’instant que la délégation n’est en réalité qu’une composition (comme peut laisser l’entendre votre exemple de factorisation) : j’entends par là que le code commun devient juste un composant et où le service qu’il offre ne fait plus parti de l’interface du composé ce qui nuit à la cohérence de son comportement (là ou elle était assuré par le contrat de l’héritage).
Encore une fois, ce ne sont que des détails ! Mais à balayer tant de sujets, il doit être dur de penser à tous les cas. Dans tous les cas, bon courage à vous pour la suite =)