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.

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: