This is an interesting issue. We will explore some tools that are very powerful, but that can be also terribly misused. Enjoy 😉

In this issue you will find:

💡 Compose tip: Preview options

📝 Scope functions

🎬 Example: Using Animations API in Compose

🤕 Best Practice: Application exceptions should not implement CancellationException

📝 Article: The future of mobile development

Make Compose UI consistent, modern, refined.

Join Polished Compose to learn how strong Android products improve visual quality through better theming, cleaner layouts, motion, and polish.

Last moment to join!

Enroll now → http://polishedcompose.com/

Compose tip: Preview options

Remember that you can define multiple previews 📱 This allows you to see many different:

👉 Parameters — check the same component in different states.

👉 Screen sizes — phone, tablet, desktop

👉 Orientations — portrait, landscape

👉 Screen characteristics — density, cutouts

👉 Locales, backgrounds, API levels and much more…

Scope functions

Kotlin stdlib provides simple but very useful functions that can be called on any value, known as scope functions. Each has its purpose and use cases where it truly shines. Let’s discuss let, also, takeIf, apply, with and run.

Let is used to transform one value into another. It allows calling functions “on” parameters. This also allows method call chaining. It is often used together with ?. to transform only non-null values.

also is used to execute an additional operation (side-effect) on a value. It returns the object it was called on. It is used to make an additional operation with a value.

takeIf and takeUnless are used to turn values we are not interested in into nulls. It is often used to eliminate invalid values, or files that does not exist.

let, also, are takeIf are for any object, what map, onEach, and filter are for collections.

apply is a function similar to also, but apply chages receiver (this) inside its body in the way it refers to the object apply is called on. It is perfect for mutable object configuration (setting properties).

with also changes the receiver for its body, but it accepts it as an argument, what makes receiver change more visible. We use with to explicitly turn an argument into a receiver.

There is also run, that behaves similar to with, but I do not know any good use cases for its usage. If you want to map, prefer let, if you want to change receiver, prefer apply or with. Here is a table comparing how each of those functions works.

Example: Using Animations API in Compose

With the amazing Compose Animations API, you can make so many beautiful effects so easily; you just need an idea, and the sky is the limit. 🚀

Best Pracitce: Application exceptions should not implement CancellationException

Application exceptions should not implement CancellationException. This is because CancellationExceptionhas a special meaning for coroutines, and they do not propagate it like other exceptions!

To learn more, read this section of Kotlin Coroutines: Deep Dive

https://kt.academy/article/cc-cancellation#cancellationexception-does-not-propagate-to-its-parent

Article: The future of mobile development

What the future holds for mobile development, and how it changed in recent years.

Learn from this article 👇

https://kt.academy/article/future_of_mobile

Hope you enjoyed this week’s newsletter.

Marcin Moskala

— kt.academy

Powerful tools, you can go crazy with was originally published in kt.academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

sometimes a simple idea can make such a difference, it feels like magic. Hash Map was certainly such an idea, the way how Flows are implemented were such an idea, end even intrinsic size in Compose is such an idea. In this issue you will find:

💪 Intrinsic size in Compose

🔎 Map Hash Table

⚛️ Quick Coroutines take: Most Flow processing functions are very simple under the hood

📝 Article: New big challenger in UI development

Your UI works. Make it polished.

Polished Compose is an advanced course for Android developers who want to improve visual quality, consistency, motion, and UX details in Jetpack Compose.

Starts 8 June 2026.

Enroll now → http://polishedcompose.com/

Intrinsic size in Compose

One less known, but surprisingly useful modifier is intrinsic weight/height. They allow us to give children even size, that is max/min from each of them. 💪

Let’s start with an example problem. 🔧 Consider that you have a list of texts in a column. Texts are decorated with a card. Your designer requests all cards to have the same width, relative to the longest text.

How can we achieve it? If you use a constant width, you will not react to text changes. If you use fillMaxWidth, you will make parent as large as the screen. The only way to achieve that is by using Modifier.width(IntrinsicSize.Max) on parent (Coumn) and Modifier.fillMaxWidth() on children. ⭐

Why Modifier.width(IntrinsicSize.Max)? That means taking as much space as the largest component needs. You can also take as little space as possible using Modifier.width(IntrinsicSize.Min). For text, that means width of the widest word. 👀

Map Hash Table

The complexity of finding a value by key in the default map on JVM is O(1), which means it is blazing fast, no matter how many elements there are in this map. Let me explain how it is possible

The default map in Kotlin is LinkedHashMap, but we also often use HashMap as a lighter alternative. Both keep elements using hash table. Hash table can be compared to a set of buckets, where elements can be stored.

When an element is added to a map, it first calculated its hash code using hashCode method. This method should be fast, should return the same int for equal values, and should possibly return different ints for different values.

We calculate hash code modulo number of buckets, and this is where element is added. Hash table is an array, and bucket number is the index of an element in this array.

Finding elements in the map is simple: we calculate its hash code modulo number of buckets (fast), and we know in what bucket it should be. Now we need to compare only with elements in this bucket.

The trick is that on JVM the number of buckets is always significantly higher than the number of elements, so of hashCode is implemented well, once we know bucket index, this bucket should either have this element or be empty.

Set works the same way, under the hood it is quite often just a map with constant value.

Quick Coroutines take: Most Flow processing functions are very simple under the hood

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.

Article: New big challenger in UI development

Could a UI framework that started on Android become a serious challenger beyond mobile?

This article looks at Compose as a multiplatform declarative UI framework written in Kotlin, and why it is starting to appear not only on Android, but also on iOS, desktop, and the web.

It covers:

• how Compose differs from DOM/CSS-based frontend approaches
• why previews, testing tools, and animation APIs matter in practice
• how teams use Kotlin across backend and clients, and why that makes Compose attractive

A useful perspective for developers watching the future of UI development across platforms.

👉 https://kt.academy/article/compose_new_challenger

I hope this newsletter was a valuable part of your week.

Marcin
— kt.academy

Tricks that make amazing experience was originally published in kt.academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Do you understand data classes? MutableStateFlow.update? Text in Compose? Compose itself? Those are the questions we will ask in today issue 😃

In this issue you will find:

💡 MutableStateFlow hint: Use update function to avoid synchronization issues

🔎 Text vs BasicText in Compose

📝 Deep dive into data classes

⚛️ Quick Compose take: Modifiers are everything

📝 Article: Collection Literals in Kotlin

Polished Compose is a 2-week advanced course for Android developers who want to improve theming, responsive layouts, animations, and visually polished UI in Jetpack Compose.

Learn how to structure interfaces that stay consistent, scalable, and production-ready as your app grows.

Starts 8 June 2026

Enroll now → https://www.polishedcompose.com/

MutableStateFlow hint: Use update function to avoid synchronization issues

Updates to MutableStateFlow should be made using the update function; otherwise, conflicts might cause some updates to be lost.

Text vs BasicText in Compose

What is the difference between Text and BasicText in Compose? They are both used to represent text, but…

👉 Text is a material component that includes many built-in features, making it easy to create text that looks good and is accessible. 𝐓𝐞𝐱𝐭, 𝐛𝐲 𝐝𝐞𝐟𝐚𝐮𝐥𝐭, 𝐝𝐞𝐩𝐞𝐧𝐝𝐬 𝐨𝐧 𝐋𝐨𝐜𝐚𝐥𝐓𝐞𝐱𝐭𝐒𝐭𝐲𝐥𝐞 𝐚𝐧𝐝 𝐋𝐨𝐜𝐚𝐥𝐂𝐨𝐧𝐭𝐞𝐧𝐭𝐂𝐨𝐥𝐨𝐫.

👉 BasicText displays an unstyled text, but is it highly configurable, so we can make it look any way we want. 𝐓𝐞𝐱𝐭 𝐮𝐧𝐝𝐞𝐫 𝐭𝐡𝐞 𝐡𝐨𝐨𝐝 𝐢𝐬 𝐣𝐮𝐬𝐭 𝐚 𝐰𝐫𝐚𝐩𝐩𝐞𝐫 𝐨𝐯𝐞𝐫 𝐁𝐚𝐬𝐢𝐜𝐓𝐞𝐱𝐭.

So when to use each? I typically start from Text, as it is often enough, and it looks good with minimal configuration, but I switch to BasicText if Text is limiting me.

Deep dive into data classes

Data classes are not just syntactic sugar; they have completely changed how we treat classes and objects, and by doing so, they have extremely simplified development. Let me explain 👇

In Java (before 14) and many other languages, developers need to learn about functions like equals, hashCode, and toString to define classes to represent data models.

There is no such need in Kotlin! In Kotlin, we have two types of classes: regular and data, and we nearly never need to define anything else!

Regular classes are perfect for representing components of our application, such as services, controllers, repositories, etc. They are unique and protect their state.

Data classes are perfect for representing a bundle of data. All the classes like Book, Product, or NewsFeet. Data modifier makes objects equal if their content is equal (primary constructor properties). It also provides consistent hashCode, and toString that prints the content.

Data modifier also provides the copy method, which is a game-changer for immutability. It allows us to make a new instance with some specific difference.

Data modifier also allows object destructuring, but beware, because Kotlin currently only supports position-based destructuring.

Java 14 introduced a similar feature called record classes, but let’s be honest, record classes have much more restrictions and Java projects are still full of equals, hashCode and toString.

Data modifier introduced a powerful abstraction, that made Kotlin much more beginner-friendly. Newcomers do not need to learn about correct overriding equals, hashCode, and toString, they can just use data classes, like we all do 😉

Quick Compose take: Modifiers are everything

If you strip composables from all the layers of abstraction, you will see that everything is just Layout and modifiers. Practically everything you see drawn on the screen is drawn by modifiers.

Article: Collection Literals in Kotlin

The new feature in Kotlin that allows for concise and expressive collection creation.

Read about it here: https://kt.academy/article/collection-literals

Hope you found this newsletter worthwhile.

Marcin Moskała

— kt.academy

Do you understand it? was originally published in kt.academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

This issue is packed with knowledge, so we have no time to spare! In this issue you will find:

💡 Preview parameters in Compose

💪 Cancellation in Kotlin Coroutines

📈 Optimising into arrays

📝 Article: Why do developers count from zero?

⭐ Project: vmScope

Preview parameters in Compose

Preview in Jetpack Compose is highly configurable, which makes development incomparably better than in other technologies. Let me show you 👇

You can use Preview annotation before any composable with no parameters. Such a composable can be previewed at any moment, or started on a device in separation.

You can also preview composables with optional parameters.

But you can also provide preview providers for parameters. Such providers can provide multiple variants of parameters, that leads to multiple previews. Is you start it on a screen, you can easily switch between different parameter configurations.

All those options contribute to amazing programming experience, as practically any single component can be simply previewed and started in separation.

Cancellation in Kotlin Coroutines

Most people do not even think about cancellation, but it is extremely important, and both Android and backend developers benefit from Kotlin Coroutines cancellation mechanisms. Let me give you some examples.

Thanks to structured concurrency, cancellation propagates from child to parent. That is a game-changer for Android developers, where each scope is associated with a view, so if the view gets destroyed, all its processes get cancelled.

But cancellation mechanisms are also a great benefit for backend developers. If you make async calls and one of them fails, others are cancelled by default.

Also when you define a backend application in a framework like Ktor, that is coroutines-first, if an HTTP connection is lost, call gets immediately cancelled, the same if WebSocket or RSocket connection is lost.

Exceptions happen, and connections get lost. Now you can calculate how many resources that can help us save if cancellation lets us close a connection with another service earlier, or not make a request at all, or not calculate something, or release a thread previously blocked.

Kotlin Coroutines cancellation is not perfect, but still, it is the best solution I know, and I am very happy to have it in Kotlin.

Optimising into arrays

Transforming lists into arrays can sometimes help us have a crazy amount of memory❗ Of course, such optimizations make sense only in very specific cases.

The size of IntArray is typically 5 times smaller than an array or a list of ints. The reason is simple: IntArray uses primitives that need only 4B. In other cases, we need a wrapped type that needs 16B for an object and 4B for reference.

Wrapped types also add a cost of accessing the underlying values and garbage collecting all the objects. That is why one of the first optimizations we do when we make performance tuning is optimizing for primitives.

Though this optimization only works for primitives. A typical list of object will need similar amount of memory as an array, because default list in Kotlin is just a wrapper over array. A wrapper that allows much simpler use.

That is why such an optimization should only be done on performance-critical parts of our code, where performance is more important than simplicity, as it often complicates our code and makes it less idiomatic.

Article: Why do developers count from zero?

Why do developers count from zero?

This article explains the classic reasoning behind zero-based indexing and why the convention became so deeply rooted in programming.

It covers:

