Now available worldwide with doorstep delivery 🛒✨ https://geni.us/bbg-msd

The Mobile System Design Interview book is finally here! 🤩📚 Now available worldwide with doorstep delivery 🛒✨ https://geni.us/bbg-msd

Nail your next mobile system design interview! Whether you’re facing questions like “Design YouTube” or “Build a chat app,” you’ll learn a proven framework that works for both Android and iOS platforms. Real-world case studies walk you through complete solutions step by step, covering a broad range of mobile system design topics.

This book is perfect for mobile engineers preparing for interviews and for engineering leaders, including managers and CTOs, who want to refine their architecture skills. You’ll tackle mobile-specific challenges like offline sync, performance optimization, and scalable data flow. Each chapter breaks down complex problems into manageable pieces, giving you the confidence to tackle any mobile system design question that comes your way.

Why dive in right away?

• 🏆 Built for YOU — whether you’re a mobile engineer gearing up for interviews, a tech lead sharpening architecture skills, or an industry leader curious about mobile internals.
• 🔧 Practical to the core — real-world case studies, reusable checklists, and trade-off cheat sheets you can plug straight into your workflow.
• 💡 5-step playbook — turns any “Design X” prompt into a structured answer that speaks the interviewer’s language.
• 📝 7 fully solved questions — every decision, diagram, and pitfall exposed.
• 🔢 175 topics covering the full spectrum of mobile system design principles.

Table of Contents

Chapter 1 Introduction
Chapter 2 A Framework for Mobile System Design Interviews
Chapter 3 Design a News Feed App
Chapter 4 Design a Chat App
Chapter 5 Design a Stock Trading App
Chapter 6 Design a Pagination Library
Chapter 7 Design a Hotel Reservation App
Chapter 8 Design the Google Drive App
Chapter 9 Design the YouTube app
Chapter 10 Mobile System Design Building Blocks
Quick Reference Cheat Sheet for MSD Interview

Grab your copy now ➡️ https://geni.us/bbg-msd ➡️ Open the book ➡️ Master the framework ➡️ Tackle complex mobile design with clarity and confidence. 🚀

If it helps you land that dream role, tag me — I’ll celebrate with you! 🥂🎉

#MobileSystemDesign #SystemDesign #TechInterviews #AndroidDev #iOSDev #SoftwareEngineering #MobileDev #Interviews

In this blog post, I’m covering how I prepared for various Staff level interviews at different companies. Given the versatile skill set a Staff+ position requires, each company might have their unique interview processes. You need to be flexible and ready for any type of interview. Staff+ positions are scarce, and there’s a fair bit of competition. Making the company wait in order to prepare for their different interviews might mean losing out to someone who was ready to impress from day one.

Note: It’s perfectly okay if you’re unfamiliar with Staff+ positions if you’ve recently begun your career as an IC, or if you’re simply curious about what it takes to get there. This blog post is relevant for you too 😊 Keep reading! Companies may also conduct these types of interviews at other levels.

I have experience interviewing at FAANG, as well as large and medium-sized tech companies, but I won’t divulge specifics about the companies I interviewed with or the intricacies of their processes, as these can evolve rapidly. Interviewers will tell you everything you need to know at the right time. Instead, I’ll give you insights into the most common interview types: 1) Data Structures and Algorithms (DS/A), 2) area of expertise (Android in my case), 3) system design, and 4) behavioural interviews.

But in case you’re wondering… Yes, I did! I passed multiple interview processes and joined Bumble Inc. 🐝 as a Staff Android Engineer. In the upcoming sections, I’m explaining how to prepare for those 4 types of interviews, and some tips to help you nail them.

Are you ready to be a Staff+ engineer?

You, better than anyone, know if you’re ready to be a Staff+ engineer or if it’s a goal you’re aspiring towards. This journey to this level involves not just technical skills but also a keen understanding of leadership and impact. I wouldn’t be giving justice to the topic if I tried to give you advice in a couple of paragraphs. For that, I’m relying on amazing authors who wrote entire books about the topic.

My favourite book to understand what the role is about is The Staff’s Engineer’s Path by Tanya Reilly. This is an authentic masterpiece. Another book you might find interesting is Staff Engineer by Will Larson.

In a nutshell, a Staff+ IC engineer typically operates at a senior level within a company. They may have extensive technical knowledge on a particular area and often take leadership roles. They’re responsible for driving technical excellence, providing mentorship, and contributing to high-level decision-making.

Preparing the DS/A interview

The Data Structures and Algorithms interview is probably the most controversial one — some love it, while others hate it! I can understand why some companies choose to conduct this kind of interviews:

1. They help refine your coding skills. You are able to translate thoughts into functional code.
2. A simple question can be built upon to see how the candidate reasons about, collaborates, and incorporates feedback from the interviewer.
3. They force you to think about a problem in a structural way.

Those 3 points are crucial to succeed in a DS/A interview. Let’s go one by one.

Improving your coding skills

Apart from learning the different types of exercises you can face, you need to solve the problem presented to you. Getting to a working solution is indispensable. The efficiency with which you arrive at a solution and make improvements can significantly impact the depth of discussions with your interviewer, which often translates into a successful interview.

To get that efficiency, I recommend learning the most common utilities in your programming language of choice. In Kotlin, I got familiar with uncommon Collections APIs that could come in handy in some exercises. There are helpful Kotlin Collections cheat sheets you can use; for example, I used this one by Jussi Hallila. I also refreshed my knowledge on some useful APIs like the Random API, the Mutex API, and thread-safe collections to name a few. This knowledge not only streamlines your coding but also opens avenues for more insightful discussions during the interview.

Practising

The best way to get better at this type of interview is by practising, practising, and more practising. Dust off that familiar green cover of Cracking the Coding Interview by Gayle L. McDowell and diligently work through the different chapters. Additionally, prove your DS/A skills on other platforms! I used LeetCode and was quite happy with it. Go through as many exercises as possible from the Grind 75 questions to gain a thorough understanding of all the possible DS/A questions. Also, do mock interviews to try those skills out in front of another human being. For this, I used Pramp: I missed some variety, but overall, it offered what I needed.

You and the interviewer

Different interviewers have different interview styles but the most common type I’ve seen is that interviewer who aims to understand your limits while ensuring a positive experience. In your interview, you’ll probably start with a question that has a somewhat straightforward solution using brute force.

How you get to the solution is as important as what you type. Think out loud and discuss different alternatives with your interviewer: their trade-offs, their time and space complexities, possible improvements, etc. The best advice I can give you is to actively listen to your interviewer’s feedback and apply it to your approach. Unless you find yourself in an unusual circumstance, most interviewers genuinely want to see you succeed! They are likely to offer hints or guidance to help you navigate the problem.

Structure your way to solve the problem

To tackle a specific problem, I follow the problem-solving structure outlined in Cracking the coding interview book: Listen, think of edge cases, brute force, optimise, walk through your approach, implement, and test.

In my preparation for Staff positions, I found Adam Bennet’s On interviewing blog post a valuable resource. In particular, I enjoyed his Github project, containing gems like the common strategies for DS/A interview problems.

Preparing the Android (or your area of expertise) interview

Android interviews can take diverse formats. You may be tasked with building an app on the spot, improving an existing app, identifying and fixing intentional bugs in the codebase, or completing a home assessment that you subsequently discuss during the interview.

If you need to complete a home assessment, I highly recommend reading Paul Blundell’s Android interviews blog post. Also, look at his implementation of one of those home assessment apps and learn how to implement pagination on your own.

If you’re tasked with building an app from scratch during the interview, practice creating a simple app with two screens — a list and a detail screen — using an MVx architecture. If you need to improve an existing application, I relied on the above mostly. The rest of my preparation came with my experience as an Android developer.

Given my confidence in topics like Architecture, Dependency Injection, Jetpack Compose, or threading, I didn’t prepare much about them. However, it’s advisable to find out about the company’s Android tech stack and get to know those tools and how they align with your existing knowledge.

Preparing the System design interview

The system design interview is my favourite one by far. You might think they don’t require that much preparation, but they do if you want to nail them. Call me systematic, but I believe these interviews also benefit from a methodical strategy.

When facing a system design problem, it’s crucial to know which questions to ask upfront. The key is to ask questions in a logical sequence, adjusting your choices based on the information gathered. I usually start gathering requirements from the interviewer to understand what we’re building and for whom. Ask for both functional and non-functional requirements such as Daily Active Users (DAU), authentication, offline mode, pagination, etc.

Then, you can make informed decisions and dive into the details of choosing the right network protocol (e.g. REST, gRPC, GraphQL, etc.) and defining the data models based on the business requirements and the end points to communicate with the backend.

I had cheat sheets with questions based on priority (i.e. what to ask first), and other cheat sheets based on topics such as performance, networking, data management, etc. Remember that system design problems might not always have a single right answer. Engage in dialogue, discuss trade-offs, and work towards a shared understanding with your interviewer.

Mobile system design interview

If you’re in mobile app development, the go-to resource for acing the system design interview is Alex Lementuev’s Mobile system design Github project. This comprehensive repository contains everything you need to succeed in this type of interview. Pay particular attention to the pros and cons outlined for the different topics, as that’s indispensable to justify your decision-making. Apart from learning the different choices you can make, this resource also helps you structure the way you approach the interview. To see how to apply that knowledge in an actual interview, check out the mock interviews in his Youtube channel. I highly recommend observing how people approach the problems.

When covering the Architecture of the mobile app, think about the recommended layered Android architecture and Unidirectional Data Flow (UDF).

Apart from this, I read content from the ByteByteGo newsletter and the System design interview books (1, 2) by Alex Xu, refresh the different design patterns, and read the Designing Data-Intensive Applications book by Martin Kleppmann.

As with any other interview type, you need to practice, practice, and more practice. Find a feature of your favourite app and think about how you would design it. For more inspiration, you can see the exercises listed in the Mobile system design project mentioned above.

Preparing the behavioural interview

To prepare for the behavioural interview, you can follow the approach outlined in Cracking the Coding Interview book. Prepare a table with your most important projects and systematically reflect on key aspects. For example: what was most challenging, what you learned, what was most interesting, the hardest bug, what you enjoyed the most, conflicts, what you’d do differently, leadership, and failures.

Other questions can be: a time when you learned a valuable lesson, your ability to move the team forward, to have an influence outside of your team, passion for wanting to make things happen, a time when your performance exceeded expectations, a time when you received a performance review that you felt was unjustified, etc.

Remember that the interview is a Staff+ role. Focus on expertise, leadership, and impact. You should be able to give examples of how the work you did linked to business impact, how you acted like a multiplier for other developers, and demonstrate that you’re thinking about business outcomes alongside technical expertise. This structured approach ensures that you’re well-prepared to articulate your experiences, achievements, and challenges during the behavioral interview.

Here’s the best tip ever: DO NOT LIE! Honesty is key throughout the interview process. Even if you manage to succeed by providing inaccurate information, it can lead to misunderstandings when you join the team. But don’t be shy either! It’s your interview and your moment to shine ⭐. You need to sell yourself. Focus on your personal achievements and what you contributed to the projects.

Refining your leadership style

Leadership comes with experience, but refining your leadership style can be accelerated by applying insights from relevant books. In addition to the Staff engineer books I mentioned in the introduction, consider exploring the following books that I enjoyed a lot:

• The Culture Code by Daniel Coyle: learn different skills to build an exceptional team. Focus on creating a culture of safety, sharing vulnerability, and establishing a clear sense of purpose.
• Crucial Conversations by Kerry Patterson: learn essential techniques for what to do before opening your mouth, how to open your mouth, and how to bring the conversation to a constructive conclusion.
• The Culture Map by Erin Meyer: understand and navigate cultural differences in this insightful and practical guide, perfect for both your work and personal life.
• Never Split the Difference by Chris Voss: discover negotiation skills to listen, empathise, and get the most out of your conversations with people.
• Radical Candor by Kim Scott: learn how to care personally while challenging your team directly to get optimal performance.

As you read these books, use your own judgement to select and implement the ideas that resonate with you. Authenticity is key. Adapt and apply the lessons in a way that aligns with your unique leadership style.

Conclusion

Preparing for Staff+ IC level interviews requires a multifaceted approach that includes technical, behavioural, and leadership aspects. The journey involves navigating through various interview formats, from DS/A to system design and behavioural assessments.

Embracing a structured preparation strategy is essential: learn about the different topics, choose your own strategy, practice with mock interviews, listen actively, and work with your interviewer toward the best possible solution.

Take the time to prepare for the 4 different interviews properly. Plan your time as it works for you. You can spend a couple of weeks on each interview to deep dive into the different aspects of it. And when the interviews are getting closer, maybe you can keep studying one type a day.

What makes you unique is your own strengths and experiences. Even if you learn a lot from external resources, tint your interviews with personal anecdotes and learnings. That will make those special, and you’ll be able to stand out from the crowd.

Lastly, when facing interviews… Have fun! Look at those problems as opportunities that you’re genuinely willing to overcome. You’re a capable and confident professional with a wealth of knowledge and skills. You got this! Best of luck on your interview journey!

[Bonus] You got the job!

Congratulations on landing the job! Before starting your new position, I’d recommend reading The First 90 days book by Michael Watkins. This book can help you onboard into your new position. Even if the company has its own onboarding plan, prepare your personal journey and run both in tandem.

Oh, and here’s a friendly reminder: show some love to your new colleagues and their code. No judgments! Everything they’ve done has a story. You’re there to level up the game, not to rain on anyone’s parade. Cheers to your new adventure! 🚀

Good luck! 🍀

Crash Course on the Android UI Layer | Part 2

State Holders and Saving State

This blog post series aims to summarise the Android Developer guidance on the UI layer. We’ll explore all the entities involved in it, understand the role each part plays, and discuss best practices.

By the end of this series, you will have a general understanding of what happens on the UI layer and how to best handle state and logic within it, the various APIs involved, and how to use them. Additionally, we’ll provide decision trees to assist you when you’re in doubt.

In part 1, we covered the UI and the UI state. You should already know the different entities present on the UI layer, and how to think about the UI and UI state effectively.

Crash course on the Android UI layer | Part 1

Now it’s time for Part 2! We’ll cover state holders and other UI layer-related topics such as where to hoist state and save UI state on Android.

If you prefer to consume this content in video format, check out the talk I delivered at Droidcon London 2023:

Peeling Back the Layers: Unmasking the UI-nknown!

State holders

State holders simplify the UI by handling logic and/or exposing UI state. In this section, we’ll see how to implement state holders and the implementation details to consider.

To determine the implementation details, we first need to identify the types of logic commonly found in an Android app.

Types of logic

We have already discussed that business logic involves implementing the product requirements that specify how application data is created, stored, and modified. When business logic is present in the UI layer, it’s recommended to manage this logic at the screen level. We’ll see more of this later.

Another type of logic is the UI logic. UI logic determines how to display state changes on the screen. While business logic dictates what to do with data, UI logic determines how to visually display it. The UI logic is dependent on the UI configuration.

For instance, in a typical app, displaying a details screen may involve navigation when the app is running on a phone. However, it could entail showing an element next to another when running on a tablet.

The different types of logic respond differently to configuration changes:

• UI logic should re-execute if it’s affected by a configuration change.
• Business logic should generally continue after a configuration change.

For instance, the UI logic that determines whether to display the bottom bar or the navigation rail should be re-executed or re-evaluated after a screen size configuration change. On the other hand, the business logic for following a particular interest or refreshing them shouldn’t be cancelled or restarted simply because the user rotated or unfolded the device. Such interruption wouldn’t provide a good user experience.

Where to handle that logic

Business logic on the UI layer should be handled as close as possible to the screen level. Most of the business logic is handled by the data layer. Thus, keeping it close to the screen makes it easier to scope the logic correctly and prevents low-level UI components from becoming tightly coupled to the business logic.

Business logic should be handled by the screen level state holder, which would normally extend from androidX.ViewModel.

When it comes to UI logic, it’s acceptable to manage it within the UI itself if the logic and state involved are relatively straightforward. However, when the UI becomes more complicated, it’s a good idea to delegate that UI logic complexity to a plain class state holder. In this case, the state holder wouldn’t extend from androidX.ViewModel.

We’ll see more of this in the upcoming sections! Now, let’s see how the different types of state and logic related to each other:

As a summary of what happens on a typical screen, the data layer exposes application data to the rest of the hierarchy. The ViewModel then applies business logic to that data to produce the screen UI state. The UI itself or a plain state holder class observes the screen UI state to modify UI elements or its state.

Handling business logic — androidX.ViewModel

We’ve discussed the androidX.ViewModel or Architecture Components ViewModel class quite extensively as the implementation detail of a screen-level state holder.

In the code snippet below, we can observe its main functionalities: 1) exposing the screen UI state and 2) handling business logic.

@HiltViewModel
class InterestsViewModel @Inject constructor(
  private val userDataRepository: UserDataRepository,
  authorsRepository: AuthorsRepository,
  topicsRepository: TopicsRepository
) : ViewModel() {

  val uiState: StateFlow<InterestsUiState> = ...

  fun followTopic(followedTopicId: String, followed: Boolean) {
    viewModelScope.launch {
      userDataRepository.toggleFollowedTopicId(followedTopicId, followed)
    }
  }

  ...
}

But why is the ViewModel the right place for this?

androidX.ViewModel benefits

The main benefit is that ViewModel survives configuration changes, offering a longer lifetime than the screen itself. You can scope a ViewModel to an Activity, Fragment, Navigation graph or the destination of a Navigation graph. When a configuration change happens, the system provides the same instance of the ViewModel.

Surviving configuration changes makes androidX.ViewModel the perfect place to expose the screen UI state and handle business logic. The screen UI state is also cached and instantly available before and after a configuration change. And business logic will continue executing if it was initiated with a ViewModel-scoped CoroutineScope (e.g. viewModelScope).

