This is a blog of an ongoing series on my journey with Kotlin Multiplatform.

• Going Modular — The Kotlin Multiplatform Way
• KMM Preferences Datastore
• KMP Environment Variables (Part 1)
• Intercepting Ktor Network Responses in Kotlin Multiplatform
• Navigating the Waters of Kotlin Multiplatform: Exploring Navigation Solutions
• Enhancing iOS UI Previews: Swift UI Packages & Kotlin Multiplatform Mobile.
• Integrate Kotlin-Inject-Anvil To Tv Maniac
• Simplifying KMP Test Infrastructure with kotlin-inject-anvil— You are here. 👈

The complete implementation is available in the TvManiac. Let’s jump right in.

The Problem: Manual Test Doubles

Previously, our tests looked like this. This was a big object and I had to change it every time I added a new feature/dependencies to the project.

class DefaultRootComponentTest {
    @Test
    fun `initial state should be Home`() = runTest {
        val testComponent = TestComponent::class.create()
        val rootComponent = DefaultRootPresenter(
            componentContext = componentContext,
            rootNavigator = FakeDefaultRootNavigator(),
            discoverFactory = FakeDiscoverPresenterFactory(),
            homeFactory = FakeHomePresenterFactory(
                traktAuthRepository = FakeTraktAuthRepository()
            ),
            // ... more fake factories
        )

        // Test implementation
    }
}

RootComponentTest required manually creating fake presenter factories, leading to:

• Boilerplate code duplication across tests.
• Maintenance overhead when adding new dependencies.

The Solution: Test Components with DI

The goal was simple: leverage kotlin-inject-anvil to create test components that automatically provide all required dependencies, just like our production code.

Note: This pattern is not used across the entire project. I am using this in the rootComponent as this requires quite some dependencies and the graph is a bit complex. Other unit tests use the fakes directly and there’s no need for the test component. This solution is for complex objects. In this case, the App’s root component.

Step 1: Creating the Test Scope

First, I defined a dedicated scope for test dependencies. It’s a simple interface and acts as a marker for the DI processor and does not affect the production components.

interface TestScope

Step 2: Test Modules for Dependencies

To provide test implementations, I created TestDataModule that adds all the required dependencies. We use fakes in the case and not the actual implementation. With the use of dependency inversion, we can easily create fake implementations.

@ContributesTo(TestScope::class)
interface TestDataModule {
    @Provides
    @SingleIn(TestScope::class)
    fun provideDatastoreRepository(): DatastoreRepository = FakeDatastoreRepository()

    @Provides
    @SingleIn(TestScope::class)
    fun provideTraktAuthManager(): TraktAuthManager = FakeTraktAuthRepository()
}

Step 3: Platform-Specific Test Components

I then created platform-specific test components instead of trying to share them in commonMain. Since we are using DI, anvil will generate the specific component for each platform. We need to extend the platform component in our test since this will have all the bindings with everything stitched together. So we need to do structure our tests to follow this structure.

Note: That generated type is named after our component with the Merged suffix: TestJvmComponentMerged.

@Component
@SingleIn(TestScope::class)
@MergeComponent(TestScope::class)
abstract class TestJvmComponent : TestJvmComponentMerged {
    abstract val datastoreRepository: DatastoreRepository
    abstract val traktAuthManager: TraktAuthManager
    abstract val rootPresenterFactory: DefaultRootPresenter.Factory
    abstract val homePresenterFactory: DefaultHomePresenter.Factory
}

The iOS component follows the same pattern:

@Component
@SingleIn(TestScope::class)
@MergeComponent(TestScope::class)
abstract class TestIosComponent : TestIosComponentMerged {
    abstract val datastoreRepository: DatastoreRepository
    abstract val traktAuthManager: TraktAuthManager
    abstract val rootPresenterFactory: DefaultRootPresenter.Factory
    abstract val homePresenterFactory: DefaultHomePresenter.Factory
}

Step 4: Refactoring Tests

The real magic happens in the test refactoring. I transformed tests to use an abstract class pattern that separates shared test logic from platform-specific DI setup. The platform spefict test simply initialize the objects and all the tests reside in `commonMain`. Each platform then initialized it’s component.

• Jvm -> TestJvmComponent
• iOS -> TestIosComponent

commonMain

abstract class DefaultRootComponentTest {
    abstract val rootPresenterFactory: DefaultRootPresenter.Factory
    abstract val datastoreRepository: DatastoreRepository

    @Test
    fun `initial state should be Home`() = runTest {
        val rootComponent = rootPresenterFactory.create(componentContext)

        turbineScope {
            rootComponent.stack.test {
                val config = awaitItem().active.configuration
                assertThat(config).isInstanceOf(Config.Home::class)
            }
        }
    }
}

Provide Platform-specific implementations:

jvmTest

internal class DefaultRootComponentJvmTest : DefaultRootComponentTest() {
    private val testComponent: TestJvmComponent = TestJvmComponent::class.create()

    override val rootPresenterFactory: DefaultRootPresenter.Factory
        get() = testComponent.rootPresenterFactory

    override val datastoreRepository: DatastoreRepository
        get() = testComponent.datastoreRepository
}

iOSTest

internal class DefaultRootComponentJvmTest : DefaultRootComponentTest() {
    private val testComponent: TestIosComponent = TestIosComponent.create()

    override val rootPresenterFactory: DefaultRootPresenter.Factory
        get() = testComponent.rootPresenterFactory

    override val datastoreRepository: DatastoreRepository
        get() = testComponent.datastoreRepository
}

This allows us to easily scale our tests. Say we add support for desktop app, we only need to add the DesktopComponent and leverage the existing tests.

Key Learnings

1. Dependency Inversion & Tests

The project uses Dependency Inversion pattern and this makes testing effective. This allows us to decouple dependencies and test them in isolation. We also use Fakes in the projects and no mocks. With the use of dependency inversion, we can avoid using mocks in the project. Below are some good articles that talk more about this.

• Fakes Are Great, But Mocks I Hate
• Replacing Mocks
• Test Doubles
• Use test doubles in Android

2. Platform-Specific Test Components

Initially, I tried placing TestComponent in commonMain, but this doesn’t work with kotlin-inject’s code generation. Each platform needs its own component to properly generate the dependency graph.

3. Useful for Complex Objects

As much as this seems like overkill for this project, this demonstrates how this can be done in bigger projects. This also allows us to easily add new dependencies without touching the tests

What’s Next?

This test infrastructure sets the foundation for more robust testing patterns. Future improvements could include:

• Adding integration test components with real implementations.
• Exploring shared test components for cross-platform integration tests.
• Maybe splitting the RootComponent to smaller components.

Until we meet again, folks. Happy coding! ✌️

Intro

If you’ve used Anvil before, you know it takes away a lot of the boilerplate code and makes DI seamless. If Anvil is new to you, it basically allows you to contribute dagger modules and component interfaces to your DI graph, merge all the contributions, and add them to your component during compilation. Ralf Wonderatschek and Gabriel Peal gave an in-depth talk about this. Dagger + Anvil: Learning to Love Dependency Injection. You should check it out.

I have been using kotlin-inject on my pet project for a while now, and I have had a good time with it, coming from using Dagger in other projects. One thing I missed was using Anvil. This was not available until recently, when kotlin-inject-anvil joined the chat.

This is a blog of an ongoing series on my journey with Kotlin Multiplatform. This article will focus on my experience and journey integrating/migrating to kotlin-inject-anvil into the project.

• Going Modular — The Kotlin Multiplatform Way
• KMM Preferences Datastore
• KMP Environment Variables (Part 1)
• Intercepting Ktor Network Responses in Kotlin Multiplatform
• Navigating the Waters of Kotlin Multiplatform: Exploring Navigation Solutions
• Enhancing iOS UI Previews: Swift UI Packages & Kotlin Multiplatform Mobile.
• Integrate Kotlin-Inject-Anvil To Tv Maniac — You are here. 👈

If you want to see the code, here’s the pull request.

Koltlin-Inject-Anvil Integration

Before integrating kotlin-inject-anvil, one thing that bothered me was how to approach the integration/migration. I thought the process would be a pain as I already have multiple modules in my project. Do I rip the bandaid off and do it all at once? Is it possible to do it gradually? Spoiler alert: it is possible to do it gradually. This approach might not work for your project, depending on the size of the team. There are multiple ways of doing this, but this worked for me. This approach made it easier to determine if I broke the current implementation or introduced new errors.

Here’s a quick overview of how I approached the migration.

• Add dependencies
• Apply@ContributesTo annotation
• Apply @ContributesBinding annotation
• Add ksp kotlin-inject-anvil compiler dependencies.
• Delete component interfaces.
• Replace @Component with @MergeComponent and create a subcomponent.

Let’s take a quick look at how each step is implemented.

Add kotin-inject-anvil Dependencies.

This is pretty straightforward. We need to add the dependencies to our project.

kotlinInject-anvil-compiler = { group = "software.amazon.lastmile.kotlin.inject.anvil", name = "compiler", version.ref = "kotlin-inject-anvil" }
kotlinInject-anvil-runtime = { group = "software.amazon.lastmile.kotlin.inject.anvil", name = "runtime", version.ref = "kotlin-inject-anvil" }
kotlinInject-anvil-runtime-optional = { group = "software.amazon.lastmile.kotlin.inject.anvil", name = "runtime-optional", version.ref = "kotlin-inject-anvil" }

kotlinInject-anvil-runtime-optional is optional, and your project would work without it. I added it so I can get rid of my custom scope and use kotlin-inject-anvil’s scopes to keep everything consistent.

To make things easier, I created a bundle with kotlin-inject dependencies, and I use that instead.

[bundles]
kotlinInject = [
  "kotlinInject-runtime",
  "kotlinInject-anvil-runtime",
  "kotlinInject-anvil-runtime-optional"
]

We can then add it to our module like so. implementation(libs.bundles.kotlinInject)

Add @ContributesTo Annotation

We can now annotate our interface components with @ContributesTo. I also replaced my custom scope with kotlin-inject-anvil scope: @ApplicationScope -> @SingleIn(AppScope::class). As mentioned, this is optional and will work with your custom scopes. Here’s how the component looks.

Before

interface CastComponent {
  
  @Provides
  @ApplicationScope  
  fun provideCastDao(bind: DefaultCastDao): CastDao = bind
  
  @Provides
  @ApplicationScope
  fun provideCastRepository(bind: DefaultCastRepository): CastRepository = bind
}

After

@ContributesTo(AppScope::class)
interface CastComponent {
  
  @Provides
  @SingleIn(AppScope::class)
  fun provideCastDao(bind: DefaultCastDao): CastDao = bind
  
  @Provides
  @SingleIn(AppScope::class)
  fun provideCastRepository(bind: DefaultCastRepository): CastRepository = bind
}

One small thing I did later was move the @SingleIn annotation to the class instead of having it in the binding functions.

Add @ContributesBinding Annotation

The next thing we can do is annotate all classes that have interface implementations with @ContributesBinding. Once we’ve plugged everything in, Anvil will provide the bindings for us, and we can get rid of the component above with the manual binding.

Before

@Inject
class DefaultCastRepository(
  private val dao: CastDao,
) : CastRepository {
    ...
}

After

@Inject
@SingleIn(AppScope::class)
@ContributesBinding(AppScope::class)
class DefaultCastRepository(
  private val dao: CastDao,
) : CastRepository {
    ...
}

Add KSP Dependencies.

To check if the changes we’ve made work as intended, we can add the Kotlin inject Anvil compiler dependency and generate the component classes. addKspDependencyForAllTargets(libs.kotlinInject.anvil.compiler). addKspDependencyForAllTargets is an extension function that creates KSP configurations for each target. e.g kspAndroid kspIosArm64

We can build our app and take a look at the generated code.

Anvil will generate the bindings for us similarly to what we had above. This will be generated for all our classes annotated with @ContributesBinding(AppScope::class).

@Origin(value = DefaultCastRepository::class)
public interface ComThomaskiokoTvmaniacDataCastImplementationDefaultCastRepository {
  
  @Provides
  public
      fun provideDefaultCastRepositoryCastRepository(defaultCastRepository: DefaultCastRepository):
      CastRepository = defaultCastRepository
}

Delete Manual Bindings.

Now that our bindings and components are being generated, we can delete our component interfaces with provider functions.

In my previous implementation, each module was responsible for creating its own DI component. The shared module then added all these SuperType Components to the parent/final component for each platform component. This is a bit painful and can easily get out of hand as your project grows. 😮‍💨

Thanks to kotlin-inject-anvil, we can get rid of these as they are now generated for us once we add the merge annotation. 🥳

Final Boss: @MergeComponent Annotation

@ContributesSubcomponent Annotation

Since we can only have one component annotated with @MergeComponent, we need to annotate ActivityComponent to @ContributesSubcomponent, create a factory that our parent scope will implement.

Before

@SingleIn(ActivityScope::class)
@Component
abstract class ActivityComponent(
  @get:Provides val activity: ComponentActivity,
  @get:Provides val componentContext: ComponentContext = activity.defaultComponentContext(),
  @Component
  val applicationComponent: ApplicationComponent =
    ApplicationComponent.create(activity.application),
) : NavigatorComponent, TraktAuthAndroidComponent {
  abstract val traktAuthManager: TraktAuthManager
  abstract val rootPresenter: RootPresenter
  
companion object
}

After

You should note that we converted our abstract class to an interface, as only interfaces can be annotated with contributed @ContributesSubcomponent. For more details on annotation usage and behavior, see the documentation.

@ContributesSubcomponent(ActivityScope::class)
@SingleIn(ActivityScope::class)
interface ActivityComponent {

  @Provides
  fun provideComponentContext(
    activity: ComponentActivity
  ): ComponentContext = activity.defaultComponentContext()

  val traktAuthManager: TraktAuthManager
  val rootPresenter: RootPresenter

  @ContributesSubcomponent.Factory(AppScope::class)
  interface Factory {
    fun createComponent(
      activity: ComponentActivity
    ): ActivityComponent
  }
}

@MergeComponent Annotation

To create our graph and our components to our graph, we need to replace kotlin-injects @Component with kotlin-inject-anvil @MergeComponent and get rid of the SharedComponent.

Before

@Component
@SingleIn(AppScope::class)
abstract class ApplicationComponent(
  @get:Provides val application: Application,
) : SharedComponent() {
  abstract val initializers: AppInitializers
  companion object
}

After

I added annotation, removed the supertype from the application component, and added ActivityComponent.Factory.

@MergeComponent(AppScope::class)
@SingleIn(AppScope::class)
abstract class ApplicationComponent(
  @get:Provides val application: Application,
) : ActivityComponent.Factory {
  abstract val initializers: AppInitializers
  abstract val activityComponentFactory: ActivityComponent.Factory
}

Now, if we look at the generated code, we can see that Anvil adds all the generated components to our graph when we compile the app.

If you forget to delete any provide functions, you will get the following error at compile time.

e: [ksp] Cannot provide: com.thomaskioko.tvmaniac.data.cast.api.CastDao
e: [ksp] as it is already provided

This is expected; you can track down the duplicate provide method and delete it.

Conclusion

With this in place, we have now gotten rid of manual bindings, replacing them with @ContributesTo and @ContributesBinding. We also deleted our god component class and got rid of a lot of boilerplate, thanks to Anvil.

@Ralf and all the contributors have done a fantastic job with kotlin-inject-anvil. The integration was smooth. I’m looking forward to how these libraries evolve. (Maybe it should be renamed to KiAnvil. Get it? You know, like Keanu, because of how lethal it feels? No? 😂 Don’t worry, I will see myself out.)

Thanks, @Ralf, for reviewing the article. Until we meet again, folks. Happy coding! ✌️

References

• Dagger + Anvil: Learning to Love Dependency Injection..
• KSP with Kotlin Multiplatform
• Kotlin Inject Anvil README

Integrate Kotlin-Inject-Anvil To Tv Maniac was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Intro:

Remember our adventure in Going Modular — The Kotlin Multiplatform Way? Well, this is a continuation of that. (Sort of 😁). I say sort of because this article focuses on the Swift side of things. We will explore how creating UI components in a separate Swift package can significantly improve the development experience when working on the iOS App.

This is a blog of an ongoing series on my journey with Kotlin Multiplatform.

• Going Modular — The Kotlin Multiplatform Way
• KMM Preferences Datastore
• KMP Environment Variables (Part 1)
• Intercepting Ktor Network Responses in Kotlin Multiplatform
• Navigating the Waters of Kotlin Multiplatform: Exploring Navigation Solutions
• Enhancing iOS UI Previews: Swift UI Packages & Kotlin Multiplatform Mobile. — You are here. 👈

If you are interested in the code, here is the Pull Request. Let’s get this party started.

The KMM Preview Headache 🤕

While working with KMM on iOS, one of my biggest headaches is that Previews don’t load in XCode. I don’t know why XCode does not play nice with KMM. It either takes too long to load or fails. The only way to see what I am creating is by running the application. This is frustrating as it slows development time.

Enter Separate Swift Packages 📦

By relocating our UI components into a separate Swift package, we’re not just organizing our code, but we’re also unlocking a host of benefits that can significantly enhance our development experience:

1. Functional SwiftUI Previews

• By isolating views from the KMM framework, providing real-time UI development feedback, and improving the developer experience, we can load views faster.

2. Improved Reusability

• Components can be easily reused across the application, leading to a more modular architecture and reducing code duplication.

3. Streamlined Testing

• With this in place, Snapshot testing becomes a viable option for ensuring UI consistency. Coming soon. 🤓

4. Optimized Project Structure

• A clear structure makes it easy to maintain and update our components.

App structure:

I ended up creating two packages:

• SwiftUIComponents: This package contains common views used in various screens. Colors, Buttons, CardView, PosterImage etc
• TVManiacUI: This Package includes Screen UI Views. eg. CastList, TrailerList, ShowInfoView. etc

Below is what the structure of the App looks like.

TvManiac/
├── shared/
│   └── ... (Kotlin shared code)
├── androidApp/
│   └── ... (Android-specific code)
├── iosApp/
│   ├── iosApp.xcodeproj
│   ├── iosApp/
│   │   └── ... (iOS app-specific code)
│   └── Modules/
│       └── SwiftUIComponents/
│       │   ├── Package.swift
│       │   └── Sources/
│       │       └── SwiftUIComponents/
│       │           └──Components/
│       │                 ├── BottomNavigation.swift
│       │                 ├── HeaderContentView.swift
│       │                 └── ...
│       │           ├── CollapsibleView.swift
│       │           ├── TrailerItemView.swift
│       │           └── ...
│       └── TVManiacUI/
│           ├── Package.swift
│           └── Sources/
│               └── TVManiacUI/
│                   └──Models/
│                       └── SwiftCast.swift
│                       └── SwiftTrailer.swift
│                   ├── CastListView.swift
│                   ├── ShowInfoView.swift
│                   ├── ProviderListView.swift
│                   └── ...

Implementing the Approach

Integrating a package in XCode is a straightforward process. These are the steps I followed:

1. Package Creation and Configuration

• Create a new Swift package (`SwiftUIComponents`) using your preferred method (Xcode UI or Swift Package Manager CLI).
• Configure the `Package.swift` file to specify the iOS deployment target and any necessary dependencies.

2. Component Migration

• Migrate SwiftUI views and components from your KMP iOS project to the new package.
• Refactor as needed to ensure components are self-contained and don’t rely on KMM-specific code.

3. Dependency Management

