Which side-effect handler for a one-time coroutine action in Compose?
This tests your understanding of Compose lifecycles and side-effect handlers. A good answer names LaunchedEffect(Unit), explaining the constant key ensures the effect runs only once. A red flag is suggesting launching coroutines on every recomposition.
What's really being asked
This question tests your understanding of the difference between composition, recomposition, and the composable lifecycle. It's not just about knowing the LaunchedEffect API, but precisely why it's correct for this scenario and how to use its key parameter to control its execution frequency. The interviewer is looking for precision and an awareness of performance pitfalls.
The full answer
A strong answer hits four points in order. First, state the correct handler is LaunchedEffect with a constant key, like Unit or true. Second, explain that LaunchedEffect creates a coroutine scope that is automatically cancelled when the composable leaves the composition. Third, clarify that using a constant key (Unit) is the critical piece that ensures the coroutine is launched only once when the composable first enters the composition. It will not be relaunched on subsequent recompositions. Fourth, briefly contrast this with why other handlers like SideEffect (runs on every recomposition) or DisposableEffect (primarily for cleanup) are incorrect for this specific task.
The mistakes people make
The biggest red flag is suggesting rememberCoroutineScope and then calling scope.launch directly within the body of the composable. This is a critical error, as it will launch a new coroutine on every single recomposition, potentially creating thousands of network requests and crashing the app. Another wrong answer is just saying LaunchedEffect without specifying the key (Unit), which shows an incomplete understanding of how to control its execution. Finally, suggesting init in a ViewModel answers a different architectural question; you should first answer the question as asked about composable-level effects.
What usually comes next
Expect follow-ups like: "What if you need to refetch data when an ID changes?" (Answer: Change the key to LaunchedEffect(id) { ... }). "When would you use rememberUpdatedState with LaunchedEffect?" (Answer: When the effect's coroutine needs to access a value from the composable that changes over time, without restarting the effect itself). "Why not just fetch this in the ViewModel's init block?" (Answer: That's a great architectural choice for screen-level data, but the question tests knowledge of composable-scoped effects, which are useful for smaller, self-contained components).
A concrete example
To fetch initial data for a screen, you'd use LaunchedEffect(Unit) { viewModel.fetchInitialData() }. If you incorrectly used rememberCoroutineScope and wrote scope.launch { viewModel.fetchInitialData() } in the composable body, and a text field on that screen caused 5 recompositions per second as the user typed, you would be launching 5 redundant network requests every second. The correct LaunchedEffect(Unit) approach launches exactly one request when the screen first appears.
Interview question
To perform a coroutine action only once when a composable first enters the composition, which handler is most appropriate?
- a.SideEffect { ... }
- b.DisposableEffect(Unit) { ... }
- c.LaunchedEffect(Unit) { ... }Correct
- d.rememberCoroutineScope().launch { ... }
Why? this is the answer
LaunchedEffect with a constant key like Unit ensures the coroutine runs only once when the composable first enters the composition. Directly calling rememberCoroutineScope.launch would relaunch the coroutine on every recomposition.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #jetpack compose
- #kotlin
- #coroutines
- #side-effects
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles