DEV Community: Ryan Belz

Learning Kotlin Multiplatfom Mobile: Entry 3.5

Ryan Belz — Tue, 30 Aug 2022 01:47:02 +0000

This is a continuation of the last post Learning KMM: Entry 3.

Instead of installment 4, I went ahead and used my big developer brain and incremented this version number to 3.5 because it does not truly feel like a version 4.

📝 Intro

In the last post we went over the Model and Intent part of MVI. In this post we are going to be going over the View part.

In the previous posts in this series I had already made two basic login screens using both Jetpack Compose and SwiftUI here.

This post is mainly going to be about using MVI Kotlin in tandem with Decompose to create components that I can wire up to my views.

🎶 Decompose

So what exactly is Decompose and why do I need to use it? Well you don't exactly need to use Decompose to use the created stores in MVI Kotlin if you are using a declarative UI like Jetpack Compose and SwiftUI. However, Decompose makes it easier to create life-cycle aware components (which is super helpful on android) and comes with a multi-platform router for navigation.

Because of this you are able to now share even more code between apps (navigation logic) and you have a better separation of concerns between UI and non-UI code.

Feel free to read more on the overview of Decompose here.

🌳 The Root Component

Each view is going to wire up to a component but all components need to descend from a parent component. The beginning component is going to be the component for the entire application which will be referred to as the "Root" component.

The root component is also where the shared router navigation is going to live. Inside the root component you can find configurations for children components as well as the current router state of the application.

Im going to gloss over a bit of the implementation details of the root component to keep the focus on the Login view. I will probably revisit this later when talking about navigation within the application.

🤖 Login Component

Once the scaffolding of the root component is set up we can continue to wire up our Login View to the Login Store.

Since we will define the initial component of the Root component as the Login Component, we will automatically be directed to this Login View once the application loads.

Android

@OptIn(com.arkivanov.decompose.ExperimentalDecomposeApi::class)
@Composable
fun RootContent(component: Root) {
    Children(routerState = component.routerState) {
        when (val child = it.instance) {
            is Root.Child.Login -> LoginScreen(child.component)
        }
    }
}

iOS

struct RootView: View {
    @ObservedObject
        private var routerStates: ObservableValue<RouterState<AnyObject, RootChild>>

    init(_ component: Root) {
        self.routerStates = ObservableValue(component.routerState)
    }

    var body: some View {
        let child = self.routerStates.value.activeChild.instance

        switch child {

            case let login as RootChild.Login:
                LoginView(login.component)

            default: EmptyView()
        }
    }
}

In both of these logic blocks you can see we are switching the specific type of "Child" configuration to the LoginView or LoginScreen and passing the child component which is our "LoginComponent".

You can see this login component here

class LoginComponent(
    componentContext: ComponentContext,
    storeFactory: StoreFactory
) : Login, ComponentContext by componentContext {

    private val store = instanceKeeper.getStore {
        loginStore(storeFactory)
    }

    override val models: Value<Login.Model> = store.asValue().map(stateToModel)

    override fun onLogin() =
        store.accept(Intent.Login(models.value.username, models.value.password))

    override fun onPasswordChanged(password: String) =
        store.accept(Intent.UpdatePassword(password))

    override fun onUsernameChanged(username: String) =
        store.accept(Intent.UpdateUsername(username))
}

Essentially what this class is doing is forwarding the actions invoked by the view onto the Login Store from the previous post. The model of the Login Store is also being exposed in a way that can be consumed in both Jetpack Compose and SwiftUI.

🎶 Compose Code

Consuming the store is very straight forward using Jetpack Compose and looks like the following.

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun LoginScreen(component: Login)
{
    val state by component.models.subscribeAsState()

    // omitting some code for brevity
    ...

    OutlinedTextField(
        value = state.username,
        onValueChange = component::onUsernameChanged
    )
}

🐣 SwiftUI Code

Consuming the store in SwiftUI is a little more complex than android. It involves some creating of quite a lot of extension code to wrap the observable value, component router state, and exposing the library values from MVI Kotlin and Essenty that we accomplished using gradle in part one of this blog post. Once all of the helper extensions are set up you are left with something like this:

struct LoginView: View {
    private var component: Login

    @ObservedObject
    private var models: ObservableValue<LoginModel>

    @State private var isSecured: Bool = true

    init(_ component: Login) {
        self.component = component
        self.models = ObservableValue(component.models)
    }


    var body: some View {
        let model = models.value

        let usernameBinding = Binding(get: { model.username }, set: component.onUsernameChanged)
        let passwordBinding = Binding(get: { model.password }, set: component.onPasswordChanged)

        // omitting some code for brevity
        ...

        TextField("Username", text: usernameBinding)
        Button("Login", action: component.onLogin)
}

🧪 Testing with Napier

Since the action of logging in is not yet wired up yet I figured I would take this time to research a multi-platform logging solution that I could use to at least verify the login action was working as intended.

After some research I stumbled upon Napier and it was very easy to setup.

After following the documentation and setting up the initialization calls I added logging to the login button function.

private fun logIn(username: String, password:String) : String {
    // Authenticate the user
    // this is probably going to take a while
    // this will also return a auth token
    Napier.i("called log in $username, $password")
    return "AuthToken"
}

After running the android app and fake logging in you can see the following in the logs:

2022-08-29 21:31:02.520  5005-5005  LoginStoreKt$logIn      com.belzsoftware.voix.android        I  called log in test@test.com, test123
2022-08-29 21:31:35.669  5005-5005  LoginStoreKt$logIn      com.belzsoftware.voix.android        I  called log in yhskhkjsdf, yolo7383

And after running the iOS app:

08-09 20:58:28.603 💙 INFO logIn.internal + 619 - called log in Dsfsdfsdfsd, sdfsdfsdf
08-09 20:58:28.765 💙 INFO logIn.internal + 619 - called log in Dsfsdfsdfsd, sdfsdfsdf
08-09 20:58:29.503 💙 INFO logIn.internal + 619 - called log in Dsfsdfsdfsd, sdfsdfsdf
08-09 20:58:36.427 💙 INFO logIn.internal + 619 - called log in Dsfsdfsdfsd, sdfsdfsdf
08-09 20:58:42.497 💙 INFO logIn.internal + 619 - called log in Dsfsdfsdfsd, sdfsdfsdfs
08-09 20:58:48.164 💙 INFO logIn.internal + 619 - called log in Dsfsdfsdfsd, test@test.com
08-09 20:59:04.594 💙 INFO logIn.internal + 619 - called log in Dsfsdfsdfsd, test@test.com

⌛️ Closing

The second part of this post was a little speedy so I suggest taking a further look into the repo. I figured out most of how to set this up by looking at the sample GitHub repos listed on the decompose example page.

In the next part of the series I am going to try to get Firebase authentication hooked up to the login view so we can actually get some integration going and not some basic logging.

I will probably be taking a little break from this project but will be returning eventually as I still want to keep my self-promise of not letting this die off until I feel accomplished.

Learning KMM: Entry 3

Ryan Belz — Fri, 12 Aug 2022 23:36:58 +0000

So like I mentioned in Learning KMM: Entry 1...

to force myself to not drop this project I am going to attempt to write my experiences while learning using Kotlin Multiplatform Mobile.

I have not forgotten about this, just have been a little ~~lazy~~ busy 😅.

🥱 Just a forewarning this is going to be a bit of a longer read than the first two entries and I will be breaking it into two parts.

⌛️ TLDR: check out the repository and read the docs on MVI Kotlin and decompose here.

📸 Overview

So to get started, this entry is going to be all about creating reusable components and classes that contain business logic for logging into my barebone views.

To do this I utilized the following Kotlin packages

Now MVI architecture is very new to me and I might explain this a bit like an idiot, but nevertheless I will try my best.

⚔️ MVI vs MVVM

MVI stands for Model-View-Intent and is a:

architectural pattern that utilizes unidirectional data flow

Meaning that the data only flows in one direction from the model to the view and vice versa. This flow helps maintain a single source of truth and usually contains a single immutable state of the entire view. It, quite like MVVM, usually allows for the model to know nothing about the view.

MVVM stands for Model-View-ViewModel and is:

structured to separate program logic and user interface controls

MVVM is something that I am more familiar with. This pattern usually does not entail having the entire immutable view state inside of a component but, just like stated before, the view model is completely unaware of the view.

I know from brief reading that some prefer MVVM to MVI as it is less components and classes and easier to get "up and running" to hook views up to business logic components or view models.

Also from brief research, it seem that there are two popular packages/libraries that are commonly used for both MVI and MVVM in Kotlin multi-platfom mobile projects.

MVI Kotlin by arkivanov
moko mvvm by icerock development

I am going with MVI Kotlin purely on the fact that I know nothing about it so it will be a bigger learning experience.

🏗 Setup

So there are a few essential packages to add to your shared gradle file definition to get started.

listOf(
    iosX64(),
    iosArm64(),
    iosSimulatorArm64()
).forEach {
    it.binaries.framework {
        baseName = "Shared"
        export("com.arkivanov.decompose:decompose:0.6.0")
        export("com.arkivanov.essenty:lifecycle:0.4.1")
        export("com.arkivanov.mvikotlin:mvikotlin-main:3.0.0-beta02")
    }
}

commonMain {
    dependencies {
        implementation("com.arkivanov.mvikotlin:mvikotlin:3.0.0-beta02")
        implementation("com.arkivanov.mvikotlin:rx:3.0.0-beta02")
        implementation("com.arkivanov.mvikotlin:mvikotlin-main:3.0.0-beta02")
        implementation("com.arkivanov.mvikotlin:mvikotlin-extensions-coroutines:3.0.0-beta02")
        implementation("com.arkivanov.decompose:decompose:0.6.0")
        implementation("com.arkivanov.essenty:lifecycle:0.4.1")
        implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.2")
        implementation("io.github.aakira:napier:2.6.1")
    }
}

named("iosMain") {
    dependencies {
        api("com.arkivanov.mvikotlin:mvikotlin:3.0.0-beta02")
        api("com.arkivanov.mvikotlin:rx:3.0.0-beta02")
        api("com.arkivanov.mvikotlin:mvikotlin-main:3.0.0-beta02")
        api("com.arkivanov.mvikotlin:mvikotlin-extensions-coroutines:3.0.0-beta02")
        api("com.arkivanov.decompose:decompose:0.6.0")
        api("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.2")
        api("com.arkivanov.essenty:lifecycle:0.4.1")
        api("io.github.aakira:napier:2.6.1")
    }
}

There are some pretty specific things going on here that need to be pointed out that I ran into. First, you need to make sure the iOS dependencies are marked as "api" instead of "implementation" and to be totally honest with you I do not know why 😅. Second, it is important to make sure you export these three libraries to your shared iOS framework so that you can them in your Swift code. In the Android project you can get away with adding these dependencies straight to the gradle file. Once you have all this set up you should be ready to roll 🎲.

🎨 Model creation

The first part of MVI is the model, you can't have MVI without the model!

In this case the model is actually really simple for just a two input login screen.

data class Model(
    val username: String,
    val password: String
)

🏪 The Store

The store is where the business logic is going to go and will accept all "intents" and "messages" and output all "labels" and "state".

With the MVI Kotlin package you can choose either the Reaktive or Coroutine extensions and create a store pretty. I picked Coroutines out of personal preference and experience.

First for our store we need to define our State.

internal data class State(
    val username: String = "",
    val password: String = ""
)

The "Intents" of the store need to be defined. I like to think of "Intents" as actions that "Intend to change the state". In this case there is three.

One to update the username
One to update the password
One update to attempt to login

internal sealed interface Intent {
    data class UpdateUsername(val username: String): Intent
    data class UpdatePassword(val password: String): Intent
    data class Login(val username: String, val password: String): Intent
}

Now when an "Intent" gets sent to the store it is executed by the "Executer" which you will see shortly. When the "Intent" is executed it outputs a "Message". This "Message" contains whatever has happened as a result of the "Intent" executing. The output, or "Message", is then sent to a "Reducer" which reduces the state using the "Message". Now this sounds very confusing but it makes a little bit of sense once you see the implementation.

First the "Store" in all its glory ⭐️

@OptIn(ExperimentalMviKotlinApi::class)
internal fun loginStore(storeFactory: StoreFactory) : Store<Intent, State, Nothing> =
    storeFactory.create<Intent, Nothing, Msg, State, Nothing>(
        name = "LoginStore",
        initialState = State(),
        executorFactory = coroutineExecutorFactory {
            onIntent<Intent.Login> { intent ->
                val token = logIn(intent.username, intent.password)
                dispatch(Msg.LoggedIn(token))
            }
            onIntent<Intent.UpdateUsername> { dispatch(Msg.UpdateUsername(it.username)) }
            onIntent<Intent.UpdatePassword> { dispatch(Msg.UpdatePassword(it.password)) }
        },
        reducer = { msg ->
            when (msg) {
                is Msg.LoggedIn -> copy()
                is Msg.UpdatePassword -> copy(password = msg.password)
                is Msg.UpdateUsername -> copy(username = msg.username)
            }
        }
    )

private fun logIn(username: String, password:String) : String {
    // Authenticate the user
    // this is probably going to take a while
    // this will also return a auth token
    Napier.i("called log in $username, $password")
    return "AuthToken"
}

And now the "Messages" 📨

private sealed interface Msg {
    class UpdateUsername(val username: String): Msg
    class UpdatePassword(val password: String): Msg
    class LoggedIn(authToken: String) : Msg
}

Final Breakdown:
Maybe an easier way to explain is just walking through someone attempting to log in.

The user loads up the login screen with the default state of a new Login data class (Empty string username and password).
The user types a username and every keystroke sends a "Intent" to the executor.
Since there is no logic when changing the username we immediately dispatch a "Message" containing the most recent username string.
The "Reducer" picks up the new username and COPIES (emphasis copies) the entire state object with the new username.
The same steps (2-4) is done with the password.
Once the user has both entered a username and password they might tap a button to log in.
In the executor for "log in" you can see us simulate some type of business logic hitting an Auth mechanism to validate the username and password and return a "Auth token".
Once the token is returned we dispatch a message containing the token which could then be either copied into the state or hopefully in the future saved locally.

Since we actually have not wired up our auth (going to use Firebase Auth in an upcoming post hopefully 🤞) I added some logging to just double check what was being sent to the log in function.

Hopefully this explanation makes a bit of sense to you 🙂.

And here is where I am going to break into part two (technically part 4) of the series to talk about how to wire up the Login Store to the View.

Stay tuned for part 4 and as always you can review all code here in the Voix GitHub repository.

Learning KMM: Entry 2

Ryan Belz — Wed, 15 Jun 2022 00:11:35 +0000

My second go at learning some more about Kotlin Multiplatform is really not so much going to be about KMM. This post will be about using Jetpack Compose and SwiftUI to create a simple login view that I can later hook up to some shared Kotlin business logic. So let us get into it again 😎.

Jetpack Compose (Android) 🤖

I would say I am more familiar with how to create android applications so this won't be too uncomfortable for me. I have, however, very minimal experience using Jetpack Compose to create any sort of UI so there might be a bit of a learning curve.

I started off by adding the necessary package implementations in my android project gradle file to support.

🚀 Jetpack Compose (with activity support)
🎨 Material3
🎼 Accompanist package (to help color the app/navigation bars)
🖼 Material Icons

dependencies {
    implementation(project(":shared"))
    implementation("androidx.appcompat:appcompat:1.4.2")
    implementation("androidx.compose.ui:ui:1.2.0-beta03")
    implementation("androidx.compose.runtime:runtime:1.2.0-beta03")
    implementation("com.google.accompanist:accompanist-systemuicontroller:0.17.0")

    // Tooling support (Previews, etc.)
    implementation("androidx.compose.ui:ui-tooling:1.2.0-beta03")

    // Foundation (Border, Background, Box, Image, Scroll, shapes, animations, etc.)
    implementation("androidx.compose.foundation:foundation:1.2.0-beta03")

    // Material Design 3
    implementation("androidx.compose.material3:material3:1.0.0-alpha13")
    implementation("androidx.compose.material3:material3-window-size-class:1.0.0-alpha13")

    // Material design icons
    implementation("androidx.compose.material:material-icons-extended:1.2.0-beta03")

    // Integration with activities
    implementation("androidx.activity:activity-compose:1.4.0")
}

After setting up the gradle file I worked on the colors/theming files needed for Material3. I made use of the handy material theme generator to generate color and theme kotlin files. After exporting the files I ended up with a composable theme to use at the root main activity.

@Composable
fun AppTheme(
    useDarkTheme: Boolean = isSystemInDarkTheme(),
    content: @Composable () -> Unit
) {

    val colors = if (!useDarkTheme) {
        LightColors
    } else {
        DarkColors
    }

    val systemUiController = rememberSystemUiController()
    systemUiController.setSystemBarsColor(colors.primary)

    MaterialTheme(
        colorScheme = colors,
        typography = AppTypography,
        content = content
    )
}

Now getting to work on the actual login screen was pretty straight forward. I created a new file to declare my view code. I went with just two outlined inputs and one button, not going too crazy with the styling. This is how my screen turned out.

The styling is cookie cutter since most of it is out of the box Material3. The trickiest part about this view was the view password button but this was solved pretty easy though with some google-fu:

var password by rememberSaveable { mutableStateOf("") }
var passwordVisible by rememberSaveable { mutableStateOf(false) }

....

OutlinedTextField(
    value = password,
    modifier = Modifier
        .fillMaxWidth()
        .padding(10.dp, 5.dp),
    onValueChange = { password = it },
    label = {
        Text(text = "Password")
    },
    leadingIcon = {
        Icon(Icons.TwoTone.Password, contentDescription = "Password input icon")
    },
    keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Password),
    visualTransformation = if(passwordVisible) VisualTransformation.None else PasswordVisualTransformation(),
    trailingIcon = {
        val icon = if(passwordVisible) Icons.TwoTone.Visibility else Icons.TwoTone.VisibilityOff
        val description = if (passwordVisible) "Hide password" else "Show password"

        IconButton(onClick = { passwordVisible = !passwordVisible }) {
            Icon(icon, contentDescription = description)
        }
    }
)

Overall I think this is a very nice looking very simple login screen. I enjoyed the experience creating UI code and not using XML android layouts. The preview functionality was also very quick and saved me from reloading the app a ton. Now onto iOS...

SwiftUI (iOS) 🍎

As mentioned previously, I have very little experience with native iOS development let alone SwiftUI. So I went with a more straight forward approach to the login page and did not use any third party dependencies for styling or theming.

For simple color styling I found a very helpful article which explained how to utilize light/dark colors.

I created a Colors.xcassets file and used the color codes from the material 3 theme generator above to plug in here ending up with the following result. I didn't get too crazy with it 😆.

After I had the colors I created a new SwiftUI file and got to work on the login view. Some specific styling I needed to apply was:

Outlined text fields
Icons in the text fields
Password view button
Capsule like primary button

To get an icon on the left of the text field was easy. I put an Icon and a Textfield in an HStack 😅. To get the rounded outline I had to apply an overlay to the HStack and ended up with something like this.

HStack {
    Image(systemName: "person")
    TextField("Username", text: $username)
}
.padding(10)
.overlay(RoundedRectangle(cornerRadius: 10)
   .strokeBorder(Color("Primary"), style: StrokeStyle(lineWidth: 1.0)))

For the primary button I had to clip the button shape and they even have a preset style for Capsule clip shapes.