• why starting from 0 made sense when memory was more constrained
• how array address calculations become simpler with zero-based indices
• why some languages still chose differently, even though most kept the convention

A short but useful read for developers who like understanding where common programming habits come from.

https://kt.academy/article/index_zero

Project: vmScope

Do you lack default error handler in viewModelScope? This library by Luka Velimirovic might be what you look for! It offers configurable multiplatform vmScope, as a replacement for viewModelScope. This library was made as a final project on Coroutines Mastery, great congratulations to Luka for creating it ❤

Code 👉 https://github.com/VelkosX/vmscope

I hope you found something useful in this newsletter.

Marcin Moskała
kt.academy

Hints for productivity and performance was originally published in kt.academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

This issue is about API shape and recomposition scope — the stuff that makes your codebase feel either “clean and predictable” or “why is this so hard to maintain?”. We’ll revisit state hoisting decisions in Compose, peek into a Kotlin pattern you’ve been using for years without noticing (fake constructors), and look at a Compose trick that can noticeably reduce recomposition work. We’ll wrap with a question many teams debate: when to use MutableStateFlow directly vs stateIn.

In this issue you will find:

🎦 New YouTube videos

👉 Hoisting state

🔎 Fake interface constructor pattern

💪 Compose Best Practice: Prefer lambda modifiers for frequently changing state

🤔 MutableStateFlow vs stateIn

📝 Article: Is Kotlin a savior of Java?

The Advanced Compose cohort starts in one week.

This program is about confidence when building and reviewing Compose code — understanding recomposition, modifiers, semantics, and testing at a deeper level.

This edition runs now. The next cohort will be next year at a higher price.

If this fits the problems you’re currently solving, registration remains open.

New videos

Another week, and we have new videos for you:

How many developers are there?

What are Explicit backing fields and where they can be dangerous?

Kotlin in 3 minutes by Marcin Moskała

You hopefully seen some of our videos already, and you might have some opinions about you like and what you dislike. Please, share those in comments, we will read them all, and it is perfect time to influence this channel development.

Hoisting state

One of the most important decisions you need to make when defining custom composables is wrather you want to store mutable state locally or hoist it.

When state is local:

👉 Logic can be reused.

👉 Component has simpler API.

When we hoist it:

😨 There are more (or more complex) parameters.

👉 Logic can be more easily customised.

👉 Caller can decide how state is stored and how persistent is it.

👍 We can easily preview all different states.

I would say, that local state is more React-like, but hoisting this state it much more Compose-like. It is a popular approach hoist all state up to view models.

Fake interface constructor pattern

A fake interface constructor returning a private class or object expression is a very common pattern in Kotlin team libraries. It allows us to expose only the interface, which is safe and offers maximum API flexibility.

Examples include Job, CoroutineScope, CompletableDeferred, Channel, Mutex, Semaphore, MutableStateFlow, MutableSharedFlow, List, and much more!

Nearly every time it looks like we use a constructor from a kotlin or kotlinx library, it is actually a fake constructor.

Why is this pattern used? It gives library creators the freedom to change what actual class is returned.

It also allows returning different classes depending on arguments (performance optimization).

Finally, such functions could create an object based on an argument using more complex algorithms, which would be inappropriate for constructors.

There are more reasons to expose factory methods instead of constructors, I explained them in Effective Kotlin, Item 32: Consider factory functions instead of secondary constructors

https://kt.academy/article/ek-factory-functions

Compose Best Practice: Prefer lambda modifiers for frequently changing state

Prefer lambda modifiers for frequently changing state❗Why? Because this way we limit recomposition scope. If we read state when we build modifiers, this scope change triggers whole this composable recomposition, and requires building modifiers again. If we read state in a composable lambda, only this lambda will get recomposed with scope change 👌

MutableStateFlow vs stateIn

We can often transform a coroutine into a StateFlow using stateIn, but should we do that? What do you think?

Article: Is Kotlin a savior of Java?

Can a competing language actually help save Java?

This article looks at a provocative idea: Kotlin may be one of the main reasons Java started evolving faster again.

It covers practical points developers care about:

• why Kotlin gained so much traction on Android and backend
• which Java features arrived after Kotlin had already made similar ideas familiar on the JVM
• why Kotlin may be pushing the whole JVM ecosystem forward, not just competing with Java

A good read for developers interested in Kotlin, Java, and where JVM development is heading next.

👉 https://kt.academy/article/kotlin_vs_java

I hope this newsletter gave you something practical to take away.

Marcin Moskała
kt.academy

Is it clean and predictable? was originally published in kt.academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article was featured in Kotlin Weekly#505

Introduction

Like everyone else I was excited to try out different AI tools and later on to try and build my own AI agent. That got me thinking, what would be a good use case? I wanted to build something which I can use and then naturally, share it with others who might have a similar interest.

What did I build? I built an AI agent to help me with my FPL team! I was tired of coming in last every week and I wanted a change! Since I’ve followed the game for a while, I can use my own footballing knowledge to double-check the accuracy of the agent’s recommendations.

How does Koog fit in? Well, this is the core piece of the solution! Initially I tried building it the API way — call an endpoint directly every time you want an output from the LLM (see this version of the repo). While this is a good starting point, you also have to build a lot around it. Think manually managing tool calls, context window, iteration cycles and much more.

In this article, I will show you how Koog helps solve most of the manual orchestration and let’s you focus on building the actual agent. As usual, the source code is linked at the end of the article!

FPL agent

First, let’s take a look at what we are building!

Does this look like some random boxes? Don’t worry! Let me break this down step by step. This will also give us clarity on how to build the agent and we can get into the juicy part of looking at the code after that!

Detecting user intent

The agent is responsible to only help with FPL related queries and therefore should not answer any random query. In this step the agent takes the user query as an input, reads the system instruction and then detects if the query is related to FPL. If it’s not then we simply fail at this step and don’t proceed further and the output will be something like: I’m built specifically for Fantasy Premier League advice. To help you with that, are you deciding on a transfer or a captain for this GW?

Providing FPL advice

Now that the user query was deemed to be about FPL, the next step is to answer it. A key piece here is that instead of letting the LLM use it’s own FPL knowledge, we provide the FPL data as a tool to the agent. Now, if the LLM wants to know the price of a player or upcoming fixtures of a team, then it calls the methods we provided to get this information. Koog takes care of calling the relevant methods to fetch the data and then processes this to reach the final decision. The output of this step is what the user sees as the answer to their query.

