Since the last post, a lot has changed on Project Dino, now renamed to Synapse. The intense white theme has shifted to (or more like in the process) adopting a bright, calm yellow inspired from Pluribus(2025). Last article's code references have been updated.

Difference between @Preview & Live Edits​

Android Studio comes with manual/automated live edits, which, when a user makes changes to code, reflects those in a running emulator, without needing a full recompilation (*generally).

But what if the component is nested deep in a parent page that can be accessed only by authentication? What if it's visible only on a specific user action like a pop-up or a toast? So, if only using Live Edits, as a dev I would have to manually trigger these flows every single time or add in testing code to make this specific component always visible, not forgetting the huge resource footprint with a running emulator at all times.

The biggest sell of Previews? Isolation.

The above shows login page in Preview mode. Since Previews are purely UX related feature, they don't have to rely on any kind of developer added component conditions.

Some things that Compose Previews resolves:​

• Build-and-Deploy Time Sink: No longer need to build your app to check the background changing from grey to turquoise. Previews reflect instantly.

• UI Edge Cases and States: As aforementioned, rather than hardcoding conditions to see error/success states of UI elements, these can be mocked with Previews, completely isolated from the core program.

• Display size fragmentation: Same screen, but want to see previews for desktops and tablets? Compose has got you covered.

• Helps you write better code: Hmm how? Well, since Previews are decoupled from the memory states & backend, YOUR CODE needs to be clean enough to mock UI by just passing parameters. This comes with an incredible amount of reusability for the components.

Let's go over some of these.

Build-and-Deploy Time Sink​

I deal with React for web at most times. So, cuz of this I never imagined that instant preview (or hot-reload) wasn't a gold standard on the Android side until very recently.

Let me show a very practical comparison.

Since Synapse supports a shared UI, I run most of my builds on iOS simulators (much smaller memory footprint). As shown, a simple color change needed a few seconds for rebuild & installation (though this would be much faster for android builds, but still needs the same process).

What about Previews?

Bamm! Instant because preview compilation doesn't care about the rest other than the element at hand.

UI Edge Cases and States​

For this, let's use simple test element. Synapse uses a bottom sheet here to cycle between selected models. Will be using the ModelSelectionRadioMenu compose element.

Since Previews are dev-only tools, we can keep them in separate preview modules. For this ModelSelectionRadioMenu, we create a previews/componentsPreview.kt file and mark the composable as private.

@Preview(showBackground = true)
@Composable
private fun ModelSelectionRadioMenuPreviewIndividual() {
ModelSelectionRadioMenu(
        onClick = {},
        state = ModelSelectionParamDetails(/*a custom data class*/
            name = "Google Gemini",
            description = "Advanced model from Google",
            incomingType = ModelDefinitions.GEMINI.name,
        ),
        currentSelection = ModelDefinitions.GEMINI.name
    )
}

This renders:

Hmm, pretty basic right? What if I want to view the same with different string values?

Compose comes with this incredibly powerful method @PreviewParameter, which supports passing large datasets as parameter to the Preview parent of the composable. Basically think of it as passing a large list, and rendering a UI element for each. More on this here.

Now for the same ModelSelectionRadioMenu

private class ModelSelectPreviewProvider : PreviewParameterProvider<ModelSelectionParamDetails> {
    override val values = sequenceOf(
        ModelSelectionParamDetails(
            name = "Google Gemini",
            description = "Advanced model from Google",
            incomingType = ModelDefinitions.GEMINI.name,
        ),
        ModelSelectionParamDetails(
            name = "Claude Opus",
            description = "Advanced model from Anthropic",
            incomingType = ModelDefinitions.CLAUDE.name,
        )
    )
}

/*botInterface/previews/componentsPreview.kt*/
@Preview(showBackground = true)
@Composable
private fun ModelSelectionRadioMenuPreviewMultiple(
    @PreviewParameter(ModelSelectPreviewProvider::class) incomingClass: ModelSelectionParamDetails
) {
    ModelSelectionRadioMenu(
        onClick = { tst ->

        },
        state = incomingClass,
        currentSelection = ModelDefinitions.CLAUDE.name
    )
}

This renders:

Display size fragmentation​

One of the biggest advantages of Compose Multiplatform is writing UI code that works across phones, tablets, and desktops. But how do you verify your layouts look good on all these different screen sizes without constantly switching between devices or emulators?

Compose Preview comes with built-in device presets that let you preview your composables on different form factors. You can use predefined device types like Devices.PIXEL_2_XL for phones or Devices.NEXUS_7 for tablets, but the real power lies in custom device specifications.