Button("Login", action: {})
                .frame(minWidth: 0, maxWidth: .infinity)
                .padding(10)
                .foregroundColor(.white)
                .background(Color("Primary"))
                .clipShape(Capsule())

In both code snippets you can see me making use of the Color("Primary") from the color asset catalog file from earlier.

Now onto the hardest part, the view password button. This was very similar to the Jetpack Compose example. All we needed was to keep track of the toggled state and show and hide UI elements based on the state.

@State private var password: String = ""
@State private var isSecured: Bool = true

....

HStack {
    Image(systemName: "lock")
    if isSecured {
        SecureField("Password", text: $password)
    } else {
        TextField("Password", text: $password)
    }
    Button(action: { isSecured.toggle() }) {
        Image(systemName: self.isSecured ? "eye.slash" : "eye").foregroundColor(.black)
    }
}
.padding(10)
.overlay(RoundedRectangle(cornerRadius: 10)
    .strokeBorder(Color("Primary"), style: StrokeStyle(lineWidth: 1.0)))

At the end of the day this is the screen that I ended up with.

The inputs are not as nice looking as android, but i'm sure if more time was spent we could figure out something a bit more fancy. I think I achieved the goal though so I will leave it for now.

Overall thoughts 🤔

Comparing this experience to Xamarin I would say it just feels right and let me explain my opinion a bit more.

