TODO App

TODO-List Sample application demonstrating proper archtecture with the following aspects:

Model / View / Presenter
Reactive Functional Programming
Kotlin
High-Coverage Unit Testing
Dependency Injection
Singleton-Proxy Pattern (to ease unit testing, no PowerMock)

Packages

Feature Driven -- Each logical component should be within it's own package
Flatter is Cleaner -- Keep to a minimum of subpackages to keep code clean

Example Screen Feature:

- com.exallium.todoapp.myscreen
- - MyScreenComponent.kt    -- Dagger Component Class
- - MyScreenController.kt   -- View / Controller Implementation
- - MyScreenModel.kt        -- Model Interface
- - MyScreenModelImpl.kt    -- Model Implementation
- - MyScreenModule.kt       -- Dagger Module
- - MyScreenView.kt         -- View Interface
- - MyScreenPresenter.kt    -- Presentation Logic Class

MVP

View -- A conductor Controller instance (Interfaced) Responsible for all direct communication with Android views
Presenter -- An object which is given a reference to a View Interface and a reference to a Model Interface. Responsible for all presentation logic.
Model -- An Interactor object which is acted upon by the presenter, and communicates with the rest of the system.

Reactive

Views expose events, like clicks and other such events as observables. Views also expose simple getters and setters for current view-state.
Models will communicate via observables / singles, as these often require background processing, unless it makes sense not to do so.

Conductor

The application is a single-activity, custom-view architecture. Conductor makes this very easy to implement.

Dagger

The "factory" for the application is a DAG. All components should be generatable via this graph, and care should be taken to reduce creation of logical objects within other logical objects as much as possible. This eases testing.
Every object, with the exception of System-Created objects, should be generated via dagger with construction time injection.

Butterknife

// Usage:
@BindView(R.id.view)
lateinit var view

Unit Tests

This project attempts to maintain as high code coverage as possible.

Testing from the command line can be done like so:

./gradlew testDebug

Jacoco is used to generate code coverage reports for debug builds. To get code coverage on a specific build variant:

./gradlew jacoco<build-type>TestReport
./gradlew jacocoDebugTestReport # code coverage for debug builds

Mockito 2 is utilized to allow proper mocking of final methods and classes, which allows us to avoid PowerMock.

exallium/todoapp