Compression

Why do we need compression? As the conversation keeps going, the agent context also keeps growing. In our case, we also have tool calls which return FPL data and this quickly leads to context bloat. Compressing the agent history helps improve performance, enhances accuracy and also reduces cost. If you are on a free tier, it also helps you avoid reaching your rate limits sooner!

Persistence

Why do we need persistence? There are several advantages of having persistence. (i) In case of any failures (tool failure, server failure), Koog now has the previous checkpoint data and it can retrieve it to know where it was. (ii) Koog has context about previous conversations of the user and would not have to start fresh every time. (iii) It also acts as a audit log and would greatly help in debugging any potential issues.

How do we finally build it?

Now that you understand the different parts, how do we actually build this agent? Since the whole agent is nothing but a set of sequential flows, I decided to use the subgraphs feature of Koog to build this. More specifically, the custom strategy graphs feature. I would highly encourage you to read the official documentation to understand more about subgraphs, custom strategy graphs, pre-defined nodes and components, structured output, history compression and persistence!

Every step from input to output is defined as a node. These nodes are connected by edges, ensuring that the output of one step seamlessly becomes the input for the next.

// #1.1
edge(nodeStart forwardTo inputProcessingPrompt) 
// #1.2
edge(inputProcessingPrompt forwardTo processInput) 
// #1.3
edge(processInput forwardTo nodeFinish onCondition { !it.shouldProceed } transformed { it.response })
// #3.1
edge(processInput forwardTo evaluateCompression onCondition { it.shouldProceed })
// #3.2
edge(evaluateCompression forwardTo compressHistory onCondition { it.shouldCompress })
// #3.3
edge(evaluateCompression forwardTo scoutAdvicePrompt onCondition { !it.shouldCompress })
// #2.1
edge(compressHistory forwardTo scoutAdvicePrompt) 
// #2.2
edge(scoutAdvicePrompt forwardTo provideSuggestion) 
// #2.3
edge(provideSuggestion forwardTo nodeFinish) 

Let’s now look at each of the steps in more detail! I have purposely marked the compression step as #3 so we can first go through the natural flow of a user asking a question and the agent providing an answer. Let’s look at compression and persistence after we understand the core flow!

Step 1: Intent detection

edge(nodeStart forwardTo inputProcessingPrompt) 
edge(inputProcessingPrompt forwardTo processInput) 
edge(processInput forwardTo nodeFinish onCondition { !it.shouldProceed } transformed { it.response })

val inputProcessingPrompt by nodeAppendPrompt<String>("input-process-prompt") {
  system(inputProcessInstruction)
}

val processInput by subgraphWithTask<String, InputProcessResponse>(
  name = "input-processor",
  llmModel = geminiConfig.getLLMModel(geminiConfig.model.inputProcess),
  assistantResponseRepeatMax = 1
) { input ->
    """
      User query: "$input"
    """.trimIndent()
}

@Serializable
@LLMDescription("The output format after processing the user query")
data class InputProcessResponse(
    @property:LLMDescription(
        """
           Whether we should proceed to the next step. Will be "true"" only if the query is related to Fantasy Premier League or English Premier League related. 
        """
    )
    val shouldProceed: Boolean,
    @property:LLMDescription("Response of the LLM in the current step")
    val response: String,
    @property:LLMDescription("The original user query which is needed in the next step")
    val originalInput: String,
    val shouldCompress: Boolean = false
)

• nodeStart represents the starting node of the subgraph.
• nodeFinish represents the finish node of the subgraph. This is where the workflow stops.
• inputProcessingPrompt is used to append the system prompt for detecting the user intent via nodeAppendPrompt. You can find the system prompt here.
• processInput is responsible for reading the user query and detecting if it’s related to FPL. subgraphWithTask is a subgraph which performs a specific task using the provided tools and returns a structured output. In our case, it takes the user query as the input (String) and returns InputProcessResponse as the output.
• If the user query is not related to FPL, then we stop here and return a static response to the user. This is handled via a check in onCondition. Since the final output should also be a message (i.e. a string), we use transformed to pass the response back to the user.

Step 2: FPL advice

edge(compressHistory forwardTo scoutAdvicePrompt) 
edge(scoutAdvicePrompt forwardTo provideSuggestion) 
edge(provideSuggestion forwardTo nodeFinish)

val scoutAdvicePrompt by nodeAppendPrompt<InputProcessResponse>("scout-advice-prompt") {
  system(scoutAdviceInstruction)
}

val provideSuggestion by subgraphWithTask<InputProcessResponse, String>(
  name = "scout-advisor",
  llmModel = geminiConfig.getLLMModel(geminiConfig.model.suggestion),
  tools = fplToolsRegistry.tools,
  assistantResponseRepeatMax = 5
) { context ->
    """
      User query: "${context.originalInput}"
    """.trimIndent()
}

val fplToolsRegistry = ToolRegistry {
  tools(fplApi)
}

• scoutAdvicePrompt is used to append the system prompt for providing FPL advice. You can find the system prompt here.
• provideSuggestion is responsible for reading the user query and answering it.
• To answer the user query accurately, the LLM requires access to the latest FPL data. This data retrieval is facilitated via tool calls. In our case, we make use of the Annotation based tools feature. You can find all the available methods here.
• assistantResponseRepeatMax limits how many assistant responses are allowed before concluding the task cannot be completed. This is important to prevent the agent from getting stuck in an infinite loop.

Step 3: Compression

edge(processInput forwardTo evaluateCompression onCondition { it.shouldProceed })
edge(evaluateCompression forwardTo compressHistory onCondition { it.shouldCompress })
edge(evaluateCompression forwardTo scoutAdvicePrompt onCondition { !it.shouldCompress })

val evaluateCompression by node<InputProcessResponse, InputProcessResponse> { input ->
  llm.readSession {
    val messages = prompt.messages
    val shouldCompress = messages.size > 20 && messages.sumOf { it.content.length } > 200_000

    input.copy(shouldCompress = shouldCompress)
  }
}

val compressHistory by node <InputProcessResponse, InputProcessResponse>("compress-history") { input ->
  llm.writeSession {
    model = geminiConfig.getLLMModel(geminiConfig.model.retrieval)
    replaceHistoryWithTLDR(
        strategy = RetrieveFactsFromHistory(concepts = fplConceptsToCompressHistory)
      )
    }

  input
}

