When working with the Android Gradle plugin you are really likely to run into a block of code that looks like this: compileOptions { sourceCompatibility JavaVersion.VERSION_xx targetCompatibility JavaVersion.VERSION_xx } sourceCompatibility - restricts language features that we can use in our codebase. Usually is set up to a version of the JDK used for compilation. As an example using JavaVersion.VERSION_11 enables us to use var keyword for local variable type definition.

Recently ran into a problem where providing the generated type of sqldelight database directly into the dagger graph from module classes would fail with error.NonExistentClass error. Failure seemed to be happening randomly if one would invoke the clean task before assemble. This seems to be a limitation of the kapt since all non-existent types in the declaration are replaced by NonExistentClass, which is an issue for our dagger dependency. For a workaround it’s recommended to set error type inference in stubs using:

I’ve always liked creating simple annotation processors. There is something satysfing to see lot’s of code being generated for you while all it takes is just providing correct annotation to correct element and Et voila! That is of course if you trust compiler to generate correct code. To verify generated code of my annotation processors I’ve usually created a module that would provide sample on how to correctly use the processor and how to use the generated code.

Last week as Google announced release of Android P preview they also release first alpha version of new support library that includes, amongst many interesting changes, new additions to design support library. From now on the library will include new MaterialButton, MaterialCardView, layout for Chips and BottomAppBar, also I hope we’ll get BackLayerLayout in future releases. BottomAppBar, being an extensions of Toolbar, feels like a compromise to provide user with some actions comfortably without the need to reach for them with thumb in the Toolbar on top on devices with bigger screen.

So, I got burned by Kotlin recently. Don’t get me wrong here, I like it that I still find myself in situations where I think things should work, but they just don’t. Let me describe the problem here. My colleague asked if I know how one could debounce LiveData emissions, similar to behaviour of debounce operator of RxJava, with a help of MediatorLiveData and some simple code, that just always reschedules message send to UI thread, I tried to implement it like this: