How an #Android pro would work.. If I were one

Some principles, patterns, and good practices that you may follow if you want to become "a pro"

Transcript

1. How an #Android “Pro” would Work... … If I were one Víctor Olmo Gallegos Hernández Mobile developer at AppAndWeb Olmo Gallegos @voghDev
2. #AndroidDev like engineers Víctor Olmo Gallegos Hernández Mobile Developer - AppAndWeb Olmo Gallegos @voghDev mobiledevstories.com Vol. II Also known as...
3. About the speech Motivation (The problem) Becoming “a pro” The theory The tools Applying the theory: Approaches
4. About the speech Motivation (The problem) Becoming “a pro” The theory The tools Applying the theory: Approaches
5. An Engineer (or a group of them) builds a (presumably expensive) unmaintainable code base, with zero or low test coverage Application has to be rebuilt / redesigned several times (meaning the whole Application, not the UI) Many lead companies had to face the painful challenge of rebuilding! The (most usual) problem
6. Some examples... 2k/3kLOC God Activities / Fragments Strongly coupled spaghetti code Deficient (or lack of) architecture Incorrect design patterns - Common antipatterns (Singleton invasion, Observer / SRP violations...) Context misuse (memory leaks) More info: see S.T.U.P.I.D.
7. About the speech Motivation (The problem) Becoming “a pro” The theory The tools Applying the theory: Approaches
8. S.O.L.I.D. Single Responsibility Principle Open-Closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle - Talking about this since 2014, concept is much older - early 2000 - Robert C. Martin
9. S.O.L.I.D. Single Responsibility Principle Open-Closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle - Talking about this since 2014, concept is much older - early 2000 - Robert C. Martin
10. Design Patterns
11. Design Patterns Singleton Builder Abstract Factory Creation Adapter Facade Observer Command NullObject Repository Model-View-Presenter Behaviour Structure http://www.slideshare.net/PedroVicenteGmezSnch/software-design-patterns-on-android
12. “You won’t learn how to use a Design Pattern until you have implemented it the wrong way” Victor Olmo Gallegos Hernández - “Personal reflection“
13. “You won’t learn how to use a Design Pattern until you have implemented it the wrong way” Victor Olmo Gallegos Hernández - “Personal reflection“ misimplemented it
14. “You won’t learn how to use a Design Pattern until you have implemented it the wrong way” Victor Olmo Gallegos Hernández - “Personal reflection“ misimplemented it
15. Model-View-Presenter: Motivation Model-View-Controller
16. Model-View-Presenter: Motivation Model-View-Controller Expectation
17. Model-View-Presenter: Motivation Model-View-Controller Expectation Reality View and Controller are tightly coupled! Controller knows too much Taken from iOS article. Appliable to Android and other frameworks https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52
18. Model-View-Presenter: Motivation Model-View-Controller Expectation Reality View and Controller are tightly coupled! Controller knows too much Taken from iOS article. Appliable to Android and other frameworks https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52
19. Model-View-Presenter: Graphically
20. Model-View-Presenter: Graphically
21. Model-View-Presenter: Graphically
22. Model-View-Presenter Model-View-Presenter Model-View-Controller natural extension. The usage of the App is modeled as an interaction between two main actors: the View and the Presenter. Activities / Fragments / CustomViews implement the abstract View class (do not confuse with android.view.View) Presenter represents the events that can happen to the App (onItemClicks, onDataReceived, onCreate). View represents the reactions to these events (showLoading, hideLoading, showUsersList, showErrorMessage, showPushDialog).
23. Model-View-Presenter
24. Model-View-Presenter
25. Principles
26. DRY principle "Duplicate code is the root of all evil in software design. When a system is littered with many snippets of identical, or nearly identical code, it is indicative of sloppiness, carelessness, and sheer unprofessionalism. It is the guilt-edged responsibility of all software developers to root out and eliminate duplication whenever they find it." Robert C. Martin, “Clean Code - A handbook of agile Software Craftmanship”
27. DRY principle - “Duplication is far cheaper than the wrong abstraction” - Concept of premature optimization - Overengineering http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction
28. “You don’t know how to abstract properly until you have done enough wrong abstractions” Victor Olmo Gallegos Hernández - “Personal reflection“
29. Demeter’s Law
30. Demeter’s Law A function f() inside a class C may only call methods of these: • C • an object created by f() • an object passed to f() as argument • an instance variable of C public class C { public void f() { // ... } }
31. This slide has been removed... d8)
32. What “pros” don’t do... Strongly framework-coupled classes “S” from S.O.L.I.D. constantly violated ...or try to avoid at all costs
33. What “pros” don’t do... Strongly framework-coupled classes Impossible to Test Difficult to change behavior or add features + DB logic in UI thread ! ...or try to avoid at all costs
34. Tips / advices - Abstractions are always a good idea - Watch out for premature optimization - Avoid deep class hierarchies - Go with the “L” (do Liskov exchanges) - Expose your dependencies - Depend on abstractions, never concretions
35. Tips / advices - Abstractions are always a good idea - Watch out for premature optimization - Avoid deep class hierarchies - Go with the “L” (do Liskov exchanges) - Expose your dependencies - Depend on abstractions, never concretions
36. Tips / advices - Abstractions are always a good idea - Watch out for premature optimization - Avoid deep class hierarchies - Go with the “L” (do Liskov exchanges) - Expose your dependencies - Depend on abstractions, never concretions
37. Tips / advices - Abstractions are always a good idea - Watch out for premature optimization - Avoid deep class hierarchies - Go with the “L” (do Liskov exchanges) - Expose your dependencies - Depend on abstractions, never concretions
38. Tips / advices - W 1, R&M ∞ - Focus on writing testable code - Cover as much as possible with Tests
39. The tools
40. “Pros” work with the community! - By using third-party libraries - By contributing to them / sending them Pull Requests - By developing their own libraries - By trolling opening issues or resolving existing ones
41. Some essential third-party libraries • retrofit / retrofit2 • okhttp3 • picasso • butterknife • dagger2 • RecyclerView • design-lib • espresso • JUnit • Mockito • Glide • parceler • SectionedRecyclerView / FABRevealLayout • WheelIndicatorView / QRCodeReaderView • Contributions from myself - next slide 0:-) (Tomás Ruiz-López) (David Lázaro Esparcia) Libs “Made in Granada”
42. Some third-party libs made (with ) by myself ^o^ https://github.com/voghDev/PdfViewPager https://github.com/voghDev/ProgressButtonView
43. Some third-party libs made (with ) by myself ^o^ https://github.com/voghDev/PdfViewPager https://github.com/voghDev/ProgressButtonView
44. PdfViewPager issues from users
45. PdfViewPager issues from users
46. PdfViewPager issues from users
47. dagger2 - Dependency Injection framework • Components • Modules • Any receiver class (normally Activities / Fragments / Views) Component Module Module Activity Fragment Presenter
48. dagger2 - Dependency Injection framework
49. dagger2 - Dependency Injection framework
50. Custom Views (plus styleables) - Excellent separation of responsibility - Do extensive use of them - Three ways of implementing: 1. Extending from Widgets (TextView, ImageView, EditText…) 2. Extending from Layout / ViewGroup, inflating XML layout 3. Extending from View and overriding onDraw to paint on canvas - Don’t forget to abstract when possible! - Example: ProgressButtonView (2.) - WheelIndicatorView (3.) https://speakerdeck.com/voghdev/number-androiddev-like-engineers
51. Some conventions that most “pros” follow - Strict package, class, var, layout, view naming. Never violate it! - Package distribution - iterate / choose the one that fits best - Checkstyle - Gradle flavors - BuildConfig vars https://github.com/voghDev/dagger2-clean-mvp-example/
52. Android Studio is your (very best) friend - Shortcuts • Alt+A > Search everywhere • Alt+J > God (in form of Android Studio shortcut) • (2x) Shift > Search everywhere • (2x) Ctrl+Shift+S > Extract style • Alt+Shift+Up/Down > Move line up / down • Ctrl+D > Duplicate line • (2x) Ctrl+Shift+G > Generate Signed APK • Shift+F6 > Refactor - Rename... • Alt+Enter (some usages in the next slide)
53. Android Studio is your (very best) friend - Shortcuts • Alt+A > Search everywhere • Alt+J > God (in form of Android Studio shortcut) • (2x) Shift > Search everywhere • (2x) Ctrl+Shift+S > Extract style • Alt+Shift+Up/Down > Move line up / down • Ctrl+D > Duplicate line • (2x) Ctrl+Shift+G > Generate Signed APK • Shift+F6 > Refactor - Rename... • Alt+Enter (some usages in the next slide)
54. Android Studio is your (very best) friend - Shortcuts • Alt+A > Search everywhere • Alt+J > God (in form of Android Studio shortcut) • (2x) Shift > Search everywhere • (2x) Ctrl+Shift+S > Extract style • Alt+Shift+Up/Down > Move line up / down • Ctrl+D > Duplicate line • (2x) Ctrl+Shift+G > Generate Signed APK • Shift+F6 > Refactor - Rename... • Alt+Enter (some usages in the next slide) Special thanks to @jrgonzalez (Quadbits) for telling me about Alt+J !!
55. Android Studio is your (very best) friend - Shortcuts • Alt+ Enter ➢ Implement abstract class ➢ Create field / local var / method ➢ declare public / protected ➢ Add braces to if statement
56. Android Studio is your (very best) friend - Live templates (Available in https://github.com/voghDev/DevFestTalks/tree/master/settings) ✓ They save us precious time ✓ Risky when code is not clean! - Act as an effective “boilerplate machinegun” • datasource • presenter • presenter-impl • renderers An interesting talk: http://www.slideshare.net/everywaretech/weapons-for-boilerplate-destruction
57. Android Studio is your (very best) friend - Live templates (Available in https://github.com/voghDev/DevFestTalks/tree/master/settings) ✓ They save us precious time ✓ Risky when code is not clean! - Act as an effective “boilerplate machinegun” • datasource • presenter • presenter-impl • renderers An interesting talk: http://www.slideshare.net/everywaretech/weapons-for-boilerplate-destruction
58. More approaches that many “pros” follow - Rosie - A full MVP implementation made by @goKarumi, based on CLEAN architecture - RxJava - “Java library for asynchronous programming with observable streams” - MVVM - Another interesting architectural pattern, alternative to MVP - Scala on Android - applying this Lightweight Functional Programming language for #AndroidDev - Kotlin - Concise, simple and very easy to read Programming language made by JetBrains
59. Summing up - Nobody leaves this room “being a pro”, neither do I - If you have gained some “experience points” and feel motivated to start improving your coding skills, that’s definitely a win - Feel free to come and ask me, or reach me via email: olmo@appandweb.es
60. Credits and Links - Swordfigthing with dagger: https://realm.io/news/360andev-mike-nakhimovich-swordfighting-dagger-dependency-injection-android/ - Android architecture blueprints: https://github.com/googlesamples/android-architecture/ - Very skilled android architectures and good practices: http://www.quadbits.com - Rosie - Android framework to create applications following the principles of CLEAN architecture: https://github.com/Karumi/Rosie - All the credited talks and repos in https://github.com/voghDev/dagger2-clean-mvp-example - Ez video to gif converter: http://ezgif.com/video-to-gif/
61. Thanks for coming, folks!
62. Thanks for coming, folks!
63. Questions and answers
64. Questions and answers
65. Appendix
66. Basic CLEAN architecture