• evaluateCompression is responsible to determine if history compression is required. llm.readSession provides the current state of the agent. In our case, we check if the the total back and forth messages in the session are over 20 and if the total characters of the messages is over 200,000.
• compressHistory is responsible to perform history compression. llm.writeSession provides the replaceHistoryWithTLDR method to modify the agent state.
• We make use of the RetrieveFactsFromHistory strategy to compress the history. This strategy searches for specific facts in the message history and compresses the whole history to just these facts for future LLM requests. You can find all the facts here.
• Note: This is a approach needs to be observed and can be tweaked based on real world data.

Step 4: Persistence

• For our particular use case, we enable continuous persistence. This ensures that a checkpoint is automatically created after each node is run.
• We leverage the custom storage provider feature by using Firestore database as our storage source. To implement custom storage providers, we will have to define our own PersistenceStorageProvider.

class FirestorePersistenceProvider : PersistenceStorageProvider<Any> {

    override suspend fun getCheckpoints(
        agentId: String,
        filter: Any?
    ): List<AgentCheckpointData> {
        // return all saved checkpoints from firestore
    }

    override suspend fun saveCheckpoint(
        agentId: String,
        agentCheckpointData: AgentCheckpointData
    ) {
        // insert data into firestore
    }

    override suspend fun getLatestCheckpoint(
        agentId: String,
        filter: Any?
    ): AgentCheckpointData? {
        // return last saved checkpoint
    }
}

• You can find the custom implementation here.

Putting it all together

Now that we understood how to implement the different components, let’s stitch it all together to create our final agent!

// Agent tools - FPL data retrieval 
private val fplToolsRegistry = ToolRegistry {
  tools(fplApi)
}

// Main agent strategy
private val scoutStrategy = strategy<String, String>("fpl-scout") {
  
  // User intent detection
  val inputProcessingPrompt by nodeAppendPrompt<String>("input-process-prompt") {
    system(inputProcessInstruction)
  }

  val processInput by subgraphWithTask<String, InputProcessResponse>(
    name = "input-processor",
    llmModel = geminiConfig.getLLMModel(geminiConfig.model.inputProcess),
    assistantResponseRepeatMax = 1
   ) { input ->
      """
        User query: "$input"
      """.trimIndent()
  }

  // History compression
  val evaluateCompression by node<InputProcessResponse, InputProcessResponse> { input ->
    llm.readSession {
      val messages = prompt.messages
      val shouldCompress = messages.size > 20 && messages.sumOf { it.content.length } > 200_000

      input.copy(shouldCompress = shouldCompress)
    }
  }

  val compressHistory by node <InputProcessResponse, InputProcessResponse>("compress-history") { input ->
    llm.writeSession {
      model = geminiConfig.getLLMModel(geminiConfig.model.retrieval)
      replaceHistoryWithTLDR(
        strategy = RetrieveFactsFromHistory(concepts = fplConceptsToCompressHistory)
        )
      }

    input
  }

  // FPL advice 
  val scoutAdvicePrompt by nodeAppendPrompt<InputProcessResponse>("scout-advice-prompt") {
    system(scoutAdviceInstruction)
  }

  val provideSuggestion by subgraphWithTask<InputProcessResponse, String>(
    name = "scout-advisor",
    llmModel = geminiConfig.getLLMModel(geminiConfig.model.suggestion),
    tools = fplToolsRegistry.tools,
    assistantResponseRepeatMax = 5
  ) { context ->
      """
        User query: "${context.originalInput}"
      """.trimIndent()
  }

  // Agent workflow
  edge(nodeStart forwardTo inputProcessingPrompt)
  edge(inputProcessingPrompt forwardTo processInput)
  edge(processInput forwardTo nodeFinish onCondition { !it.shouldProceed } transformed { it.response })
  edge(processInput forwardTo evaluateCompression onCondition { it.shouldProceed })
  edge(evaluateCompression forwardTo compressHistory onCondition { it.shouldCompress })
  edge(evaluateCompression forwardTo scoutAdvicePrompt onCondition { !it.shouldCompress })
  edge(compressHistory forwardTo scoutAdvicePrompt)
  edge(scoutAdvicePrompt forwardTo provideSuggestion)
  edge(provideSuggestion forwardTo nodeFinish)
}

// Invoking the agent
val agent = AIAgent(
    id = userId,
    strategy = scoutStrategy,
    promptExecutor = simpleGoogleAIExecutor(apiKey = geminiConfig.apiKey),
    llmModel = geminiConfig.getLLMModel(geminiConfig.model.default),
    toolRegistry = fplToolsRegistry
) {
    // Custom persistence
    install(Persistence) {
      storage = FirestorePersistenceProvider() 
      enableAutomaticPersistence = true
      rollbackStrategy = RollbackStrategy.MessageHistoryOnly
    }

  }

agent.run(input)

You can find the entire agent here.

That’s it! With these steps, you have a fully functioning AI agent which answers all your FPL queries and helps you build the perfect team for future game weeks!

You can find the source code of the agent in this repository.

GitHub - rubenquadros/GameweekScout-Server: AI agent which helps you with suggestions for your FPL team.

Contributions are most welcome! Please feel free to create issues or start a discussion if you are looking for more features or want to improve something!

What’s next?

I’m working on creating a web app (Compose web) so users can ask their queries and this agent will serve as a backend to answer them! This is something I’m working on as a hobby project but if you are interested, please free to reach out to me on slack via the kotlinlang slack workspace!

Additional resources

• Official Koog documentation to know more about Koog and it’s features.
• Official Koog API reference for a deep dive into the API.
• Koog articles by Vadim Briliantov — creator of Koog.
• Jetbrains blog series on building AI agents in Kotlin. Please read all the parts!
• Github repo of Koog for more examples.

Thanks for reading! If you liked the article please do leave a clap 👏 and don’t forget to subscribe and follow to get regular updates! :) You can also connect with me on LinkedIn.

Building Reliable AI Agents with Koog was originally published in kt.academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today’s issue mixes “small Compose habits that prevent real user pain” with a couple of Kotlin tools you can apply instantly. We’ll talk about where important state should live (and why remember is not enough), a neat way to make preconditions explicit with require/check, a Compose clickability gotcha, and then zoom out to the bigger picture: what Kotlin Coroutines quietly give you for free when you lean into their strengths.

In this issue you will find:

💪 Compose best practice: Keeping important state in view models or rememberSaveable

👉 Require and check

💡 Compose hint: clickable modifier has parameter enabled