@Preview(
    name = "Phone Portrait",
    device = "spec:width=411dp,height=891dp,dpi=420"
)
@Preview(
    name = "Tablet Landscape",
    device = "spec:width=1280dp,height=800dp,dpi=213,orientation=landscape"
)
@Preview(
    name = "Desktop",
    device = "spec:width=1920dp,height=1080dp,dpi=160"
)
@Composable
private fun ResponsiveLayoutPreview() {
    // Your composable here
}

With Synapse being a KMP app targeting Android & iOS, I can quickly iterate through different screen sizes to ensure the UI adapts correctly. No need to fire up multiple emulators or resize windows manually—just add multiple @Preview annotations with different device specs, and Android Studio will show all of them side-by-side in the preview panel.

Alternatively, triggering the Check UI mode on IntelliJ also generates screen previews.

Nice! But how does @Preview work?​

This will need an article on its own. Will add it soon!

Since Compose Multi-platform combines the UI aspect for both iOS and Android, how do you implement Google authentication such that the UI code remains unified while maintaining the ideal authentication flow specific to these platforms in Kotlin without using a KMP library?

Kotlin Multiplatform simplified​

Refer to Project Synapse code to understand the archiecture. Basically, the UI layer of the application is shared between iOS and Android (composeApp module), with shared module acting as the common ground for business logic sharing between UI and backend server, while Ktor-based server rests in the server module. More here.

The Google Auth​

There are two most common things in a Google authentication flow:

1. The user manually signs in to the app by tapping the Sign in with Google button.
2. The user is automatically signed in, either from previously stored session state or via a bottom sheet that lets them pick from existing Google accounts.

In this article, we explore implementation of Google authentication for Android while maintaining a common UI on a KMP app.

Setting up, expect / actual functions​

The above is the structure of our Compose Multiplatform app. The commonMain module contains the shared UI code for both Android and iOS platforms, while platform-specific implementations reside in the androidMain and iosMain modules.

In our implementation, the Sign in with Google UI interface will be shared, but the behaviour will be controlled by platform specific code.

The implementation of UI button in commonMain:

refer: SignInMethod.kt

@Composable
fun ClickableContinueWithGoogle(nonce: String, handleReceivedGoogleTokenId: (String) -> Unit) {
    val authProvider = rememberGoogleAuthProvider()
    val scope = rememberCoroutineScope()
    var loaderState by remember { mutableStateOf(false) }

    // Auto sign-in check on component mount
    LaunchedEffect(nonce) {
        if (nonce == Defaults.default) return@LaunchedEffect
        loaderState = true
        authProvider.checkExistingCredentials(nonce)?.let { token ->
            handleReceivedGoogleTokenId(token)
        }
        loaderState = false
    }

    Image(
        painter = painterResource(Res.drawable.btn_android_id_rec),
        contentDescription = "Continue with Google",
        contentScale = ContentScale.FillWidth,
        modifier = Modifier.fillMaxWidth(.5f)
            .clickable {
                scope.launch {
                    if (nonce == Defaults.default) return@launch
                    loaderState = true
                    authProvider.signIn(nonce)
                        .onSuccess { token ->
                            handleReceivedGoogleTokenId(token)
                        }
                        .onFailure { exception ->
                            // TODO: Handle error properly
                            println("Sign-in failed: ${exception.message}")
                        }
                    loaderState = false
                }
            }
    )
}

So what exactly is this? This is a composable function in which we define ClickableContinueWithGoogle which has two ways to trigger a sign in. Our automated implementation triggers in a LaunchdedEffect and a modifier with clickable property. Both these use methods from rememberGoogleAuthProvider() - an expect implementation which we explore next.

expect implementation for rememberGoogleAuthProvider​

refer: GoogleAuthProvider.kt

/**
 * Interface for Google authentication functionality across platforms.
 * Provides a common abstraction for Google Sign-In operations.
 */
interface GoogleAuthProvider {
    /**
     * Initiates the sign-in flow with the provided nonce.
     *
     * @param nonce The nonce value from the server for token validation
     * @return Result containing the Google ID token on success, or an error
     */
    suspend fun signIn(nonce: String): Result<String>

    /**
     * Checks for existing credentials without prompting the user.
     * Useful for automatic sign-in on app launch.
     *
     * @return The existing Google ID token if available, null otherwise
     */
    suspend fun checkExistingCredentials(nonce: String): String?
}

/**
 * Platform-specific factory function to create a GoogleAuthProvider instance.
 * Each platform provides its own implementation.
 */
@Composable
expect fun rememberGoogleAuthProvider(): GoogleAuthProvider

This expect composable has an actual implementation for each Android & iOS. This defines an interface on how the returned class properties need to be structured.

Since we are defining actual functions to be platform specific, we need to use native libraries.

