Effective Kotlin

Modifier builders or resources that are used for many composables can be extracted for better performance. Why making something many times, if you can create it only once 😎

This is what the map, filter, and onEach from Kotlin Coroutines look like under the hood. Yes, it's that simple. Flow under the hood is as simple and efficient as it can be.

derivedStateOf can only observe snapshot state; it cannot observe parameters! If you use any parameter that might change, you must include it as a key in remember to create new derived state when it changes!

If you need to persist identity of a component that changes place, that can be achieved with movableContentOf. It allows using the same composable objects as children of different parents. That is especially useful when we define adaptive layouts.

There is no other feature that shaped so strongly what Kotlin looks like today! Extension functions, one of the most beloved Kotlin features, turned out to be likely the most influential one. Let me explain briefly 👇🧵

If Python is your “get things done” language, what starts breaking once the codebase grows to years, not weeks? This article by Marcin Moskala compares Python vs Kotlin through real code (scripts → CRUD → backend), and shows why teams are increasingly treating Kotlin as a pragmatic “Python, but production-scalable” option. Originally published on the JetBrains blog. Read: kt.academy/article/python…

Most Compose developers misunderstand state, and how its changes cause recomposition. Let’s review what everyone should know about state.

GlobalScope is a poor practice and it should be avoided. Let me explain why, and what should we use instead.

Most Compose teams don’t struggle because Compose is complex. They struggle because everyone applies different patterns. When knowledge lives in a few people’s heads, UI behavior becomes accidental. Advanced Compose helps teams build shared mental models, so everyone reasons about UI changes the same way. That’s when code reviews get easier and regressions drop. Explore how Advanced Compose aligns teams → advancedcompose.com

No matter if you want to write documentation, an article, or just better understand what you read, you should know the essential programming nomenclature Stop confusing: 🚨 arguments and properties, 🚨 statements and expressions, 🚨 properties and fields and much more kt.academy/article/progra…

Have you ever “fixed” a Compose performance issue by randomly reshuffling state or adding `remember`, without being sure *why* it worked? I published a short quiz to help you check whether you actually understand recomposition and stability in Jetpack Compose. Verify your mental model, catch common misconceptions and get a clearer direction on what to revisit next 👇 kt.academy/article/quiz-r…

Have you heard about the bug that nearly destroyed Earth? In 1983, the soviet early warning system showed five incoming nuclear missiles from the USA. Lt. Col. Stanislaus Petrov reasoned that if the U.S. wanted to attack the Soviet Union, would it really launch only five missiles? He ordered his men to stand down (which was against higher orders), and 23 minutes later, radar outposts confirmed that there were no incoming missiles. The mistake was due to a system bug. So if you accidentally released a bug on production, know that it could have been worse, much worse.

Certificates are external proof. Confidence is internal. A certificate works well on LinkedIn. It’s also something you can show to your team or manager. But real confidence comes from being able to explain: – why this UI behaves correctly – why a refactor is safe – and when an approach will break The certificate is the signal. The understanding is what you use at work. If this fits your work, explore Advanced Compose -> advancedcompose.com

Here is an overview of different row arrangement options in Jetpack Compose.

Component parameter order should never be random! This is how we order them: 1. Required parameters (no optional value). Those should be essential parameters of this component. For non-essential, provide default value. 2. modifier: Modifier = Modifier at first optional position. 3. Optional parameters, so parameters with default values. Those should be majority of your parameters. 4. Finally, layouts or components that have content might please content slot at the last position to support trailing lambda convention.

Simplest Nav2 → Nav3 Migration Guide If you’ve already used Nav2, here’s the quick “what maps to what” when moving to Nav3: Destinations → NavKey NavController → BackStack NavGraphBuilder → entryProvider composable<...> → entry<...> navigate(Destination) →.add(Destination) navigateUp() →removeLastOrNull() enterTransition + exitTransition → transitionSpec popEnterTransition + popExitTransition → popTransitionSpec @jovchem Get the full migration walkthrough here 👇 kt.academy/article/nav2-t…

AI makes writing code cheaper. It does not make judgment cheaper. AI can generate Compose code, but it cannot reliably explain behavior, predict consequences, or choose long-term trade-offs. Those limits are exactly where career value concentrates as teams adopt AI. Engineers who understand how UI actually works are the ones trusted with reviews, refactors, and architectural decisions. That trust is what drives job security and advancement in an AI-assisted world. Advanced Compose builds the ability to reason about behavior and correctness. Polished Compose extends it to designing UI that stays consistent under change. Details on building that understanding are available here: Advanced Compose 👉 advancedcompose.com Polished Compose 👉 polishedcompose.com

This is how modifiers are applied one after another: 👉 Background draws behind the whole area. 👉 Clip limits drawing space to the circle shape. 👉 Border draws border, around whole square, but it gets limited by circular area. It also clips the area where border is drawn (to prevent overdrawing it) 👉 Offset moves component area. 👉 Padding limits component area. 👉 Image is drawn in this area (changed by offset and padding) where not clipped (by clip and offset).

Even with strong skipping mode, stable types should be preferred. The greatest source of unstable parameters is collections. 𝐋𝐢𝐬𝐭, 𝐒𝐞𝐭, 𝐚𝐧𝐝 𝐌𝐚𝐩 𝐚𝐫𝐞 𝐮𝐧𝐬𝐭𝐚𝐛𝐥𝐞. There are three main ways to deal with that. 👇

This crash is brutal because it often happens only with “real” data and often only in “specific” situations `IllegalArgumentException: Key … was already used` Why does it happen? Elements in collections are identified by values returned from a key function. So this result MUST BE unique. If two elements on the same list have the same key, this error occurs. How to prevent it? - Use immutable and unique values as keys, typically IDs from the data layer. - If the domain model doesn’t provide a unique ID, construct your key in a way that is unique. Learn about using keys in Compose collections in the Advanced Compose course 👉 advancedcompose.com