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