For Android, we install Google credentials libs in androidMain/build.gradle.kts file:

val credentialVersion = "1.6.0-rc01"
implementation("androidx.credentials:credentials:$credentialVersion")
implementation("androidx.credentials:credentials-play-services-auth:$credentialVersion")
implementation("com.google.android.libraries.identity.googleid:googleid:1.1.1")

Android actual implementation​

refer: GoogleAuthProvider.android.kt

import android.content.Context
import android.util.Log
import androidx.compose.runtime.Composable
import androidx.compose.runtime.remember
import androidx.compose.ui.platform.LocalContext
import androidx.credentials.*
import androidx.credentials.exceptions.GetCredentialException
import com.alwinsden.dino.BuildKonfig
import com.google.android.libraries.identity.googleid.GetGoogleIdOption
import com.google.android.libraries.identity.googleid.GetSignInWithGoogleOption
import com.google.android.libraries.identity.googleid.GoogleIdTokenCredential
import com.google.android.libraries.identity.googleid.GoogleIdTokenParsingException

@Composable
actual fun rememberGoogleAuthProvider(): GoogleAuthProvider {
    val context = LocalContext.current
    return remember {
        AndroidGoogleAuthProvider(
            context = context,
            credentialManager = CredentialManager.create(context)
        )
    }
}

Suspended signIn function​

refer: GoogleAuthProvider.android.kt

override suspend fun signIn(nonce: String): Result<String> {
    return try {
        val signInWithGoogleOption = GetSignInWithGoogleOption.Builder(
            serverClientId = BuildKonfig.CLIENT_ID_GOOGLE_AUTH
        )
            .setNonce(nonce)
            .build()

        val request = GetCredentialRequest.Builder()
            .addCredentialOption(signInWithGoogleOption)
            .build()

        val result = credentialManager.getCredential(
            request = request,
            context = context
        )

        Log.i(TAG, "Manual Google Sign-in success")
        extractGoogleIdToken(result)
    } catch (e: GetCredentialException) {
        Log.e(TAG, "Error getting credential", e)
        Result.failure(e)
    }
}

Here BuildKonfig is a generated object created by a popular Kotlin Multiplatform (KMP) Gradle plugin called BuildKonfig. It injects the Google console auth key from secrets.properties file. more here.

What is Nonce here?​

This is a safety mechanism in place to prevent replay attacks. Nonce flows from the server, usually a JWT token.

Valkey implementation: Valkey Glide

| Backend System                              |
|---------------------------------------------|
| 1. Generate Secure Nonce                    |
|    & Save to Valkey/Redis                   |
|               |                             |
|               v                             |
| 2. Share Nonce with CLI/Client              |
|               |                             |
|---------------|-----------------------------|
                |
                v
| CLI / Client Application                    |
|---------------------------------------------|
| 3. Init GAuth Builder (setNonce)            |
|               |                             |
|               v                             |
| 4. Perform Google Sign-In                   |
|    (Result: Encrypted Token ID w/ Nonce)    |
|               |                             |
|               v                             |
| 5. Send Token ID to Backend                 |
|               |                             |
|---------------|-----------------------------|
                |
                v
| Backend System                              |
|---------------------------------------------|
| 6. Verify Google Token Signature            |
|               |                             |
|               v                             |
| 7. Extract Nonce & Check Valkey/Redis       |
|               |                             |
|    [  Exists & Matches?  ]                  |
|       | Yes           | No                  |
|       |               +----> | Reject |     |
|       v                                     |
| 8. Generate Custom App JWT                  |
|               |                             |
|               v                             |
| 9. Return JWT to CLI (Login Success)        |
|_____________________________________________|

Suspended checkExistingCredentials function​

override suspend fun checkExistingCredentials(nonce: String): String? {
    return try {
        val googleIdOption = GetGoogleIdOption.Builder()
            .setFilterByAuthorizedAccounts(true)
            .setAutoSelectEnabled(true)
            .setServerClientId(BuildKonfig.CLIENT_ID_GOOGLE_AUTH)
            .setNonce(nonce)
            .build()

        val request = GetCredentialRequest.Builder()
            .addCredentialOption(googleIdOption)
            .build()

        val result = credentialManager.getCredential(
            request = request,
            context = context
        )

        Log.i(TAG, "Auto Google Sign-in success")
        extractGoogleIdToken(result).getOrNull()
    } catch (e: GetCredentialException) {
        Log.d(TAG, "No existing credentials found", e)
        null
    }
}

In either case, the returned Google token ID, serves the same primary function.

This expect function also has a corresponding implementation in iOS which requires a more complex setup and will be discussed in an upcoming article. Until then check the code here.