Building a career in Android Development

As an Android developer I learned that when I develop an app it is not about me, it is about the users who will interact with the app I build. The quality of the code and also the involvement to deliver high-quality features are reflected in the experience of our users.
As a team leader, I understood better than launching an app is a team effort and our way to collaborate, our shared vision will have an important impact on the success of a product.
In this talk, I’m going to cover some of the lessons I learned along the way and I will present a roadmap that in my opinion should be crossed by each Android developer. We will talk about Kotlin, how to write Clean Code in Kotlin, guidelines in building the app architecture, and how to create an achievable learning plan.

Transcript

1. Building a career in Android Development @magdamiu
2. ABOUT ME • Squad Leader Developer @Orange • Android Google Developers Expert • Trainer & Speaker • Co-organiser GDG Pitesti & WTM Romania
3. Employment history Web Developer Aug 2010 - Oct 2010 Android Developer Nov 2010 - Aug 2015 Android Technical Lead Sept 2015 - Dec 2019 Squad Lead Developer Jan 2019 - Present GDE Android Feb 2019 - Present
4. OOP Q: What’s the object-oriented way to become wealthy? A: Inheritance
5. Cohesion
6. Coupling
7. Best case scenario Cohesion Coupling high low
8. • Don’t Repeat Yourself • Applicable whenever we copy / paste a piece of code D.R.Y.
9. • Keep It Simple and Stupid • Whenever we want to implement a method to do all things K.I.S.S.
10. • You Ain’t Gonna Need It • Don’t write code which is not yet necessary Y.A.G.N.I.
11. • Single responsibility (SRP) • Open-closed (OCP) • Liskov substitution (LSP) • Interface segregation (ISP) • Dependency inversion (DIP) S.O.L.I.D.
12. Design Patterns
13. Law of Demeter A B B is a friend of A C C is a friend of B *Note: A friend of a friend is a stranger Messages from A to B are OK Messages from A to C are discouraged
14. “Tell, Don't Ask” Principle
15. Objects vs Data Tell, don’t ask. Don’t talk to strangers. Dealing with Objects? Dealing with Data?
16. Kotlin A modern and pragmatic language for the industry, not an academic one.
19. • General-purpose • FP + OOP • Open source (Apache 2.0) • Developed by JetBrains • Static typing What is Kotlin?
20. Kotlin is 100% interoperable with Java *.kt *.java Kotlin compiler Java compiler *.class *.jar App Kotlin runtime
22. // Elvis operator val name: String? = null val lengthOfName = name?.length ?: -1 println(lengthOfName)
23. // Elvis operator val name: String? = null val lengthOfName = name?.length ?: -1 println(lengthOfName) // => -1
24. class Utility { // infix functions = functions with a single parameter infix fun String.onto(other: String) = Pair(this, other) } fun main(args: Array<String>) { val blueShoes = "blue".onto("shoes") val yellowScarf = "yellow" onto "scarf" println(blueShoes) // => (blue, shoes) println(yellowScarf) // => (yellow, scarf) }
25. fun String.removeFirstLastChar(): String = this.substring(1, this.length - 1) Receiver type Receiver object
26. Data classes are a concise way to create classes that just hold data. Data classes Function Price Getters and Setters 0 Lei equals() & hashCode() 0 Lei toString() 0 Lei componentN() 0 Lei copy() 0 Lei TOTAL FREE!
27. Coroutines are lightweight threads
28. co + routines coroutines Cooperation Functions
29. Clean Code “Clean code is readable. It tells a story.” Uncle Bob, Clean Code
33. Code quality “measure” WTFs/min Few WTFs Developer Many WTFs Developer
34. Use intention-revealing names Types Names Classes and Objects Customer, Account, WikiPage Methods postPayment, deleteAccount, displayPage Solution domain names AccountVisitor Problem domain names churnPerMonth
35. “UNCLEAN” CODE CLEAN CODE
36. users.filter{ it.job == Job.Developer } .map{ it.birthDate.dayOfMonth } .filter{ it <= 10 } .min() WARNING: Use explicit argument names and avoid using too often “it”
37. users.filter{ user -> user.job == Job.Developer } .map{ developer -> developer.birthDate.dayOfMonth } .filter { birthDay -> birthDay <= 10 } .min() WARNING: Use explicit argument names and avoid using too often “it”
38. fun sumUpUserPoints(): Int { var sumAllPoints = 0 for (user in users) { sumAllPoints += user.points sendEmail(user) } return sumAllPoints } No side effects Side effect
39. fun computeSqrt(number: Double): Double { if(number >= 0) { return Math.sqrt(number) } else { throw RuntimeException("No negative please") } } Nothing is something...
40. fun getMovie(id: Int): Movie { val movie = movieRepository.findMovie(id) return movie ?: throw RuntimeException("Movie not found") } Throw exceptions
41. sealed class MovieSearchResult data class MovieFound(val movie: Movie) : MovieSearchResult() object MovieNotFound : MovieSearchResult() object DatabaseOffline : MovieSearchResult() fun getMovie(id: Int): MovieSearchResult { val movie = movieRepository.findMovie(id) return if (movie == null) { MovieNotFound } else { MovieFound(movie) } } Return result class
42. inputStream.use { outputStream.use { // do something with the streams outputStream.write(inputStream.read()) } } “try-with-resources” in Kotlin - initial solution
43. arrayOf(inputStream, outputStream).use { // do something with the streams outputStream.write(inputStream.read()) } “try-with-resources” in Kotlin - improved solution
44. private inline fun <T : Closeable?> Array<T>.use(block: ()->Unit) { // implementation } use implementation
45. Kotlin is about developer’s happiness and productivity.
46. Android Jetpack A set of libraries, tools and guides to help make app building quick and easy.
47. Android Jetpack Follow best practices Fewer crashes and less memory leaks with backwards-compatibility baked in. No boilerplate code You can focus on what makes your app great. Reduce fragmentation Reduce complexity with libraries that work consistently across Android versions and devices.
48. Android Jetpack UI Jetpack Compose Foundation AndroidX, Android KTX Architecture LiveData, ViewModel, Lifecycle, Room, Navigation, Paging, Hilt Behaviour Slices, Security, Permissions
49. *Recommended app architecture Activity / Fragment Model Room Remote Data source Retrofit SQLite REST API ViewModel LiveData Repository
50. Architecture Components: Room for databases Components Entity, Dao, Database “Relations” @Embedded, @Relation, @ForeignKey Queries @Insert, @Update, @Delete, @Query, @RawQuery
51. Tools for Android development CI/CD Pipeline
52. Learning Plan “A goal without a plan is just a wish.” Antoine de Saint-Exupéry
53. Achievable Learning Plan @Work Code review & Pull Request @Home SWOT & OKRs
54. @Work Code review & Pull Request
55. <Code> Reviewer Author
56. Author
57. Writing the code • Make sure you understand your task • Refactor the code if it’s unreadable • Write tests and follow the team conventions • Format your code before commit it
58. The boy scout rule Leave the campground cleaner than you found it.
59. Before the code review • Add relevant commit comments • Send pull requests often • Have minimum 2 reviewers (one is senior)
60. After the code review • Be humble • You are on the same side with your reviewer(s) • Know when to unlearn the old habits
61. Reviewer
62. Use I… comments • I think… • I would… • I believe… • I suggest...
63. Ask questions • Have you consider using… ? • What do you think about… ? • Have you tried to… ?
64. It’s about the code, not about the coder • This code… • This function… • This line of code...
65. Feedback equation* Observation of a behavior Impact of the behavior Question or Request I observed this function has 60 lines. This makes it difficult for me to understand the logic. I suggest extracting a part of the code into other functions and give them relevant names. * Defined by Lara Hogan
66. @Home SWOT & OKRs
67. The “process” SWOT Where I am now Retro How it was and what’s next OKRs What I want to achieve Review What I achieved 01 02 04 03
68. Personal SWOT Analysis ME Weaknesses Skills that should be improved (technical or work habits) Threats Impediments at work, changes, weaknesses lead to threats Strengths Advantages like: skills, achievements, certifications, education, connections Opportunities Events, conferences, new role/project, industry growing
69. • Goal setting in a collaborative way • Objective => WHAT • Key results => HOW • “It’s not a key result unless it has a number” OKRs
70. • Superpower #1 => focus and commit to priorities • Superpower #2 => align and connect for teamwork • Superpower #3 => track for accountability • Superpower #4 => stretch for amazing OKRs superpowers
71. • 0.7 to 1.0 = green (we delivered) • 0.4 to 0.6 = yellow (we made progress, but fell short of completion) • 0.0 to 0.3 = red (we failed to make real progress) Scoring @Google
72. OKR sample Learn Kotlin for Android Development 6 months / weekly review Quantity Goal Quality Goal Result 1 Kotlin Koan per week Learn specific features of the language => 1 feature / week Exercise often and on a set of Koans proposed by JetBrains Write one detailed article about a specific topic per month Improve my writing skills and learn by teaching to others Learn new things, help the community and get feedback 3 code samples runned per week Get a repo with samples that I can re-check (use ktlint) Gain real experience in programming using Kotlin
73. • Score your results • Keep notes of your accomplishments • Look for feedback because development is continuous • Surround yourself with people who motivate and inspire you • Find a mentor Review
74. • Did I accomplish all of my objectives? ◦ YES => what contributed to my success? ◦ NO => what obstacles did I encounter? • If I were to rewrite a goal achieved in full, what would I change? • What have I learned that might alter my approach to the next cycle’s OKRs? • Understand what is your WHY • Repeat the process Retrospective
75. Official Documentation from Google Blogs and Websites Code Examples (Codelabs & GitHub) Newsletters Books & Online Courses From where to learn more... Videos & Youtube Channels Podcasts ‍‍Twitter Conferences & Meetups Troubleshooting https://magdamiu.com/2019/09/22/lets-talk-android/
76. • Define with your colleagues a set of conventions • Justify technology use • Enforce good practices (XP) • Question until you understand • Criticize ideas, not people • Testing, testing, testing • Integrate early, integrate often • Emphasize collective ownership of code • Prioritize and actively evaluate trade-offs • Listen to users My summary
77. CREDITS: This presentation template was created by Slidesgo, including icons by Flaticon, images from Unsplash, and infographics & images by Freepik. THANKS! magdamiu.com @magdamiu