Another advantage lies in its seamless integration with other Jetpack libraries, particularly with Jetpack Navigation. Navigation retains the same instance of a ViewModel in memory when the destination is part of the back stack. This enables you to navigate back and forth between destinations in the back stack, with the data instantly available on the screen, without the need to reload the data every time you navigate back to that destination.

Jetpack Navigation also automatically destroys the instance of a ViewModel when the destination is no longer part of the back stack. Making it safe to go to a previous destination without seeing the previous user data on the screen.

Other Jetpack integrations include Hilt. By using the @HiltViewModel annotation, you can effortlessly obtain ViewModels with dependencies from the domain or data layers.

androidX.ViewModel best practices

ViewModel’s scoping is what makes this type suitable as an implementation detail of a screen-level state holder. However, this power shouldn’t be abused. Here are some best practices to keep in mind when using this class:

• Use it at the screen level. Avoid using a ViewModel to handle the complexity of reusable UI elements. Due to its scoping, the same UI elements under the same ViewModel scope would get the same instance of a ViewModel. In most cases, this is undesirable.
• Make the ViewModel generic enough to accommodate any UI form factor. The ViewModel should not be aware of which UI is using it. Keep the ViewModel’s API surface (exposed Screen UI state and functions exposed) representative of the application data it handles, rather than including UI-specific details. For example, when indicating that data is loading, the screen UI state might contain a field called isLoading rather than showLoadingSpinner. How the UI communicates data loading to the user is only relevant to the UI.
• Don’t hold references to lifecycle-related APIs. The ViewModel has a longer lifetime than the UI, and retaining references to Context or Resources objects can lead to memory leaks.
• Don’t pass ViewModels around. Considering all the points mentioned, keep the ViewModel class as close as possible to the screen level. Otherwise, you might inadvertently provide low-level components with access to more state and logic than they actually need.

androidX.ViewModel gotchas

Not everything is perfect in the ViewModel realm. There are certain considerations to keep in mind when using this API, especially in regard to ViewModel’s viewModelScope:

• Work initiated using viewModelScope continues to execute while the ViewModel is in memory. That’s good but can also lead to issues if the work runs for an extended period. For long-running work that might take more than 10 seconds to complete, consider other alternatives such as WorkManager. More about background work in the docs.
• Unit testing work triggered by viewModelScope requires some additional setup in the testing environment. The MainDispatcher must be replaced in tests.

Using androidX.ViewModel

Does this section mean you always need to use ViewModel? Well, as the implementation of a screen-level state holder, yes, but only if the benefits apply to your app.

If you care about configuration changes (which, you should!) and/or you’re using other Jetpack libraries, it might make sense to use it. However, even if you decide not to, consider introducing a plain screen-level state holder class to handle the business logic complexity at the screen level.

Handling UI logic — Plain state holder class

You should introduce a state holder class when your UI starts growing in complexity. The threshold depends on you and your team. It’s a matter of when you feel the need to simplify the UI.

In the upcoming code snippet, there’s no immediate need to create a state holder for the UI. It merely contains an expanded boolean that is modified when the user interacts with the UI.

@Composable
fun <T> NiaDropdownMenuButton(items: List<T>, ...) {
  var expanded by remember { mutableStateOf(false) }

  Box(modifier = modifier) {
    NiaOutlinedButton(
      onClick = { expanded = true },
      ...
    )
    NiaDropdownMenu(
      expanded = expanded,
      onDismissRequest = { expanded = false },
      ...
    )
}

When the UI requires more state and the associated logic becomes more complex, introduce a state holder. This is precisely what the Compose library does for some of its components. The following code snippet belongs to the state holder of the various Drawer composables:

@Stable
class DrawerState(
  initialValue: DrawerValue,
  confirmStateChange: (DrawerValue) -> Boolean = { true }
) {
  internal val swipeableState =  SwipeableState(...)

  val currentValue: DrawerValue
    get() { return swipeableState.currentValue }

  val isOpen: Boolean
    get() = currentValue == DrawerValue.Open

  suspend fun open() = animateTo(DrawerValue.Open, AnimationSpec)

  suspend fun animateTo(targetValue: DrawerValue, anim: AnimationSpec<Float>) {
    swipeableState.animateTo(targetValue, anim)
  }
}

A few points to observe there:

• It holds state such as the currentValue of the Drawer.
• State holders are composable. DrawerState internally depends on another state holder: SwipeableState.
• It manages UI logic, including actions like opening the drawer and animating to a specific value.

Just as Compose offers these state holders, you can implement similar patterns in your project to simplify the UI. The following code snippet belongs to NiaAppState, the state holder of the NiaApp composable function.

@Stable
class NiaAppState(
  val navController: NavHostController,
  val windowSizeClass: WindowSizeClass
) {
  val currentDestination: NavDestination?
    @Composable get() = navController
      .currentBackStackEntryAsState().value?.destination

  val shouldShowBottomBar: Boolean
    get() = windowSizeClass.widthSizeClass == WindowWidthSizeClass.Compact ||
      windowSizeClass.heightSizeClass == WindowHeightSizeClass.Compact

  fun navigate(...) { ... }

  fun onBackClick() { ... }
}

In a similar fashion, it exposes UI state such as the currentDestination and whether or not to show the bottom bar, while also managing UI logic like navigating and handling back-click events.

Note: In Compose, the naming convention for state holders is to end with State. That’s why we’re naming the classes NiaAppState and DrawerState.

Plain state holder classes best practices

It’s actually recommended to create a state holder for reusable UI components. This enhances the reusability of the UI and provides external control.

Plain state holder classes can hold references of lifecycle-related APIs. These instances follow the UI lifecycle. When the UI goes through a configuration change, a new instance of the state holder is created. Thus, it’s acceptable to hold references to Context or Resources because there won’t be any memory leaks. In Jetpack Compose, these state holders are also scoped to the Composition.

If your plain class requires business logic, it’s a good practice to inject that functionality into the class. Whoever injects this functionality can ensure it outlives the UI scope.

Handling large ViewModels

If a ViewModel is handling the business logic complexity of several sizeable UI elements, it could potentially become large and challenging to manage and reason about. How could we simplify the ViewModel?

1. Introduce the domain layer. Delegate the business logic complexity of the ViewModel to use cases that handle interactions with different repositories. However, this approach may still result in a ViewModel with a substantial list of use cases to depend on.
2. Create multiple state holders for the various elements of the UI and hoist them in the ViewModel so that they can get all its benefits. The ViewModel essentially becomes a state hoisting mechanism that survives configuration changes.
3. Instead of #2, you might consider creating multiple ViewModels to manage the complexity of those non-reusable UI elements. While this approach is acceptable, bear in mind that ViewModels operate with unbounded memory, and when you have multiple ViewModels, it can become challenging to monitor their size and memory footprint.

Where to hoist state

You should place state in the lowest common ancestor that reads or writes the state.

As a recap: In the UI, you might 1) not have state at all, 2) have state in the UI itself, 3) have state in a state holder in order to simplify the UI, 4) hoist the state higher up in the UI tree so that other composable callers or ancestors can control the state, 5) hoist the state in a ViewModel if it’s needed by business logic.

If the state is required by business logic, whether for reading or writing, it should be hoisted in the screen-level state holder. If not, it should be placed in the appropriate node of the UI tree.

Let’s take a look at the UI hierarchy of a typical Chat app and discuss why certain state is placed where it is:

• The screen UI state should be placed in the ViewModel (#5) because the ViewModel applies business logic to create it.
• The LazyList is part of the ConversationScreen and not the MessagesList because the screen has additional functionality that require that state, such as scrolling to the most recent messages when the user sends a new message in UserInput.

To learn more about this topic, check out the State hoisting in Compose talk by Alejandra Stamato.

Saving UI state

In this blog post, we’ve explored the androidx.ViewModel API as a means to preserve state across configuration changes. However, Android provides additional alternatives to safeguard your state even more effectively.

The SavedState APIs enable your state to persist through configuration changes and system-initiated process death. The system stores this data in a Bundle, requiring the data to be parcelized for storage. Typically, you’d store transient UI state that depends on user input or navigation.

Ultimately, to survive not only the above but also unexpected app dismissals (e.g. the user killing your app), you can use persistent storage. This is subject to disk space limitations and is typically used for storing application data.

For more information about this topic, check out the Saving UI state on Android talk.

Conclusion

After reading this crash course on the UI layer, you should have a general understanding of the processes occurring within this layer and the tools required to manage state and logic effectively.

How Android is designed to make your app reactive to different UI Configurations and devices makes some API decision trees more complex than some Developers might like. But at the same time, it also gives you the tools to make your app behave as expected, delivering a great user experience.

Hope you enjoyed this read! Feel free to share your thoughts or ask questions in the comments section! Thank you 😊

Remember that if you prefer to consume this content in video format, check out the talk I delivered at Droidcon London 2023:

Peeling Back the Layers: Unmasking the UI-nknown!

Crash course on the Android UI layer | Part 2 was originally published in Bumble Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Crash Course on the Android UI Layer | Part 1

The UI and UI State

This blog post series aims to summarise the Android Developer guidance on the UI layer. We’ll explore all the entities involved in it, understand the role each part plays, and discuss best practices.

By the end of this series, you will have a general understanding of what happens on the UI layer and how to best handle state and logic within it, the various APIs involved, and how to use them. Additionally, we’ll provide decision trees to assist you when you’re in doubt.

This is part 1, where we’re covering the UI and the UI state. Part 2 covers state holders and other UI layer-related topics such as where to hoist state and save state on Android.

If you prefer to consume this content in video format, check out the talk I delivered at Droidcon London 2023:

Peeling Back the Layers: Unmasking the UI-nknown!

The UI layer in the grand scheme of things

The UI layer isn’t the only layer you can find in a typical app architecture. Alongside it, you can also find the data layer and sometimes, the domain layer. According to the Android Architecture documentation:

• The UI layer displays data on the screen.
• The data layer exposes application data and contains the vast majority of the business logic of the app.
• The domain layer is an optional layer that aims to 1) simplify and 2) reuse the potential business logic complexity of the UI layer. No less, no more.

Note: The business logic is what gives value to your application. It’s the implementation of product requirements that determines how your app fetches, stores, and modifies data.

Entities in the UI layer

The UI layer consists of three distinct entities with clearly defined responsibilities. This distinction helps with separation of concerns, enhances testability, and promotes reusability.

• The UI, or UI elements, render data on the screen.
• The UI state describes the data to render on the screen. If the UI represents what the user sees, the UI state is what the app specifies the user should see.
• An optional state holder is introduced to simplify the UI by managing a portion of its logic, holding its UI state, and exposing it to the UI. State holders are employed when the complexity of state and logic within the UI increases, making it more challenging to reason about.

Unidirectional data flow

However, an app doesn’t show static information. Users regularly interact with it to perform operations that could potentially modify the application state. User events are typically handled by the state holder, and after processing them, they may result in a change in the UI state. In such cases, the UI state is not static. The state holder would expose a stream of UI state, and its emissions would be immediately reflected in the UI. This concept is also referred to as Unidirectional Data Flow (UDF) in the documentation.

The UI

The guidance in the documentation and this blog post applies to both the View system and Jetpack Compose. The role of the UI in the UI layer remains independent of your choice of UI toolkit.

When considering the UI layer, Developers tend to imagine the UI layer just at the screen level — that part of the UI tree that shows application data in most parts of the available display. And typically, Developers use the androidx.ViewModel as a state holder implementation detail.

However, just as you create “multiple” data layers for handling different types of data (e.g. PaymentsRepository, UserRepository, etc.), you have the flexibility to introduce UI layer entities at any point in the UI tree, or UI hierarchy, where they are needed. The granularity of this decision depends on the complexity of your UI.

As we’ll see in the state holder sections, you can introduce a state holder at any point within the UI tree to simplify the UI. In fact, this is recommended in certain scenarios.

The UI state

The UI state describes the information to be displayed on the screen. In this section, we’ll see how to model, produce, and observe the UI state.

Types* of UI state

There’s a subtype of UI state that usually requires special treatment—the Screen UI state. This is often derived from the application state exposed from the data layer. This shout-out is because it contains most of the information displayed on the screen, which aligns with what the user is usually most interested in.

As a sneak peek of what’s to come later, it’s important to note that the Screen UI state should persist or be cached across configuration changes.

How to produce UI state

Producing UI state is the output of the state holder processing some inputs. These inputs can be: 1) events, 2) local sources of state change, or 3) external sources of state change.

Which APIs should we use in different cases?

• The UI state should be exposed as an observable data holder class (e.g. StateFlow, Compose State<T>, or LiveData). This type ensures that the UI always has a UI state to render on the screen.
• Inputs can take various forms, primarily as streams of data or one-shot APIs.

Let’s see some examples of this!

Producing UI state with local source of state change

Imagine we’re on a screen that allows the user to roll two dice. Besides displaying the dice values, we also want to keep track of how many times the user rolls the dice. Our UI state could look like the following:

data class DiceRollUiState(
  val firstDiceValue: Int? = null
  val secondDiceValue: Int? = null
  val numberOfRolls: Int = 0
)

The business logic for rolling the dice is implemented through a one-shot call to the Random API.

firstDiceValue = Random.nextInt(1..6),
secondDiceValue = Random.nextInt(1..6),
numberOfRolls = currentUiState.numberOfRolls + 1

So, how do we hold this UI state in the state holder? Creating an observable data holder class! In this example, we’re using the MutableStateFlow API to achieve this. To avoid direct dependencies on the Random API, which could potentially impact reusability and testability, we introduce a more generic RandomProvider interface, with its implementation being the Random API.

class DiceRollStateHolder(
  private val randomProvider: RandomProvider
) {

  private val _uiState = MutableStateFlow(DiceRollUiState())
  val uiState: StateFlow<DiceRollUiState> = _uiState.asStateFlow()

  fun rollDice() {
    _uiState.update { currentState ->
      currentState.copy(
        firstDiceValue = randomProvider.nextInt(1..6),
        secondDiceValue = randomProvider.nextInt(1..6),
        numberOfRolls = currentState.numberOfRolls + 1
      )
    }
  }
}

The business logic for generating this UI state is local to the state holder. To prevent exposing a mutable version of the observable state holder that would allow direct modification of the UI state and violate the single source of truth principle, we expose the UI state as StateFlow. uiState is the read-only version of our mutable state that we convert using the .asStateFlow operator.

Note: Instead of MutableStateFlow, we could’ve also modelled our Ui State using Compose State<T> or even LiveData. For patterns and best practices concerning the use of Compose State<T> in this context, check out the State production docs.

Producing UI state with external source of state change

Application data comes from other layers of the hierarchy in the form of streams of data. To adapt this data to UI state, we must transform it into an observable data holder type. In the following example, we greet the user by displaying their name on the screen.

class DiceRollViewModel(
  userRepository: UserRepository
) : ViewModel() {

  val userUiState: StateFlow<String> =
    userRepository.userStream.map { user -> user.name }
      .stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5_000),
        initialValue = ""
      )
}

The state holder gets an instance of the data layer (i.e. UserRepository) as a dependency. It then maps the userStream: Flow to extract the specific information we are interested in, which in this case, is the user’s name. Since the map operator returns a Flow, we use the .stateIn operator to convert the Flow to a StateFlow, an observable data holder type.

.stateIn is a common operator used in state holders when dealing with Flows from other layers of the hierarchy and/or combining multiple data streams. Its method definition contains:

• scope: defines the lifecycle of the resulting StateFlow.
• started: determines the strategy for starting and stopping sharing. In the code snippet, we use WhileSubscribed(5_000) to stop collecting data from upstream flows (e.g. the one coming from UserRepository) when there are no collectors/observers for a specific period, in this case, 5 seconds. In this way, if the UI is not visible to the user for more than 5 seconds, we can cancel those data layer flow collections and save resources to protect the device’s health.
• initialValue: specifies the initial value of the StateFlow. As mentioned earlier, using an observable state holder type guarantees that the UI always has a UI state to render on the screen, and this parameter plays a crucial role in achieving that.

Summary of producing UI state

Let’s see a summary of what types to expose based on the type of input and the source API:

1. If you’re using one-shot APIs or local business logic, use a MutableStateFlow or Compose MutableState<T> to store the state in your state holder. Then, expose it as StateFlow or Compose State<T>.
2. When the source type is an external stream provided as a Flow, you should expose a StateFlow.
3. If you are dealing with both types of input, such as having at least one external stream, combine all the inputs and expose the UI state as a StateFlow.

For more information about this topic, check out the State holders and state production talk or the UI layer State production docs.

How to model UI state

The UI state describes the UI at a certain point in time. The UI is the visual representation of the UI state. We previously defined a UI state defined as a data class in the DiceRollUiState code snippet above. Here it is again:

data class DiceRollUiState(
  val firstDiceValue: Int? = null
  val secondDiceValue: Int? = null
  val numberOfRolls: Int = 0
)

It’s crucial that the fields in the UI state are immutable (i.e. vals) to ensure timing and consistency guarantees. Typically, UI state fields have sensible default values to facilitate creation and copying. However, not all UI states are that straightforward as the previous one.

Let’s consider a different scenario where we want to enable the user to roll the dice only when they are logged in. When the user lands on the screen, we check the user state and make a decision. Here’s a possible UI state for this case:

sealed interface DiceRollUiState {

  data object Loading : DiceRollUiState

  data class DiceRoll(
    val username: String,
    val numberOfRolls: Int,
    val firstDiceValue: Int? = null,
    val secondDiceValue: Int? = null,
  ) : DiceRollUiState

  data object LogUserIn : DiceRollUiState

}