📈 Kotlin Coroutine advantages

📝 Article: IntelliJ’s New Kotlin Coroutine Inspections, Explained

⭐ Project from Coroutines Mastery 2025: ReviewFlow

⏳ Price increases April 1 — this isn’t a joke.

Advanced Compose moves from €299 → €449 tomorrow.

The Bundle moves from €449 → €599.

If you’ve been considering joining, this is the final window at the Early Bird rate. The cohort starts April 13, and we won’t run it again this year.

This is the last reminder.

Details and enrollment are here → www.advancedcompose.com

Now, let’s move to today’s topic.

New videos

Our YouTube channel is growing! This week, you can learn the essence of how Compose works in 3 minutes, watch a funny video explaining why developers count from 0, and learn why extensions are not changing class behavior. Remember, you can help us with channel development by sharing those videos, leaving likes and comments, and, of course, subscribing and watching.

Understand Compose in 3 minutes

In what order are Compose modifiers applied?

The most common and hurtful misconception about Kotlin

Compose best practice: Keeping important state in view models or rememberSaveable

Beware❗Do not use remember for important state, as it can easily be lost, for instance with screen rotation. Everything that is important should be kept in a view model on in rememberSavable 👍

On the other hand, remember that rememberSavable is more demanding, so it should only be used for data that should persist configuration changes. Regarding form data, I don’t think users would be happy with having it lost.

Require and check

In Kotlin you can use require and check to enforce preconditions in your code. require throws IllegalArgumentException, so it is used to check arguments, and check throws IllegalStateException, so it is used to check state.

Compose hint: clickable modifier has parameter enabled

Clickable modifier can be disabled by argument, do not use conditional modifier for that!

Kotlin Coroutine advantages

Developers often grumble about all the complexity that Kotlin Coroutines hide under the carpet. But this library also hides its best advantages; we often benefit from them without even knowing about it. So let’s explore the key advantages of Kotlin Coroutines.

Let’s start with simplicity. With coroutines, we can write simple, imperative code. For backend developers, that is nothing new, but for Android it is a game-changer that we can have that while running on the main thread.

At the same time, coroutines allow a simple introduction of synchronicity with async/await. That is a well-recognized pattern, but in Kotlin Coroutines it offers structured concurrency with ease.

Coroutines are also efficient. Coroutines are lighter than threads. Suspending functions are much lighter than Single, and Flow is much lighter than Observable. Coroutines can only be compared to virtual threads from Loom, but it is only because Loom uses its own coroutines under the hood.

Programmers also underestimate the importance of cancellation. It is critical for Android developers where if a view is destroyed, we should also cancel all its processes. Coroutines offer powerful and effortless cancellation thanks to structured concurrency.

But cancellation mechanisms are also a great benefit for backend developers. If you make async calls and one of them fails, others are cancelled by default.

Also when you define a backend application in a framework like Ktor, that is coroutines-first, if an HTTP connection is lost, call gets immediately cancelled, the same if WebSocket or RSocket connection is lost.

Synchronization offers numerous powerful tools for synchronizing coroutines. You can easily make one coroutine wait for another coroutine to complete using join or suspend until another coroutine provides a value using CompletableDeferred or Channel.

Coroutines also offer the best support for testing I could see in any library. Kotlin Coroutines supports operating in virtual time, which lets us write precise, fast, and deterministic tests for cases that are hard to test with other libraries.

Virtual time also allows us to test timeouts, retries, and other time-related operations. It also allows us to verify what happens in different scenarios. What if X is faster than Y but slower than Z? What if X is faster than Z? We can easily simulate and test all these scenarios with virtual time!

Kotlin Coroutines provide a powerful abstraction for expressing and processing asynchronous streams of values. This abstraction is called Flow. Flow is much lighter than RxJava or Reactor streams, and its implementation is much easier. It also has a rich feature set with many useful operators.

Coroutines are multiplatform, so you can use them in any Kotlin target and in common modules.

That is why I believe that Kotlin Coroutines is currently the best tool in the market for concurrency. Certainly the best for Android, but also the best for the backend, but only if we use its advantages instead of just treating it like “lightweight threads”.

Article: IntelliJ’s New Kotlin Coroutine Inspections, Explained

How many coroutine issues in code review come from patterns that “work”, but are still misleading, inefficient, or unsafe?

I break down IntelliJ’s new Kotlin coroutine inspections and explain what they actually mean in practice. This article is especially useful if you work with coroutines regularly and want sharper mental models, not just IDE hints.

https://kt.academy/article/intellij-coroutines-new-warnings

Project from Coroutines Mastery 2025: ReviewFlow

Dealing with Play Store In-App Review orchestration on Android can be hard, but here comes ReviewFlow library that makes it easy and coroutines-friendly. This great project was made as a final project on Coroutines Mastery, congratulations to Klemens Zleptnig for making such an ambitious project.

👉 Code: https://github.com/klemensz/android-review-flow

What I like most is when coroutine knowledge turns into a real solution to a real problem. That is exactly what we aim for in Coroutines Mastery. If you want to build this kind of practical understanding, join the next edition this November.

Hope you found this newsletter worthwhile.

Marcin Moskała
 — kt.academy

Small habits that prevent real user pain was originally published in kt.academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today is about small decisions that quietly shape correctness and performance. We’ll start with a Kotlin gotcha that looks harmless but isn’t, then jump into one of the most useful Compose tools for keeping recompositions under control, and we’ll close with a reminder that still saves people from wrong mental models: suspending functions are not coroutines.

In this issue you will find:

🎦 New YouTube videos

💡 Do not use object expressions for exceptions

💪 The power of derivedStateOf

🔎 Suspending functions are not coroutines!

📝 Article: Flow Guessing Game!

⭐ Project from Coroutines Mastery 2025: Comet

We’re currently enrolling for the Advanced and Polished Compose cohort course.

The content and schedule are already fixed.

What changes over time is only the entry price.

The regular price is €449.

Until March 31, you can join for €299.

If this course fits the work you’re doing now, the current pricing window is still open.

You’ll attend the first sessions and evaluate the depth and pace yourself.

If it turns out not to be the right fit, you can step back within the first 3 days.

Strong material welcomes early inspection.

Join Advanced Compose — www.advancedcompose.com

Join Polished Compose — www.polishedcompose.com

This is what a developer said about our previous cohort:

New YouTube videos by Marcin Moskała

Our YouTube is growing! Last week we published three short videos:

