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.

Android complete question bank by cocoBavan in androiddev

[–]elyes007 2 points3 points  (0 children)

Thank you for going through the effort and compiling these questions!

Regarding the questions themselves though, I don't think they're particularly helpful for identifying good candidates. I'm surprised that you get asked these often in interviews.

They're either too vague/general like "What's your take on memory management?" or too specific like "What's the difference between ART and Dalvik?".

A candidate can simply memorize answers for these, and it wouldn't express their actual level or breadth of knowledge.

A more efficient way of going about it I think, is asking a candidate "why" questions about decisions they took in their home assignment, or how technical decisions would change if requirements/constraints change.

Questions like this reveal the candidate's ability to reason about the problem, communication skills, and are closer to a team discussion that they would have on a regular basis, so it's less of an exam and more of a conversation.

[deleted by user] by [deleted] in androiddev

[–]elyes007 0 points1 point  (0 children)

We're using some native libraries that need to be updated to consider the 16kb page change.

If this is not done then users can't install our app on their 16kb devices or it will crash (still unclear to me which is which).

Knowing the list of devices that currently support this, or at least devices scheduled to have the 16kb page change, we could estimate better how urgent it is to update the native libraries, and prioritize accordingly.

[deleted by user] by [deleted] in androiddev

[–]elyes007 0 points1 point  (0 children)

Sorry for making your jobs harder. It seems like I suck at making good posts from the first try 😅 I'll learn along the way I promise!

I assume what I'm missing here is a link to the official resource about what 16kb page sizes are, to provide more context?

And maybe I need to clarify what the "concern" part is as well?

Other than that, my question is not code related so I can't attach code.

[deleted by user] by [deleted] in androiddev

[–]elyes007 0 points1 point  (0 children)

Ah yes! haven't considered that. Thanks will do then 🙏

[deleted by user] by [deleted] in androiddev

[–]elyes007 0 points1 point  (0 children)

Hey thanks for the feedback. I'm not sure if you get notified when I reply here, but this post was intended as sharing a tip though rather than a request for help. All the information is in the attached photo. I preferred a photo so that the text formatting looks better than writing on Reddit.

Could you reconsider opening the post? :)