Cutting edge Android stack
One year later
Anton Rutkevich, JunoIgor Korotenko, Juno
What’s in the stack?
What’s is the stack?
Core ideas
Core ideas
1.Safetya. Immutability
b. Easy concurrency
2.Concise code
3.Modularity (SOLID-inspired, Clean architecture)
4.Test-ready
Safety. Immutability
Basics
1.No state - simpler program
a. “Simple made easy” talk by Rich Hickey
2.Mutable state is the core of concurrency issues
3.Allows to perform more optimizations
4.Immutability is transitive
a. Can be broken by one mutable item
Reference immutability
Objects immutability. Data classes
Collections immutability
Rx
1.Implicitly relies on immutable data in streams
2.Hides the state in operators & subjects
Safety. Easy concurrency
Concurrency is hard
Rx approach to concurrency
Safety. Other
Safe by default
1.Immutability by default
2.Classes & methods are final by default
3.Nested classes don’t hold a reference to the outer
4....
Null safety
Functional style
Advanced type safety. Why?
More checks are guaranteed at compile time
Type safety. Sum types 1. TimeDiff
Type safety. Sum types 2. Network response
Concise code
Properties, type inference
Smart casts
Stream-like API
Easy to understand complex data-flow
Modularity. Architecture
High-level view on architecture
ViewModel
Vie
w
starts hereRetrofit BL homeSOLID
Dagger 2 helps here
Service A
Service B
Service D
Net
wor
king
ends here
Testability
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
Rx
1.TestScheduler
2.TestSubscriber
Mockito
1.Still using PowerMock in “legacy” parts
2.Clean architecture eliminates the need of PowerMock
AssertJ
Just AssertJ
Roboliectric
No need for it, as UI & business logic are isolated from the
platform
Spock + Groovy
1.Works
2.Hard to set up
3.Fun to use, when everything works
4.Not really fun when something breaks (dynamic Groovy)
Kotlin
Interop
Koltin interop’s rule of thumb
1.No black magic -> works fine
2.Black magic ->
most probably works fine, but need to re-check
Koltin + Dagger 2
Initially DI code was in Java
Now, with kapt, DI can also be in Kotlin
Koltin + Retrofit
Just works :)
Koltin + Rx
Works even better than Java + RxJava
1.Lambdas (non-capturing)
2.Extension functions
Koltin + Gson
Gson uses reflection to set field values
-> can set null into non-nullable field.
Beware!
Rx + Retrofit
Retrofit provides API for Rx:
Response as Observable<T>
What other libs bother you?
Challenges
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
Java -> Kotlin interop
Beware of nulls that come from the Java’s dark side
String!
Static code analyzers
1.Findbugs
a. ?
2.Pmd
a. ?
3.Lint
a. Works in IDE now, command line support comes soon
4.Compiler does lots of what static analyzers do in Java
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
Method count
1.Kotlin ~6K
2.RxJava ~5K
3.Multidex works
Proguard
Works, causes ~ same amount of issues as in Java
Be a stream
Outro