DEV Community: Brady Aiello

Easier Testing with Kotlin Delegates

Brady Aiello — Fri, 10 Dec 2021 17:55:32 +0000

TL;DR

You can use constructor injection of interfaces along with Kotlin delegates to make your code more modular without changing your class hierarchy. This has the benefit of not only making testing easier, but also code reuse, modularity, and easier dependency injection.

The Problem

Recently I had the opportunity to simplify a Kotlin class hierarchy for a client. These aren't the actual classes, but the structure was something like this:

interface Task {
    val scope: CoroutineScope
        get() = GlobalScope

    suspend fun doSomething(taskName: String): Unit {
        scope.launch {
            delay(1000L)
            print("I am $taskName")
        }
    }
}

interface Coffee: Task {
    fun makeCoffee() {
        print("Drip Drip")
        scope.launch {
            doSomething("making coffee")
        }
    }

    fun drinkCoffee() {
        print("Mmmmm...")
        scope.launch {
            doSomething("drinking coffee")
        }
    }
}

interface Breakfast: Task {
    fun eatBreakfast() {
        print("Om nom nom")
        scope.launch {
            doSomething("eating breakfast")
        }
    }
}

interface Morning:
    Task,
    Coffee,
    Breakfast

class DefaultMorning: Morning {
    fun morningRoutine() {
        makeCoffee()
        drinkCoffee()
        eatBreakfast()
    }

    override suspend fun doSomething(taskName: String) {
        scope.launch {
            delay(15000L)    
            println("I'm tired and I'm $taskName")
        }
    }
}

We have a couple layers of inheritance, using an interface of interfaces. If we want to test it without the delay, we'll need to override the doSomething() method. If we do that, we're not actually testing the DefaultMorning. Rather, we're testing something similar to DefaultMorning:

class TestMorning: Morning {
    fun morningRoutine() {
        makeCofee()
        drinkCoffee()
        eatBreakfast()
    }

    override suspend fun doSomething(taskName: String) {
        println("I'm tired and I'm $taskName")
    }
}

We'll have to do the same thing for testing other classes as well:

class TestCoffee: Coffee {
    override suspend fun doSomething(taskName: String) {
        print("I am $taskName")
    }
}

This begs the question, "Is there a better way?"

Enter Kotlin Delegates

Merriam-Webster defines delegate as a verb and a noun, and I think the former is more relevant:

1: to entrust to another
// "delegate authority"
// "delegated the task to her assistant"

That's what we want to do. We don't want DefaultRoutine to implement any interfaces itself. Instead, we want to delegate those implementations to someone else. We'll pass them as parameters that we can substitute during testing, without creating another class. Let's see what that would look like, starting at the bottom of our class hierarchy.

// Removing default interface impl for clarity
interface Task {
    val scope: CoroutineScope
    suspend fun doSomething(taskName: String): Unit
}

interface Coffee: Task {
    fun makeCoffee()
    fun drinkCoffee()
}

class DefaultCoffee(private val task: Task): 
    Task by task,
    Coffee {
    fun makeCoffee() {
        print("Drip Drip")
        scope.launch {
            doSomething("making coffee")
        }
    }

    fun drinkCoffee() {
        print("Mmmmm...")
        scope.launch {
            doSomething("drinking coffee")
        }
    }
}

The Upside

What advantage does this have? Now we can more easily control DefaultCoffee's implementation, which comes in handy for testing. In production we'll use DefaultTask:

class DefaultTask: Task {
    override val scope: CoroutineScope
        get() = GlobalScope

    override suspend fun doSomething(taskName: String): Unit {
        scope.launch {
            // Some long network request
            delay(2000L)
            print("I am $taskName")
        }
    }
}

And we might have a Task implementation for testing:

class TestTask: Task {
    override val scope: CoroutineScope
        get() = TestScope()

    override suspend fun doSomething(taskName: String): Unit {
        scope.launch {
            print("I am $taskName")
        }
    }
}

We want to delegate the Task interface to some implementation, so DefaultCoffee doesn't need to implement it, or rely on default implementations. We'll do that using a Kotlin delegate. The delegate syntax uses the by keyword, to say, "I implement this Task interface by delegating it to some implementation."

To get there, we'll change Coffee a bit:

interface Coffee: Task {
    fun makeCoffee()
    fun drinkCoffee()
}

class DefaultCoffee(private val task: Task): 
    Task by task,
    Coffee {
    override fun makeCoffee() {
        print("Drip Drip")
        scope.launch {
            doSomething("making coffee")
        }
    }

    override fun drinkCoffee() {
        print("Mmmmm...")
        scope.launch {
            doSomething("drinking coffee")
        }
    }
}

Now this lets us test the DefaultCoffee class directly, by swapping out Task implementations:

val defaultTask = DefaultTask()
val testTask = TestTask()

val defaultCoffee = DefaultCoffee(defaultTask)
val testCoffee = DefaultCoffee(testTask)

No mocks or extending the actual class under test required!

Putting it all together

We can do the same thing with Breakfast:

interface Breakfast: Task {
    fun eatBreakfast()
}

class DefaultBreakfast(private val task: Task): Breakfast, Task by task {
    override fun eatBreakfast() {
        print("Om nom nom")
        scope.launch {
            doSomething("eating breakfast")
        }
    }
}

val defaultBreakfast = DefaultBreakfast(defaultTask)
val testBreakfast = DefaultBreakfast(testTask)

Now we can do the same thing with Morning:

interface Morning :
    Task,
    Coffee,
    Breakfast

class DefaultMorning(
    private val task: Task,
    private val coffee: Coffee,
    private val breakfast: Breakfast
) : Morning,
    Task by task,
    Coffee by coffee,
    Breakfast by breakfast {
    override val scope: CoroutineScope
        get() = task.scope

    override suspend fun doSomething(taskName: String) =
        task.doSomething(taskName)
}

In this way, we are composing DefaultMorning from several implementations of interfaces via delegates.

This is in contrast to:

Inheriting implementations via an abstract class
Relying on default implementations
Making DefaultMorning implement everything itself

Unlike 1, we don't need a deep class hierarchy. Unlike 2, we can test our class directly, and don't need to make the default implementation open. Unlike 3, DefaultMorning is terse.

Through this composition, we can still have an "is a" relationship that might be required by whatever API we're working with, but they can be implemented in a "has a" sort of way.

❓ Isn't this redundant?

You may reasonably ask, "Why do we need to override scope and doSomething() if they're already implemented by our delegate(s)?

If you omit them, IntelliJ will tell you something like:

Class 'DefaultMorning' must override public open suspend fun doSomething(taskName: String): Unit defined in com.mynamespace.DefaultMorning because it inherits many implementations of it

This is because the Task, Coffee, and Breakfast delegates all implement the Task interface, and the compiler doesn't know which one to use. (Even though we told it specifically which implementation we want (by defaultTask) to use). So we have to delegate those calls (more) explicitly.

⚠️ Don't hardcode delegates

If you don't pass delegates into the constructor, like this:

class DefaultCoffee(private val task: Task) :
    Task by task, Coffee { /*...*/ }

but hardcode them like this:

class DefaultCoffee() : 
    Task by DefaultTask(), Coffee { /*...*/ }

then you are tightly coupling that Task implementation to DefaultCoffee. Swapping out implementations will be difficult, defeating our major purpose of using delegates. You might need to do some mock gymnastics and/or override methods of the class under test with an object declaration 😫. Instead, treat yourself to a pleasurable testing experience, and practice constructor injection of your delegates 😄.

Conclusion

That's all I got for today! Delegates seemed strange when I first learned about them, but after struggling with testing things that heavily relied on inheritance and default interface implementations, I found delegates helped me test with ease. I hope it helps you as well.

If you have questions or comments, let me know in the comments below. You can also reach me on Twitter at @AielloBrady, or on the Kotlin Slack. And if you find this interesting, and might like to work with or work at Touchlab, we'd love to hear from you!

class Brady(val fingers: Typing): Typing by fingers

KoMPose Kit: KaMP Kit goes Jetpack Compose

Brady Aiello — Tue, 24 Aug 2021 16:38:22 +0000

KaMP Kit and Jetpack Compose

Hey folks, Brady from Touchlab here. I've only been at Touchlab since the beginning of the year, but KaMP Kit, our simple-but-not-too-simple sample project to help those considering Kotlin Multiplatform, started way back at the end of 2019. Back then, Jetpack Compose had just been announced in May. It was a time full of optimism about the modern mobile UI development experience, but also of wild instability. The first method of getting Jetpack Compose to work on your machine involved pulling down the AndroidX development toolchain, and running a special version of Android Studio via terminal commands. Eventually, preview, alpha, and beta version of Compose could be used in the canary version of Android Studio (more history). Starting July 28, 2021, Compose went stable, and a version of Android Studio Arctic Fox, which supports Compose, was released in the stable channel shortly thereafter. Now we can use a stable version of Compose with a stable version of Android Studio. We at Touchlab have been excited about Compose for a long time; you can watch us geek out about it here. And though the community has been interested in Compose for KaMP Kit since at least May 2020, we didn't want folks who are trying out Kotlin Multiplatform with KaMP Kit to also have to learn a changing Jetpack Compose API, and require them to use a special version of Android Studio. Now that these obstacles have been removed, we feel comfortable fully endorsing Jetpack Compose in KMM.

Cutting Code

After moving to Jetpack Compose, we were able to remove a lot of things that clutter the KMP learning experience. XML views are gone, which means developers don't need to worry about context switching between XML and Kotlin, findViewById(), or configure viewBinding or dataBinding. Removing the RecyclerView, its ViewHolder, and Adapter, and replacing it with a LazyColumn from Compose simplifies the sample considerably. Although we had to bring in Compose dependencies, @russhwolf noticed that by abandoning AppCompatActivity in favor of ComponentActivity, we were able to remove the large AppCompat library from our dependencies entirely.

Exposing a Flaw in our State Management

If you're now converting an app to use Jetpack Compose, you may have noticed that modeling your view state using a sealed class may not work as well as it used to in the View world. That's because Views implicitly kept state that we relied on. Compose made this more apparent, and forced us to stop relying on our UI for any state whatsoever.

For example, let's say we have Loading, Success, and Error states to describe our UI, and that we are currently showing the Success state to describe a list of items in our UI, while fetching more data. In the View world, we emit a Loading state, which just makes the loading spinner visible, in addition to the stale list, while fetching a fresh list. It just comes down to showing what we're already showing, and then making a loading spinner visible.

However, in the Compose world, we don't have all possible views on the screen, only toggling some as visible. Instead, we need to emit all of the UI we want to show whenever the State changes. In our example, when we emit the Loading state, the success UI with our list of data goes away, and only the loading spinner is visible. This is very jarring, and not a great user experience. This is because we're using a sealed class for something that's not mutually exclusive. Success and Loading are not mutually exclusive, unless Loading only describes an empty screen with a loading spinner. Ryan Harter has written about this issue, and Android GDE @ditn Adam Bennett told me that his team at Cuvva also had this discussion. Perhaps the simplest solution is to have a data class with nullable fields:

data class DataState<out T>(
    val data: T? = null,
    val exception: String? = null,
    val empty: Boolean = false,
    val loading: Boolean = false
)

This covers the only Loading, only Success, only Error, Loading and Success, and Loading and Error possibilities. It harkens back to the old Android architecture components samples' Resource<T> class.

Though, some argue that those State combinations should all be mutually exclusive sealed classes, which is also a great approach that avoids the nullability issues. If Loading is the only State that can coexist with other States, we can also just add a boolean field.

Whichever way you go, you should make sure not to model any of your UI state as mutually exclusive of others unless it actually is mutually exclusive of others.

Swipe To Refresh

Swipe-to-refresh functionality is an extremely common UI element, and as such, it is available on Android's legacy View system in SwipeRefreshLayout. The Compose equivalent isn't part of the core Compose UI, but there is a solid solution.

To get this same functionality in Compose without implementing swipe-to-refresh yourself, you'll want to use Accompanist-SwipeRefresh, which is a Google library, but isn't officially part of Jetpack. You'll also need to make sure that any content inside the SwipeRefresh Composable is scrollable. You may have to wrap some content in a Column with a verticalScroll modifier per the documentation. If you miss this step, you could emit a non-scrollable Error state, and be unable to swipe to refresh again.

Given its popularity, it seems a little strange that swipe-to-refresh isn't a core part of Compose. But this brings us to another way that Compose shines. Compose, and its 1st party associated libraries, are completely unbundled from the operating system. This means that Compose can run on any device running Android API 21 (Lollipop) and newer.

Transforming Flows

Compose uses a special observable type to know when to update UI. In Compose, this is the State<T> class. When State changes, all @Composable functions dependent on that State are reinvoked, and emit the corresponding UI. By exposing data as StateFlows from our KMM module, we can use the Flow extension function collectAsState() and clean it up even more with delegate syntax. We want to collect the Flow safely, avoiding collection when the view goes to the background, and restarting it when it comes back to the foreground. We'll use Manuel Vivo's post, "A safer way to collect flows from Android UIs" as a guide to create a lifecycle-aware Flow.

val lifecycleOwner = LocalLifecycleOwner.current
val lifecycleAwareDogsFlow = remember(
        viewModel.breedStateFlow, 
        lifecycleOwner
    ) {
    viewModel.breedStateFlow
        .flowWithLifecycle(lifecycleOwner.lifecycle)
}
val dogsState by lifecycleAwareDogsFlow
    .collectAsState(viewModel.breedStateFlow.value)

The delegate syntax is nice because we get best of State and its backing data. Our dogsState is actually not a State, so we don't need to put .value to get the value, but because it delegates its get()s to a State, @Composable functions that take it as a parameter are still invoked whenever its value changes.

Conclusion

Jetpack Compose has been an exciting project to follow, and it's clear that it has a bright future for reactive and declarative UI. Updating to Compose has simplified KaMP Kit, and exposed a flaw in our previous state management approach, forcing us to become better developers. Our goal with the KaMP Kit project is to give folks interested in Kotlin Multiplatform the easiest way to get started, and now that Compose is stable, it makes learning KMM easier than ever.

Google and Facebook Login on Android with Coroutines

Brady Aiello — Fri, 30 Jul 2021 18:07:57 +0000

Intro

I recently started using Google One Tap and Facebook login for some auth work for one of our clients at Touchlab, and wanted to make sure I was using the recommended best practices using coroutines and the new Activity Result API. This was trickier than I realized, because the docs for Google One Tap are out of date, and the API for Facebook login is out of date. So after figuring it out, I wanted to share some code snippets for my future self, and I hope you get something useful from it as well.

Additionally, I've found a use case that Google One Tap does not support, and a solution for getting around it, so to assure your users have an optimal sign-up and sign-in experience. Let's dive in!

Google One Tap

One Tap is a cool way to sign up or sign in a user to your app pretty seamlessly. On sign up, you authorize the app to continue, and if you've already authorized the app, you can just just choose an account, and continue on.
Sign Up:

Sign In:

Google's Sean McQuillan writes a great overview of the benefits of One Tap over the normal Google sign in API here. The One Tap docs are pretty complete, but they start getting out of date here. The demo code:

oneTapClient.beginSignIn(signInRequest)
    .addOnSuccessListener(this) { result ->
        try {
            startIntentSenderForResult(
                result.pendingIntent.intentSender, REQ_ONE_TAP,
                null, 0, 0, 0, null)
        } catch (e: IntentSender.SendIntentException) {
            Log.e(TAG, "Couldn't start One Tap UI: ${e.localizedMessage}")
        }
    }
    .addOnFailureListener(this) { e ->
        // No saved credentials found. Launch the One Tap sign-up flow, or
        // do nothing and continue presenting the signed-out UI.
        Log.d(TAG, e.localizedMessage)
    }

There are a couple issues here. We want to use coroutines, so we'll need to wrap the beginSignIn() call with suspendCancellableCoroutine{}. That's pretty straightforward. The second thing we notice is that the 7-parameter startIntentSenderForResult() method is deprecated. Instead, the new way is to call launch() on an instance of ActivityResultLauncher<IntentSenderRequest> , passing an instance of IntentSenderRequest as a parameter. It sounds complicated, but it's not bad. And the nice part is that, by tying the callback to the intent sender itself, we don't need to add unique result integers to determine who sent the intent.

That part will look something like:

val intentSender: ActivityResultLauncher<IntentSenderRequest> =
    registerForActivityResult(
        StartIntentSenderForResult()
    ) { activityResult ->
        val data = activityResult.data
        val credential: SignInCredential =
            oneTapClient.getSignInCredentialFromIntent(data)
        Log.d("Credential", credential.googleIdToken.toString())
        activity?.lifecycleScope?.launchWhenStarted {                  
            loginViewModel
                .loginToOurServerWithGoogle(
                    credential.googleIdToken.toString()
                )
        }
    }

NOTE: It's crucial that you call registerForActivityResult() when the Fragment or Activity is created. The app will crash if you register your callback any other time.

We've registered for the Activity Result, so now we need to actually launch the Intent. We'll start by calling beginSignIn(), and adding a success and failure callback.

oneTapClient.beginSignIn(signInRequest)
        .addOnSuccessListener(fragmentActivity) { result ->
            try {
                intentSender.launch(
                    IntentSenderRequest
                        .Builder(result.pendingIntent.intentSender)
                        .build()
                )
            } catch (e: IntentSender.SendIntentException) {
                Log.e(
                    "SignUp UI",
                    "Couldn't start One Tap UI: ${e.localizedMessage}"
                )
            }
        }
        .addOnFailureListener(fragmentActivity) { e ->
            // Maybe no Google Accounts found
            Log.d("SignUp UI", e.localizedMessage ?: "")
        }

And to coroutines-ify it, we'll wrap those callbacks in suspendCancellableCoroutine(). Also, instead of executing our callback right here, we'll just resume with the result, which we'll use later.

@ExperimentalCoroutinesApi
suspend fun beginSignInGoogleOneTap(
    fragmentActivity: FragmentActivity,
    oneTapClient: SignInClient,
    signInRequest: BeginSignInRequest,
    onCancel: () -> Unit
    ): BeginSignInResult =
    suspendCancellableCoroutine { continuation ->
        oneTapClient.beginSignIn(signInRequest)
            .addOnSuccessListener(fragmentActivity) { result ->
                continuation.resume(result) { throwable ->
                    Log.e("SignUp UI", "beginSignInGoogleOneTap: ", throwable)
                }
            }
            .addOnFailureListener(fragmentActivity) { e ->
                // No Google Accounts found. Just continue presenting the signed-out UI.
                continuation.resumeWithException(e)
            }
            .addOnCanceledListener {
                Log.d("SignUp UI", "beginSignInGoogleOneTap: cancelled")
                onCancel()
                continuation.cancel()
            }
    }

The full code isn't much more than that. Full gist:

Classic Google Sign-In

As awesome as Google One Tap is, there are a few uncovered use cases:

If the user is not logged in to any account on the Android device, it will fail.
If the user wants to sign up or sign in using an account that is currently not signed in on the Android device, it will fail.
If the user has cancelled the One Tap auth too many times, the user will be unable to start the One Tap auth flow for 24 hours.

To cover these common use cases, we can use the classic Google Sign-in API as a backup. This makes the auth flow more complex, but gives the user the most flexibility:

To get here, we'll do the same as before:

Call registerForActivityResult()
Launch an Intent

And then we'll integrate the legacy auth flow as a fallback if any of the use cases listed.

Call registerForActivityResult()

fun getLegacyGoogleActivitySignInResultLauncher(
    fragment: Fragment,
    fragmentActivity: FragmentActivity,
    onIdToken: (String) -> Unit
): ActivityResultLauncher<IntentSenderRequest> =
    fragment.registerForActivityResult(ActivityResultContracts.StartIntentSenderForResult()) { activityResult ->
        try {
            val token: String? = Identity.getSignInClient(fragmentActivity)
                .getSignInCredentialFromIntent(activityResult.data)?.googleIdToken
            if (token != null) {
                onIdToken(token)
                Log.d(TAG, "getLegacyGoogleActivitySignInResultLauncher: $token")
            }
        } catch (e: Exception) {
            Log.e(fragment::class.java.toString(), e.toString(), e)
        }
    }

Launch an Intent. Like One Tap, the classic Google Sign-In API returns a Task to which we attach callbacks. Like before, we'll wrap the callbacks with suspendCancellableCoroutine().

@ExperimentalCoroutinesApi
suspend fun beginSignInGoogleLegacy(
    fragmentActivity: FragmentActivity,
    clientId: String,
): PendingIntent =
    suspendCancellableCoroutine { continuation ->
        val request: GetSignInIntentRequest = GetSignInIntentRequest.builder()
            .setServerClientId(clientId)
            .build()

        Identity.getSignInClient(fragmentActivity)
            .getSignInIntent(request)
            .addOnSuccessListener { pendingIntent ->
                continuation.resume(pendingIntent) { throwable ->
                    Log.e(TAG, "beginSignInGoogleLegacy: ", throwable )
                }
            }
            .addOnFailureListener { exception ->
                Log.e(TAG, "beginSignInGoogleLegacy", exception)
                continuation.resumeWithException(exception)
            }
            .addOnCanceledListener {
                Log.d(TAG, "beginSignInGoogleLegacy: cancelled")
                continuation.cancel()
            }
    }

