Using Kotlin in the Android app

[arnaudvergnet]

Maybe this has already been brought up, but I could not find information in the repo.

Since Java and Kotlin are interoperable (see this and this) I was wondering if you would accept new contributions in Kotlin.

Kotlin is the official language for Android and new frameworks are written for it (Jetpack Compose for example), this would make the app easier to maintain in the long run.

[biodranik]

Kotlin is good for development and for using 3party libraries. But it is worse for performance and device's battery: https://medium.com/rsq-technologies/comparative-evaluation-of-selected-constructs-in-java-and-kotlin-part-1-dynamic-metrics-2592820ce80

If you see any significant blockers/reasons why we should start using Kotlin now, please share, and let's discuss it.

Regarding 3party libraries, what is really required/needed/missing for OM in your opinion?

[andrewshadura]

I'm not sure why performance is important for the front-end given that all CPU-heavy code is in C++. The performance hit is likely going to be negligible compared to the huge safety and convenience improvements.

[biodranik]

KISS + YAGNI.

[arnaudvergnet]

I did not know about the performance difference! Maybe this could be mitigated by keeping key parts in java. But then this would make the codebase harder to read as it would mix 2 languages.

I did not find any blockers to start using Kotlin, but I tried it and felt it was easier to work with it. Less boilerplate code, more null safety and other benefits for developers. As I was looking into doing some refactoring on the Android app, I was wondering if it would be a good idea to write new classes in Kotlin.

Regarding 3party libraries, I saw Jetpack Compose was Kotlin only, so I felt more libraries could start following this trend. This could one day prevent OM to use such libraries.

[biodranik]

IMO now it would be better to focus on existing bugs and features. And switch to Kotlin only when we hit a real blocker. What do you think?

[arnaudvergnet]

Yes that would be the best solution for now, thanks for answering my questions!

[andrewshadura]

In this case, Kotlin is KISS, as it drastically reduces the complexity of the code.

…

On Mon, 14 Mar 2022, at 14:44, Alexander Borsuk wrote: KISS + YAGNI.

-- Cheers, Andrej

[biodranik]

Migrating existing code to Kotlin is not KISS.

[andrewshadura]

I don't see why given that there are people willing to do the work. OTOH there are a lot of people who won't even touch Java code with a ten foot pole, but would be willing to work on Kotlin code (myself included), so it may actually bring new contributors.

…

On Mon, 14 Mar 2022, at 14:52, Alexander Borsuk wrote: Migrating existing code to Kotlin is not KISS. —

-- Cheers, Andrej

[biodranik]

A good Android programmer usually reads and writes Java code too. We consider switching when it becomes really necessary, or benefits obviously overweight cons (time to refactor, runtime and battery overhead).

[biodranik]

I would like to add that the main issue now is not with the Java itself, but with many overcomplicated patterns used to implement simple features. Android and iOS implementations can and should be made simpler first. Repeating the same complex patterns in Kotlin doesn't make any sense.

[arnaudvergnet]

I'm back with some more refactoring ideas! I've been looking a bit at Jetpack Compose, and I think it would be worth considering.

It is no secret that the current Android app is a mess, especially if you look at the layout folder. Compose will help solve that issue by writing reusable components in Kotlin. Their approach at building UI looks a lot like QML or React.

Migration can be done incrementally as explained here. We could start with simple screens such as the about page, and as we write reusable components the rest of the screens would be easier. It would also help in migrating to Material 3 theme as discussed in #4676. We could then make 3 migrations at once: Kotlin, Compose and Material 3.

Google seems to be really pushing this framework forward and it seems they want to make it the official method for building apps. If there is no noticeable impact on performance, I really think it would be nice to start working with it instead of waiting to be limited by the Java/XML views. While refactoring over-complicated patterns, why not migrate to Compose at the same time? It would save a lot of development time.

It is even possible to write cross platform apps for desktop. As desktop do not require as much optimization as mobile devices, we could share the android code with the desktop version so it is more up to date.

A Compose app seems to be less complex and easier to maintain than a regular XML views app. This could help on-boarding new developers on the project. And as it is the new trendy Android tech stack (v1 was released in July 2021), it could help find new potential contributors.

Keep in mind I have no experience on Compose yet, so everything I say here is not out of experience, but from information I found online. We need to lookup the limitations, the impact on performance (especially when mixing XML and Compose), and ask experienced Compose devs for their thoughts on such migration.

[biodranik]

Unfortunately, the common UI codebase for different platforms newer was ideal, in decades. Writing native platform code without any "cross-platform" overhead produces better quality software, that looks natively and consumes less battery. These are very important features that should be always kept in mind.

[bam80]

It probably deserve separate discussion but in my understanding in QML case there is just no any "cross-platform" overhead by design - the apps speak to hardware directly via OpenGL or other native graphics API, so there are just no any translation layers capable to provoke the overhead.
But that is theory, I don't know how it will be on practice. And that's what I would like to know.

[arnaudvergnet]

For cross platform stuff, see https://github.com/orgs/organicmaps/discussions/1865.

Cross-platform UI only works if you have a very specific design and you don't care about respecting the platform's native look. QML apps look really out of place and don't respect Android's gestures or styling. If you want to respect the platform's styling/look and feel it will require more work and make the code more complex. Qt works really great for convergent applications, but cross-platform is another issue.

Regarding performance, I haven't done any proper testing, its just the feeling I got after using some apps (might be because the gestures are not responding the same way as native android apps). Qt on Android is still in its early days so it can probably be improved. And Qt apps have to ship their own rendering engine if they don't use native components so it will probably increase the app size.

[bam80]

Cross-platform UI only works if you have a very specific design and you don't care about respecting the platform's native look. QML apps look really out of place and don't respect Android's gestures or styling. If you want to respect the platform's styling/look and feel it will require more work and make the code more complex. Qt works really great for convergent applications, but cross-platform is another issue.

From what I can see, that's not quite true, at least in theory - Qt Quick Controls support styles, and Material Style based on the Google Material Design Guidelines is one of those.

[bam80]

There is interesting comparison:
Flutter vs Qt QML for cross-platform app development

PS:
oh, just noted you don't speak about Flutter here..

[biodranik]

Do you have any information on compose overhead for the battery life? I don't believe that this "code simplicity" comes for free. For example, if there is a choice of using Java instead of Kotlin, but saving one hour of battery life for a day-long trip, then the answer is obviously Java. We develop apps for users in the first place.

Looks like there are some optimization techniques already for compose. Does it mean that we can hit similar issues?

[biodranik]

Let's reconsider Kotlin in its minimal form, without overhead, to make the code more readable/less verbose: #12588