Flipping it on it's head to have this Idea for theme synchronization between Android XML Themes &amp...

# compose

[handstandsam]

Flipping it on it's head to have this Idea for theme synchronization between Android XML Themes & Compose:
• Apply Compose (Kotlin Defined) styles upon Existing Android Views. This could be done by extending the current View set to make AndroidX.Button.ComposeThemed or something?
You would force attributes of your Compose Defined Theme in that Android View programmatically and ignore existing style attributes.

It seems like a nice way to start defining styles in Kotlin, and slowly migrating existing widgets over to use those styles.

Thoughts?

[Adam Powell]

It can't be done in a general way; in short, here's why: https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/content/res/ResourcesImpl.java;l=1401

[Adam Powell]

the android framework downcasts the provided data structure requiring themed attribute resolution to happen from static compiled xml from the apk

[Adam Powell]

at the point where you're willing to use custom view subclasses as your widget stand-ins to get theming from compose, you might as well host compose in a series of separate views and use the compose versions of those widgets 🙂

[handstandsam]

Thanks for the insight. We are providing customization of current android views programmatically, but are looking to do it via code and not styles. So far it's worked in limited cases... I'm looking forward to Compose, but in the meantime before it's Stable, is there a full-proof way without XML?

[handstandsam]

For example in our Button Class which extends `MaterialButton`:

setTextSize(TypedValue.COMPLEX_UNIT_PX, context.resources.getDimension(params.textSize))

setCornerRadiusResource(params.cornerRadius)
        
setTypeface(context, params.typeface)

etc.

[Adam Powell]

What kinds of dynamic behavior and scoping are you looking for? Most solutions are going to have a similar shape of scoped observable subscription setting properties using existing view API, but those extensions are going to be very purpose-built for each view and property

[Adam Powell]

theming and styling as most people think of it is comprehensive and cross-cutting enough that this turns into a large task pretty quickly

[handstandsam]

🤔 - We're building an SDK that needs to be configurable. Our engineer working on this theming piece said it would be challenging to fight the styles of a client application (because like you said it's super complex), so they decided to go with the programatic approach. It is limited at this time, so I'm curious to see where it'll go and what limitations there will be.

I don't know the solution super well, but the general idea is that a 3rd party provides styles to an SDK so that it "feels the same" look and feel wise.

[handstandsam]

I think the rationale was that if we let people style everything via a theme, it could get out of hand... Will fill in more on this topic as I learn more about it.

[Adam Powell]

Generally that's spot on, it gets out of hand quickly

[Adam Powell]

The android team has a lot of similar challenges with standard apps like the package installer and following OEM-supplied device themes in those apps

[Adam Powell]

theming at the view level gets complex when you're working across third parties like that because every theme attribute you accept is an API contract for the host, but worse than that, every theme attribute the views you use as implementation details accept is a public API contract for the host as well.

[Adam Powell]

So if a view you use changes its contract, they've transitively changed your contract that you publish too.

[Adam Powell]

to address it we've moved further toward making those contracts explicit and deeply limiting what can cascade down to implementation detail components - this is part of why MaterialTheme for compose is so limited in scope.

[handstandsam]

Yeah, limiting it is definitely important. That's why we would have primitives as inputs.

Colors, fonts, spacing, and then would apply them, but not give full control, but still give a general feel.

Some product requirements want it to be 100% the same, but that's just not scalable like you mention.

[Adam Powell]

right, at that point what the host app is asking for is an SDK that lets them build their own UI for the functionality altogether.

[handstandsam]

I'll take this message to their product owner 😂

[handstandsam]

Amen.

[handstandsam]

alright, back to the weekend. Thanks for the conversation!