Any plan to add Kotlin Multi-platform Mobile support?

[kaushalyap]

This seems great, compared to MPAndroidChart, since KMM is reaching stability, Any plans to support KMM?

[Gowsky]

Hi @kaushalyap,
KMM support is not our priority currently, but we’ll look into supporting it in the future.

[kaushalyap]

@Gowsky Any plans for this, since KMP is becoming more mature?

[Gowsky]

@kaushalyap Just like I said before, we will consider adding it in the future.

[sproctor]

I need charting functionality in a Compose/KMP app. Would you be willing to accept a PR to add multiplatform support in the near future?

[Gowsky]

Hi @sproctor, yes, we would accept such a PR. But please remember that Vico must still be available for the view system and Jetpack Compose. The current core module would need additional abstraction over classes such as Canvas, Paint, and Path. Other usages of Android-specific classes (like RectF) would need custom implementations. It would be a massive and challenging library rewrite.

The rewrite will take lots of time, and the current Vico 2 development introduces many changes you would need to merge regularly. Otherwise merging changes may get problematic.

I don't want to discourage you, and I just wanted to make you aware that it won't be an easy task.

[ahmedhosnypro]

I really love vico, and wish you will support KMP in the future

[Monabr]

KMP support is really needed!

[Gowsky]

I noticed that you gave a thumbs-down emoji to my reply about the Compose Multiplatform not being our priority. May I know why?

The amount of work needed to add Compose Multiplatform support while keeping native compatibility with the view system will be astronomical. It’s planned, but we can’t drop everything else. Our current top priority is stabilizing Vico 2 and promoting it to beta.

Please keep in mind that this is a free project. You’re more than welcome to contribute if it's so important to you.

[Monabr]

I can't agree with you. To me it looks like just transferring all logic from regular compose to multiplatform compose. That is, only packages will change.

[Gowsky]

@MonBar that’s totally inaccurate. The compose module may be easy to migrate, but the main logic is in core, which currently depends on low-level Android APIs shared between Compose and views. Compose Multiplatform doesn’t use these APIs. To keep a universal core module and native view compatibility, we’ll need to add complex graphical abstraction layers.

If you still can't agree with me, and it's way easier than I picture it, why won't you open a pull request if it's so easy to do?

[Monabr]

Why does Compose library use Android's XML views? Isn't that weird?

[Gowsky]

@Monabr, your premise is false. It's an Android library with independent modules for Compose and views:

• To use Vico with Compose, you add only Vico's compose module. There are no underlying views or XML. Compose is used natively.
• To use Vico with views, you add only Vico's views module. There's no underlying composable. Views are used natively.

Both of these modules implement core, which includes common, UI framework-agnostic logic. It depends on low-level Android APIs and doesn't use either Compose or views. The challenge with Compose Multiplatform is that core can no longer directly use these low-level APIs.

Isn't that weird?

No, it's not, because it's not true. What I find weird is that you started arguing with me using a provocative tone and a know-it-all attitude without having this basic knowledge about the project. The README file mentions that both Jetpack Compose and the view system are supported and they work independently without the reliance on their interoperability. You can learn more about it here. I highly recommend that you do at least minimal research before engaging in such discussions, especially with this tone.

[sproctor]

Writing the abstractions for this is neither trivial nor complicated. When I first looked into it, I didn't realize they still supported Android Views. The simplest path forward would to be to create a fork that ditches the Android View system support and uses only Compose APIs, or convince the maintainers of this project to do that. The more complicated path would be to create an abstraction with mappers to both Compose and Android. It's not a big project, but it's more than I have time for. Koala plot already supports KMP and covers my desired use case.

[Gowsky]

If you were unfamiliar with a basic feature of the code base until recently, what makes you believe you’re now in a position to make such definitive judgments? There’s much more to adding Compose Multiplatform support than creating a graphical abstraction layer. Your failure to consider the remaining aspects discredits your assessment.

Thank you for your interest in contributing, but there’s no reason to make unsubstantiated comments minimizing the complexity of a task that you’re not involved in, especially when I’ve confirmed that we’ll look into it.

[sproctor]

Yes, before using a library, I was unfamiliar with the parts of it that are not useful to my application. During my initial investigation, I was still searching for a library the could fill my requirements.

You have your own priorities and only you can determine them. They don't match with mine and that's fine. If I were motivated, I could do the work for myself. For my application, it's a minor feature that I've accomplished another way.

I didn't say it's not a substantial amount of work, and I did look into it after my initial comment.

[Gowsky]

Yes, before using a library, I was unfamiliar with the parts of it that are not useful to my application.

Understandable, but that’s not the question. I asked why you think you’re now in a position to make such definitive judgements, not whether you were unfamiliar with the library at some point. You’ve not shared or demonstrated anything to support the accuracy of your assessment. Mine is based on 3.5 years of experience co-authoring the project from scratch.

You have your own priorities and only you can determine them. They don't match with mine and that's fine. If I were motivated, I could do the work for myself. For my application, it's a minor feature that I've accomplished another way.

I’m not arguing against any of that. Contributing isn’t required. But if you’re not involved in development, why baselessly argue that I’m exaggerating the task’s complexity? I have nothing to gain by doing so. The request has been accepted.

I didn't say it's not a substantial amount of work

You said it was not “complicated” and “not a large project.” What else do those comments mean than “not a substantial amount of work”? What do they achieve?

and I did look into it after my initial comment

I’m not denying that. Again, thank you for doing so.

[sproctor]

I asked why you think you’re now in a position to make such definitive judgements

It's my opinion after have migrated multiple projects to KMP. Anyway, I'm out of this conversation now. Good luck with your project.

[Gowsky]

Different projects have entirely different requirements. I don't think you can make a valuable estimate without also having a deep understanding of Vico's unique structure. A subjective judgment with no specifics is not productive if you're not involved in the task.

Good luck with your project.

Thanks!