• If your UI components require a specific package, use Swift Package Manager’s dependency declaration to manage package relationships. In my case, I added `SDWebImageSwiftUI` and `YouTubePlayerKit` and removed them from the main app.

4. Final Step

• In your main iOS project, go to File > Add Packages.
• Select `SwiftUIComponents` package.
• (Optional) Create a new scheme and select the framework, in this case, `SwiftUIComponents.` This allows us to switch between the Main app and the UI package.

With that in place, here’s an example of how the project structure looks after implementing this approach. 🥳

Conclusion

I highly recommend trying this approach. It’s made my life easier, my code cleaner, and the general structure better. Next, we might add snapshot tests, a CI/CD job, and more cleanup.

Until we meet again, folks. Happy coding! ✌️

Disclaimer: This blog post does not aim to compare various navigation libraries; instead, it offers insights into my personal journey of arriving at a navigation solution. The intention is not to provide a comparative analysis of different libraries but to share my decision-making process.

Intro:

Now, let’s delve into the journey. My initial focus was on streamlining Compose Screens and refining the presentation layer. I wanted to relocate the navigation logic from the screens to the presentation layer. This decision stemmed from my perspective that navigation is inherently more of a state management concern than a UI element. After conducting some brief research, I decided to centralize and share the navigation logic. Have the logic in a separate navigation module and have it handle routing to different screens. After some experimentation, I shared the navigation logic between iOS and Android.

This is a part of an ongoing series on my journey with Kotlin Multiplatform.

• Going Modular — The Kotlin Multiplatform Way
• KMM Preferences Datastore
• KMP Environment Variables (Part 1)
• Intercepting Ktor Network Responses in Kotlin Multiplatform
• Navigating the Waters of Kotlin Multiplatform: Exploring Navigation Solutions — You are here. 👈

If you’d like to know how things looked initially, read Going Modular — The Kotlin Multiplatform Way. Let’s dive in and see how we ended up here.

Navigating the Sea Of Libraries

There are a couple of things to consider before deciding what library to use, as there’s no “best” library. This could be something like how new the library is. What does the support look like? Is it actively maintained? Might it add complexity to your app? If you are in a team, how many people are familiar with it? How does it impact your architecture? I could go on, but it depends on your desire.

There are a couple of third-party alternatives that you can choose from:

• Voyager: A pragmatic approach to navigation
• Decompose: An advanced approach to navigation that covers the full lifecycle and any potential dependency injection.
• Appyx: Model-driven navigation with gesture control.
• PreCompose: A navigation and view model inspired by Jetpack Lifecycle, ViewModel, LiveData, and Navigation

Fortunately or unfortunately, I only tried two of the mentioned libraries; my experience is below.

1. Voyager

Voyager is a new navigation library explicitly built for Compose multiplatform, which is designed to make navigation in Compose-based apps more straightforward and intuitive.

Setup & General Use

My experience with Voyager was seamless. It’s easy to set up and get things going. The `ScreenModel` class is also useful for multiplatform state management.

*Dependency injection(Optional)

Voyager integrates well with the different dependency injection frameworks. It currently supports koin, kodein, hilt, and Kotlin-inject.

Conclusion

I did not go with Voyager because I wanted to keep the UI side native per platform (Android: Compose & iOS SwiftUI) and only share the ScreenModel. It’s possible to create a custom ScreenModel/ViewModel where the Lifecycle is bound on the Voyager lifecycle and, on iOS, the UiViewController lifecycle. However, I was looking for something that works out of the box. This was an oversight on my end, but it was a good experiment. If/when I create a Compose Multiplatform App, I will go with Voyager.

2. Decompose

Decompose is a Kotlin Multiplatform library for breaking down your code into tree-structured lifecycle-aware business logic components (aka BLoC), with routing functionality and pluggable UI

Setup & General Use

Decompose does a good job of decoupling from the OS libraries. I had a hard time getting things up and running compared to my experience with Voyager. Once you understand the core concepts, it’s not that bad. The good thing is the project is well documented, and there are multiple project samples. [John O’Reilly’s](https://johnoreilly.dev/) project, Confetti, also helped immensely with my migration.

*Dependency injection(Optional)

Decompose is flexible and should work with any dependency injection framework. It currently supports koin, kodein, and Kotlin-inject, which I use in my project].

Conclusion

Decompose works for me because it allows me to keep the native UI instead of using Compose Multiplatform and share the navigation and presentation logic between platforms.

Pre-Decompose

Let’s take a trip down memory lane and see what things look like before moving to decompose. Each platform handled its navigation — i.e., Jetpack Navigation on Android and Navigation API for iOS. The image below shows what the Android architecture looked like. This was highly inspired by Lachlan McKee’s article Scalable Jetpack Compose Navigation.

Each feature module is responsible for creating its navigation factory, which the App module adds to the NavGraph.

Hello Decompose

Let’s quickly look at how things look with decompose in place. I will not go through the setup process. There are multiple articles on how to do this, but here’s an overview of what the architecture looks like with Decompose.

Thanks to the implementation of decompose, navigation logic joins the shared codebase (KMM). This means each platform only has UI implementation, such as Android with Jetpack Compose and iOS with Swift, and no business logic.

One thing I might do in the future is move the Android Feature modules to the presentation layer, as they are currently just composables. I’m still thinking about this. 🤔

With this structure, I can easily change the presentation & navigation layers and try something else if needed.

The gif below shows how both apps work with shared logic. Thanks to Decompose, we can handle navigation, display, and hide views, in this case, the BottomBar.

Until next time

There’s no silver bullet for navigation yet, so use what works for you or your team. One significant takeaway from this experiment is the importance of considering an iOS perspective first. The adage ‘If it works on iOS, it should translate smoothly to Android’ underscores the value of prioritizing platform considerations in development decisions.

If you are curious about how the Migration looked, you can look at the PR below.

Migrate to Decompose by thomaskioko · Pull Request #108 · thomaskioko/tv-maniac

Thank you for taking the time to join me on this journey. Feel free to share any opinions or ask any questions you may have. With that, my app has been Decomposed. ✌️

Big thanks to Arkadii Ivanov and Hannah Olukoye for reviewing this post.

Resources

• Decompose Documentation.
• Shared Navigation on Kotlin Multiplatform with Decompose (KMP)

Navigating the Waters of Kotlin Multiplatform: Exploring Navigation Solutions was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction:

Handling various HTTP response codes is crucial when building mobile applications that communicate with APIs. This article will explore how to use Ktor’s `HttpResponseValidator` to intercept and handle responses in mobile applications.