The UI state would be either loading (Loading), indicating that the user needs to log in (LogUserIn), or displaying the dice roll values with the username on the screen (DiceRoll).

When should you use a data class, sealed interface/class or a combination of both?

• Use a sealed interface/class when the screen can be in multiple exclusive states.
• Use a data class when the data inside it can mutate. This is particularly useful in screens following an offline-fist approach where the screen might simultaneously display loading indicators, data, and error messages.

How to model complex UI state

When dealing with complex screens, you need to make sure you don’t create UI inconsistencies. As an exercise, let’s try to model the home screen of Jetnews, a Compose sample app.

The primary content of the screen presents a feed of articles and an open article details section where users can read the article. As a preliminary step to model the entire UI screen, one might define the following UI state:

private data class HomeViewModelState(
  val postsFeed: PostsFeed? = null,
  val selectedPostId: String? = null,
  val isArticleOpen: Boolean = false,
  val favorites: Set<String> = emptySet(),
  val isLoading: Boolean = false,
  val errorMessages: List<ErrorMessage> = emptyList(),
  val searchInput: String = "",
)

However, there’s a problem. Can you spot it? Due to the default values, we could create UI inconsistencies! We could have a UI state with a selectedPostId without postsFeed. That wouldn’t be realistic, that should never occur. To resolve this issue, we need to introduce a more strongly typed state to prevent these problems. Considering that our business requirements allow either posts or nothing to be displayed on the screen, we can introduce a sealed interface on top of this state:

sealed interface HomeUiState {

  val isLoading: Boolean
  val errorMessages: List<ErrorMessage>
  val searchInput: String

  data class NoPosts(
    override val isLoading: Boolean = false,
    override val errorMessages: List<ErrorMessage> = emptyList(),
    override val searchInput: String = ""
  ) : HomeUiState

  data class HasPosts(
    val postsFeed: PostsFeed,
    val selectedPost: Post,
    val isArticleOpen: Boolean,
    val favorites: Set<String>,
    override val isLoading: Boolean = false,
    override val errorMessages: List<ErrorMessage> = emptyList(),
    override val searchInput: String = ""
  ) : HomeUiState
}

Now our UI would either show HasPosts or NoPosts. In the HasPosts variant, it’s not possible to have a selectedPost without an existing postsFeed. Problem solved! While the initial approximation of our UI state could still prove useful for modelling the entire UI state privately, this type is never exposed. Ultimately, you would map that state to HomeUiState:

private data class HomeViewModelState(...) {

  fun toUiState(): HomeUiState =
    if (postsFeed == null) {
      HomeUiState.NoPosts(...)
    } else {
      HomeUiState.HasPosts(...)
    }
}

Exposing single vs multiple UI state streams

We often engage in discussions regarding whether a state holder should expose a single or multiple streams of data.

What we’ve been advising people so far is that you’d expose a single stream of UI state if fields depend on each other. On the other hand, if those fields are independent of each other and do not lead to UI inconsistencies, it’s acceptable to expose multiple streams.

Some may argue that if they are entirely independent, it implies they affect different parts of the UI, and each of those parts could have their own state holders. Sure, I agree. But if you don’t want to create multiple state holders and expose multiple UI states from a higher level one, that’s acceptable as well.

How to consume UI state

Ideally, UI state should be consumed from the UI in a lifecycle-aware manner. That is, only when the UI is visible on the screen. In the Android lifecycle, that is when the lifecycle is above the STARTED and STOPPED states. There are different APIs available to do this in an easy way.

For Android Views, you can use the repeatOnLifecycle or flowWithLifecycle APIs, which are found in the androidx.lifecycle.lifecycle-runtime-ktx artifact. Here’s how you’d use repeatOnLifecycle:

class SomeActivity : AppCompatActivity() {

  override fun onCreate(savedInstanceState: Bundle?) {
    // ...
    lifecycleScope.launch {
      repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.uiState.collect {
          // New UI state! Update the UI
        }
      }
    }
  }
}

Inside the repeatOnLifecycle coroutine block, you collect from the UI state. repeatOnLifecycle automatically creates a new coroutine that executes the block when the lifecycle reaches that state, and cancels the coroutine running the block when it falls below that Lifecycle state.

In Compose, use the collectAsStateWithLifecycle API that uses the repeatOnLifecycle API under the hood. This is available in the androidx.lifecycle.lifecycle-runtime-compose artifact. This API collects the underlying flow given a certain lifecycle State, and represents the latest value of the flow as Compose State<T>. This allows the composable function to recompose whenever a new element is emitted.

@Composable
fun SomeScreen(
  modifier: Modifier = Modifier,
  viewModel: SomeViewModel = viewModel()
) {
  val uiState: SomeUiState by viewModel.uiState
                  .collectAsStateWithLifecycle()

  // Emit UI given uiState. SomeScreen will recompose
  // whenever `viewModel.uiState` emits a new value.
}

For more information about collecting in a lifecycle-aware manner, watch the Collect flows on Android talk or read the repeatOnLifecycle and collectAsStateWithLifecycle articles. If you’re interested in how these APIs were created, read the repeatOnLifecycle API design story blog post.

Now that you’ve read part 1 of the crash course on the UI layer, you should have a general understanding of the different entities present on this layer, and how to think about the UI and UI state effectively.

In part 2, we’ll cover state holders and other UI layer-related topics such as where to hoist state and saving state on Android.

Crash course on the Android UI layer | Part 2

👋 See you there!

Remember that if you prefer to consume this content in video format, check out the talk I delivered at Droidcon London 2023:

Peeling Back the Layers: Unmasking the UI-nknown!

Crash course on the Android UI layer | Part 1 was originally published in Bumble Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Android brand, ART updates, Dagger KSP, Jetpack Compose, documentation updates, and more!

Welcome to Now in Android, your ongoing guide to what’s new and notable in the world of Android development.

Most of the content of this post is available in the form of a video or podcast, so feel free to watch or listen rather than read on. (Or do all three to help you remember! There won’t be a quiz.)

A new modern look for the Android brand 💅

Android is updating its visual identity that better represents our Android community, and reflects Android’s core ethos of being open, iterative and inclusive.

The Android robot became a prominent fixture of our logo, and now we’re giving Bugdroid an entirely new 3D look. We wanted the bugdroid to appear as dynamic as Android itself.

You’ll start seeing the new aspects of the brand identity, like the updated logo and 3D bugdroid, appear on Android devices and in more places starting this year.

A new modern look for the Android brand

Latest ARTwork on hundreds of millions of devices 🎨

Thanks to ART Google Play system updates, hundreds of millions of devices receive the latest performance improvements, security fixes, & OpenJDK APIs! Learn how we modularized Android to allow ART, the engine powering Android, to update independently.

In the coming months, we’ll be releasing ART 14 to all compatible devices. ART 14 includes OpenJDK 17 support along with new compiler and runtime optimizations that improve performance while reducing code size.

Latest ARTwork on hundreds of millions of devices

Library releases 🚀

The latest release of Dagger and Hilt — v2.48 — includes the alpha release of their KSP processors. Instructions for using them can be found in the Dagger KSP guide. This release contributes to getting rid of KAPT in your Gradle builds and making them faster. There are some breaking changes you should be aware of, check out the 2.48 release notes for more information.

Release Dagger 2.48 · google/dagger

Articles and documentation updates 📚

Ben Trengrove gave an update on Jetpack Compose Accompanist libraries. Some libraries will be deprecated with no replacement, including Pager Indicators and WebView. Drawable Painter and Permissions are considered feature complete. And Adaptive, Test Harness and Navigation Material continue to be experimental.

An update on Jetpack Compose Accompanist libraries — August 2023

We updated the modularization guidance to include more common patterns such as test modules and dependency inversion. With dependency inversion, your modules depend on abstraction modules instead of concrete implementations. Read the guide to learn more about these topics.

Whether your source code is written in Java, Kotlin, or both, there are several places you must choose a JDK or Java language version for your build. The new Java versions in Android builds guide help you identify which JDK is which, how to choose the right one in different scenarios, and which Java language features you can use in your project.

If you want to get started with animations in Compose, we created a new guide with a list of common animation use cases and the right API to use in each scenario. Also, we improved the previous animations in Compose diagram with an easier API decision tree. Doesn’t it look nice?

Sample projects 🧑‍💻

The Now in Android open source app is now using screenshot tests to verify the visual appearance of certain Compose screens and components. Screenshot tests can automatically verify combinations of attributes that make sense such as different app states, screen sizes, locales, or themes.

To see that in action, this PR adds some screenshot tests to the design system module in the project, and this other one sets up screenshot testing in the app.

Adds screenshot tests to :core:designsystem by JoseAlcerreca · Pull Request #931 · android/nowinandroid

Now then… 👋

That’s it for this time with a new Android brand, ART updates, the Dagger and Hilt KSP processors alpha release, Accompanist libraries updates, improvements to the modularization and Compose animations guidance, and screenshot testing in the Now in Android app.

