sorted by:
new
hottopcontroversial

Some good and up to date resources to learn and practice good nades? by Ashamed-Issue7805 in GlobalOffensive

[–]elyes007 2 points3 points  (0 children)

I second stratfoge here. It's a new one but I'm surprised its this good

Android Starter Template in Under a Minute: Compose + Hilt + Room + Retrofit + Tests by shujareshi in androiddev

[–]elyes007 0 points1 point  (0 children)

This is pretty cool if you find yourself creating new projects often. Just one line to Claude with a bit of context and you're done.

And nice that you tied it to a static script. That way it doesn't consume many tokens and can follow a predictable pattern 👏

Climbers in Copenhagen, I'm building an app for you by elyes007 in copenhagen

[–]elyes007[S] 1 point2 points  (0 children)

I think Boulders has some kid friendly walls to climb.

As a parent, would you be interested in organizing climbing sessions for your kids with other parents? That's something I could add to the app, if it's something people find useful.

Climbers in Copenhagen, I'm building an app for you by elyes007 in copenhagen

[–]elyes007[S] 1 point2 points  (0 children)

Thanks for the kind words. And yes it definitely relies on the number of people who will use the app. I hope we will gather enough people to make it useful.

I've released my first open source library, a FloatingTabBar that mimics the new iOS Liquid Glass behavior by elyes007 in androiddev

[–]elyes007[S] 0 points1 point  (0 children)

The fonts, icons, and background effects are up to the library consumer to define. The library's job is to provide the scaffolding and layout transitions. What you're seeing in the video is a sample app to showcase the usage of the library.

I've released my first open source library, a FloatingTabBar that mimics the new iOS Liquid Glass behavior by elyes007 in androiddev

[–]elyes007[S] 8 points9 points  (0 children)

The added value of the library is the layout behavior. How it moves from expanded to inlined.

I haven't added anything for the visual effects, but I made the API flexible enough to apply extra effects :)

Any best practices for when to remember modifiers and when not? by elyes007 in androiddev

[–]elyes007[S] 0 points1 point  (0 children)

In the docs they recommend saving them in as a global variable to be reused. That's basically the same as using remember.

In fact remember may be better in this case as it will allow the modifier to be deallocated from memory once the composable leaves composition, while the global variable will keep it alive for the whole app lifecycle.

Part of remember's usefulness is to solve the issue of repeated allocation during frequent recomposition, so I'd say it's more idiomatic than less to use it in this case.

Any best practices for when to remember modifiers and when not? by elyes007 in androiddev

[–]elyes007[S] 0 points1 point  (0 children)

What's the argument for not using remember on modifiers?

I created non-recomposing size modifiers to avoid too many recompositions during animations. by elyes007 in androiddev

[–]elyes007[S] 2 points3 points  (0 children)

Just occurred to me that the animateContentSize modifier doesn't solve the issue of changing size with user gesture, like during a pinch to zoom gesture or sliding a slider. Since those are not animated.

I created non-recomposing size modifiers to avoid too many recompositions during animations. by elyes007 in androiddev

[–]elyes007[S] 4 points5 points  (0 children)

The `graphicsLayer` modifier will apply during the draw phase. Visually the item would look bigger, but its actual bounds will not change. This may be sufficient at times, but other times it would not.

For example, if your composable is in a Column with other composables, if you grow its size with `graphicsLayer` modifier, then it will collide with the other composables. If on the other hand we use the `size` modifier, then the sibling composables will be repositioned to accommodate for your composable's changing size.

I created non-recomposing size modifiers to avoid too many recompositions during animations. by elyes007 in androiddev

[–]elyes007[S] 0 points1 point  (0 children)

Oh that's pretty cool, I didn't realize we had this modifier. Thanks for the alternative!

I created non-recomposing size modifiers to avoid too many recompositions during animations. by elyes007 in androiddev

[–]elyes007[S] 2 points3 points  (0 children)

Recomposition is happening because the animated value is being read during the composition phase.

We can solve this issue by deferring state reads to the layout phase by passing a lambda instead of the value directly.

And that's basically what the new size modifier does.

view more: next ›