We’ll use Trakt as a use case since it’s what I am for my project, but the concept should work for any API. One of the status codes from Trakt is `403` (Forbidden), which indicates that the server understands the request but refuses to authorize it. We’ll see how we can intercept such responses, format the message and present this to the user.

Below is what we’ll be able to achieve at the end of this. 😎

TL;DR

If you just want to look at the code, click the link below.

Ktor Error Handling by c0de-wizard · Pull Request #95 · c0de-wizard/tv-maniac

Understanding HttpResponseValidator

Ktor is a robust Kotlin-based framework for building server-side and client-side applications. It provides a flexible and extensible architecture to efficiently handle HTTP requests and responses. One of the key components in Ktor is the `HttpResponseValidator,` which allows developers to define a custom response.

Intercepting Responses

To intercept responses, we need to add `HttpResponseValidator` inside the HttpClient’s body Ktor’s to check the response’s status code and take appropriate action. Before doing that, we need to enable default validation by setting the `expectSuccess` property to `true.` This terminates `HttpClient.receivePipeline` if the status code is unsuccessful.

Here’s our custom exception class.

API Response Wrapper

With the HttpResponseValidator in place, we can create an extension function to wrap API responses.

You can also use kotlin-result or Arrow’s Either depending on your needs. In this case, we will create our class. `ApiResponse`

API Requests

We can now create a function with a return type `ApiResonse<T>` and use the extension function we created to make the API call.

You can now invoke the Api call and handle the response based on your implementation. In my case, I am using Store5. (Blog coming soon). We make the API call inside the `fetcher.` If successful, cache it else, throw an exception.

By doing this, Store will wrap the exception in the `StoreReadResponse.Error` type, ensuring the flow does not break the stream and will still receive updates when data changes. We can now propagate the result and handle it in the presentation layer. In this case, when we get an exception, we show a SnackBar.

And that’s it! 🎊 I hope this post helped. If you liked it, give it some claps! 👏

Post Series

1. Going Modular — The Kotlin Multiplatform Way
2. KMP Preferences Datastore
3. KMP Environment Variables (Part 1)
4. Intercepting Ktor Network Responses in Kotlin Multiplatform.

Reference material

• Create a Fancy Toast Component Using SwiftUI
• Response validation

Thanks to Hannah Olukoye for reviewing this article.

Intercepting Ktor Network Responses in Kotlin Multiplatform was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I will talk about my experience working with environment variables on Kmm (Kotlin Multiplatform) and how I am currently using it in my project Tv-Maniac

GitHub - c0de-wizard/tv-maniac: Tv-Maniac is a personalized entertainment tracking and recommendation Multiplatform app (Android & iOS) for tracking TV Shows using Trakt.

Environment Variables

During the development lifecycle of a mobile app, you may create apps that use API keys or passwords. It is best practice to store such sensitive info in a secure place. In Android, you’d ideally use local.properties or gradle.properties to set this up on iOS, configuration files commonly known as xxconfig The good thing about this is you can configure it to support multiple builds/targets: e.g., Dev, QA and Prod depending on your needs.

Now that we have that in mind, how do we go about this for a KMM project? There are multiple ways you can do this, but I will only talk about the first two since it’s what I have worked with.

1. Custom gradle plugin
2. BuildKonfig
3. Config file reader
4. gradle-buildconfig-plugin

1. Custom Gradle Task

I will not go in-depth on this but give an overview. We can use some Gradle utils to generate code from build properties. There are three main concepts that we will need to make this possible.

1. Creating a gradle task.
2. Defining the generated file.
3. Setting the source set

With that in mind, we will need to create a task that produces a file as output. We can use Sync for this. According to Gradle’s documentation, it synchronizes the contents of a destination directory with some source directories and files. It’s more like a copy task.

Once we have that in place, we can dynamically use TestResourceFactory to create files. If you have a custom source set, you will need to define it. Otherwise, gradle won’t recognize it.

You can check out this answer by @aSemy on StackOverflow.

2. BuildKonfig

This is a library that embeds values from a gradle file. If you are an Android dev, this will feel more like home. It’s pretty simple.

I created a small function to help us read from gradle.properties.

Below is how we use the custom function and buildConfig to read from gradle.properties

To generate the files, run ./gradlew generateBuildKonfig. The generated class will look like so:

3. Config File Reader

We can create a resource reader to help read from yaml configuration files. The good thing about this is we can easily create multiple environment files for different flavors. Builkonfig supports this, but I have difficulty switching between environments in a different project.

This implementation is from Touchlab’s Droidcon KMM App, which has a neat way of reading files from both iOS and Android. I’d say this is the meat of it. YamlResourceReader helps us serialize the yaml file into a data class object. readAndDecodeResource takes in two params:

1. name: Name of the yaml file. We have this as a parameter so that you can pass in different files based on the build target you want.
2. strategy: Serialization strategy. We will be using kotlinx.serialization , but you could also use Gson or Jackson.

Android Platform Implementation

We could also use Android AssetManager to read from the bundled assets context.assets.open(name) but this example we are using javaClass.classLoader

iOS Platform Implementation

Resources Folder

We then need to add our configuration files. Kmm libraries have a structure folder for resources. You can name them whatever you want. qa.yaml or release.yaml depending on your needs. In this case, qa.yaml.

We need to drag or add the file on iOS, so it’s accessible. For uniformity, I have created a directory called Resources and added the file there.

One extra step was to create a symlink in the root directory so we could easily access it. (This is optional)

Reader Implementation

Tying things up together. We can now use the resource reader and pass the intended file.

Conclusion

There are two things we need to do:

1. Remember to add the files on iOS.
2. Depending on your application, you might want to ignore the file so you don’t publish sensitive info.

With that, all our resources are in one directory. There might be a better way, but this has worked for me. I’m always up to learning from you, so feel free to poke holes in my implementation. 😅

In part 2, we will look at how to create different build flavors. Until then, happy coding.

In this article, well, take a look at how to DataStore and how to use it in a Kotlin Multiplatform project.

Recently Google announced a couple of Jetpack Multiplatform libraries. One is DataStore, a storage solution that allows you to store key-value pairs. This has been rewritten & is now available on Kotlin Multiplatform, targeting Android & iOS.

Something to take note of is that these libraries are experimental and should not be used on production apps!

What you will learn:

1. Setting up Datastore.
2. Dependency Injection.
3. Creating a repository
4. I am writing a test.

TvManiac Project

A lot is changing at the moment on this project as I am cleaning up and creating a better structure for this project. The changes referenced here can be found in this commit.

GitHub - c0de-wizard/tv-maniac: Tv-Maniac is a personalized entertainment tracking and recommendation Multiplatform app (Android & iOS) for tracking TV Shows using Trakt.

