However, as we move away from platform-specific APIs, we often hit those small “quality of life” roadblocks. One of these, although it looks pretty basic, are Toast messages.

If you’re coming from native Android development, you’re used to a simple Toast.makeText(…).show(), but, in the multiplatform world, there is no “common” toast.

While you could reach for the expect/actual pattern to wrap native Toast on Android and UIAlertController or custom UIViews on iOS, this approach often leads to inconsistent behavior and design headaches.

Today, I want to talk about how to implement a pure Compose-based toast system that works seamlessly across all targets.

The Problem with Platform-Specific Toasts

When you implement toasts via expect/actual, you face several challenges:

• Design Disparity: Android has its native Toast, but it requires a Context, iOS doesn’t have a direct equivalent (usually requiring a custom UIView or UIAlertController), Desktop/Web need a custom Compose-based overlay
• Context Management: on Android you need a Context, which isn’t always easy to grab from shared business logic.
• Positioning: iOS users expect notifications near the top of the screen(avoiding the Dynamic Island), while Android users expect them at the bottom.
• Flexibility: Native toasts are notoriously hard to customize beyond simple text.

The Pure Compose Approach

The idea is to build the toast system entirely in Compose, using an event based implementation to handle requests to show toast messages and keep a consistent behavior while still respecting platform-specific quirks.

The Toast

First of all we need to define what a Toast is.
As most will already know a Toast is a short, informational message that an app displays briefly near one edge of the screen and it generally contains simple text.

Thus, in the most simple implementation a Toast will have:

• A message
• A duration
• An alignment on the screen (e.g. BottomCenter)

This can be hold in a simple Toast class:

class Toast(
    val message: String,
    val durationMillis: Long,
    val alignment: Alignment
)

Managing the requests to show a Toast

To make things work globally I needed a way to manage requests to show a Toast coming from everywhere in my app, so I went for an event based solution.

I used a MutableSharedFlow to handle Toast Events asynchronously and enable the UI to requesting for a toast message to be shown

private object ToastEvents {
    private val _events = MutableSharedFlow()
    val events = _events.asSharedFlow()

    suspend fun publish(event: Toast) {
        _events.emit(event)
    }

    suspend fun subscribe(onEvent: (Toast) -> Unit) {
        events.collectLatest { event ->
            currentCoroutineContext().ensureActive()
            onEvent(event)
        }
    }
}

This way I’m able to subscribe to the toast events flow and handle Toast visualization seamlessly.

The Container (The “Magic” Sauce)

The heart of the implementation is the ToastContainer. A component wrapping the entire application to show the toast on top of the app’s content.

This is where content rendering and platform specific positioning happen.

@Composable 
fun App() { 
  MaterialTheme { 
    ToastContainer(modifier = Modifier.fillMaxSize()) { 
      // Put here your app's content 
    } 
  } 
}

This component is responsible for subscribing to the ToastEvents Flow

LifecycleEventEffect(Lifecycle.Event.ON_START) { 
        coroutineScope.launch { 
            ToastEvents.subscribe { 
                toast = it 
 
                if ( toast?.message?.isBlank() == true ) 
                    return@subscribe 
 
                if ( toast?.durationMillis == 0L ) 
                    return@subscribe 
 
                coroutineScope.launch { 
                    alignment = toast.alignment 
                    shouldShowToast = true 
                    delay(toast?.durationMillis ?: 0L) 
                    shouldShowToast = false 
                } 
            } 
        } 
    }

handling actual toast showing logic and defining the toast layout.

I implemented it as a BoxWithConstraints composable to better suit alignment needs.
Using AnimatedVisibility, we can create a smooth entrance and exit for the toast message. I opted for a combination of fadeIn and expandHorizontally to give it a modern, “pill-like” feel.
The container also automatically adjusts colors based on isSystemInDarkTheme(), ensuring the toast is always readable:

BoxWithConstraints( 
        modifier.fillMaxSize() 
    ) { 
        content.invoke() 
        AnimatedVisibility( 
            visible = shouldShowToast, 
            enter = fadeIn() + expandHorizontally(expandFrom = Alignment.CenterHorizontally), 
            exit =  shrinkHorizontally(shrinkTowards = Alignment.CenterHorizontally) + fadeOut(), 
            modifier = Modifier.align(alignment) 
        ) { 
            Row( 
                modifier = Modifier 
                    .background(if ( isDarkTheme ) Color.White else Color.Black, RoundedCornerShape(24.dp)) 
                    .widthIn(ButtonDefaults.MinWidth, 300.dp) 
                    .padding(horizontal = 12.dp, vertical = 5.dp), 
            ) { 
                Text( 
                    text = toast?.message ?: "", 
                    textAlign = TextAlign.Center, 
                    color = if (isDarkTheme) Color.Black else Color.White, 
                    fontWeight = FontWeight.Medium, 
                    maxLines = 1, 
                    overflow = TextOverflow.Ellipsis, 
                    fontSize = 12.sp 
                ) 
            } 
        } 
    }

In order to handle the different platforms I had to complicate a bit the things to handle alignment based on the platform

when(platform.name) { 
      PlatformName.IOS -> Alignment.TopCenter 
      PlatformName.JVM -> Alignment.BottomEnd 
      else -> Alignment.BottomCenter 
}

and padding based on the positioning of the toast

private fun getPaddingValues(alignment: Alignment) : PaddingValues { 
    return when(alignment) { 
        Alignment.TopStart -> PaddingValues(top = 24.dp, start = 24.dp) 
        Alignment.TopCenter -> PaddingValues(top = 24.dp) 
        Alignment.TopEnd -> PaddingValues(top = 24.dp, end = 24.dp) 
        Alignment.BottomStart -> PaddingValues(bottom = 24.dp, start = 24.dp) 
        Alignment.BottomCenter -> PaddingValues(bottom = 24.dp) 
        Alignment.BottomEnd -> PaddingValues(bottom = 24.dp, end = 24.dp) 
        Alignment.CenterStart -> PaddingValues(start = 24.dp) 
        Alignment.CenterEnd -> PaddingValues(end = 24.dp) 
        else -> PaddingValues(0.dp) 
    } 
}

I thought these could be sensed defaults but you can have your own.

Finally, I only had to define the public API for showing a toast from inside an app’s code:

/** 
 * Displays a text-only toast message. 
 * 
 * @param message The text message to display. 
 * @param durationMillis The duration the toast remains visible (defaults to 3000ms). 
 * @param alignment The screen alignment for the toast (defaults to platform-specific Auto). 
 */ 
fun showToast(message: String, durationMillis: Long = ToastDefaults.DURATION_DEFAULT, alignment: Alignment = ToastDefaults.DEFAULT_ALIGNMENT) { 
    val coroutineScope = CoroutineScope(Dispatchers.Default) 
    coroutineScope.launch { 
        ToastEvents.publish(Toast(message, durationMillis, alignment = alignment)) 
    } 
}

and call it like this

ToastContainer { 
    Column { 
        Button(onClick = { showToast("Hello Multiplatform!") }) { 
            Text("Show Toast") 
        } 
    } 
}

All of this can be extended at own will, so far I added the ability to have an icon on one side of the text or even pass a custom composable to the toast to allow maximum personalization.

Why this works

• Pure Compose: No expect/actual bridges for the UI.
• Context-Free: You can trigger a toast from a simple function call
• Adaptive: It automatically handles padding and alignment differently for iOS (Top), Android (Bottom), and Desktop (Bottom-End)
• Customization: you can have your own positioning and content

Building for multiplatform shouldn’t mean sacrificing the user experience or writing messy bridges for every tiny UI element.

By moving the toast logic into a shared Compose container, we gain total control over the look and feel while keeping the API dead simple.

Hope this little description of my experience with Toasts could help you with your Compose Multiplatform apps.

I’ve wrapped the whole implementation — including the custom composable support, the event system, and the platform-aware positioning — into a library called mToast.
You can check out the full source code and the sample app on GitHub:

and use it from maven central in your project

kotlin { 
    sourceSets { 
        commonMain.dependencies { 
            implementation("it.xabaras:mtoast:0.2.0") 
        } 
    } 
}

Thanks for reading, your experience and opinions are welcome in the comments.

Someone could ask: Why would you need to write permission handling code on your own while there’s many good libraries out there to do the same?

Actually there’s more than one reason why one would do so.

First of all I wanted to clearly understand how permissions are handled across platforms (especially between Android and iOS), then I wanted to minimize the number of dependencies needed to develop a large app, finally I wanted to try and find my way through the permissions woods.

Obviously anyone can come out with the solution which better suits their needs, what follows is just my way, but you can try and find your own.

I went for expected/actual object classes and lambda expressions to implement my solution since they looked the most straightforward way to me, for you don’t have to instantiate new objects in the native code of the Android and iOS apps and you don’t need to define classes or interfaces for the callbacks, which means less boilerplate code.

What follows is an exemple wich uses the Contacts permission but it can easily be adapted to every kind of permission with proper permission handling code on both Android and iOS.

Now let’s see what and where needs to be made in a Compose Multiplatform project in order to get the permissions thing done.

In my description I assume the project to having the standard structure of a CMP project as created by the Kotlin Multiplatform Wizard.

Common part

First of all I created a new object class (I called it ContactsPermissionHandler) in the commonMain project

expect object ContactsPermissionHandler {
    fun isPermissionGranted() : Boolean
    fun isPermissionPermanentlyDenied() : Boolean
    fun requestPermission(
        callback: (isGranted: Boolean, isPermanentlyDenied: Boolean) -> Unit
    )
}

actual object ContactsPermissionHandler {
  private lateinit var _activity: ComponentActivity
  private lateinit var _callback: (isGranted: Boolean, isExplicitlyDenied: Boolean) -> Unit
  private lateinit var requestContactPermissionLauncher: ActivityResultLauncher

  actual fun isPermissionGranted() : Boolean {
    return ContextCompat.checkSelfPermission(
      _activity,
      Manifest.permission.READ_CONTACTS
    ) == PackageManager.PERMISSION_GRANTED
  }

  actual fun isPermissionPermanentlyDenied() : Boolean {
    return ContextCompat.checkSelfPermission(
      _activity,
      Manifest.permission.READ_CONTACTS
    ) != PackageManager.PERMISSION_GRANTED &&
    _activity.shouldShowRequestPermissionRationale(Manifest.permission.READ_CONTACTS).not()
  }

  actual fun requestPermission(callback: (isGranted: Boolean, isPermanentlyDenied: Boolean) -> Unit) {
    val permission = Manifest.permission.READ_CONTACTS
    when {
      ContextCompat.checkSelfPermission(
        _activity,
        permission
      ) == PackageManager.PERMISSION_GRANTED -> {
        callback.invoke(true, false)
        Log.d("ContactsPermissionHandler", "Contacts Permission granted")
      }

      else -> {
        Log.d("ContactsPermissionHandler", "Asking for Contacts permission")
        _callback = callback
        requestContactPermissionLauncher.launch(permission)
      }
    }
  }

  fun setActivity(activity: ComponentActivity) {
    _activity = activity
    requestContactPermissionLauncher =
      _activity.registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
        if (isGranted) {
          _callback.invoke(true, false)
          Log.d("ContactsPermissionHandler", "Contacts Permission granted")
        } else {
          val isPermanentlyDenied =
            _activity.shouldShowRequestPermissionRationale(Manifest.permission.READ_CONTACTS).not()
          _callback.invoke(false, isPermanentlyDenied)
          Log.d("ContactsPermissionHandler", "Contacts Permission denied")
        }
      }
  }
}

override fun onCreate(savedInstanceState: Bundle?) {
  super.onCreate(savedInstanceState)
  ContactsPermissionHandler.setActivity(this)

  ...

  setContent {
    App()
  }
}

NSContactsUsageDescription
To send messages to the user's contacts

actual object ContactsPermissionHandler {

    actual fun isPermissionGranted() : Boolean {
        return CNContactStore.authorizationStatusForEntityType(CNEntityType.CNEntityTypeContacts) == CNAuthorizationStatusAuthorized
    }

    actual fun isPermissionPermanentlyDenied(): Boolean {
        return CNContactStore.authorizationStatusForEntityType(CNEntityType.CNEntityTypeContacts) == CNAuthorizationStatusDenied ||
                CNContactStore.authorizationStatusForEntityType(CNEntityType.CNEntityTypeContacts) == CNAuthorizationStatusRestricted
    }

    actual fun requestPermission(callback: (isGranted: Boolean, isPermanentlyDenied: Boolean) -> Unit) {
        val store = CNContactStore()
        when (CNContactStore.authorizationStatusForEntityType(CNEntityType.CNEntityTypeContacts)) {
            CNAuthorizationStatusNotDetermined -> {
                store.requestAccessForEntityType(CNEntityType.CNEntityTypeContacts) { granted, error ->
                    if (granted) {
                        callback.invoke(true, false)
                    } else {
                        callback.invoke(false, false)
                    }
                    error?.let {
                        NSLog("ERROR: [ContactsPermissionHandler] ${it.description}")
                    }
                }
            }
            CNAuthorizationStatusDenied -> {
                callback.invoke(false, true)
                NSLog("INFO: [ContactsPermissionHandler] Permission denied")
            }
            CNAuthorizationStatusRestricted -> {
                callback.invoke(false, true)
                NSLog("INFO: [ContactsPermissionHandler] Permission restricted")
            }
            CNAuthorizationStatusAuthorized -> {
                callback.invoke(true, false)
                NSLog("INFO: [ContactsPermissionHandler] Permission granted")
            }
            else -> {
                NSLog("ERROR: [ContactsPermissionHandler] An unknown error occurred while handling contacts permission")
            }
        }
    }
}

The first thing you can notice is that the class is completely written in Kotlin, so there’s no need to write native swift code, plus, you don’t need to implement anything else but the three methods defined in the commonMain and you’re all set.

Compose

Let’s now se the Compose part and how to actually resquest permissions in your app.

Based on the code written so far you just need to call the proper methods from the ContractsPermissionHandler object class in you Compose code, as you would usually do for a class implemented in the same project, and KMP will do all the magic of executing the actual native code on each platform.

Here follows a small example of how a simple Composable would look like

Hope this little walkthrough on permissions could help you achieve what you want in your Compose Multiplatform apps when it comes to permissions.

Your experience and opinions are welcome in the comments.

@Composable
@Preview
fun ExamplePermissionScreen(modifier: Modifier)
{
    var isPermissionGranted by remember { mutableStateOf(ContactsPermissionHandler.isPermissionGranted())}
    Column(
        modifier = modifier.fillMaxWidth()
    ) {
        if ( isPermissionGranted ) {
            Text(
                text = "Thanks for granting the permission to access your contacts!"
            )
        } else {
            Text(
                text = "In order to send messages to your friends we will need your permission to read contacts"
            )
            Button(
                onClick = {
                        ContactsPermissionHandler.requestPermission() { isGranted, _ ->
                            isPermissionGranted = isGranted
                        }
                    })
            {
                Text("Give permission")
            }
        }
    }
}

Hope this little walkthrough on permissions could help you achieve what you want in your Compose Multiplatform apps when it comes to permissions.

Your experience and opinions are welcome in the comments.

This post is also available on Medium.

But since updating to the latest macOS iteration I started experiencing Android Studio unexpected crashes.

At the beginning I wasn't able to detect the cause but eventually I managed to understand the problem: Android Studio would't start at all with an exernal monitor attached to my MacBook and would crash when connecting one.

From there to solve the issue I had to to go past several tries, reading system logs and searching on the internet but in the end I succeeded in fixing it.

The crashes were due to the Metal GPU in my MacBook Pro so I had to start Android Studio via command line adding the following JVM parameter: -Dsun.java2d.metal=false

