FunctionalAndroidReference is a showcase project of Functional Reactive Programming on Android, using RxJava.
It's a companion app to the presentation "Fully Reactive Apps" at Droidcon UK 2016.
It is not meant to be a canonical reference, but as an example of how far functional programming can be taken. It's also a collection of patterns and ideas about how to express use cases, business features, and UX on a FRP paradigm.
The project has multiple self-imposed limitations:
Full separation between UI and business logic.
The project is split into several modules. Every module has its own README file.
The UI layer is written purely in Java 7 with Android dependencies.
It depends on all modules below.
The business logic that controls the views. It doesn't contain any Android dependency.
It is written in Kotlin for convenience, but it could be rewritten in Java 7 with ease, although it will be a bit verbose without lambdas (see retrolambda).
It depends on the modules below.
Any network services, POJOs, and communications that aren't in the Android framework. Again, it's not dependent on any Android.
Written in Kotlin too.
It depends on the module below.
Helpers and common general types. No Android.
Written in Kotlin, with no Android dependencies.
liblogic and libservices must contain as few classes as pragmatically possible. Favour functions instead.
Every function must be written as an expression body.
Every function must be as pure as possible.
Every parameter in a function must be passed explicitly. No globals, no fields.
Prefer encapsulating variables in closures rather than fields. If using fields, final fields will be mandated whenever possible.
Collections must be immutable.
No nullable types outside the UI and service layers.
Use functional patterns like unions, laziness, or higher order functions, instead of classic OOP Gang of Four patterns.
Every method in the UI layer is either:
a stream/signal, represented by a method returning an
a new UI state: new text value, new element on a RecyclerView, show a dialog... represented by a void/
Every function in the business layer is:
rx.Subscriptionencompassing all the behaviour for one or many use cases.
Every use case must be accompanied of a test suite covering its complete behaviour.
Every public function must be documented.
Inlined comments only when intent isn't clear.
Separate the business logic from the Android lifecycle at the earliest layer possible.
Avoid DI frameworks like Dagger, and hand-roll injection instead.
Avoid code generation outside Kotlin helpers.
Copyright (c) pakoito 2016
The Apache Software License, Version 2.0