https://kotlinlang.org logo
Join Slack
Powered by
Hello! I’m looking for in depth resources about c...
# compose
k
Hello! I’m looking for in depth resources about compose. Mostly how to build UI without google material implementation because, products that I work with or designers do not care about Google’s theme. And I find cumbersome to make copy/paste and dive into the material components and find all the styling they applied.
s
You can try avoiding bringing in the material or material3 dependencies completely, and build everything on top of foundation, nothing stopping you from doing so. The only bad part there is that you will have to build a lot of things yourself. But since you say your design system is completely custom anyway I suppose that’s what you want.
k
Yeah that’s what I’m doing. But I was wondering if there is something more than just raw documentation and looking into implementations of those components. Some explanations around 
Layout
, 
MeasurePolicy
, 
ParentDataModifier
and how to handle internal states with 
remember
and also something about usage of 
staticCompositionLocalOf
. Building custom layouts by extending i.e. 
FrameLayout
was straightforward as you would do it as just implementing a class. Where in compose it all happens in scope of a function.
t
Compose is much more flexible than the legacy layout system. So you could maybe use material components anyway. But most of the documentation is relevant even if it describes maybe just a material component. Compose need you to completely relearn how to write your UI. So you should first get some experience working with material components and than you can adapt them to you needs or build you own from scratch.
Btw. many compose components are not Material. Especially the layouting stuff
k
That’s true. The problem mostly is that with material there is plenty of paddings, colorsOnContent and fonts that are not matching the designs that I work with
That results with let say 
TexetEditLayout
having wrong borders, to much padding, hint in wrong place, etc.
I wrote the the theme following google sample don’t remember which jetXYZ project had it and it’s fine
t
Yes for this you could just use the foundation components.
You can also define you own color system but it is of course easier to use the Material one.
k
all design definitions of shapes, fonts and colors are to what my designer set. But it takes some time to find where and why I’m getting different color that expected
t
Yes me too 😄 And with Material3 it changes again. But for most component you can manually change the colors.
Even if it is a Material component
e.g.: Button
I would recommend to use Material3 as base. You can than define you own composables for your design which change the default colors if you have an custom color system.
k
Yeah, I don’t want to reinvent the wheel… I don’t have 2 years to make working framework 😂 …
t
It is so easy in Compose:
Copy code
@Composable
fun CustomDesignButton(
    onClick: () -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    content: @Composable RowScope.() -> Unit
) {
    Button(
        modifier = modifier,
        onClick = onClick,
        colors = ButtonDefaults.buttonColors(
            containerColor = YourColorSystem
        ),
        content = content
    )
}
Keep in mind to make you color system flexible enough to support darkmode or other changes.
a
Another possible approach is to convince your team to use the material design, with the rationale that it will save a lot of resources (e.g. development time, fixing issues, etc.). 😁
k
@Arkadii Ivanov couldn’t convince PO that payment flow in modal sheet is bad design and this component is not for that sooo I doubt 😂
a
@Timo Drick you mention the “legacy layout system”. You mean there is a newer method?
t
I see the XML/View layout system as legacy. And compose is the new one.
New apps only need one activity and no fragments and no XML most of the time. Except you want to do a slow migration from existing fragments and activities
d
I did several large projects without using MaterialTheme at all. I've just copied and adapted what's inside 
MaterialTheme
and made that into 
AppTheme
. As for components, I still use many material (2) components (text, text fields, alert dialogs, sheets), because actually they are quite flexible. The main thing to keep track of here is to pass all colors manually, and almost all current components have them exposed as arguments (thankfully). And then you simply build your own uikit and don't specify those colors each time.
Oh and you also can have something like
Copy code
fun AppTheme(content: @Composable () -> Unit) {
  MaterialTheme(colors = AllMagentaColors) {
    CompositionLocalProvider(
      LocalAppThemeColors provides myColors
    ) {
      content()
    }
  }
}
which will aid you in transition, because each time you don't specify the color and some material component will default to something from MaterialTheme, it will turn out as magenta which you won't miss 🙂 Then you can remove that "debug" wrapper.
j
Some stuff moved from material into foundation, same goes for Accompanist. I have done hybrid design systems and fully customized. Most of the time need to look at M3 source code I would say. The core concept in material seems to be Surface, so that one I recommend using custom box and combine all variants of checkable, swipeable etc from built in Modifiers. For colors if not need dynamic colors, its quite straight forward declare your own, but I recommend follow contrast accessibility and such Material theme builder can help with. Not necessarily same color tokens. Most stuff like Button just wrapping Surface/Box and input field use BasicTextField. Quite easy implement from foundation. I recommend check Local compositions and state holders in compose, heavily used. Like LocalContentColor to share colors between components.

https://youtu.be/l6rAoph5UgI▾

This quite good explains more bare bone layout and such. Check LookaheadLayout and SubcomposeLayout as well. Probably needed in heavy custom components. When things go complex if want to have tonal elevations, shadows, blurring, custom font loading, override ripple effects (not only in material) imo. Its not that huge duplicate your own system if everything is so custom compared to material, probably spend more time hacking material components than build from scratch. Curious if using same system for web, iOS or such. I bet they have similar challenges?
https://developer.android.com/jetpack/compose/designsystems/custom This show hybride variant as well as custom concepts.
Sample with custom surface https://github.com/joeldenke/android-template/blob/main/core/designsystem/src/main/java/se/joeldenke/theme/ui/component/JSurface.kt Can also check rest of design system. Not complete, just a basic one I check to remind myself how to do 😁
c
Jetsnack is our current sample implementation of a completely custom design system that is not Material: https://github.com/android/compose-samples/tree/main/Jetsnack
designers do not care about Google’s theme
@Kamil K curious on this statement relative to the designs you are trying to implement. I assume there’s an iOS app version for your app - do the designers not follow Apple’s HIG or use any native controls out-of-the-box there? Compose Material is meant to be the foundational UI components library to build an app that looks and feels native on Android, despite the perception that it’s meant only for Google apps.
k
They use components but do everything their way or mixing iOS. I.e. switches in design are straight from iOS. But mostly what I mean is that they do not follow material design system. Make a TextInputLayout have text in different place, disappear rather move it around, snackbar coming from behind bottom bar. Bottom sheet not covering bottom nav. Bottom nav in details screen.
s
Sounds to me like you got a very normal scenario tbh 😅 That's what a lot of us are working with too. What I do is start with m3 components and adjust accordingly. If the component looks different enough, well I gotta tell you, you gotta make it yourself, no shortcuts besides copy pasting the existing implementation of m3 as a starting point. Also as others mentioned, not sure about your leverage, but when something looks too iOS-y I just do it in the Android way and then continue with my day. If they say that they absolutely need it in the iOS style, explain to them that you're gonna spend 3 days on it and if that's an acceptable waste of time. And if they say yes, then well, you spend those days.
j
Can always go compose multiplatform and go one design for all platforms. Ignore uikit, material etc and create one unique system. In end I think end users will tell if like or not. Mixing back and forth has always been in app development. Today many concepts between iOS and Android at least aligns. Worse when Material 1 released 😁
260 Views
Open in Slack
PreviousNext
Powered by