Hey guys. Perhaps less so with Kotlin, but it seem...

# compose

[caelum19]

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?

Utils.kt

[Zach Klippenstein (he/him) [MOD]]

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

[Leland Richardson [G]]

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

[Leland Richardson [G]]

i actually like the toPx() helper

[Leland Richardson [G]]

the arrangement thing IMO is something that should be much easier to accomplish than it is

[Leland Richardson [G]]

(or is it already and none of is in this thread know what it is yet?)

[caelum19]

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

[Adam Powell]

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

[caelum19]

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? 😄

[Leland Richardson [G]]

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

[caelum19]

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

[caelum19]

I guess that choice is a lot easier before mainstream usage 😄

[Leland Richardson [G]]

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

[Adam Powell]

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

[caelum19]

x-y problems?

[Adam Powell]

xyproblem.info

[Adam Powell]

that site is a little terse/snarky about it, but the idea holds 🙂

[caelum19]

haha yeah like mine 😄

[Adam Powell]

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

[Leland Richardson [G]]

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

[caelum19]

very interesting

[Adam Powell]

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

[caelum19]

that's a really cool idea

[Adam Powell]

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 🙂

[Adam Powell]

same with writing slide decks for conference talks over the years

[Adam Powell]

a lot of android Fragment API improvements over the years came about because I was embarrassed at the slides I had to write for a talk

[caelum19]

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

[Adam Powell]

"pre-x?"

[caelum19]

the old support library

[Adam Powell]

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

[Adam Powell]

prior to adopting kotlin the prospect of someone learning programming by learning android was pretty far out there

[caelum19]

interesting

[caelum19]

I am curious why Kotlin got on so well in Android but other adopters are so far behind

[caelum19]

at work I have finally broken from using Java and my teammates will be surprised by the next PR that contains this language Caelum keeps raving on about

[Adam Powell]

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

[Adam Powell]

more recently, everything about coroutines since android heavily relies on async and concurrent code

[caelum19]

ooo yeah the coroutines are so nice

[caelum19]

somehow I missed when flows became a thing

[Adam Powell]

RxJava caught on like wildfire in the android community

[Adam Powell]

and a huge portion of its usage on android tends to be for the scheduling rather than reactive streams

[caelum19]

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

[Adam Powell]

if you know flow you know rx

[caelum19]

TIL

[caelum19]

OH

[caelum19]

streams felt so much more confusing

[caelum19]

Is it just me or does Kotlin have really really good naming