The bug that nearly destroyed Earth is a terrifying story that nearly no one talks about. Presented in visually entertaining form:

https://www.youtube.com/watch?v=xakNW96l3r4

In what order are Compose modifiers applied? There is a clear explanation of how Compose modifiers work. It is related to another video, which presents our Modifier Game and how to win it.

https://www.youtube.com/watch?v=ddTkt4aEgEI

https://www.youtube.com/watch?v=1exvDo5wuqc

Do not use object expressions for exceptions

Exceptions should not be represented with object declarations❗ . Even though they look like having no mutable state, they do — each exception contains a stacktrace, so each exception must be unique.

The power of derivedStateOf

derivedStateOf is an important function in Compose that we use for limiting the number of recompositions. Let me show you how it works and when it should be used. 👇

First the problem with a raw value calculation. Such a calculation is only appropriate if it is really cheap, as it is triggered by any recomposition, so by any value change. It also triggers whole composable recomposition for changes in state properties it uses. (2/4)

Using remember with a key is enough to limit the number of recalculations, but to make it work correctly, we must use state as a key. That requires reading snapshot state in component body, so recomposing it whenever this body changes. derivedStateOf provides narrow scope, so allows us to prevent parent recomposition.

Though you must remember, that derivedStateOf body can only observe state, it cannot observe parameters. Take a look at the above example: threshold must be a key of remember!

Suspending functions are not coroutines!

Suspending functions are not coroutines! Those are functions that can suspend a coroutine, so they must be called from a coroutine, but they are not coroutines themselves. Compare them to JavaScript async functions that represent asynchronous coroutines.

Article: Flow Guessing Game!

One of the most useful questions you can ask yourself when reading Flow code is:

“Can I predict the behavior before I run it?”

If the answer is no, that usually means your understanding is still too close to syntax and not yet close enough to execution. And with Flow, that distinction matters a lot. Pipelines can stay readable on the surface while hiding assumptions that turn out to be wrong in practice.

That is why I made this game. More about the game can be found in this article

It is a direct exercise in Flow reasoning: inspect the pipeline, think carefully, and decide what it does. Not approximately. Precisely.

A good challenge for developers who want to move from “I know the operators” to “I understand the behavior”.

Play here: https://game.kt.academy/?game=flow

⭐ Project from Coroutines Mastery 2025: Comet

Today I want to share with you a stunning library and top final project on Coroutines Mastery 2025. Comet by Pandu Baraja is a library for automatically tracking coroutines and their execution time. It allows us to track and analyze coroutine execution in real-time. It still has some limitations, but man, that seems like a very powerful idea!

Code 👉 https://github.com/pandubaraja/comet

I hope you found something useful in this newsletter.

Marcin

— kt.academy

Fighting with bugs was originally published in kt.academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

This one is a “mental models” issue: UiState pattern in Compose, Kotlin lambda traps that bite even experienced devs, and a Compose trait that explains a whole class of “why did my component lost state” bugs. We’ll also zoom out to Flow itself — because a lot of confusion disappears once you internalize that Flow is synchronous by nature.

In this issue you will find:

🎦 New YouTube videos

👉 UiState pattern

🤕 Traps and mistakes when using lambda expressions

🤯 Composable identity

💡 Flow implementation

⭐ Project from Coroutines Mastery 2025: Where2fly

Reminder: Start With Nav3 is on March 19

Quick reminder — we’re going live on March 19 at 1pm (UTC+1) with Start With Nav3.

Bring your questions for the live Q&A — or send them in advance.

Can’t join live? Register anyway to get recording access.

Register (free) → https://webinar.kt.academy/start-with-nav3-05

What does this require, week to week?

One question engineers ask before joining the cohort is simple:

What does the weekly workload actually look like?

We recorded a short 1-minute walkthrough showing the structure — Busy Mode, Regular Mode, and how the schedule fits around a normal engineering week.

Watch the overview here → https://advancedcompose.com/#how-the-course-works

New YouTube videos by Marcin Moskała

Great news, everyone! We started posting content on YouTube. Those are short and entertaining videos on a variety of topics. We are ready to release two new videos every week, so if you liked this one, remember to subscribe!

The first video is about Kotlin, not an enemy, but as a savior of Java. Make sure to send it to all your Java-loving friends ;)

https://youtu.be/82XT--LmVDA

The second one presents a new player in UI development. Who could it be? I know you know, but let’s discover it together, and see why Compose is in many ways better than big frontend frameworks. Make sure to send this one to your friends who are frontend developers ;)

https://youtu.be/T-8yoCSnwnU

I hope you had as much fun watching those videos as I had making them. This is just the beginning, so observe this channel, and remember that you can support it by sharing it with others, leaving comments, or likes. It is especially important now, since we just started, and a small kick would be really useful.

UiState pattern

One of the most heated discussion in Android is about using UiState pattern. UiState aggregates all possible states of a view into one hierarchy. In result:

👉 Our view is consistently represented in one property.

👉 We do not need to deal with properties that are currently not displayed (like news, when we are still loading).

👉 We update our views using copy, what eliminates dependencies between updated properties (like when we first change a, and then b, and we accidentally calculate new state of b based on the new state of a, instead of on the old one).

😨 In complex views, UiState can become really big and complex.

😨 Using UiState makes it harder (but not impossible) to optimise recomposition by moving reads directly to where they are needed (for that, the most efficient way is defining State in view model).

🤔 UiState often duplicates some classes from domain (what adds boilerplate, but some consider beneficial as it defines ui-specific representation of those classes).

Traps and mistakes when using lambda expressions

Lambda expressions are amazing, but they can also be very tricky. Here is my collection of the most common traps and mistakes developers make when they use lambda expressions.

Each lambda expression is defined with braces. Raw braces that are not part of any structure make lambda expressions. What is printed by the below code? The answer is nothing. This lambda expression is never called.

A common mistake, especially by developers with a Scala background, is to create lambdas in single-expression functions. The below code does not print 42; it prints the lambda expression name.

We can destructure in lambdas, what can be a bit confusing in some cases. This code prints John Doe and Jane Smith in the first case, but only John and Jane in the second case.

Trailing lambdas (outside arguments bracket) always refer to the last parameter. Below code prints first CA and then AB. That is why when we have multiple functional parameters it is best practice to call them by name.

Lambdas return the result of the last expression as a result. Here it means 30.

Using raw return means non-local return, so returning from the closes function. To return from lambda expression you need to use a label.

