In modern app development, apps are increasingly expected to be offline-first, meaning they should be able to handle operations with limited or no network connectivity. As a result, caching has become a first-class citizen in app architectures, providing multiple benefits: fewer network calls reduced data usage improved performance, and easier data management across app screens. In this post, I’ll discuss a common naive approach, and introduce a more scalable, reusable, and testable caching strategy.

With this long-awaited issue now resolved, the Android Gradle Plugin (AGP) properly supports testFixtures source sets. This means you no longer need to create a separate module to expose test fixtures or include them in the main source set. Test fixtures The testFixtures source set is particularly useful for improving test code reusability. It provides developers with a structured way to create and share test-related code across multiple test suites (e.

For anyone setting up Java, Kotlin, or Spring SDKs manually, the process of tweaking environment variables like HOME and PATH might feel cumbersome. Fortunately, there’s a much simpler solution: SDKMAN!. I’ve been happily using SDKMAN! for a while, and it has made managing SDKs a breeze. With SDKMAN!, installing Java, changing the default Kotlin version, or updating to the latest Spring Boot version is a one-liner. Installing SDKMAN! Getting SDKMAN! up and running on a UNIX-based system is straightforward.

The domain layer is the heart of your application, where business rules are defined and enforced. One critical aspect of these rules is error handling, which must be as detailed as the business requirements dictate. It’s the domain layer that determines the granularity of error handling, ensuring that errors are managed appropriately based on the specific needs of the business. Let’s consider the following example: 1 2 3 4 5 data class Data(val a: Int, val b: Int) interface Repository { fun getData(): Data?

Imagine you’re building a complex application with several layers: a presentation layer for user interactions, a domain layer for business rules, and a data layer for managing data. One common pitfall developers face is confusing data flow direction with dependency direction, often assuming they must be the same. But here’s a crucial question: Can dependency direction differ from data flow direction? Yes, it can, and knowing how is vital for creating a robust architecture.

Normally, Typealias and inline value class (which I’ll refer to as value class throughout this text) are utilized for different purposes. However, developers might occasionally use one for the other. Let’s explore some examples and clarify the differences. Typealias kotlinlang.org does a pretty good job explaining Typealias: Type aliases provide alternative names for existing types. If the type name is too long you can introduce a different shorter name and use the new one instead.