#AndroidDev like Engineers

Initiation-level speech for novice / intermediate developers who want to improve their Android Development process and follow some widely extended and recommended principles.

Transcript

1. #AndroidDev like engineers Víctor Olmo Gallegos Hernández Mobile Developer - AppAndWeb Olmo Gallegos @voghDev mobiledevstories.com
2. About the speech Motivation Framework-independent aspects Framework-dependent aspects
3. About the speech Motivation Framework-independent aspects Framework-dependent aspects
4. Motivation Engineers doing really bad code. (I know it because i’ve done it myself) Programming is not easy !! even less doing it well Result: Engineers with very strong base, but...
5. Motivation Engineers doing really bad code. (I know it because i’ve done it myself) Programming is not easy !! even less doing it well Result: Engineers with very strong base, but... Coding like plumbers
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. EXPECTED
8. EXPECTED REALITY
9. EXPECTED
10. EXPECTED REALITY
11. Result Very unmaintainable code Project lives for 6 months and has to be fully rebuilt Very hard to add a simple features, high chance of breaking another ones
12. Solution ?
13. Solution ? NOPE There ain’t such “Solution”
14. What can we do then?
15. What can we do then? Let’s start with the….
16. About the speech Motivation Framework-independent aspects Framework-dependent aspects
17. SOLID
18. SOLID
19. SOLID
20. SOLID
21. SOLID
22. Single responsibility principle (SRP) Open-closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle SOLID
23. Single responsibility principle Open-closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle SOLID
24. Single responsibility principle Open-closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle SOLID
25. Single responsibility principle (SRP) Basic programming principle: classes that do just one thing. A class or module should have one, and only one, reason to change. “No side effects” - my class must not be affected by changes in another classes “First rule of functions: They should be small Second rule: They should be smaller than that” SOLID
26. Single responsibility principle Open-closed principle (OCP) Liskov substitution principle Interface segregation principle Dependency inversion principle SOLID
27. Open-closed principle (OCP) Classes should be open for extension, and closed for modification The “Five lines of code” example. We’ll see examples of this l8r. SOLID
28. Single responsibility principle Open-closed principle (OCP) Liskov substitution principle Interface segregation principle Dependency inversion principle SOLID
29. Liskov Substitution Principle (LSP) A class should be substitutable by instances of its derivatives without altering the correctness of the program. SOLID
30. Single responsibility principle Open-closed principle (OCP) Liskov substitution principle Interface segregation principle Dependency inversion principle SOLID
31. Interface Segregation Principle Interfaces should be as simple as possible “Clients should not be forced to depend upon interfaces that they do not use” Counterexample: PagerAdapter SOLID
32. Interface Segregation Principle SOLID
33. Single responsibility principle Open-closed principle (OCP) Liskov substitution principle Interface segregation principle Dependency inversion principle SOLID
34. Dependency Inversion Principle Always depend on abstractions, not on concretions SOLID
35. Dependency Inversion Principle Always depend on abstractions, not on concretions SOLID
36. Dependency Inversion Principle Always depend on abstractions, not on concretions SOLID
37. Dependency Inversion Principle Always depend on abstractions, not on concretions SOLID
38. Dependency Inversion Principle Always depend on abstractions, not on concretions SOLID
39. Design Patterns
40. Design Patterns Singletons Observer Repository Builder NullObject Model-View-Presenter
41. Design Patterns Singletons are DANGEROUS! Observer Repository Builder NullObject Model-View-Presenter
42. Design Patterns Singletons are DANGEROUS! Android SDK provides you various methods for managing your scopes. You probably won’t need to write this code The S in S.T.U.P.I.D. is for Singleton!
43. Design Patterns Singletons Observer Repository Builder NullObject Model-View-Presenter
44. Design Patterns 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).
45. Design Patterns 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).
46. Model-View-Presenter
47. Design Patterns Model-View-Presenter Sadly, we’re not talking about MVP in more depth (though we should, it is probably the most interesting pattern) “We’re leaving the best pig without acorns”
48. Solid… Design Patterns...
49. CLEAN architecture Uncle Bob’s abstract architecture Plenty of example implementations on GitHub
50. About the speech Motivation Framework-independent aspects Framework-dependent aspects
51. ➙ Naming conventions ➙ CustomViews + styleables ➙ Styles ➙ Package distribution ➙ One Model per subsystem! ➙ Android studio features ➙ Mastering gradle ➙ Some interesting external libraries ◆ RecyclerView ◆ Picasso / Glide ◆ butterknife ◆ Android design library (Material stuff like Toolbar, CoordinatorLayout, Fab’s) Framework-dependent aspects ◆ retrofit2 ◆ dagger2 ◆ renderers ◆ DBFlow
52. Widgets: @+id/customers_listView @+id/customers_tv_name @+id/customer_iv_picture Naming conventions Create your own naming conventions, based on existing Android ones! Activities: YourOwnNameActivity (e.g. CustomerDetailActivity) Fragments: YourOwnNameFragment (e.g. CustomersFragment) CustomViews: YourOwnNameView (e.g. CustomerProfileView) Layouts: activity_your_own_name.xml fragment_your_own_name.xml view_your_own_name.xml
53. Naming conventions: Pros • Runtime errors can be brought to compilation time • Helps detecting code smells (if your activity/fragment/view doesn’t fit in the naming conventions, you’re probably doing it wrong) • Avoids NPEs and other errors due to name clashes (R.id.title) Examples can be found on the next slides...
54. CustomViews Excellent way of dividing your responsibilities (cleaning your code) Three main ways of implementing CustomViews (there are more) Very likely to do Open/Closed code! 1. Extending from Widgets (TextView, ImageView, EditText…) 2. Extending from Layout / ViewGroup, then inflating XML layout 3. Extending from View and overriding onDraw to paint on canvas
55. CustomViews Extending from Widgets (probably the easiest way)
56. Extending from Layout/ViewGroup, then inflating XML layout (you can also add your widgets programatically) CustomViews
58. CustomView Styleable Example usage of Custom View + styleable
59. CustomViews Another example: QuadWheelView
60. Extending from View, painting on Canvas ( onDraw() ) CustomViews
61. • Do extensive use of styles • Separate your styles into different .xml files instead of one styles.xml ◦ res/values/button_styles.xml ◦ res/values/textview_styles.xml ◦ res/values/mycustomview_styles.xml • Also separate your styleables into different files (one file per CustomView) Styles
62. Like naming and styles, have your own package distribution This could be an example ▪ datasource ▹ api ◦ parse ◦ retrofit ▹ mock ▹ db ◦ model ▪ global ▹ di ▹ util ▹ model ▹ MyApplication.java Package distribution ▪ interactor ▹ impl ▪ ui ▹ activity ▹ fragment ▹ view ▹ presenter
63. global/model/CustomNotification.java represents the Notification in my domain One model per layer
64. global/model/CustomNotification.java represents the Notification in my domain datasource/db/NotificationDBEntry.java represents a notification into DB One model per layer
65. global/model/CustomNotification.java represents the Notification in my domain datasource/db/NotificationDBEntry.java represents a notification into DB Object Mapper! One model per layer
66. Android Studio is your friend • Shortcuts ◦ Extract style ◦ Move line up / down ◦ Duplicate line ◦ Alt+Enter > Implement abstract class ◦ Alt+Enter > Create field / local var / method ◦ Alt+Enter > declare public / protected ◦ and much much more... • Live templates (use them with responsibility!) Android Studio Features
67. Mastering Gradle Flavors app/build.gradle, inside android { } BuildConfig vars
68. Flavors app/build.gradle, inside android { } BuildConfig vars Mastering Gradle
69. External libraries
70. External libraries
71. External libraries
72. Libraries from square • retrofit / retrofit2 • dagger • otto • picasso • butterknife Other libs from Google • dagger2 • RecyclerView • Android design library (CoordinatorLayout, Toolbar, Fabs…) External libraries • Palette
73. More useful libs • Glide • renderers • google/exoplayer • DBFlow Libs ”made in Granada” :-) • SectionedRecyclerView (Tomás Ruiz-López) • WheelIndicatorView (David Lázaro) Thanks guys for the awesome work! External libraries
74. More useful libs • Glide • renderers • google/exoplayer • DBFlow Libs ”made in Granada” :-) • SectionedRecyclerView (Tomás Ruiz-López) • WheelIndicatorView (David Lázaro) Thanks guys for the awesome work! External libraries
75. “Hate the code you wrote 6 months ago” Continuous improvement is the key
76. “Hate the code you wrote 6 months ago” Continuous improvement is the key Thanks to those who inspired this speech and made this possible
77. Questions and Answers That’s all folks!
78. We are hiring! contacto@appandweb.es