Android app for weather info and nearby restaurants
The project follows Clean Architecture
by Robert C. Martin (inspired by, among others, Hexagonal and Onion architectures). Instead of
presenters, view models (and live data objects) are being used, as that plays more nicely with
Android live cycles and configuration changes. Entity classes constitute rich domain model,
besides of just storing data they as well provide behavior (having methods like fetch,
send etc.), hence initial state of them should be always modeled as "unknown" so that initial
actions, like fetch, can be called on them and differentiation between unknown (e.g.
not-fetched yet) state and an empty (e.g. no data) state can be made.
The codebase foundations have been built following SOLID Object-Oriented design principles. The complexity is being split into single-responsibility units of code (both at the class and method level). Dependency inversion principle, assisted by Dagger 2 (elaborated further on below), is being followed so that dependencies on implementation details from the outer layers are not escalating throughout the codebase. Implementation details include also Android specific dependencies as they are more tricky to mock in JVM unit tests and as well it promotes lower coupling and better code design in general.
The code is packaged by feature. At root level of each feature package the core business logic is
being placed. Further implementation or technology specific details are being placed in their
subpackages, including classes specific to UI and the backend API. For truly app generic
concepts, which are used at the application level or meant to be reused across many different
features, the app package has been created.
State is stored only in Reductor store, being a single source of truth, with controlled access (modifications dispatched as pure functions, read-only access of substates exposed to relevant parts of client code – promoting encapsulation).
The code design follows dependency injection principle, employing Dagger 2 in [the recommended way of using it on Android](https://google.github .io/dagger/android.html). Primarily one application scope is being used and that should be optimal for these two modules (with their expected memory footprints) and constitutes a natural approach considering application's global Reductor store being used to store the application state. Subcomponents are currently just being used for extending dependency graph. Dagger singletons are being used only when it's strongly justified, promoting stability through micro-restarts (getting clean new instance – less stateful, hence simpler app) and better memory footprint (not holding on to no longer needed objects). Small and simple modules are created per set of related concrete implementation dependencies – which promotes greater flexibility with swapping concrete dependencies in the future or providing fake implementations in particular automated UI (functional) test scenarios.
RxJava 2 is used for asynchronous composable processing chains passed across the inner layers of the architecture stack. Where at each layer specific processing, being part of responsibility of a given layer, is added.
To better model nullability and get support from compiler when dealing with the absent ("empty")
state, Optional is being used. The implementation used is the one present in the
Lightweight-Stream-API library (described more broadly in the Java 8 section).
The app follow single activity architecture in order to make migration to the navigation architecture component easier.
Related state modifications are dispatched from use case specific interactors (Clean Architecture), as opposed to state global middlewares, which promotes encapsulation. Value (immutable) objects (powered by AutoValue) are being used across the app. PCollections (persistent and immutable collections) are being used everywhere inside the state container (in the reducers). Even when the data is coming from the outside, it's being placed inside of a persistent and immutable collection. PCollections are being used everywhere through standard Java collections interfaces to not escalate dependency on them.
The code makes use of Java 8 new language features, especially lambdas, with the support of the desugar tool built in the Android Studio toolchain. Some Java 8 language APIs are being used through backport libraries. Those include ThreeTen (date-time) and Lightweight-Stream-API. The latter besides pure backport features adds some additional operators and support for custom operators. It's advised to best avoid using them for smooth transition to the original Java 8 API in the future (when min API level can be upgraded to 24).
Tests follow Testing Pyramid,
where:
- most of them are isolated unit tests (testing one thing in a single unit of code with its dependencies mocked),
- some integration tests (integration between just two real instances), (planned)
- and a few UI functional E2E Espresso tests (which usually fake relevant backend API responses to simulate test scenario). (planned)
The unit and integration tests are super fast running locally on a dev machine in a JVM (can be used efficiently for TDD). Espresso UI tests are slightly slower as they require pushing APKs to emulator and instrumenting the test run.
Gif of app in action:
Icon made by https://www.flaticon.com/authors/smashicons from www.flaticon.com