Let’s get started!

For our project, we need to add the preference core dependency.

dependencies {
    implementation("androidx.datastore:datastore-preferences-core:1.1.0-dev01")
}

Now we need to create a function in commonMainto help us create an instance of our DataStore object. We can use expect/actual pattern and have each platform have its implementation, but I will create a function and set it up when setting up injection. It's a straightforward function that takes in two parameters: Coroutine scope and the filePath.

fun createDataStore(
    coroutineScope: CoroutineScope,
    producePath: () -> String
): DataStore<Preferences> = PreferenceDataStoreFactory.createWithPath(
    corruptionHandler = null,
    migrations = emptyList(),
    scope = coroutineScope,
    produceFile = { producePath().toPath() },
)

internal const val dataStoreFileName = "tvmainac.preferences_pb"

And that’s it. 🙂 We can now move over to the injection of the DataStore. As I mentioned in my previous article, we have a “hybrid injection setup” where we use Hilt on the Android side and Koin on iOS; however, I plan on migrating to Koin in the future. 😅

Dependency Injection:

Android:

This should be self-explanatory:

@Provides
@Singleton
fun provideDataStore(
    @ApplicationContext context: Context,
    @DefaultCoroutineScope defaultScope: CoroutineScope
): DataStore<Preferences> = createDataStore(
    coroutineScope = defaultScope,
    producePath = { context.filesDir.resolve(dataStoreFileName).absolutePath }
)

IOS Koin Module:

For iOS, it’s almost similar. We need to create a function that creates the dataStoretore object and then add that to koin module

fun dataStore(scope: CoroutineScope): DataStore<Preferences> = createDataStore(
    coroutineScope = scope,
producePath = {
    val documentDirectory: NSURL? = NSFileManager.defaultManager.URLForDirectory(
        directory = NSDocumentDirectory,
        inDomain = NSUserDomainMask,
        appropriateForURL = null,
        create = false,
        error = null,
    )
    requireNotNull(documentDirectory).path + "/$dataStoreFileName"
  }
)

actual fun settingsModule(): Module = module {
    single { dataStore(get()) }
}

Boom. We can now create a repository and use it to get the theme and set the theme. The implementation looks like so.

class SettingsRepositoryImpl(
    private val dataStore: DataStore<Preferences>,
    private val coroutineScope: CoroutineScope
) : SettingsRepository {

override fun saveTheme(theme: String) {
        coroutineScope.launch {
            dataStore.edit { settings ->
                settings[KEY_THEME] = theme
            }
        }
    }

override fun observeTheme(): Flow<Theme> = dataStore.data.map { theme ->
        when (theme[KEY_THEME]) {
            "light" -> Theme.LIGHT
            "dark" -> Theme.DARK
            else -> Theme.SYSTEM
        }
    }

companion object {
        val KEY_THEME = stringPreferencesKey("app_theme")
    }

Testing

The test is pretty simple.

Creating the DataStore & repository objects.

private var preferencesScope: CoroutineScope = CoroutineScope(testCoroutineDispatcher + Job())   
private val dataStore: DataStore<Preferences> = PreferenceDataStoreFactory.createWithPath(
        corruptionHandler = null,
        migrations = emptyList(),
        scope = preferencesScope,
        produceFile = { "test.preferences_pb".toPath() },
    )
private val repository = SettingsRepositoryImpl(dataStore, testCoroutineScope)

Clear/remove the key after running a test.

The other thing we need to do is clear the saved item after running a test. We could do this two ways, delete the file in the application dir or remove the preferences using the key. We will use the latter. We do that by creating a function and using @AfterTest annotation. We also need to cancel the context associated with the data store.

@AfterTest
fun clearDataStore() = runBlockingTest {
    dataStore.edit {
        it.remove(KEY_THEME)
    }
 preferencesScope.cancel()
}

Since DataStore uses coroutines, we will use Turbine for tests. This isn’t complicated. Here, we test that the theme gets updated.

@Test
fun when_theme_is_changed_correct_value_is_set() = runBlockingTest {
    repository.observeTheme().test {
        repository.saveTheme("dark")
        awaitItem() shouldBe Theme.SYSTEM //Default theme
        awaitItem() shouldBe Theme.DARK
    }
}

One thing that I will improve in the future is deleting the generated test file. Right now, we ignore all .preferences_pb files created during testing.

This is how our test class looks like after stitching everything together.

private var preferencesScope: CoroutineScope = CoroutineScope(testCoroutineDispatcher + Job())
private val dataStore: DataStore<Preferences> = PreferenceDataStoreFactory.createWithPath(
    corruptionHandler = null,
    migrations = emptyList(),
    scope = preferencesScope,
    produceFile = { "test.preferences_pb".toPath() },
)
private val repository = SettingsRepositoryImpl(dataStore, testCoroutineScope)

@AfterTest
fun clearDataStore() = runBlockingTest {
    dataStore.edit {
        it.remove(KEY_THEME)
    }
    preferencesScope.cancel()
}

@Test
fun default_theme_is_emitted() = runBlockingTest {
    repository.observeTheme().test {
        awaitItem() shouldBe Theme.SYSTEM
    }
 }

 @Test
 fun when_theme_is_changed_correct_value_is_set() = runBlockingTest {
    repository.observeTheme().test {
        repository.saveTheme(Theme.DARK)
        awaitItem() shouldBe Theme.SYSTEM //Default theme
        awaitItem() shouldBe Theme.DARK
        }
    }
}

Final Thoughts

We’ve covered steps for using DataStore in a Kotlin Multiplatform project. I must say, it was super simple to get this up and running. You can use this in your ViewModel. For my project, I’m using a FlowRedux StateMachine, which I will discuss in the next post.

Any comments, good or bad, are always welcome.

Resources

• Check out the DiceRoller sample app.
• Jetpack Multiplatform Libraries.

Thanks to Marton Braun for reviewing this article.

I recently decided to dive into the Kotlin Multiplatform world. So far, so good. This article talks about my journey modularising a project I’ve been working on.

There are other ways to do this, but this worked for me.

TvManiac

I’m using TMDB to fetch Tv Show information. Here’s how it looks on both platforms. I have much work done on Android since that’s my territory. I’m updating the iOS side of things as I learn. You can find the source code for the project on Github.

GitHub - c0de-wizard/tv-maniac: Tv-Maniac is a personalized entertainment tracking and recommendation Multiplatform app (Android & iOS) for tracking TV Shows using Trakt.

The Shared Module

Before discussing modularisation, let me share why I decided to do this. The shared module contains common logic for both platforms. (iOS & Android).

