Development - rafael-cagliari/chuck-norris-facts-app GitHub Wiki

Project Architecture

This project utilizes a Clean Architecture and MVVM architecture patterns. Being divided between the Domain Module (Use Cases and Repository Interface), Data Module (Repository Implementation and Data Source) for service requests and database management, and App/Presentation Module (ViewModels and Fragments), as seen on the image bellow.

Network Requesting

The Retrofit lib was utilized for calling the Chuck Norris Fact API (https://api.chucknorris.io/). I've also decided to implement a "filter fact by category" functionality, taking advantage of the API's already existing querying option: https://api.chucknorris.io/jokes/random?category={category}.

Database management

Room Database was utilized for storing and managing the retrieved facts.

Reactive Programming

All Retrofit and RoomDB calls were made async through RXJava, using the Single observer, which returns only 2 possible responses, a value or an error. Errors messages are turned into Toasts and presented to the user.

UI: Facts List Screen

The Facts List screen uses a Recycler View to display all Chuck Norris Facts stored in the Database. Each item contains the facts's category, a delete and share button, which allows you to send that fact to a friend. The font size is automatically adjusted based on the number of characters (>80).

UI: Fact Search Screen

Clicking the Search Fact button retrieves a new fact from the API. The selected fact category is shown bellow the button. Clicking Add to List adds the fact to the Database. You can click the filter icon on the menu tab for changing categories, it calls another fragment, a bottom sheet dialog. Both the fragments use the shame shared viewmodel.

Testing

  • Unit Testing: Tested the Network and Database calling Use Cases through JUnit.
  • UI Testing: Automated tests were made with Espresso for the following cases: searching a fact, searching a filtered fact, adding a fact, adding a filtered fact and deleting a fact. Espresso Idling Resource was utilized for performing tests on async tasks.

Finishing

Dependency Injection was done with Koin.

Continuous Integration (CI) was implemented through GitHub actions. Upon merge request to the main branch, different tests are run, including gradlew build in order to confirm the new code can build successfully.