Stypox/dicio-android

Migration to Kotlin

Doomsdayrs opened this issue · 8 comments

Doomsdayrs commented

Android is using Kotlin more and more, It is wise to start coding in Kotlin too.

I suggest starting with conversion of the gradle scripts to kotlin scripts, then the rest can follow.

Stypox commented

I recently built an app using modern Android technologies (Jetpack Compose), and I agree that Kotlin is better than Java for writing apps in general.
However for Dicio I am not completely sure whether migrating to Kotlin is the best idea:

  • Java is more known and accessible for newbies, allowing more people to write skills and contribute to Dicio. If we were to migrate to Kotlin a possibility would be to enforce skills to use Jetpack Compose to provide views, but I am not sure how that would work out, because it would cut off people who don't know Compose.
  • Migrating a whole app takes much time, and I don't have that much time to do it all at once, but keeping files both in Java and Kotlin things a bit ugly (not the biggest problem though)
  • I would like to keep the basic libraries of Dicio (in particular dicio-skill and dicio-numbers) written in Java, to make sure other skills or projects can use them at their will, but Kotlin is not always interoperable with Java
  • The interoperability problem would also arise when implementing custom skills to be loaded from the marketplace: making sure those work in a straightforward way is important

I am open to changes, and I do not oppose migrating to Kotlin, but first the above concerns need to be addressed. For example, do you want to handle the conversion of the logic to Kotlin yourself? I would gladly pick up the UI and convert it to Jetpack Compose afterward.

Doomsdayrs commented

I recently built an app using modern Android technologies (Jetpack Compose), and I agree that Kotlin is better than Java for writing apps in general. However for Dicio I am not completely sure whether migrating to Kotlin is the best idea:

* Java is more known and accessible for newbies, allowing more people to write skills and contribute to Dicio. If we were to migrate to Kotlin a possibility would be to enforce skills to use Jetpack Compose to provide views, but I am not sure how that would work out, because it would cut off people who don't know Compose.

Kotlin is only a few minor changes in syntax compared to Java, as Kotlin was built to replace Java. With significantly less overhead to create classes and functions, making it more accessible to read and understand.

Furthermore, Kotlin is the language for Android development now, and Compose is the library for UI creation, As time goes on Java and XML becomes more and more a legacy system, and you'll have an inverse of people not knowing Java/XML, and knowing Kotlin/Compose.

* Migrating a whole app takes much time, and I don't have that much time to do it all at once, but keeping files both in Java and Kotlin things a bit ugly (not the biggest problem though)

AndroidStudio provides a shortcut to auto convert all Java to Kotlin, after a bit of logic verification it should only take 1-3 hours depending on the complexity of logic.

* I would like to keep the basic libraries of Dicio (in particular dicio-skill and dicio-numbers) written in Java, to make sure other skills or projects can use them at their will, but Kotlin is not always interoperable with Java

Kotlin is built to be interoperable with Java, Please explain.

* The interoperability problem would also arise when implementing custom skills to be loaded from the marketplace: making sure those work in a straightforward way is important

Please check Tachiyomi in regards to loading custom Kotlin code from separate APKs.

I am open to changes, and I do not oppose migrating to Kotlin, but first the above concerns need to be addressed. For example, do you want to handle the conversion of the logic to Kotlin yourself? I would gladly pick up the UI and convert it to Jetpack Compose afterward.

Sure, Once I have some time it can be done in a few hours with one giant commit. Or I could do it piece by piece.

  • 👍1
Stypox commented

Furthermore, Kotlin is the language for Android development now, and Compose is the library for UI creation, As time goes on Java and XML becomes more and more a legacy system, and you'll have an inverse of people not knowing Java/XML, and knowing Kotlin/Compose.

I agree with you on this. Also, writing skill UIs in Compose probably would simplify many things related to XML instantiation. So Kotlin/Compose is a win/win.

AndroidStudio provides a shortcut to auto convert all Java to Kotlin, after a bit of logic verification it should only take 1-3 hours depending on the complexity of logic.

Yeah, but from my experience the code autogenerated by Android Studio can usually be improved and is not always easily understandable.

Kotlin is built to be interoperable with Java, Please explain.

There are some kotlin features that have no counterpart in Java, for example named arguments. But this is probably not a big issue anyway: things like @JvmOverloads and @JvmStatic do exist to solve some of these issues. Though not all, I think: for example the Room database library (written in Java) is not completely compatible with all features of Kotlin data classes. That's why I would still like the dicio-skill and dicio-sentences-compiler code to remain Java. The UI (dicio-android) can be converted though.

Sure, Once I have some time it can be done in a few hours with one giant commit. Or I could do it piece by piece.

If you want to do it, that'd be great, thank you! I think the best approach is to first make one big commit with the Android Studio autogenerated code, and then some smaller commits fixing the various issues that arise.

Stypox commented

Could you take a look at #157? If you have any suggestion on how to improve the kotlin code feel free to share them. I will take care of migrating to Jetpack Compose and Material 3 later.

Doomsdayrs commented

Could you take a look at #157? If you have any suggestion on how to improve the kotlin code feel free to share them. I will take care of migrating to Jetpack Compose and Material 3 later.

Sure thing, I'll be available to look over this Tonight (4 hours or so) and comment about any improvements that can be made :D

  • ❤️1
Doomsdayrs commented

Just to note, There are issues with App architecture that should be handled before moving over to compose later.

I suggest looking into MVVM

Doomsdayrs commented

I suggest looking into ACRA for error handling

Stypox commented

Thank for taking a look!

I suggest looking into MVVM

Yes, I know about that now. I did not when I first built this app. While migrating to Compose I will make sure there is separation of concerns according to MVVM. I will also use e.g. hilt and other modern components.

I suggest looking into ACRA for error handling

I know about ACRA, since it is used in NewPipe. However I think it is mostly useless for these reasons:

  • Implementing an UncaughtExceptionHandler is simple enough, no need for a whole library to do it. This has not already been implemented in Dicio mainly for lazyness.
  • ACRA seems to have some problem with uncaught exceptions, since half of the times when NewPipe crashes the error activity (that should be triggered by ACRA's UncaughtExceptionHandler) does not show up.
  • At the moment I don't want to send logs anywhere. Letting users copy-paste a formatted report to post on GitHub works well enough (and is already implemented, try to ask the calculator to divide by zero).
  • Since I don't want automatic logs at all, the only non-automatic sender in ACRA that remains is email, but sending an email intent is also pretty simple to implement without using a library