Come back here soon for the next update from the Android developer universe! 💫

Now in Android #90 was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Android Studio Electric Eel, Architecture, Kotlin Multiplatform, WearOS, CameraX, Stylus, and more.

Welcome to 2023 and a new episode of Now in Android, your ongoing guide to what’s new and notable in the world of Android development.

Episode 75 Video and Podcast

Now in Android is also offered as a video and podcast.

Android Studio Electric Eel is stable ⚡

This release includes updates and new features that cover across design, build & dependencies, emulators & devices, and IntelliJ.

This version brings improvements to the Compose Preview that now updates automatically, the layout inspector that now displays recomposition counts, visual XML linting for Views, sync performance with parallel project imports, SDK Index integration, a new logcat, resizable emulators, physical devices mirroring, and more!

For more information check out the blog post or the video, and download the latest stable version today to try it out for yourself!

Android Studio Electric Eel

AndroidX releases 🚀

Since the previous episode, there have been some AndroidX releases worth highlighting.

Graduated to stable, we can find AppCompat 1.6.0 that primarily supports Android 13 including per-language preferences and predictive back, and Room 2.5.0 that got its runtime converted from Java to Kotlin and new features such as the Upsert annotation and room-paging support for RxJava and Guava.

The Lifecycle’s new 2.6.0-alpha04 version removes the experimental annotation from the collectAsStateWithLifecycle API and deprecates the pausing dispatcher and launchWhenX APIs.

As new libraries, we can find the androidx.credentials library that helps users sign into apps, using their stored credentials including passwords and passkeys. Also new privacy sandbox libraries such as the adservices one that enables integration with Privacy Preserving APIs, and sdkruntime that contains components for building and loading Runtime enabled SDKs on old versions of Android Platform.

Articles 📚

Don Turner wrote about adding a domain layer to an app that covers how the team added a domain layer to the Now in Android app for improved readability, scalability and portability.

Adding a domain layer

Anton Hansson wrote about extending the Android SDK that covers the Extension SDK framework that enables the team to introduce new functionality outside of major API level releases allowing faster innovations such as the new photo picker, and provide backward compatibility.

Extending the Android SDK

chiara chiappini wrote about the ease the development of media apps for Wear OS with the media toolkit you’ll learn how to bring your media app to Wear OS smartwatches with the help of the newly released Wear media toolkit.

Ease the development of media apps for Wear OS with the media toolkit

Mozart Louis wrote the first part of a HDR series, migrating from TextureView to SurfaceView. Migrating to the preferred SurfaceView enables HDR playback on supported devices.

