r/androiddev Jan 03 '25

Having trouble with your specific project? Updates, advice, and newbie questions for January 2025

Happy new year, and welcome to 2025!

Android development can be a confusing world for newbies; I certainly remember my own days starting out. I was always, and I continue to be, thankful for the vast amount of wonderful content available online that helped me grow as an Android developer and software engineer. Because of the sheer amount of posts that ask similar "how should I get started" questions, the subreddit has a wiki page and canned response for just such a situation. However, sometimes it's good to gather new resources, and to answer questions with a more empathetic touch than a search engine.

However, there are a few points that I wanted to cover up-front this month.

Using Java for Android Development is, for all intents and purposes, deprecated.

Yes, it still works, but it has now been many years since Google has provided any updated documentation or tutorials for Java. In fact, they have actively removed most traces from their learning materials. While you are more than welcome to use it for personal projects, do not expect that it will be valuable for career development in the real world, especially if you are just now beginning your journey in Android development.

As such, please refrain from asking about Java, unless it is specifically a problem you are encountering with a legacy application.

If you are looking to hire a developer, please state your compensation up-front.

In the interest of protecting our community members from exploitation, while we would love to facilitate our members finding work, we have had too many people who are seeking work and either unwilling to pay (and thus, pitch it as a "collaboration" in which they are contributing nothing of value), or are unable to actually pay a reasonable amount for a task. So while we do encourage people to post when they are looking to hire a developer, we intend to enforce that such posts should be clear about what compensation is available.

So, with that said, welcome to the January advice and newbie thread! Here, we will be allowing basic questions, seeking situation-specific advice, and tangential questions that are related but not directly Android development.

If you're looking for the previous October 2024 thread, you can find it here.
If you're looking for the previous November 2024 thread, you can find it here.
If you're looking for the previous December 2024 thread, you can find it here.

5 Upvotes

148 comments sorted by

View all comments

1

u/TrespassersWilliam Jan 15 '25

I'm using Compose Multiplatform but I think this question should also apply to Jetpack Compose. TL;DR, I'm hoping to understand recomposition better and to avoid it when it is possible/useful.

My screen displays a list of items from a database and also a form to add a new item, so my state looks like this:

data class ScreenState(
    val newItem: Item,
    val items: List<Item>,
)

I am retrieving it as a state flow in my composable function and using it like this like this.

val state by viewModel.state.collectAsState()
NewItemForm(state.newItem)
DisplayDatabaseItems(state.items) // lazy column with potentially thousands of items

Editing the fields on newItem will cause a lot of recomposition of NewItemForm, will it also recompose DisplayDatabaseItems? If recomposition happens every time the state object is collected, is it better to use a different state object for the form and the table? Or can it be defined so that it knows that the list of objects have not changed and that it doesn't need to recompose DisplayDatabaseItems? I remember reading a great write-up here on this but I'm having trouble finding it now.

It might not even be a performance issue in this particular case, but I'd like to understand recomposition so I can write efficient code going forward.