Using Kotlin for ODK Android apps


(Udhaya Kumar) #1

Guys can we continue the android development in kotlin. IMHO Because once the project size gets big enough it will be a trouble to convert the entire code base to kotlin.


(Yaw Anokwa) #2

Why would we want to convert the entire code base to Kotlin? What are the pros? The cons? What impact will it have on attracting contributors? On stability? On maintaining the codebase?


(Saikat Mondal) #3

I think Java is okay. I don't see any reason to convert it to kotlin. If later on we need to optimize the performances we can use JNI(java native interface) to use C/C++ .


(Grzegorz Orczykowski) #4

I was thinking about enabling Kotlin in order to allow using both but converting everything to Kotlin?


(Udhaya Kumar) #5

Most of the android project are now written in kotlin and google also recommends the same. I feel i we can have kotlin support for android development it might be helpful in attracting more contributers from the community.
As for converting the entire code base to kotlin i was just mentioning it. we don't need to do now. As of now it will good if we support kotlin also


(Dr. Gareth S. Bestor) #6

Might there be a good ‘boundary’ upon which to determine what might be/not be a good candidate for porting to Kotlin initially? Eg (new?) question/control specific UI widgets first, then perhaps form navigation/lifecycle management, then finally core javaRosa type stuff? Just wondering if there could be a way to intelligently stage such a code transition (having faced similar issues wrt Objectice-C / Swift...)


(Udhaya Kumar) #7

kotlin reduces a lot of boiler plate codes. for eg. you don't need the reference the UI widgets in the java code which reduces a lot of variable in the activity code. another advantage i could see by using kotlin in our project is by using kotlin-coroutines or asynchronous task(which i believe to be good boundary as skunkworks-bat mostly deals Firebase networking code and also using room for storing local data instead of SQLIte helper i believe to be a good choice and kotlin helps a lot in using room) , right now we are using AsyncTask for that Asynchronous code and in google I/O 2018 they recommended us to move to coroutines. The https://github.com/opendatakit/skunkworks-bat project is only in the beginning stage So i thought i would be the best time to use use move from support library to AndroidX and introduce kotlin in the project


(Udhaya Kumar) #8

The reason i recommended this approach is because in my team we have just started using kotlin for android development and everyone loves it. and we are slowly porting the entire the code base from java to kotlin and now the code base has both java and kotlin code. regarding the time needed to implement the proposal in the case of https://github.com/opendatakit/skunkworks-bat is if we have a single person working on converting the support library to androidx, moving to room from SQLite Helper and shifting the code to kotlin i believe it would only take 2-3 weeks


(Dr. Gareth S. Bestor) #9

In your experience have you seen anything to suggest what might lend itself better/ worse to porting first? At least in mine, I’ve found porting ‘low’ level custom code - stuff that often doesn’t follow an overall framework (eg javaRosa) takes a bit more care to switch languages than, say, UI code that often follows a similar pattern. I say all that having zilch experience in Kotlin... but if you could offer some knowledgeable recommendations on perhaps what lends itself better, that might help guide any such a transition.


(Udhaya Kumar) #10

ok i got it.Actually i am working in a online movie booking app(JusTickets). when we ported the code to kotlin we faced few problems.
1.The first problem was with Dependency Injection (Dagger 2) . I guess one of the problem was with using lateinit keyword in kotlin code. we faced with few build time errors. it was only a minor change as we were able to correct it with help of error messages.
2. another case is few Unit tests and java fields were broken due of NPE(Null Pointer exception) in kotlin
3.a Third party lib(in our case one of payment gateway lib) was creating a lot of problems. So we left that part untouched for now.

as For the strategy we followed we were using mvvm architecture so we started from the entity layer and moved higher in the hierarchy and most of the migration can be easily done with java to kotlin tool in android studio our work was mostly to lookout for errors in generated code and correct it.

I know my answer is lacking all the details you were expecting. I just recently joined the company so i am not totally aware of all the problems the team faced while migrating :sweat_smile: .Sorry for my lack of knowledge (i am still learning). i would really appreciate any feedback regarding this proposal