Composable identity

When is a composable considered the same one and when is it considered a different one? Let’s discuss composables identity for a moment. 🤔

When you define a composable, each composable it calls received unique ID. State is persisted for the same ID path, even if arguments are different. Unless this composable disappears, even for a moment, because in such case its state is lost. 🤯

When composables are created from enumerations, like loops, they are by default identified by position. That means, adding an element at the beginning or in the middle causes recomposition of later composables. We improve that by specifying a key for identifying composables.

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. ✅

Flow implementation

Flow is synchronous by its nature. That is why the below code prints numbers with a delay of 1 second between each, and “Done” is printed after the last value. There is only one coroutine. Flow is like a suspending lambda expression. Of course, there are functions on Flow that start more coroutines, like flatMapMerge or buffer, but the nature of Flow is that it is synchronous, just like suspending functions

Project: Where2fly

Time for an application for passionates of aviation. Where2fly by Krzysztof Cieślewicz is an unofficial Android version of airspace.pansa.pl web application. It allows downloading and viewing basic airspace and updated usage plans and related information for a Warsaw flight information region. It is well-written and looks good. It also presents how to deeply test view models and repositories using the power of kotlinx-coroutines-test.

Code 👉 https://gitlab.com/krzysztof.cieslewicz1/where-to-fly

It was written as a final project on the Coroutines Mastery 2025 course.

I hope you enjoyed this newsletter.

— Marcin
kt.academy

Lambdas can trick you hard was originally published in kt.academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

This time we come to add some tools to your toolbox. We will explore interesting use of operators and context parameters, learn about the difference between StateFlow and SharedFlow, to finally explore why setting placeholder image is not only for user, but also for its device.

In this issue you will find:
💡 invoke method in UseCase classes
👉 stateInUi
📝 StateFlow vs SharedFlow
🎬 Placeholder image in a lazy grid
📝 Article: From Python to Kotlin: A transition worth making
⭐ Project from Coroutines Mastery 2025: VizCor

Here is what developers said after our previous cohort.

Advanced Compose and Polish Compose have the same rich cohort learning format — lessons, hands-on exercises, interactive games, Q&As, and an active community.

Join Advanced Compose — www.advancedcompose.com

Join Polish Compose — www.polishedcompose.com

New webinar: Start With Nav3 (Navigation3) — build a solid mental model

Nav3 (Navigation3) looks promising, but the hard part is getting the foundation right: what the core building blocks are, how the backstack works, and how to structure navigation flows so they stay readable as the app grows.

That’s exactly what we’ll cover in Start With Nav3 — hosted by Jov Mit and me.

When: 🗓️ March 19, 2026 (Thu) • 🕐 1pm (UTC+1)

Format: 30–60 min talk + 30 min live Q&A • 🎥 recording included • 🆓 free upon registration

Reserve your seat → https://webinar.kt.academy/start-with-nav3-05

Note: The join link is emailed after signup. You can submit questions before or during the webinar.

If you have missed it here It’s a concise, practical reference focused on how Compose actually behaves — Compose Advanced Cheat Sheet

https://cheat-sheet.kt.academy/advanced-compose06

invoke method in UseCase classes

One practice (quite common in Android) is to make the only public function in use case classes invoke operator. Use cases should have only one public method anyway, and it makes it easier o call it.

stateInUi

Happy to share with you stateInUi, a handy little helper function for idiomatically turning Flow into StateFlow in view models. It is also a nice example of using Context Parameters.

StateFlow vs SharedFlow

StateFlow and SharedFlow seem similar, but they are designed for different use cases, and they should not be confused. Let’s discuss the key differences and usages.

Let’s start with how they work. SharedFlow resembles a broadcast channel — emitted values are delivered to all observers. It allows setting a replay parameter specifying how many past values should be emitted to new observers.

StateFlow behaves a lot like SharedFlow with reply = 1, but StateFlow must always have a value, so an initial value must be specified when a StateFlow is created. This value can be accessed or changed using value property.

StateFlow was designed for a concrete use case: to represent an observable state. In Android, it is used to represent the state of our application, and views observe it and redraw whenever it changes. That is the key source of differences.

Redrawing view can be expensive, and state changes can be frequent. That is why two optimizations were introduced. First, updates are only emitted when they are different from the previous state. This behavior can be achieved on SharedFlow using distinctUntilChanged.

Second, StateFlow is conflated, meaning if value changes faster than observer than handle it, it might lose some intermediate updates. That is appropriate for StateFlow, because we are not interested in drawing obsolete state.

StateFlow also have some tools for state update, like update function, that lets us safely update state, by creating a new one based on the current one.

That is why StateFlow should be used concretely to represent the observable state of our application. It should not be used as a “breadcast channel”. For that we use SharedFlow.

Let’s see an Android example: Things like a progress bar or data to display should be represented by StateFlow, but exceptions or messages to show to users as toasts should be represented as SharedFlow.

However, SharedFlow values are not completely safe to be used in view models, because updates made when there is no observer will not be observed (unless we use reply, but then the same values can be displayed again). So it is best to represent our state with StateFlow.

Now let’s see a backend example. On a backend service, updates received from some websocket should be represented using SharedFlow, but an observable counter of application users can be represented using StateFlow.

To sum up, StateFlow and SharedFlow are similar, but they are designed for different use cases. StateFlow is for representing observable state, and SharedFlow is for broadcasting events. Use them accordingly.

The content of this post, with executable code snippets, can be found here:

https://kt.academy/article/sharedflow_vs_stateflow

Placeholder image in a lazy grid

One painful mistake made when using lazy lists or grids is having items with a very small size, like images before they get loaded 😨 To prevent that we should set size or use a placeholder.

Article: From Python to Kotlin: A transition worth making

If Python is your “get things done” language, what starts breaking once the codebase grows to years, not weeks?

This article 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: https://kt.academy/article/python-to-kotlin

Project: VizCor

VizCor is an amazing project by Jiri Hermann. I believe it is the most ambitious Coroutines Mastery 2025 project, showing well-implemented backend in Ktor (supporting Swagger, AsyncAPI, OpenAPI, Micrometer and more) for visualizing how coroutines work in complex scenarios that can be setup with applications builder.

Backend code 👉 https://github.com/hermanngeorge15/vizcor

Marcin Moskała
kt.academy

Tools for Kotlin developers, and how to use them well was originally published in kt.academy on Medium, where people are continuing the conversation by highlighting and responding to this story.