You will agree that starting Android Studio from the command line everytime you need to use is at least annoying but you'll find that the solution is close at hand.

Just find the studio.vmoptions file for your Android Studio version, mine was at the following path

/Users/[my_username]/Library/Application Support/Google/AndroidStudio2024.1/

and add the said JVM parameter at the top of the file:

Piece of cake!

Your experience and opinions are welcome in the comments.

This post is also available on Medium.

Next to the Composition, there’s another three, called the Semantics tree, which describes your UI in a different way that is understandable for Accessibility services.

Thus everyone using Jetpack Compose to define the UI of an Android app has had to deal with contentDescription parameters to improve accessibility of said app and providing a proper description for a given portion of the UI.

However, there are some commonly used composables (say Box or Text for instance) which don’t have a content description parameter.

I came into this while developing my first all compose app, when play console reported an issue with a UI componet not properly labelled for accessibility.
Thus I had to figure out how to set a contentDescription on that composable (it was a Box composable).

So, what should one do when it comes to composables which don’t allow to set a contentDescription in a straightforward way?

The “semantics” modifier, which provides “key = value”-style setters for any Semantics property key, may come in handy.

Suppose you have your Box with its properties and modifiers:

Box (
  contentAlignment = Alignment.CenterStart,
  modifier = Modifier
  .fillMaxWidth()
  .background(Color.Red)
)

and you want to add a custom content description for it.

As stated before, since it has not a contentDescription property, a “semantics” modifier can be used as follows

Box (
  contentAlignment = Alignment.CenterStart,
  modifier = Modifier
  .fillMaxWidth()
  .background(Color.Red)
  .semantics {
    this.contentDescription = "Custom content description"
  }
)

Hope the above may be of any help for those who struggle to find an answer to this issue.

Your experience and opinions are welcome in the comments.

This post is also available on Medium.

Therefore when it comes to adding Ad banners to our Jetpack Compose project we necessarily need to get back to the classic Android View system.

Fotunately there’s a composable which comes in handy, the AndroidView composable.

It is designed to include an Android View hierarchy in a Compose UI.

This makes pretty straightforward to include a classic BANNER size Ad in a Compose UI

AndroidView (
  modifier = Modifier.fillMaxWidth(),
  factory = { context ->
      AdView(context).apply {
          // Set the banner size          
          setAdSize(AdSize.BANNER)

          // Set the Ad unit ID
          adUnitId = "ca-app-pub-3940256099942544/6300978111"
          
          // Load the Ad
          loadAd(AdRequest.Builder().build())
      }
  }
)

Basically we can

    add the AndroidView composable to the UI definition
    create a new instace of the AdMob AdView class in the “factory” block of the AndroidView composable
    set the AdSize
    set the adUnit ID
    load the Ad

We would most likely want to use adaptive banners to maximising performance and optimizing ad size for each device.

Suppose we want to include and adaptive banner in our UI, we will need to set the AdSize properly, according to the screen size and orientation.

In order to do so, the AdMob SDK provides a set of methods in the AdSize class wich take in a context and a width as parameters and return an adSize.

Let’s assume we are including an anchored adaptive banner to our UI, what we will need to do is something like

val adSize = AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize(
    context,
    currentScreenWidth
)

 We can use the context from the factory block, as you can see from the previous code sample about classic banners.

For the screen width Jetpack Compose provides a simple solution via the LocalConfiguration class so we will be able to write

val currentScreenWidth = LocalConfiguration.current.screenWidthDp

And to wrap it all up we can define our custom composable like this 

@Composable
fun AnchoredAdaptiveBanner(modifier: Modifier) {
    val currentScreenWidth = LocalConfiguration.current.screenWidthDp

    AndroidView(
        modifier = modifier,
        factory = { context ->
            AdView(context).apply {
                // Compute the AdSize based on current screen width
                val adSize = AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize(
                    context,
                    currentScreenWidth
                )
                // Set the adaptive banner size
                setAdSize(adSize)

                // Set the Ad unit ID
                adUnitId = "ca-app-pub-4440099591868517/3269775877"

                // Load the Ad
                loadAd(AdRequest.Builder().build())
            }
        }
    )
}

 Now we can include an anchored adaptive banner into our Compose UI by simply using the AnchoredAdaptiveBanner composable.