Compose and SwiftUI declarative UI feels more intuitive than XAML
The preview functionality was a way smoother experience than "Hot Reload", I had zero problems previewing either screens
I could easily add functionality like a trailing password view button that in XAML usually ends up with either a custom view or custom renderer. Just a ton more code to implement 🫤.
Lastly, you just get the feeling that you have all the tools in the toolbox when working natively as opposed to XAML.

Now obviously this was a very simple page and I could run into more issues later on but I am pretty happy with the experience so far.

Next part I will attempt to wire up some business logic using MVI Kotlin and Decompose multi-platform libraries. I've usually used MVVM architecture but MVI looks interesting and this project is really all about learning things I don't really know all that well.

As always you can find the full code here on my github 🧑‍💻

Learning Kotlin Multiplatform Mobile: Entry 1

Ryan Belz — Wed, 01 Jun 2022 23:15:17 +0000

So.... to force myself to not drop this project I am going to attempt to write my experiences while learning using Kotlin Multiplatform Mobile. My GitHub page is starting to become the place where ideas go to die 🫠.

Disclaimer, this is my first ever attempt at documenting really anything but lets get into it.

My interest for KMM has stemmed from working with Xamarin Forms. The code sharing is amazing and I absolutely love C# but if you need to add any frills or flair to your UI, well, you better buckle up and start creating those custom renderers 🚧.

