What would you do if you needed a LazyRow where all items are forced to have the same height? There’s no perfect solution, as enforcing uniform height means every item must be measured—negating the performance benefits of using a LazyRow in the first place. But if you’re aware of the trade-offs, we can aim for a solution that’s readable, maintainable, and “lazy enough” for many use cases. Option 1: A Row with a custom SnapLayoutInfoProvider This works well when all items have the same width.

Jetpack Compose provides OverscrollEffect in androidx.compose.foundation to create customizable overscroll effects. While this works well in many scenarios, integrating it with lazy layout managers like LazyColumn can be less straightforward. A more robust alternative involves using NestedScrollConnection to create a custom overscroll modifier. However, this requires overriding methods like onPreScroll, onPostScroll, and onPreFling, which adds complexity. Interestingly, Modifier.pullRefresh, while designed for pull-to-refresh functionality, bears similarities with an overscroll modifier, albeit limited to one direction.

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?