Kotlin & RxJava in Android project. One year later. MO 2016

More that a year has passed since we've started to develop two Android projects at Juno using Kotlin, RxJava, Dagger 2 and other cool tools. During this year we've learned a lot about this cutting edge stack, its benefits and issues, and we'd love to share our experience and insignghts with you.

Transcript

1. Kotlin & RxJava in Android project One year later Anton Rutkevich, Juno Igor Korotenko, Juno
3. Contents 1. Stack benefits 2. Interop 3. Challenges
4. Stack benefits
5. What’s in the stack?
6. What’s is the stack?
7. Core ideas
8. Core ideas 1. Safety a. Immutability b. Easy concurrency 2. Concise code 3. Modularity (SOLID-inspired, Clean architecture) 4. Test-ready
9. Safety. Immutability
10. Why immutable? 1. No state - simpler program a. “Simple made easy” talk by Rich Hickey 2. Mutable state is the core of concurrency issues 3. Immutability allows to perform some optimizations
11. Immutability is transitive Reference Data Collection
12. Reference immutability
13. Objects immutability. Data classes
14. Collections immutability
15. Rx 1. Implicitly relies on immutable data in streams 2. Hides the state in operators & subjects
16. Safety. Easy concurrency
17. Concurrency is hard
18. Rx approach to concurrency
19. Safety. Other
20. Safe by default 1. Immutability by default 2. Classes & methods are final by default 3. ...
21. Null safety
22. Advanced type safety. Why? More checks are guaranteed at compile time
23. Type safety. Sum types 1. TimeDiff
24. Why sum types? Example Long Long Long if (timeDiff != -1) if (timeDiff != -1) TimeDiff if (timeDiff is TimeDiff.Known) TimeDiff.Known
25. Type safety. Sum types 2. Network response
26. Concise code
27. Smart casts
28. Stream-like API
29. Easy to understand complex data-flow
30. Modularity. Architecture
31. High-level view on architecture ViewModel View starts here Retrofit BL home SOL ID Dagger 2 helps here Service A Service B Service D Networking ends here
32. Testability
33. Main ideas 1. Separation of concerns (clean architecture principles) 2. Dependencies of SUT are interfaces 3. Business logic is isolated from platform code 4. UI layer can be replaced for tests
34. Kotlin
35. Spek
36. Interop
37. Koltin interop’s rule of thumb 1. No black magic -> works fine 2. Black magic -> most probably works fine, but need to re-check
38. Koltin + Dagger 2 Initially DI code was in Java Now, with kapt, DI can also be in Kotlin
39. Koltin + Retrofit Just works :)
40. Koltin + Rx Works even better than Java + RxJava 1. Lambdas (non-capturing) 2. Extension functions
41. Koltin + Gson Gson uses reflection to set field values -> can set null into non-nullable field. Beware!
42. Challenges
43. Testing. Koltin + Mockito 1. Everything is final by default in Kotlin a. Solution 1: PowerMock. Dirty b. Solution 2: Clean architecture. Clean 2. Mockito returns nulls where Koltin expects non-nullable a. Use Mockito-Kotlin library or write your own matchers
44. Java -> Kotlin interop Beware of nulls that come from the Java’s dark side String!
45. Compile time 1. Was kind of a problem: a. Clean ~3 min b. Incremental ~55 sec c. Of which compile Kotlin ~50 sec 2. Much better with Koltin 1.0.2 & dex in process a. Clean ~2m b. Incremental ~30 sec c. Of which compile Kotlin clean ~50 sec, incremental ~20 sec
46. Method count 1. Kotlin ~6K 2. RxJava ~5K 3. Multidex works
47. Proguard Works, causes ~ same amount of issues as in Java
48. Summay
49. Core benefits 1. Runtime checks go to compile time 2. Kindly pushes you to write better code 3. Expressive code
50. Challenges 1. Testing -> solved 2. Compile time -> not significant 3. Java interop -> be careful
51. Be a stream
52. Questions?