Hope the above may be of help for those who struggle with including AdMob ads into their Compose UIs.

Your experience and opinions are welcome in the comments.

This post is also available on Medium.

The default choice for primary key identifiers in a Room Database is usually an auto-generated Integer field, e.g.:

@PrimaryKey(autoGenerate = true) val id: Int

Integer IDs are plain and straightforward to implement but not so easy to handle when it comes to apps wich can run on multiple devices at the same time or when you have remotely stored data with all its consequences (e.g. coping with collisions is a literal hell).

In many cases like the foresaid ones having Universally Unique Identifiers maight come in handy.

Here follows a brief summary of how I managed to have UUIDs as primary keys in my Room Database based apps.

Let’s assume we have a simple Room entity we use to store our app’s users, like the one below:

@Entity data class User(
  @PrimaryKey(autoGenerate = true) val id: Int = 0,
  val firstName: String,
  val lastName: String
)

Room will auto-generate and auto-increment user IDs when you save it to the database.

Now let’s see how to achieve the same with UUIDs.

First of all we will need to convert our id to an UUID, like this:

@Entity
data class User(
  @PrimaryKey val id: UUID,
  val firstName: String,
  val lastName: String
)

But, since we don’t have a UUID field type in SQLite we will need to put some measures in place.

In the classic method we had a default zero value for our integer id, we’ll do the same for UUIDs, e.g.

@Entity(tableName = "users")
data class User(
  @PrimaryKey val id: UUID = UUID.fromString(DEFAULT_UUID),
  val firstName: String,
  val lastName: String
) {

    companion object {
        const val DEFAULT_UUID = "00000000-0000-0000-0000-000000000000"
    }
}

Now that we have our entity let’s see how to define the app’s database.

Usually you would do so

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

 Where UserDao can be defined as follows

@Dao
interface UserDao {
    @Query("SELECT * FROM users")
    fun getAll() : List

    @Query("SELECT * FROM users WHERE id = :id")
    fun getById(id: UUID) : User?

    @Insert
    fun insert(user: User)

    @Update
    fun update(user: User)

    @Delete
    fun delete(user: User)
}

 But then again, since UUIDs are not natively supported we will need to find our solution.

Here’s where TypeConverters come in handy.

We can define a proper TypeConverter to let Room convert UUIDs to/from strings

class Converters {
    
    @TypeConverter
    fun fromUUID(uuid: UUID): String? {
        if ( uuid.toString() == User.DEFAULT_UUID )
            return UUID.randomUUID().toString()

        return uuid.toString()
    }

    @TypeConverter
    fun uuidFromString(string: String?): UUID {
        string?.let {
            return UUID.fromString(string)
        }
        return UUID.fromString(User.DEFAULT_UUID)
    }

}

As you can see the “fromUUID” Type Converter will generate a new UUID for User instances with default identifier.

In order for these TypeConverters to do their job you will need to add it to the AppDatabase like this

@Database(entities = [User::class], version = 1)
@TypeConverters(Converters::class)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Once you did so, Room will automatically convert UUIDs to/from Strings making it all work seamlessly.

val db = Room.databaseBuilder(
  context, AppDatabase::class.java, "example-database"
).build()

val dao = db.userDao()
val user = User(firstName = "Paolo", lastName = "Montalto")

dao.insert(user)

This is just a sample implementation, anyone can of course find the most suitable for own needs.

Your experience and opinions are welcome in the comments.

This post is also available on Medium

Fortunately, with the advent of Android Jetpack, Security library finally came in to help.

[Continue on Medium]

In order to be able to do so, you will have... [Continue on Medium]

How I managed to install a working IntelliJ Idea CE on an ARM Chromebook

Finalmente supporta AndroidX!