To be precise, we are sharing the Network and Cache code. A couple of great introduction articles are at the end of the post. Below is the shared module initially looked at.

So why modularise the shared module?

Well, I was initially using packages to structure code. It worked, but it was a pain navigating through packages. Since I plan on updating this project, I need to do things correctly. And that, folks, is why we are here.

One other thing, any time I change a class in the shared module, the whole module is built again.

Going Modular

The image below shows what the shared module looks like after a couple of experiments here and there. But first, let’s take a look at the project structure.

Project Structure

We have a couple of modules but can group them into four main directories/modules.

• base: This module contains iOS `ApplicationComponent` classes and configuration to export the ios framework.
• core:database: DB implementation. We are using SQLDelight for this project.
• core:datastore: DB implementation. We are using SQLDelight for this project.
• core:networkutil: Contains all "common" classes used by all modules. These can be util classes like CoroutineScope/Dispatchers, util classes, e.t.c.
• core:api: Module with Ktor implementation for each respective platform. TMBD and Trakt.
• data: It contains a repository, data sources, and model classes
• domain: It contains presentation implementation. In this case, we use FlowRedux to create a shared `state-machine` for both clients.

Kmm precompiled script

Since most of the module’s build.gradle files are the same, we can use a precompiled script to save a lot of repetition. We create a file kmm-domain-plugin.gradle.kts in the buildSrc directory.

We can then add the plugin to the module and get rid of a lot of code. Now, we need to apply the script and add the module dependencies. As you can see, one advantage of this is having lean modules and don’t need to have unnecessary dependencies.

Exposing dependencies on iOS

Now that we have our modules, we need to add them to the shared module since this is the entry point for iOS. By adding the modules to commonMain, Kmm will generate an Obj-C Framework.

To expose the dependencies, we do two things

1. Add the modules as API in commonMain source set

2. Export the modules in the Framework configuration.

You’ll notice we are only adding API modules to the framework configuration. This is because we only need to expose the interfaces.

One last thing, and we can wrap things up. Let’s look at Dependency injection.

Dependency injection

I initially had what I wanted to call a mixed injection where Android uses Dagger Hilt, and the Shared module uses Koin to initialize the graph. I migrated the implementation to kotlin-inject by Eva Tatarka.

kotlin-inject/README.md at main · evant/kotlin-inject

Most modules have a di the package that contains module dependencies. As an example, this is what genre looks like: I might have yet to mention that I'm creating a Swift package and adding that to the iOS app. John O'Reilly has a fantastic article on how to go about it. Read more here. (Follow him if you want to get lost in the KMM universe. He does cover a lot of topics and shares valuable resources.)

Summary

I hope this was useful as I walked you through how I approached this challenge. I know I could have gone deeper into things. Mostly because I’m sure, there are other ways of doing this. Better/more straightforward ways. If you have some insights, please feel free to reach out. Learning is an endless loop, and I’m up for it.

What I love about Kotlin Multiplatform is:

• Most of the core business logic is shared. This allows me to spare some time and dive into the Apple world.
• UI development is Native. So I can still keep up on what’s happening on Android and learn a bit of Swift while at it.

Until we meet again. Adios.

Post Series

1. KMP Preferences Datastore
2. KMP Environment Variables (Part 1)
3. Intercepting Ktor Network Responses in Kotlin Multiplatform.

Resources

• Understand the KMM project structure.
• Kotlin Multiplatform In Production — Kevin Galligan
• Using Swift Packages in a Kotlin Multiplatform project — John O’Reilly
• Touchlab — KaMPKit
• Multiple Kotlin Frameworks in an Application — Kevin Schildhorn

Exposing dependencies on iOS

Now that we have our modules, we need to add them to the shared module since this is the entry point for iOS. By adding the modules to commonMain, Kmm will generate an Obj-C Framework.

To expose the dependencies, we do two things

1. Add the modules as API in commonMain source set

2. Export the modules in the Framework configuration.

You'll notice we are only adding API modules to the framework configuration. This is because we only need to expose the interfaces.

One last thing, and we can wrap things up. Let's look at Dependency injection.

Dependency injection

I initially had what I wanted to call a mixed injection where Android uses Dagger Hilt, and the Shared module uses Koin to initialize the graph. I migrated the implementation to kotlin-inject by Eva Tatarka.

kotlin-inject/README.md at main · evant/kotlin-inject

Most modules have a di the package that contains module dependencies. As an example, this is what genre looks like: I might have yet to mention that I'm creating a Swift package and adding that to the iOS app. John O'Reilly has a fantastic article on how to go about it. Read more here. (Follow him if you want to get lost in the KMM universe. He does cover a lot of topics and shares valuable resources.)

Summary

I hope this was useful as I walked you through how I approached this challenge. I know I could have gone deeper into things. Mostly because I'm sure, there are other ways of doing this. Better/more straightforward ways. If you have some insights, please feel free to reach out. Learning is an endless loop, and I'm up for it.

What I love about Kotlin Multiplatform is:

• Most of the core business logic is shared. This allows me to spare some time and dive into the Apple world.
• UI development is Native. So I can still keep up on what's happening on Android and learn a bit of Swift while at it.

Until we meet again. Adios.

Post Series

1. KMP Preferences Datastore
2. KMP Environment Variables (Part 1)
3. KMP: Intercepting Ktor Network Responses.

Resources

• Understand the KMM project structure.
• Kotlin Multiplatform In Production — Kevin Galligan
• Using Swift Packages in a Kotlin Multiplatform project — John O'Reilly
• Touchlab — KaMPKit
• Multiple Kotlin Frameworks in an Application — Kevin Schildhorn

Going Modular — The Kotlin Multiplatform Way was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Gradle 7.0 introduced an incubating feature to centrally manage dependencies in your Gradle project.

A version catalog is a list of dependencies, represented as dependency coordinates, that a user can pick from when declaring dependencies in a build script.

Gradle documentaiton

In this post, we will take a look at how to setup the versioning system and implement a workaround to use the catalog in pre-compiled scripts as this is not currently supported.

You can find the demo project here.

Common Dependency Magangement Patterns

There have been different patterns developers have come up with to help with dependency declaration and management.

• Using versions in properties files gradle.properties
• Creating a gradle file. dependencies.gradle
• Kotlin DSL dependencies.kts This is what we will use as an example in this post

Since the rise of Kotlin DSL where you declare libraries in buildSrc, I have never looked back, well until 7.0 😂. Basically declaring dependencies in buildSrc then using type-sage accessors to declare dependencies in the build scripts.

We could then go ahead and use this in our build script like so:

One drawback of this method is any change to the dependencies will trigger recompilation of build scripts and invalidate the build script classpath. This will end up rebuilding a lot more than what you should do for a version change.

Hello Version Catalogs

A version catalog is basically a replacement for all the previous patterns, supported by Gradle, without the drawbacks of the previous approaches.

The version catalog TOML file

Gradle offers a conventional file to declare a catalog. We’ll create a file libs.versions.toml in gradle subdirectory of the root build directory and store all our dependencies and version in there.

The TOML file consists of 3 major sections:

• [versions] used to declare versions that can be referenced by dependencies.
• [libraries] used to declare the aliases to coordinates.
• [bundles] used to declare dependency bundles.

Enable version catalog

To enable the feature to add the below line in your root project’s settings.gradle.kts

Declaring Dependencies & Versions

We can now go ahead and add dependencies to the toml file like so.

Referencing Dependencies

We can now reference dependency in the build.gralde.kts. Instead of referencing the dependency name and version from the dependency file, we had earlier can simply use it in the dependency block libs.dependencyName

One slight thing to note is androidx-appCompat (toml) becomes libs.androidx.appCompat (kts). I find this a good way of nesting/grouping dependencies.

We now have a single place where you can update everything, dependencies, and versions.

Enable version catalog for pre-compiled scripts

So far, this will work if you are just using the version catalog in the root build.gradle.ktsfile. We need to add one more thing to allow us to use the catalog system in our pre-compiled scripts. So let's go ahead and fix that.

Create settings.gradle.kts inside buildSrc directory and add the following piece of code.

This is a known issue and we will probably get rid of this code once the issue is resolved.

That’s it. You can now use the version catalog in your pre-compiled scripts. You can take a look at the documentation for further details

Originally published at Thomas Kioko.

Gradle Version Catalog + Pre-Compiled Scripts was originally published in code_wizard on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ladies and gentlemen, if you have not checked out ConstraintLayout 2.0, you are missing out. I have been playing around with it and I’m at the point of no return. Ever wanted to make cool animations? Well, it’s a walk in the park. You just need to know where the park is and how big it is. 😏

About ConstraintLayout

ConstraintLayout 2.0 was announced at Google I/O 2018. What got me excited was MotionLayout, a tool for layout animations. Yes, you read that right. Layout Animations. In this series well take a look at how we can use motion layout to create a Twitter Profile like UI.

Yap… All this was done using XML. 😃I’d recommend that you check out this introduction by Nicolas Roard.

Intro

Here’s a break down:

• Adding ConstraintLayout 2.0 & MotionLayout
• Motion Layout
• MotionScene
• OnSwipe
• Transition
• ConstraintSets
• KeyFrames
• Conclusion

Adding MotionLayout

To add motion layout to your project, simply add the following to your Gradle file:

MotionLayout

As the name says, it’s Motion + Layout files. Motion layout builds upon ConstraintLayout. It allows us to handle layout transitions and complex motion. Think of it this way, ConstraintLayout allows us to create complex layouts and MotionLayout is the icing on the cake adding animations to the layout.

So let’s start by setting up the UI using ConstraintLayout. Allow me to skip this part or I’ll end up talking about ConstraintLayouts. I’ll post some links on ConstraintLayouts at the end 😃

Voila …

Something to take note of, MotionLayout is a subclass of ConstraintLayout. So we need to make sure our root tag is MotionLayout.

MotionScene

We’ll a separate XML file inside res/xml that will contain MotionLayout information then we will reference the file in out activity file like so.

app:layoutDescription="@xml/scene_twitter_profile"

The MotionScene contains the magic.

Transition

We’ll start by checking out the Transition Element. This defines what the start and end states are. We define the states using the respective attributes: constraintSetEnd and constraintSetStart. The ids of the states can be anything, the same way we name views.

OnSwipe

OnSwipe is contained inside the Transition definition. It lets you manage the transition by matching the motion of the user’s finger. There are 3 main params:

• dragDirection: Think of this as the scroll direction (top / bottom / left / right ).
• touchAnchorId: This is the view we are tracking, in our case it will be the RecylerView. When the user scrolls up or down (dragDirection) do some magic
• touchAnchorSide: the side of the object that should track your finger (right /left /bottom /top)

This is how it looks

We are almost there… Stay with me. 🤓

ConstraintSet

We will use ConstraintSets to handle our states. To do so, we will create two ConstraintSets or should I say we’ll create a set. 😏No? Fine…

We can now add constraints for the views in the layout file. You will notice that it looks like a normal file just that we don’t specify the widget.

With only those lines of code, we get the following effect. We are not there yet but this is progress. We need to fix a couple of things but before we do that, let’s see what’s happening.

There are 3 things to take note of:

1. Attributes Override: Defined attributes in the scene file will override those in the layout file. ( layout_height, padding, margin, constraints …)So you can actually get rid of them in the layout file making it cleaner. I really like this
2. ConstraintSet values: If you take a closer look at the layout height of the toolbar, you’ll see there’s a difference. The first one defines the size of the image in its original state (expanded) and the second one in its final state (collapsed). This gives us a collapsing bar effect when we scroll.
3. CustomAttributes: We have access to various attributes that allow us to modify a widget. In this tutorial, we are using imageAlpha to modify the transparency of the image. You can read more about CustomAttributes here.

Image Fix

When we scroll up, we want the image to scroll under the toolbar. To do this we simply change the elevation of the toolbar in the final state (collapsed). We update it from 2dp to 4dp. JUST that and …. Boom!!

KeyFrameSet

Before we wrap this up, I’ll touch on KeyFrameSets. They let us change a widget at a certain point during the transition. In our case, we want to shrink the profile image when scrolling up and down.

The KeyFrameSet contains KeyAttribute. framePosition specifies when we want to modify the image. It takes in a value between 0–100. In our case, when we are 20% into the transition, start to scale down the image.

Still, on KeyFrames, we want the UserName and tweet count to appear on the toolbar. We’ll update the alpha value of the TextViews to “1” when we are 100% into the transition. This will make them visible since we’ve set the widgets to invisible by default.

Final Result

After patching it all up, we get this:

Conclusion

You can see how MotionLayout is amazing and powerful. No Java/Kolin code was used. Let that sink in.

It goes to show the power of MotionLayout. I’m really looking forward to the UI editor and other amazing updates.

The source code for this article is available on Github

Resources

1. Build a Responsive UI with ConstraintLayout
2. Android Fundaments: ConstraintLayout by Rebecca Franks
3. ConstraintLayout CodeLab

Thank you for using your precious time to read this article. Liked it? Clap 👏 to say “thanks!” and please share it to help others find this article.