Android Compose library without Material

Question

Android Compose library without Material

Closed this issue 4 months ago · 10 comments

yschimke commented 5 months ago

About this issue

Markdown() composable has a strong dependency on material components like androidx.compose.material.MaterialTheme.

For Wear these should be avoided and instead use Wear Material versions.

See https://developer.android.com/training/wearables/compose#different

Is it feasible to pull these Color and Typography factories that default to mobile material to a separate dependency?

Details

0.11
Wear (Android)

Checklist

Answer 1 · 2024-01-12T13:26:11.000Z

n.b, FAQ is missing? https://github.com/mikepenz/multiplatform-markdown-renderer/blob/develop/FAQ.md

Answer 2 · 2024-01-12T15:49:11.000Z

Good day @yschimke

Thank you very much for the report. The MaterialTheme is already only used in the default factories, allowing you to replace all of them with alternative variants:

hhttps://github.com/mikepenz/multiplatform-markdown-renderer/blob/develop/multiplatform-markdown-renderer/src/commonMain/kotlin/com/mikepenz/markdown/model/MarkdownTypography.kt
https://github.com/mikepenz/multiplatform-markdown-renderer/blob/develop/multiplatform-markdown-renderer/src/commonMain/kotlin/com/mikepenz/markdown/model/MarkdownColors.kt
https://github.com/mikepenz/multiplatform-markdown-renderer/blob/develop/app/src/main/java/com/mikepenz/markdown/ui/Theme.kt

If you adjust all of these, wouldn't R8 be capable of removing all references for Material classes?

Answer 3 · 2024-01-12T15:59:22.000Z

Yep, I'm not blocked. I would feel safer not relying on R8 to drop dependencies. Feel free to close if you feel strongly about it.

Answer 4 · 2024-01-12T15:59:55.000Z

And nice library.

Answer 5 · 2024-01-12T16:02:53.000Z

@yschimke mostly curious on it. haven't shaped a decision on it yet. Do you have an example of a library which includes compose ui and splits to a wear module and other modules due to material theme?

Answer 6 · 2024-01-12T16:10:16.000Z

The whole of Wear Compose is like that :)

It has a Wear Material Text instead of Material Text. Wear MaterialTheme instead of MaterialTheme.

But honestly, I think it's about supporting more than just Material. There are other possible design systems, and I'd personally prefer to be able to import multiplatform-markdown-renderer without any explicit material assumptions. And a markdown-material for mobile, and markdown-wear for Wear.

Answer 7 · 2024-01-13T08:45:40.000Z

Moving the MaterialTheme was done here now: 16015cf

But how would you advice on going with Text or Surface in general. I have extracted those also by copying over some parts of Text and Surface from Material. However that doesn't seem very maintainable to do that in general? 🤔

#107

Answer 8 · 2024-01-13T10:39:15.000Z

I sort of got the impression you are making most of the decisions upfront, so using BasicText directly might be the right thing.

Wear Material actually doesn't have Surface at all. So maybe uplifting those to the m2 or m3 impls might be the solution?

Thanks for attempting this, I hope overall it's a clean up and more correct as people switch between m2, m3, wear.

Answer 9 · 2024-01-13T10:42:53.000Z

Thank you for the additional input @yschimke

I would highly appreciate if you could review the PR #107

Decided to have wrappers (basically similar to what you mentioned on uplifting the m2/m3 impls) based on the normal surface/text components: https://github.com/mikepenz/multiplatform-markdown-renderer/pull/107/files#diff-8142270f21ac4367be27d783daec3cdff3fafe3e4e498bf9e046932a901b1dab - allowing the full removal of the Material dependency.

Answer 10 · 2024-01-13T11:59:23.000Z

For everyone looking for this. There is a first pre-release available with the individual m2 and m3 artifact.

v0.13.0-a01 - https://github.com/mikepenz/multiplatform-markdown-renderer/tree/v0.13.0-a01