Let's Tune This Kotlin

Simple Kotlin tips and tricks

Transcript

1. Let’s Tune This Kotlin @kingsleyadio
2. Kingsley Adio •Software Developer @HelloFresh •Eats droids for a living •Big Kotlin enthusiast •Twitter @kingsleyadio
3. Overview • Hello Kotlin • Quick Dive • Conclusion
4. Disclaimer!
5. Hello Kotlin • Modern • Safe • Developer and tool friendly • Great Java interop • Thriving ecosystem • No extra overhead
6. Quick Dive • Companion Object • To const or not to const • Inline functions • FP and collections • Lazy vs Lateinit • Sealed classes • Data classes
7. Companion Object
8. Companion Object
9. Companion Object • Prefer simple objects to hold constants • If possible, use top level constants
10. Companion Object
11. Companion Object
12. Companion Object • Companion objects are objects themselves. Take advantage of this! • They can implement interfaces and extend other classes
13. To const or not to const
14. To const or not to const
15. To const or not to const
16. To const or not to const • Prefer const for truly static final compile time guarantees. • Note: const only works for JVM primitives and Strings • Use @JvmField in other cases
17. Collections
18. Collections
19. Collections
20. Collections
21. Inline functions
22. Inline functions
23. Inline functions • Prefer to inline simple higher order functions to avoid unnecessary allocations
24. Inline functions
25. Inline functions
26. Inline functions
27. Inline functions • Slapping inline onto a function doesn’t necessarily help if the functional argument will be stored • Debugging could be tricky • Heavy inlining could disable potential JVM optimizations
28. Lazy vs Lateinit
29. Lazy vs Lateinit • Lazy is easier • Lateinit is cheaper • Both can be quite tricky
30. Sealed Classes
31. Sealed Classes
32. Sealed Classes • Sealed classes are actual classes. • Remember all the fuss with enums? They are actual concerns with sealed classes. • They are great for modelling related classes with specialised values • Result types: Result, Either, Maybe
33. Data Classes
34. Data Classes
35. Data Classes
36. Data Classes • They implement toString, equals and hashCode out of the box. • Destructuring ❤ data class • Avoid slapping data on all your POKOs just because it feels nice • Method count!
37. Bonus: no-arg plugin
38. Bonus: no-arg plugin
39. Bonus: no-arg plugin
40. Bonus: no-arg plugin • Generates a public no argument constructor. • Helps avoid self-defeating defaults • Great for JPA/BV, GSON, Moshi, Realm, etc
41. Conclusion • Kotlin is a great language with a very beautiful syntax and low entry barrier • We naturally want to explore beauty • However, beauty comes at a cost • Once we understand this, we can find the right balance between beauty and quality
42. References •https://kotlinlang.org •https://kotlin.link •https://medium.com/@tpolansk/sequences-a- pragmatic-approach-9d4296086a9d •https://speakerdeck.com/kingsleyadio/lets- tune-this-kotlin •https://github.com/kingsleyadio/gdg- devfest17-snippets
43. Danke
 &
 Have a nice Kotlin! :)