When you receive the PendingIntent, you can then use it to launch the Legacy Auth flow:

fragmentActivity.lifecycleScope.launchWhenStarted {
    val pendingIntent = beginSignInGoogleLegacy(
        fragmentActivity,
        clientId
    )
    val intentSenderRequest = IntentSenderRequest.Builder(pendingIntent.intentSender)
        .build()
    googleLegacyResultLauncher.launch(intentSenderRequest)
}

Using the Legacy Google Auth as Backup for One Tap

So, we can exit the One Tap flow in the following ways:

Case 1: The user isn't logged in to any account on the device

If this is the case, One Tap will throw an ApiException in a failureListener if you have one attached, with cause, Cannot find a matching credential. We can also confirm this at any time by grabbing the last token used and checking if it's null:
GoogleSignIn.getLastSignedInAccount(activity)?.idToken In this case, we'll need to use the Legacy Google Auth API.

Case 2: One Tap has been cancelled too many times.

If this happens, we won't be able to use One Tap for 24 hours and get an
ApiException with cause: Caller has been temporarily blacklisted due to too many canceled sign-in prompts. We can wrap this in a try/catch block, and seamlessly transition to the legacy Google auth API. When developing, I've found it helpful to get around the One Tap ban by wiping the emulator data and cold booting it.

Case 3: The user cancels One Tap manually.

This can be done by clicking the "Cancel" button when it starts loading, or by navigating back. This can be either because they don't wish to authenticate at all, or because they want to authenticate with an account that isn't listed. We don't know for sure, so we'll fall back to the Legacy Google Auth API in the case they want to authenticate with an account that hasn't been added to their Android device. If they don't want to authenticate at all, they can cancel this auth flow as well.

The full example:

https://gist.github.com/brady-aiello/dc00cf160214812c38ec64f94e820cfb

Facebook Login

Facebook auth still uses a callback-style approach, so we'll need to wrap the calls in suspendCancellableCoroutine{} as well. Unlike Google Auth, however, the Facebook Auth library has not updated to use registerForActivityResult{}. Instead, we'll need to use the deprecated way: overriding onActivityResult() in our Activity. You can follow the ticket here.

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    loginViewModel
        .callbackManager
        .onActivityResult(requestCode, resultCode, data)
    // onActivityResult() is deprecated, 
    // but Facebook hasn't added support for 
    // the new Activity Contracts API yet.
    // https://github.com/facebook/facebook-android-sdk/issues/875
    super.onActivityResult(requestCode, resultCode, data)
}

We're keeping the CallbackManager in a shared ViewModel so we can reuse the same one regardless of being in the LoginFragment or the CreateAccountFragment. Creating one is straightforward:

val callbackManager: CallbackManager = CallbackManager.Factory.create()

This all just passes along the result of launching Facebook's auth Activity so we can do something with the result. Let's make a coroutines-friendly way of getting the LoginResult.

@ExperimentalCoroutinesApi
suspend fun getFacebookToken(callbackManager: CallbackManager): LoginResult =
    suspendCancellableCoroutine { continuation ->
        LoginManager.getInstance()
            .registerCallback(callbackManager, object :
                FacebookCallback<LoginResult> {

                override fun onSuccess(loginResult: LoginResult) {
                    continuation.resume(loginResult){ }
                }

                override fun onCancel() {
                    // handling cancelled flow (probably don't need anything here)
                    continuation.cancel()
                }

                override fun onError(exception: FacebookException) {
                    // Facebook authorization error
                    continuation.resumeWithException(exception)
                }
            })
    }

And then we can pass the result along:

@ExperimentalCoroutinesApi
fun FragmentActivity.finishFacebookLoginToThirdParty(
    onCredential: suspend (LoginResult) -> Unit
    ) {
    this.lifecycleScope.launchWhenStarted {
        try {
            val loginResult: LoginResult = getFacebookToken(loginViewModel.callbackManager)
            onCredential(loginResult)
        } catch (e: FacebookException) {
            Log.e("Facebook Error", e.toString())
        }
    }
}

And we can tie it all together with the UI

@ExperimentalCoroutinesApi
private fun setupFacebookContinueButton() {
    fragmentLoginBinding?.buttonContinueFacebook?.setOnClickListener {
        activity?.let { fragmentActivity ->
            LoginManager.getInstance().logInWithReadPermissions(fragmentActivity, listOf("email"))
            fragmentActivity.finishFacebookLoginToThirdParty { loginResult ->
                loginViewModel.loginFacebook(loginResult.accessToken.token)
            }
        }
    }
}

