Hey guys. Perhaps less so with Kotlin, but it seems most projects end up having some sort of "utils" file. Here are some I have for Compose. Are these useful? Or do they reflect solutions to anti-patterns elsewhere in my code? What utils do you have that others may find useful?

I wrote something like

spacingArrangement

once, but it didn't seem to affect the size of the parent so stuff got clipped. Not sure if I was doing something else wrong too though. Your

toPx

seems like it could potentially have negative performance impact since it encourages making lots of subscriptions to the ambient, but I'd be curious to hear what the googlers think of it. Does seem like it would be handy

all of the subscriptions will end up on the same scope, but it does incur a bigger cost since you’re doing it once per call

I haven't tried getting the parent resized with spacingArrangement actually, right now I'm using it to replicate Figma's auto-layout distancing. I have been thinking about making a Figma plugin to export designs as Compose because it seems like it wouldn't actually be that hard

The

toPx()

helper is the one I was going to discourage 😛 usually you should be in terms of Dp during composition, if you need Px there often enough to justify that extension we probably have bugs to file

That's a good point because the reason I made it was to fix a compilation error when I add the @Composable() annotation to the overriden arrange, though I would still at least make it a private function for its usage in spacingArrangement, unless there's a better way? 😄

yeah i guess we might want to avoid making toPx() easier because people shouldn’t need it… and if they do, it’s a signal that a different API should maybe change to use DP

Yeah. I'm curious about how you guys make the decisions about deciding what is healthy for the ecosystem longterm vs. what is useful now

it’s easier to change things, it’s harder to know what the right change is

there's a lot of looking for x-y problems

x-y problems?

haha yeah like mine 😄

there's also whole frameworks about how to evaluate API usability that are quite useful, things that talk about how many concepts you need to combine to accomplish a task, how directly the solution corresponds to the problem, consistent abstraction layering, things of that sort

hence my first response to many questions on here is “What are you trying to do?”

very interesting

I have a doc that I maintain that is meant to explain compose to someone with about 2nd semester computer science proficiency just as an exercise; if the explanations in that doc start getting too muddled it usually means we have work to do

that's a really cool idea

if I don't like an answer in there I try to rewrite the doc with an answer I like better and then see if we can make the system actually work that way 🙂

Imagine if you had a similar document for android pre-x

"pre-x?"

the old support library

we were really targeting a different problem then, it was more about bridging the gap between android platform releases for a long time

interesting

imo it's a great fit for android because it matches android's constraints well. Very smooth interop story for interacting with a large existing API surface while keeping the native feel, cheap abstractions like extension functions and inline lambda support for higher-order functions, crossinline for helping to implement large callback object surfaces, small stdlib that behaves very well with code shrinkers

ooo yeah the coroutines are so nice

RxJava caught on like wildfire in the android community

I really want to learn rx sometime but it's hard to find the motivation as coroutines seems better for most scenarios

if you know flow you know rx

TIL