There is a way I proposed in the article. It’s not the cleanest approach but it’ll work:
If you need the data from the response you can make
uploadImage method return
Flowable<SomeResponseClass> instead of
Double and store both progress and server’s response in the object. And if the response is not available yet, the server’s response field will be null.
Hi Sean! Thanks a lot! I cannot think of another thing that could be helpful, overall when I incorporated Kotlin in the existing project by using it in separate module everything worked fine. Overall I think Kotlin and Java interoperability is great, the problem with Lombok that I described in the article was the only disturbing issue that I found.
I never said you should write getters/setters in Kotlin, it obviously doesn’t have much sense.
My point was that if you have a big project with a lot of Java classes which depends on Lombok heavily, removing Lombok from it in one sitting may be a lot of work. And I wanted you to be aware of it, not discourage you from migrating completely. Overall, Kotlin is great 😉
Of course, there is no point in using Lombok in Kotlin, I never said it is.
I have a big Android project written in Java which depends on Lombok heavily. If I wanted to introduce Kotlin to that project and didn’t want to use Dagger in Kotlin classes everything would work fine. As you said I wouldn’t have to declare the
Hi Thiago, sorry it took me so long, I must have missed your response somehow.
In the post I was referring to
RxJavaPlugins.getInstance().registerSchedulersHook method which according to “Reactive Programming with RxJava” has two disadvantages. You can only register RxJavaSchedulersHook once across all of JVM and you cannot…