Full Facebook auth:

Conclusion

To recap:

The Legacy Google API covers all use cases, but is a bit more obtrusive.
Google One Tap doesn't cover all use cases, but is less obtrusive.
Use the Legacy Google Auth API as a backup, either when the user wants to log in with a different account, or when the user isn't signed in to any Google account on the device.

That's all, folks. How are you handling auth? Are you sticking with Google's Legacy Auth to keep things simple? Just having Firebase handle it for you? Let us know in the comments. This is Brady, signing off and signing out.

Encrypted Key-Value Store in Kotlin Multiplatform

Brady Aiello — Mon, 07 Jun 2021 18:18:08 +0000

Intro

At some point you will probably need to store a user's auth token on the device, so they won't need to auth whenever they use your app. This is a solved problem on Android with EncryptedSharedPreferences and iOS with the Keychain Services API. But if you're creating a mobile app using Kotlin Multiplatform, the KMP solution might not be as clear. Today we'll go over how to store encrypted key-value data with KMP without having to reinvent the wheel.

Enter Multiplatform Settings

Multiplatform Settings is a solid multiplatform key-value store, created by Touchlab's own Russell Wolf, used extensively at Touchlab, as well as in Jetbrains' KMM Production Sample. There is a Settings interface that is implemented for Android, iOS, MacOS, and JVM platforms. At first glance, it doesn't look like Multiplatform Settings offers any encrypted storage. But thanks to the abstraction that Android has built into SharedPreferences and Multiplatform Settings' support for saving to the iOS keychain, our work is pretty easy.

KMP Encrypted Settings on Android

Let's first take a look at the default non-encrypted AndroidSettings implementation. Usually we'll use the builder, but the public constructor is really helpful here.

public class AndroidSettings @JvmOverloads public constructor(    
    private val delegate: SharedPreferences,
    private val commit : Boolean = false
) : ObservableSettings

EncryptedSharedPreferences implements the SharedPreferences interface. So all we need to do is create one, and initialize an instance of AndroidSettings with it:

AndroidSettings(EncryptedSharedPreferences.create(
    get(),
    "MyEncryptedSettings",
    MasterKey.Builder(get())
        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
        .build(),
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
), false)

Because the SharedPreferences delegate instance is a constructor argument rather than hardcoded, we can swap it out during testing, or if we want to provide an alternate implementation like we have here.

KMP Encrypted Settings on iOS

Multiplatform Settings already has an encrypted implementation of Settings in the form of KeychainSettings. It uses the iOS platform Security API(SecItemAdd(), SecItemDelete(), etc. We can use it thus:

KeychainSettings(
    service = "MyEncryptedSettings"
)

That was easy! It is marked with an @ExperimentalSettingsImplementation annotation, but I have been using it to build a client project that will soon be used by millions, and have not had any issues. If you do, please open an issue.

Providing the Right Implementation

If you plan on using both an unencrypted Settings and an encrypted Settings in shared code, you have a couple options. You can create a special wrapper class to disambiguate unencrypted and encrypted settings instances like this:

Otherwise, you will need use a named instance in your preferred dependency injection or service locator library. Here is an example using Koin, a multiplatform service locator:

Notice that the name of SharedSettingsHelper's constructor parameterencryptedSettings matches the name specified in our Koin setup; it must be exact for Koin to know which one you want. If you're using platform-specific DI / service locator solutions, they will also have options for providing named instances, like Dagger's support of the Javax @Named annotation.

Once you have it all working, you can inspect the encrypted data storage on Android, by going to Android Studio, opening Device File Explorer, and navigating data → data → (Your Package Name) → shared_prefs → (Your Encrypted Settings Name) and you may see something like this:

Sweet! The keys and values are encrypted! Now you can read and write encrypted key-value data from common Kotlin code, maximizing code sharing.

Conclusion

If you're using KMP, you don't need to create your own multiplatform encrypted settings solution. In fact, if you're already using Multiplatform Settings, you don't even need another multiplatform dependency. How are you doing encrypted key-value stores in Kotlin Multiplatform? Do you like this approach? Let me know in the comments, or Twitter. If you'd like to get into KMM and help steer its future, we're hiring!