Android HDR | Migrating from TextureView to SurfaceView (Part #1) — How to Migrate

Cedric Ferry wrote about the Stylus low latency. The post covers two new libraries (low latency graphics and motion prediction) that aim to reduce the processing time between stylus input and screen rendering, explores how these libraries work, and how you can implement a best-in-class stylus experience in your app.

Stylus Low Latency

Videos 🎥

If you want to make your app grow, you should watch these two videos, optimize paywall conversion, and engage with push notifications, to learn about those topics and improve your app.

Donovan recorded a video about CameraX concepts to introduce you to its functionality through 4 use cases: Preview, ImageCapture, VideoCapture, and ImageAnalysis.

Chris Shmerling recorded an in-depth walkthrough of a sample app using the FLEDGE API, a component of the Privacy Sandbox on Android.

Erin recorded an introduction to the Attribution Reporting API that is designed to provide improved user privacy by removing reliance on cross-party user identifiers, and to support key use cases for attribution and conversion measurement. The video walks you through a sample implementation of the Attribution Reporting API on Android.

ADB Podcast Episodes🎙

In Episode 193: Kotlin, James Ward joins Chet Haase, Tor Norbye, and Romain Guy to talk about Kotlin Multiplatform (both KMP and KMM) and what’s coming for Kotlin in 2023, especially the new K2 frontend.

Now then… 👋

That’s it for the first Now in Android episode of 2023 with a new version of Android Studio stable, AndroidX releases, articles about the domain layer, extending the Android SDK, Wear OS, HDR and the stylus, videos about app growth, CameraX and the Attribution Reporting API, a new episode of the Android Developers Backstage, and more!

Come back here soon for the next update from the Android developer universe.

Now in Android #75 was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Android Dev Summit, Modern Android development, Kotlin Multiplatform, Material Design, Now in Android app, and more!

Welcome to Now in Android, your ongoing guide to what’s new and notable in the world of Android development.

Episode 71 Video and Podcast

Now in Android is also offered as a video and podcast.

What’s new from Android at Android Dev Summit ‘22

The first day of Android Dev Summit 2022 was a blast! You can already watch the keynote and dive into our first track on Modern Android development.

Among the most important announcements, you can find the latest Compose release: October 22 (formerly known as Compose 1.3) stable! Compose for Wear OS hit its 1.0 stable release weeks ago and it’s the recommended way to build UI for Wear.

As you heard earlier this year: Google is all in on tablets, foldables, and ChromeOS. You can find updated templates for Wear OS in Android Studio, as well as a stable Android R emulator system image for WearOS. We’ve made it easier than ever to test your app on the large screen in Android Studio Electric Eel now in Beta, including resizable and desktops emulators and visual linting to help you adhere to best practices on any sized screen.

We also made it easier to take advantage of platform features in Android 13 such as the per-app language preferences and the new Photo picker which is a permission free way to allow the user to browse and select photos and videos they explicitly want to share with your app.

What's new from Android, at Android Dev Summit '22

Modern Android Development at ADS ‘22

Modern Android Development (MAD) is our set of libraries, tools and guidance that make it faster and easier to build amazing Android apps. Here is a recap of the top 3 announcements from the conference.

You can find all the MAD talks in this playlist:

Don’t forget to check out the What’s new in Jetpack blog post that contains the released updates to three major areas of Jetpack: Architecture Libraries and Guidance, Application Performance, and User Interface Libraries and Guidance. It includes the updates to WorkManager, Room, new Architecture guidance, Baseline profiles, recomposition tracing, and more!

Android Dev Summit '22: What's new in Jetpack

Also check out the What’s new in Jetpack Compose blog post that contains developers stories of how the community is adopting Jetpack Compose, and more information on the Compose October 22 release that’s shipped with a Bill of Materials (BOM). The new Compose features include staggered grids, variable fonts, swipe to refresh modifier, the new lookahead layout, and more!

What's new in Jetpack Compose

Experimental preview of Jetpack Multiplatform libraries

Kotlin Multiplatform Mobile from JetBrains is now in beta, and we have been experimenting with this technology to see how it can enable code sharing across platforms. As part of these experiments, we are now sharing a preview of Kotlin Multiplatform libraries in Jetpack. The libraries available for multiplatform as part of this experimental preview are Collections and DataStore.

With this preview, we’re looking for your feedback about using these Jetpack libraries in multiplatform projects targeting Android and iOS applications. Keep in mind that these dev builds are experimental and should not be used in production. Learn more about the available APIs in the sample app, the API reference documentation, and the blog post!

Announcing an Experimental Preview of Jetpack Multiplatform Libraries

MAD Skills: Compose basics 🎼

The MAD Skills Compose basics series has come to an end with the usual Live Q&A episode and the community tip brought to you by Adam Bennet that shares how you can speed up your learning with Compose.

If you missed any of the previous episodes, check out the wrap-up blog post where you can watch them all and find more information about them.

Compose Basics: MAD Skills Wrap-Up

Material Design releases 🎨

Material Design components for Android 1.7.0 is now stable and brings updates to Material You styling, accessibility and size coherence and new minimum version requirements. You can find a new MaterialSwitch component, shape theming, and more!

Material Design Components for Android 1.7.0

Additionally, Compose Material 3 is stable as well. This library allows you to build Jetpack Compose UIs with Material Design 3. It supports color schemes, dynamic color, material components, typography, shapes, window size classes, window insets support, and more.

Material Design 3 for Compose hits stable

Articles 📚 and videos 📹

Manda Edling and Paris Hsu wrote about the designs of the Now in Android app. The blog post describes how the team applied Material 3 concepts to the app and explores the accompanying design Figma file which has just been released.

Now in Android: a Material 3 case study

Alejandra Stamato wrote about effective state management for TextField in Compose. Check out what you need to do to prevent synchronization issues and unexpected behaviors, among them, make sure to define your TextField state variables with Compose APIs such as mutableStateOf.

Effective state management for TextField in Compose

Serban wrote about Pixel 7, the first 64-bit-only Android phone and what that implies such as dropping OS support for 32-bit code, reducing memory usage, improving performance, and enhancing security.

Pixel 7, the first 64-bit-only Android phone

Ray recorded an episode about HDR video on Android. There you can find the requirements you need and the new Android Camera2 APIs.

Talking about Camera, the Android team wrote about better device compatibility with CameraX. In this post, you’ll look at three ways CameraX makes developers’ lives easier when it comes to device compatibility. First, the CameraX Test Lab where we test over 150 physical phones every day. Second, Quirks, the mechanism CameraX uses to automatically handle device inconsistencies. And third, we’ll discuss the ways CameraX makes it easier to develop apps for foldable devices.

Better Device Compatibility with CameraX

Niharika Arora wrote the third part of optimizing for Android Go edition. This time, it’s about the tools which helped Google optimize their Google apps performance. When analyzing the memory footprint, they used Perfetto, the Memory profiler, and meminfo. For monitoring startup, they also used Perfetto, the App startup library, baseline profiles, the CPU profiler and the micro and macrobenchmark libraries.

Optimize for Android (Go edition): Lessons from Google apps Part 3

The Android ML platform team wrote about the latest updates on Android’s custom ML stack. TensorFlow Lite in Google Play services is now Android’s official ML inference engine, TensorFlow Lite Delegates are now distributed via Google Play services, and the Acceleration Service will help you pick the best TensorFlow Lite Delegate for optimal performance in runtime.

Latest updates on Android's custom ML stack

The Android Game Dev Show has a new episode. In this episode, Nate Trost talks about new updates in Android Games including game mode, game state, adaptive performance, Vulkan, and much more!

Lidia wrote about 5 Play Console updates to help you understand your app’s delivery performance. Delivery insights help you better understand and analyze your app’s delivery performance and what contributes to it, and take action to optimize the experience for your users. The post includes five recent Play Console updates you can use to get more insight into your delivery performance.

5 Play Console updates to help you understand your app's delivery performance

Lastly, the team wrote about Bringing passkeys to Android & Chrome. Google is bringing passkey support to both Android and Chrome. Passkeys are a significantly safer replacement for passwords and other phishable authentication factors. They cannot be reused, don’t leak in server breaches, and protect users from phishing attacks. This release enables two key capabilities: Users can create and use passkeys on Android devices and Developers can build passkey support on their sites for end-users using Chrome.

Bringing passkeys to Android & Chrome

Now then… 👋

That’s it for this week with Android Dev Summit and its Modern Android development track, Kotlin Multiplatform updates, Material Design releases, the Compose Basics MAD Skills series, articles and videos about the Now in Android app, TextField state management, Pixel 7, HDR on Android, CameraX, optimizing for Android Go edition, updates on custom machine learning, the Android Game Dev Show, Play delivery and passkeys.

Come back here soon for the next update from the Android developer universe.

Now in Android #71 was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Privacy Sandbox, Modularization, Architecture, Performance, Deep links, Android Go edition, Android 13, Jetpack Glance, and more!

Welcome to Now in Android, your ongoing guide to what’s new and notable in the world of Android development.

Episode 68 Video and Podcast

Now in Android is also offered as a video and podcast.

Privacy Sandbox developer preview 5 🔐

The Privacy Sandbox aims to develop new technologies that improve user privacy and enable effective, personalized advertising experiences for mobile apps. Developer Preview 5 was released, this version is a major milestone that will become the foundation for upcoming Privacy Sandbox Beta releases. Please keep giving us your feedback! See what’s changed in the blog post:

Privacy Sandbox: Developer Preview 5 is here!

Guide to app modularization 🧩

The team just released new guidance on modularization. Guidance on this topic has been one of the top community requests and here it is! The guide is split into two parts. The overview page gives you a high level, theoretical overview of the matter and its benefits. The common modularization patterns page dives deep into practical examples in the context of modern Android architecture. Take a look at the guide announcement blog post to learn more about this.

Announcing the new guide to Android app modularization

More Architecture guidance 🏛

Apart from modularization, the team released more Architecture content!

If you need to make your app work offline, we got you covered. The new Build an offline-first app guide helps you design your app to properly handle reads and writes, and deal with synchronization and conflict resolution in a device with no Internet connectivity.

Another new guide is the State holders and UI state page in the UI layer docs. Not everything needs to be present in ViewModel classes. This page goes through the different types of state holders you can find in the UI layer and what their responsibilities are.

Lastly, if you want to learn all about Architecture and be up-to-date with our current best practices, check out the Architecture pathway, that got updated with all the videos of the Architecture MAD Skills series we produced early this year and the new docs.

Mad Skills: Performance ⚡️

The MAD Skills series has come to an end with the usual Live Q&A where Ben Weiss, Tomáš Mlynarič, Carmen Jackson, and Chris Craik answered your questions.

To wrap up the series, Ben wrote this blog post that contains a summary of all the videos! Don’t miss it out!

MAD Skills Performance — Wrap Up

AndroidX releases 🚀

Since the previous episode, there are some AndroidX releases worth highlighting.

Core and core-ktx made it to 1.9.0 stable. This version improves compatibility with Android 13 adding parity between the accessibility framework and compat APIs, and some other additions. Other releases include new in beta Car app 1.3, and new in alpha Navigation 2.6 and Test Ui Automator 2.3.

See the rest of AndroidX releases in this link.

Articles 📚 and videos 🎥

The Developer Relations team wrote about how TikTok Enhanced its Video Social Experience on Android. They were able to significantly improve their overall performance by following Android’s performance guidance, and employing their deep understanding of development tools such as Android Gradle Plugin and Jetpack libraries. Read more here!

Precise Improvements: How TikTok Enhanced its Video Social Experience on Android

Sabs started a crash course series about deep links. The first part is an introduction to deep links with a blog post and a video. Get to know what a deep link is, go from URIs to app links, and more!

The deep links crash course, Part 1: Introduction to deep links

The second part goes over the different types of deep links. How to set them up, test them, and build the best user experience around them.

The deep links crash course, Part2: Deep links from Zero to Hero

Marcel wrote about experimenting with Jetpack Glance that covers a standalone experimental repository to supplement Jetpack Glance with tools that are commonly required for development but not yet available. At the moment, it includes a composable to display RemoteViews inside your app (enabling Live Edit), a debug tool to view and interact with AppWidget snapshots embedded inside the app, and a Material3 Scaffold for AppWidgets.

Experimenting with Jetpack Glance

Ben Trengove wrote about Debugging recomposition in Compose. Check it out because it also contains a screencast of Ben fixing a performance issue in Jetsnack, a Compose sample. For this, Ben also uses the layout inspector in Android Studio where you can see the recomposition and skip counts of composable functions.

Jetpack Compose: Debugging Recomposition

Nikariha started another blog post series about optimizing for Android Go edition. The first part introduces Android Go edition, why you’d want to build for it, and some best practices based on experience building the Gboard and Camera from Google apps.

Optimize for Android (Go edition): Lessons from Google apps - Part 1

ADB Podcast Episodes🎙

There has been one episode of Android Developers Backstage posted since the last Now in Android. Check it out at the link below, or in your favorite podcast client:

In Episode 188: Android 13, Chet, Romain, and Tor talk about some of their favorite new features and changes of the new version of Android, both for users and developers.

Now then… 👋

That’s it for this time, with a new developer preview of the privacy sandbox, modularization, offline-first, and state holder Architecture guidance, the end of the Performance MAD Skills series, AndroidX releases, articles on performance, deep links, Jetpack Glance, debugging recomposition, building for Android Go edition, and a new episode of ADB! Come back here soon for the next update from the Android developer universe!

Now in Android #68 was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Collecting flows in a lifecycle-aware manner is the recommended way to collect flows on Android. If you’re building an Android app with Jetpack Compose, use the collectAsStateWithLifecycle API to collect flows in a lifecycle-aware manner from your UI.

collectAsStateWithLifecycle allows your app to save app resources when not needed, such as when the app is in the background. Keeping resources alive unnecessarily can impact the user’s device health. Such resources may include firebase queries, location or network updates, and database connections.

Keep reading to know more about this API, why you should collect in a lifecycle-aware manner, and how it compares to the collectAsState API.

collectAsStateWithLifecycle

collectAsStateWithLifecycle is a composable function that collects values from a flow and represents the latest value as Compose State in a lifecycle-aware manner. Every time a new flow emission occurs, the value of this State object updates. This causes a recomposition of every State.value usage in the Composition.

By default, collectAsStateWithLifecycle uses Lifecycle.State.STARTED to start and stop collecting values from the flow. This occurs when the Lifecycle moves in and out of the target state. This lifecycle state is something you can configure in the minActiveState parameter.

The following snippet demonstrates is how to use collectAsStateWithLifecycle to collect a StateFlow’s uiState field that a ViewModel in your composable function has exposed:

Every time the AuthorViewModel’s uiState emits a new AuthorScreenUiState value, AuthorRoute will be recomposed. For more usages of collectAsStateWithLifecycle, check out the Now in Android app, and its migration PR.

To start using the collectAsStateWithLifecycle API in your project, add the androidx.lifecycle.lifecycle-runtime-compose artifact to your project.

Under the hood

Under the hood, the implementation of collectAsStateWithLifecycle uses the repeatOnLifecycle API which is the recommended way to collect flows in Android using the View system.

collectAsStateWithLifecycle saves you from typing the boilerplate code shown below that also collects flows in a lifecycle-aware manner from a composable function:

Flow collection in your architecture

Types in your app architecture shouldn’t know about the implementation details of other types. The UI shouldn’t know how the ViewModel produces the UI state. If the UI is not visible on the screen, the flow collection should stop to free up app resources if appropriate.

The UI can help free up resources by collecting the UI state using collectAsStateWithLifecycle. The ViewModel can do the same by producing the UI state in a collector-aware manner. If there are no collectors , such as when the UI isn’t visible on screen, stop the upstream flows coming from the data layer. You can do so using the .stateIn(WhileSubscribed) flow API when producing the UI state. For more information about this, watch this part of the Kotlin flows in practice talk. For testing the ViewModel producing UI state in this way, check out the testing guide.

Consumers and producers of flows don’t need to know how each other is implemented. Figuring out implementation details in a big app with multiple environments, variants, libraries, and features can be very time consuming. And even worse, maintaining code that relies on implementation details is hard.

Keeping resources active in the background

Android apps can run on a myriad of Android devices. Unfortunately, not all devices and not all users have endless resources. Apps usually run in a constrained environment. When an Android app is running, there are important factors that impact the user experience and device system health:

• CPU usage: CPUs have the highest battery consumption of all device components. Battery life is a perennial user concern. If abused, users might uninstall your app.
• Data usage: Reducing network traffic in an app when not connected to Wi-Fi can help users save money.
• Memory usage: How an app uses memory can have a very large impact on the overall stability and performance of the device.

An Android developer that wants to respect the user, device system health, or build for billions should optimize these different factors depending on the market, devices, or countries they’re targeting. Keeping unneeded resources alive can have a negative impact depending on the type of device and the Android version the device is running. Using collectAsStateWithLifecycle in the UI layer enables the rest of the hierarchy to free up resources.

collectAsState comparison

Developers often ask: if collectAsStateWithLifecycle is the safest way to collect flows from composable functions in Android, why do we need the collectAsState API now? or why not add the lifecycle-aware functionality to collectAsState instead of creating a new API?

The lifecycle of a composable function is agnostic to the platform Compose is running on. As documented on the Lifecycle of composables page, instances of composable functions enter the Composition, recompose 0 or more times, and leave the Composition.

The collectAsState API follows the Composition’s lifecycle. It starts collecting the flow when the composable enters the Composition and stops collecting when it leaves the Composition. collectAsState is the platform-agnostic API you can use to collect flows.

However, when using Compose in an Android app, the Android lifecycle also plays a critical role in how resources should be managed. Even if Compose halts recompositions while the Android app is in the background, collectAsState keeps the collection active. This makes it impossible for the rest of the hierarchy to free up resources.

Both collectAsState and collectAsStateWithLifecycle have a purpose in Compose. The latter when developing Android apps, the former when developing for other platforms.

Migrating from collectAsState to collectAsStateWithLifecycle is a no-brainer:

Collecting flows in a lifecycle-aware manner is the recommended way to collect flows on Android to enable other parts of your app to free up resources if needed.

If you’re building an Android app with Jetpack Compose, use the collectAsStateWithLifecycle composable function to do this.

P.S. Thanks to Jose Alcérreca, Marton Braun, Alejandra Stamato, and Jake Roseman for reviewing this article.

Consuming flows safely in Jetpack Compose was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Android 13 Beta 4, Predictive back gestures, Jetpack Compose, Wear OS, Text gradients, Large screens, System UI, and more!

Welcome to Now in Android, your ongoing guide to what’s new and notable in the world of Android development.

Episode 65 Video and Podcast

Now in Android is also offered as a video and podcast.

Android 13 Beta 4

We’re just a few weeks away from the official release of Android 13! Meanwhile, we published the last Beta for your testing and development. We reached Platform Stability at Beta 3, so all app-facing surfaces are final, including SDK and NDK APIs, app-facing system behaviors, and restrictions on non-SDK interfaces. With these and the latest fixes and optimizations, Beta 4 gives you everything you need to complete your testing.

Take a look at the blog post for everything you need to check and test. Watch for information on the official Android 13 launch coming in the weeks ahead! Until then, feel free to continue sharing your feedback through our hotlists for platform issues, app compatibility issues, and third-party SDK issues.

Final Android 13 Beta update, official release is next!

10 years of Google Play

In 2012, the team opened the (digital) doors of Google Play. A decade later, more than 2.5 billion people in over 190 countries use Google Play every month to discover apps, games and digital content. And more than 2 million developers work with us to build their businesses and reach people around the globe! Congratulations to the Google Play team for this huge milestone.

Celebrating 10 years of Google Play. Together.

Android Basics with Compose Unit 3 available

The Unit 3 of Android Basics with Compose course is available already! Unit 3 covers how to build apps that display a list of data and how to make your apps more beautiful with Material Design.

This is a continuation of the previous units that starts with learning programming basics and creating your first Android app, and continues with the fundamentals of Kotlin, and building more interactive apps.

https://developer.android.com/courses/android-basics-compose/course

Jetpack Compose 1.2 is now stable

This release contains new features like downloadable fonts, lazy grids, and improvements for tablets and Chrome OS with better focus, mouse, and input handling.

Read the blog post for more information about the new features and APIs, the bugs fixed, and the updated Compose public roadmap.

Jetpack Compose 1.2 is now stable!

Compose for Wear OS is now 1.0

The first stable release of our modern declarative UI toolkit is designed to help developers create beautiful, responsive apps for Google’s smartwatch platform.

Compose for Wear OS makes building apps for Wear OS easier, faster, and more intuitive by following the declarative approach and offering powerful Kotlin syntax. Moving forward, Compose for Wear OS is our recommended approach for building user interfaces for Wear OS apps.

Read the blog post for more information about what’s included in the 1.0 stable release, the tooling available in Android Studio, and how to get started.

Compose for Wear OS is now 1.0: time to build wearable apps with Compose!

AndroidX releases 🚀

Apart from the Jetpack Compose 1.2 and Compose for Wear OS 1.0 stable releases, there has been a bunch of interesting stuff released in AndroidX.

Stable are also the Core splashscreen v1.0, and Profile Installer v1.2. In RC, you can find AppCompat v1.5, Compose Compiler v1.3 that brings support to Kotlin version 1.7.10, Emoji2 v1.2, and ShareTarget v1.2. Lastly, Wear Tiles v1.1 reached its first beta version

See the rest of AndroidX releases in this link.

Articles 📚

Roberto Orgiu wrote about how to make your app large screen ready! Give it a read if you want to know how to get started with large screen support and why it is so important. Accurately handling orientation changes, aspect ratios, and adaptive layouts may seem challenging, but with new large screen experiences in mind, multiple form factors bring new possibilities to your users.

Make your app large screen ready

Ataul Munim wrote about Wear OS 3! You don’t need a physical device to test your Wear apps. Read this article to take a brief look at unique UI surfaces on Wear OS, create a Wear emulator and explore it from a user perspective.

Get familiar with Wear OS 3 (without a physical device)

Chris Arriola wrote about Jetpack Compose interop: Using Compose in a RecyclerView which covers what versions of Compose and RecyclerView you need to use to get the best performance. Furthermore, you’ll understand how the interop works under the hood.

Jetpack Compose Interop: Using Compose in a RecyclerView

Alejandra Stamato wrote two blog posts about text coloring in Compose. The first one, Brushing up on Compose Text coloring, is a very colorful blog post about how to work with Brush API together with TextStyle to achieve complex text coloring like giving a gradient to your text in a simple way.

Brushing up on Compose Text coloring

The second one, Animating brush Text coloring in Compose 🖌️, covers how to animate gradients in your text using the Brush API and Compose animations. Go check them out, I can’t stop looking at those animations now!

Animating brush Text coloring in Compose 🖌️

Diego Zuluaga and Jason Tang wrote the Prepare your app to support predictive back gestures blog post. Predictive back gestures is a feature that will be available in future versions of Android. However, to give you more time to adopt it, we made it available in the developer options of Android 13 Beta 4. Read the blog post for details on how to try out the new gesture and support it in your apps. Spoiler alert: it’s straightforward for most apps!

Prepare your app to support predictive back gestures

ADB Podcast Episodes🎙

There has been one episode of Android Developers Backstage posted since the last Now in Android. Check it out at the link below, or in your favorite podcast client:

In Episode 187: System UI: A Retrospective, Tor and Chet meet Dan Sandler and Adam Cohen from the SystemUI team. They dip into a bit of history, talking about where things were at when they joined the team, and how things have developed in the many years since. They also talk about how to expose (or not) gestures and features in a UI system.

Now then… 👋

That’s it for this time, with Android 13 reaching Beta 4, 10 years of Google Play, articles on large screens and Wear OS 3, Compose interop with RecyclerView, Compose Text coloring, animating the text coloring, and predictive back gestures, a bunch of AndroidX releases, and a new episode of ADB!

Come back here soon for the next update from the Android developer universe.

Now in Android #65 was originally published in Android Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.