Building Vesper on Ballast: One State Model to Rule Them All

Ballast serves as the foundational framework for the Vesper app, acting as the Kotlin-based interface to server-side schedules and background queue workloads. This article is part of a series focusing on the creation of a production-grade Kotlin Multiplatform (KMP) application built on a limited budget. The author, who also developed Ballast, cautions readers to consider the inherent bias in their recommendation.

Despite this, Vesper provides a real-world test of Ballast's effectiveness in a production environment, and the author believes their ideas hold up well under these conditions.

Ballast began as a Kotlin Multiplatform (KMP) Model-View-Intent (MVI) framework, drawing inspiration from the Redux library popular in the React ecosystem. However, Ballast goes beyond Redux by incorporating features unique to Kotlin, such as sealed interfaces, while still maintaining the benefits of unidirectional data flow and the safety provided by this pattern. The library is highly opinionated, aiming to provide a repeatable structure for code that can be adapted to individual applications.

A key component of Ballast is the Contract, which defines the data displayed on a screen (State) and the actions that UI and background processes can dispatch to modify the State. The State represents the current snapshot of the application, while Inputs are the actions that can change the State. Events are one-shot side effects like navigation or dialogs, but they are less necessary when working with modern Kotlin Multiplatform Compose applications.

For example, a StopwatchContract in Ballast would define a State with elapsed seconds and a running status, Inputs with actions for starting, stopping, resetting, and ticking the stopwatch, and Events for post-navigation and dialogs. The Contract serves as a blueprint for the functionality of a specific screen, outlining how the data and actions should be managed within the application.