Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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.

Anton Rutkevich

July 16, 2016
Tweet

More Decks by Anton Rutkevich

Other Decks in Programming

Transcript

  1. Kotlin & RxJava in
    Android project
    One year later
    Anton Rutkevich, Juno
    Igor Korotenko, Juno

    View full-size slide

  2. Contents
    1. Stack benefits
    2. Interop
    3. Challenges

    View full-size slide

  3. Stack benefits

    View full-size slide

  4. What’s in the stack?

    View full-size slide

  5. What’s is the stack?

    View full-size slide

  6. Core ideas
    1. Safety
    a. Immutability
    b. Easy concurrency
    2. Concise code
    3. Modularity (SOLID-inspired, Clean architecture)
    4. Test-ready

    View full-size slide

  7. Safety. Immutability

    View full-size slide

  8. 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

    View full-size slide

  9. Immutability is transitive
    Reference
    Data
    Collection

    View full-size slide

  10. Reference immutability

    View full-size slide

  11. Objects immutability. Data classes

    View full-size slide

  12. Collections immutability

    View full-size slide

  13. Rx
    1. Implicitly relies on immutable data in streams
    2. Hides the state in operators & subjects

    View full-size slide

  14. Safety. Easy concurrency

    View full-size slide

  15. Concurrency is hard

    View full-size slide

  16. Rx approach to concurrency

    View full-size slide

  17. Safety. Other

    View full-size slide

  18. Safe by default
    1. Immutability by default
    2. Classes & methods are final by default
    3. ...

    View full-size slide

  19. Advanced type safety. Why?
    More checks are guaranteed at compile time

    View full-size slide

  20. Type safety. Sum types 1. TimeDiff

    View full-size slide

  21. Why sum types? Example
    Long
    Long Long
    if (timeDiff != -1) if (timeDiff != -1)
    TimeDiff
    if (timeDiff is TimeDiff.Known)
    TimeDiff.Known

    View full-size slide

  22. Type safety. Sum types 2.
    Network response

    View full-size slide

  23. Concise code

    View full-size slide

  24. Stream-like API

    View full-size slide

  25. Easy to understand complex data-flow

    View full-size slide

  26. Modularity. Architecture

    View full-size slide

  27. 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

    View full-size slide

  28. 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

    View full-size slide

  29. Koltin interop’s rule of thumb
    1. No black magic -> works fine
    2. Black magic ->
    most probably works fine, but need to re-check

    View full-size slide

  30. Koltin + Dagger 2
    Initially DI code was in Java
    Now, with kapt, DI can also be in Kotlin

    View full-size slide

  31. Koltin + Retrofit
    Just works :)

    View full-size slide

  32. Koltin + Rx
    Works even better than Java + RxJava
    1. Lambdas (non-capturing)
    2. Extension functions

    View full-size slide

  33. Koltin + Gson
    Gson uses reflection to set field values
    -> can set null into non-nullable field.
    Beware!

    View full-size slide

  34. 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

    View full-size slide

  35. Java -> Kotlin interop
    Beware of nulls that come from the Java’s dark side
    String!

    View full-size slide

  36. 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

    View full-size slide

  37. Method count
    1. Kotlin ~6K
    2. RxJava ~5K
    3. Multidex works

    View full-size slide

  38. Proguard
    Works, causes ~ same amount of issues as in Java

    View full-size slide

  39. Core benefits
    1. Runtime checks go to compile time
    2. Kindly pushes you to write better code
    3. Expressive code

    View full-size slide

  40. Challenges
    1. Testing -> solved
    2. Compile time -> not significant
    3. Java interop -> be careful

    View full-size slide