Skip to content

Progress

Kotlin   465 commits   Last commit on Oct 24, 2018

Overview

Progress is a simple fitness tracker for managing your weight, calories, and water intake. This project is made of both an Android client written in Kotlin along with a server component written in Java. This project is publicly available through the Google Play Store and is still in active development.

Dependency Breakdown

Android Project Design

The architecture of this project was designed off of the Clean Architecture and MVP patterns. From a high level it is designed to allow decoupling of responsibility for ease of maintainability and testing purposes. An earlier pre-Kotlin version of such design can be found broken down in detail here.

Code structure alone will not allow you to see the benefits of this pattern. Specific hard and fast rules are in place at a design guideline level to keep everything properly decoupled.

  • All entities will be immutable.
  • All interactors will be the most ideal interface for requesting the associated entity.
  • All presenters will know nothing of Android.
  • All view interactions (clicks/visibility changes/ect.) will be triggered from a presenter.

Server Project Design

This server component was my first example of using the Spring framework in a production environment. Since the userbase of this project is still in the single digits scaling wasn't much of a concern so using a simple SQLite JDBC integration for the backend data made perfect sense. Authentication via any number of social or even anonymous sources is handled by Google's Firebase platform.

This setup is all configured in Docker and ran off a Digital Ocean Droplet. Network requests are filtered through CloudFlare to protect us from any denial of service attacks. Since our data is not being handled in any distributed manor we have automatic backups configured to export directly to Amazon S3 Glacier.

Since initial deployment we have had three outages but they were only caused by the underlying hardware on Digital Ocean requiring a reboot and caused no issues. Our average median response time over the last six months is 160ms.