Things that interested me about KMM:

1. Code sharing so you only have to write core code once.

2. Ability to use native cutting edge tech like Jetpack Compose and SwiftUI

3. You can quickly write native code if you need to get the job done. (Kotlin, Swift)

🎉 Here is my experience from 0 to setting up a new project:
TLDR: 8/10 experience. One minor issue while trying to run the iOS App which was quickly fixed searching stack overflow.
I pretty much followed the "Getting started" guide found here word for word.

Step 1: 💻 Setting up my environment

Straight forward enough here, I had already had android studio installed (Electric Eel canary build) on my machine with the Kotlin plugins/language pretty much up to date.
I, however, had to install the Kotlin Multiplatform plugin for android studio.

Step 2: 📦 Creating the Project

After installing the KMM plugin for android studio I followed the prompts to create a new KMM app and had it created and loaded in a quick minute.

Step 3: 🤖 Running the Android app

Easy as can be, waited for the Gradle sync and build to complete and just hit run in the upper right hand corner!

Step 4: 🍎 Running the iOS App

Now this one was a bit of a pain... When I first switched the configuration to "iosApp" I noticed a red X mark on the picture. After trying to run the app I was shown this error.

I had to do some googling but this stack overflow post
here helped to solve the issue.
I closed Android studio and ran the following in my terminal and after that my simulator ran just fine.

cd ~/Library/LaunchAgents/
rm com.jetbrains.AppCode.BridgeService.plist

🎬 Final thoughts:
All in all it was a pretty straight forward experience with iOS being the problem child like it usually is. It is probably less buggy to run the iOS app directly from Xcode but the fix was not too bad. After the fix I was up and running exploring the project structure and generated code.

Next time I would like to see if I can get something small to work like creating a shared view model. My ultimate goals for the project is to get Firebase Authentication working for both apps and get the app communicating to a Ktor Kotlin backend api for sending and receiving chat messages.

Thanks for reading 👋 and hopefully this does not join the project graveyard anytime soon 🪦.