• Environment setup
• Code style

Development

Environment setup

First off, you require the latest Android Studio 3.5 (or newer) to be able to build the app.

• TvMaze: https://www.tvmaze.com/api

Moreover, to sign your app for release you should generate an upload key and keystore following the official documentation. Append the information used to generate it into local.properties project root file following the structure:

#Signing Config
signing.key.alias = <insert>
signing.key.password = <insert>
signing.store.file = <insert>
signing.store.password = <insert>

Code style

To maintain the style and quality of the code, are used the bellow static analysis tools. All of them use properly configuration and you find them in the project root directory .{toolName}.

All these tools are integrated in pre-commit git hook, in order ensure that all static analysis and tests passes before you can commit your changes. To skip them for specific commit add this option at your git command:

git commit --no-verify

The pre-commit git hooks have exactly the same checks as CircleCI and are defined in this script. This step ensures that all commits comply with the established rules. However the continuous integration will ultimately be validated that the changes are correct.

Design

App support different screen sizes and the content has been adapted to fit for mobile devices and tablets. To do that, it has been created a flexible layout using one or more of the following concepts:

• Use ConstraintLayout
• Avoid hard-coded layout sizes
• Create alternative layouts
• Use the smallest width qualifier
• Use the available width qualifier
• Add orientation qualifiers

In terms of design has been followed recommendations Android Material Design comprehensive guide for visual, motion, and interaction design across platforms and devices. Granting the project in this way a great user experience (UX) and user interface (UI). For more info about UX best practices visit link.

Moreover, has been implemented support for dark theme with the following benefits:

• Can reduce power usage by a significant amount (depending on the device’s screen technology).
• Improves visibility for users with low vision and those who are sensitive to bright light.
• Makes it easier for anyone to use a device in a low-light environment.

Architecture

The architecture of the application is based, apply and strictly complies with each of the following 5 points:

• Android architecture components, part of Android Jetpack for give to project a robust design, testable and maintainable.
• Pattern Model-View-ViewModel (MVVM) facilitating a separation of development of the graphical user interface.
• S.O.L.I.D design principles intended to make software designs more understandable, flexible and maintainable.
• Modular app architecture allows to be developed features in isolation, independently from other features.

Modules

Modules are collection of source files and build settings that allow you to divide a project into discrete units of functionality. In this case apart from dividing by functionality/responsibility, existing the following dependence between them:

The above graph shows the app modularisation:

• :app module depends on :base, :data, :domain and :test-shared
• :data module depends on :base and :test-shared.
• :domain module depends on :base, :data and :test-shared
• :base doesn’t have any dependency.

App module

The :app module is an com.android.application, which is needed to create the app bundle. It is also responsible for initiating the dependency graph, play core and another project global libraries, differentiating especially between different app environments.

Base module

The :base module is an com.android.library only contains code and resources which are shared between other modules. Reusing this way resources, layouts, views, and components in the different modules, without the need to duplicate code.

Data module

The :data module is an com.android.library for serving network requests or accessing to the database. Providing the data source for the many features that require it.

Domain module

The :domain module is an com.android.library lays a bridge between data and view layers. It performs any business logic getting data from data module and serves to view.

Test shared module

The :test-shared module is an com.android.library, basically contains test utilities that can be used by the different modules.

Architecture components

Ideally, ViewModels shouldn’t know anything about Android. This improves testability, leak safety and modularity. ViewModels have different scopes than activities or fragments. While a ViewModel is alive and running, an activity can be in any of its lifecycle states. Activities and fragments can be destroyed and created again while the ViewModel is unaware.

Passing a reference of the View (activity or fragment) to the ViewModel is a serious risk. Lets assume the ViewModel requests data from the network and the data comes back some time later. At that moment, the View reference might be destroyed or might be an old activity that is no longer visible, generating a memory leak and, possibly, a crash.

The communication between the different layers follow the above diagram using the reactive paradigm, observing changes on components without need of callbacks avoiding leaks and edge cases related with them.

Documentation

The documentation is generated following KDoc language (the equivalent of Java's JavaDoc) via documentation engine for Kotlin Dokka.

To consult it check this link or open the project /docs directory.

Tech-stack

This project takes advantage of many popular libraries, plugins and tools of the Android ecosystem. Most of the li