DEV Community: Gustavo Fão Valvassori

Amper: a new way to configure Gradle projects?

Gustavo Fão Valvassori — Fri, 08 Dec 2023 12:05:34 +0000

Earlier this month, Kotlin Multiplatform went stable. And just a couple of weeks later, they announced a new tool to help with one of the biggest issues we have, configuration. Currently, KMP projects use Gradle as a Build System, and we must agree that it's a great tool. But the complexity around it for new users is a big issue.

Amper is a tool to help you configure your projects using a markup language. The main goal is to replace the Groovy/Kotlin programming language with something that can enforce a declarative approach. With a declarative paradigm, you can only declare what needs to be done without implementing it. If you already have experience with Maven, it may be familiar to you.

Please note that the tool is in the early stages of development, and its goal is to validate the idea before putting more effort into it. With that in mind, be aware that syntax, language, and other things may change in the future, and it’s a very experimental tool.

How does it work?

According to the docs, Amper is implemented as a Gradle plugin and uses YAML for its project configuration format. In other words, it's still a Gradle environment, but it will use an additional YAML file to configure the project. To be able to use it, you need one of the following environments:

Use one of the following IDEs:
1. IntelliJ IDEA 2023.3 or newer and the Amper Plugin; or
2. Fleet 1.26 or newer;
Use the Amper build plugin to enable it:
1. In your settings.gradle.kts, add this plugin: id("org.jetbrains.amper.settings.plugin").version("0.1.1")

When you open a project with the Amper Plugin in the IDE, it will look for the module.yaml file. This file will contain the configuration for the module (library or application), dependencies, and other project configurations (like the Java version).

Also worth noting that it also changes the project architecture. Instead of having a directory for your source set artifacts, you will have multiple src directories. In other words, your commonMain/src/kotlin will be only src now, and your iosMain/src/kotlin will be only src@ios. This is a bit confusing at first, but it helps flatten the project structure.

Our Thoughts

Amper comes to fix a huge problem for all KMP developers. We at Touchlab look forward to anything that will reduce the configuration complexity in KMP, and Amper is hopefully a step in the right direction. The Gradle team seems to be on board, at least with the concept. Hopefully the combined efforts will result in something that is truly easier to use and more maintainable.

The integration with the IDEs works fine for configuration. It knows the configuration schema and gives you valid suggestions for properties. Unfortunately, the configuration of the third-party plugins is not currently supported, but it's on their roadmap.

The project APIs are small and only supports a short range of configurations. For basic contexts it works like a charm, but when you need to do something more complex, you may need to work with Gradle again.

The Gradle interop is great. You can still have a build.gradle.kts file to make custom configurations that are not available yet in the YAML file. One does not replace the other, but complement instead. This will be useful if you need to create intermediate source-sets, configure plugins or even import libraries that have a different configuration.

For now, we recommend testing it it out on smaller projects that may not have a big impact with future changes, as it's still experimental. But we are excited to see how it will evolve in the future. If you are using it, don't forget to share your opinions with the Jetbrains team on their Feedback Form and their Slack Channel.

Additional Resources

Getting Started with Compose for Web

Gustavo Fão Valvassori — Fri, 01 Dec 2023 21:34:32 +0000

If you are a Kotlin developer like me, you are probably very excited about Jetpack Compose. It’s a modern UI toolkit for developing apps, and with the great work from JetBrains, it’s becoming a really interesting solution.

As a mobile developer, I’ve never gone in the weeds on how to properly develop sites with HTML, CSS, and JS. My closest experience was with React Native back in 2018. But now, with Compose, using a Kotlin DSL, I feel comfortable on doing this.

Compose Runtime and Component Library

Before creating a project and start coding, it's important to have a small introduction to Compose runtimes. As of now, Compose has two different runtimes on the web:

JS + HTML
Wasm + Canvas

They both use the Compose Runtime underneath, but they use different components. Long story short:

The HTML version will have HTML composable components (like H1, P, Span, Input, Div, etc.)
The Canvas version will have similar components as the Android version as it uses SKIA to draw on the Canvas.

Both of them are experimental. Note that choosing how you want to build your application will impact on possible code-sharing with native if this is what you want.

For this series of posts, I'll use the HTML version and I will be able to explore more the web components.

Creating the project

Now that we know what runtime/components we want to use, we need to create a project. My first idea was to use the KMP project wizard, but unfortunately, the Web target is not available as an option for now. As a workaround, I had to create a new clean project using IntelliJ IDEA and add the dependencies manually.

Using a clean template you will reduce the amount of code that needs to be removed/updated to make the project work. But if you prefer to use any other IDE/Template, feel free to do so and share your experience with us later :)

With that, the configuration is completed with a few extra lines:

Change the Kotlin plugin from JVM to MULTIPLATFORM
Add the Compose plugin
Declare JS source-sets
Import the dependencies
Create an HTML file



plugins {
    kotlin("multiplatform") version "1.9.20" // Make this multiplatform
    id("org.jetbrains.compose") version "1.5.10" // Add compose plugin
}

kotlin {
    js(IR) { // Declare JS source-sets
        browser()
        binaries.executable()
    }
    sourceSets {
        val jsMain by getting {
            dependencies {
                                // Import libraries
                implementation(compose.html.core)
                implementation(compose.runtime)
            }
        }
        val jsTest by getting {
            dependencies {
                implementation(kotlin("test-js"))
            }
        }
    }
}

If you have a trained eye for Gradle configuration, you probably already noticed that we are importing the Compose HTML library. And that's why we need to create an HTML page that will load and be filled by our Composable code. This file should be located at jsMain/resources/index.html.



<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <title>Compose Web</title>
    </head>
    <body>
        <div id="root"></div>
        <script src="compose-sweeper.js"></script>
    </body>
</html>

This can be very simple, just load the JS built from your Kotlin code and create a DOM element that will be you compose root.

Running the project

As with any other project using Gradle as the build system, you will run most of your changes with the gradlew binary (or the gradlew.bat if you are running on Windows). Even though there are multiple commands listed when you call gradlew tasks, the important ones are three:

./gradlew jsBrowserDevelopmentRun - Start development server;
1. This call supports the --continuous build flag that can be used for reloading the app when the code changes;
./gradlew jsBrowserProductionWebpack - Generate the bundle version of your project.
1. It will spit out a static site at the build/dist/js/productionExecutable dir;
./gradlew allTests - Run all unit tests you have implemented for your project;

How does this work?

When you start the development server, it will compile your Kotlin code and run the main() function. On this function, you can call the renderComposable method to start a composable block inside a window element.



fun main() {
    renderComposable(rootElementId = "root") {
        Text("Hello World")
    }
}

As you can see, it will render all the content inside one root element we've defined on previous sections.

Lastly, as you can see at the end of the body block, we are importing the JS file created while building our application. The default name is just the project name with a .js extension.

Now that we have everything in place, we can finally run our server and have the following result:

Final Thoughts

In this first article, we are just exploring how to create and set up your project. But we can already say that Compose Web is a promising alternative for Kotlin developers who don’t want to learn HTML/CSS/JS (even though you will need it).

In future posts, we will dig into more topics, like how to use HTML Components, Styling with CSS, Handling, and Listening to DOM events. After all the articles, you will be able to fully understand how I’ve built this Minesweeper game only using Compose.

Understanding and Configuring your Kotlin Multiplatform Mobile Test Suite

Gustavo Fão Valvassori — Wed, 12 Jan 2022 00:04:00 +0000

Writing tests is part of every developer's day-to-day routine. They help you write better and more reliable code. In addition, they can verify that your code does what it was supposed to do, and your changes haven't introduced bugs. In this article, I'll show you how to configure the test suite from your KMM project.

Understanding a test suite

Before configuring the test suite, we need to understand the different testing environments in the mobile ecosystem.

On Android, we have two different test suites. They can be Unit Tests and run in the JVM without the Android Framework or Instrumented Tests (having access to the framework) running in an Android device or emulator. To handle these different types of tests, you have different source sets on your project.

On the iOS side, things are more straightforward. Here, you can implement both Unit Tests and Instrumented Tests in the same target. That is allowed because all of them will run on the iOS Simulator or a physical device (You can change that, but by default, it's how things work). On iOS, the difference between Unit and Instrumentation is in the concept, while in Android, it's in where your code is and how you run them.

To understand a Unit Test or an Instrumented Test, we need to discuss the test pyramid briefly. It's a visual representation of the difference between the test types (or levels) described by Mike Cohn in the book "Succeeding with agile."

I do not intend to go deep into the meaning of each level. If you want a better explanation, take a look at this blog post from Ham Vocke. But to help your understanding, here is their definition in short:

Unit tests: This type tries to test your software in the tiniest portion (or unit) that they can. When you implement unit tests, you will probably use mocks and stubs to provide these unit dependencies, creating a controlled environment. So, you can think of a Unit as a class or function on your project.
Service Tests: Most projects will have at least one integration. It can be an SQLite database to store data or an HTTP client to fetch network data. The service test is responsible for testing these types of integration. When you are also testing your integration with the platform (using some class/method provided by the Android/iOS SDK), you are also writing integration tests.
UI Test: Last but not least, this type is responsible for testing your UI. Here, you will implement code that will perform actions on your project (like clicking, typing, swiping, and other operations). You can also implement Snapshot Tests to guarantee that all screens are pixel-perfect.

When considering how many of each type to write, keep in mind that each project will have different needs, but service tests run faster than UI tests, and unit tests are faster than both. In other words, opt to have more tests in the lower part of the pyramid and less in the top part

Deciding which one you should implement will depend on your requirements. But you can use this rule for most cases:

If you want to test business logic isolated, create Unit Tests;
If you're going to test the integration of more than one component (from your project or the platform framework), create Integration Tests;
If you are going to test your UI itself or some UI behavior, implement UI Tests.

Understanding the KMM Test Suite

First of all, let's review a KMM project created by the Jetbrains KMM plugin. It is composed of three different types of projects:

the first one is an Android Application inside the androidApp folder;
the next one is an iOS Application inside the iosApp folder;
and last, we have a KMP library inside the shared folder.

This image represents the basic structure, and you will probably have something that looks like this. With that in mind, we now know that there are three different types of testing configurations that we need to make:

The Android test suite;
The iOS test suite;
The Shared test suite;

Configuring your Android Suite

As we discussed earlier, on Android, you can have Instrumented Tests (that requires an emulator) and Unit Tests (that will run in the JVM on your machine). The android project will have two different directories for that. So, inside your androidApp/src dir, you will have the androidTest for instrumented tests and the test folder for Unit tests.

First, we need to add some dependencies that the KMM plugin doesn't include as default. For the Unit Tests, we will require just the JUnit. For the Instrumented tests, we will need the JUnit Extensions and the Espresso testing library. Adds this to your androidApp/build.gradle file.

dependencies {
    // All other dependencies from your application
    testImplementation("junit:junit:4.13.2")

    androidTestImplementation("androidx.test.ext:junit:1.1.3")
    androidTestImplementation("androidx.test.ext:junit-ktx:1.1.3")
    androidTestImplementation("androidx.test.espresso:espresso-core:3.4.0")
}

You also have to define your test instrumentation runner. For this, also add this line to your grade file:

android {
    defaultConfig {
        // All other app configs

        // Add this
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
    }
}

After syncing the project, we can finally implement our tests. Let's start with UnitTests. Here I'm going to create an ExampleUnitTest class inside the test/kotlin/path/to/your/package/. In that, I'll check if the platform name returned from the shared code is what we expect

class ExampleUnitTest {

    private val sut = Platform()

    @Test
    fun platform_returnsCorrectName() {
        val name = sut.platform
        assertEquals(name, "Android")
    }
}

To run this test, you can run this command on your terminal ./gradlew :androidApp:testDebugUnitTest, or use the play button on the side of your test class name. If everything is okay, you will receive a "Build Successful" message.

For the Instrumented Tests, it's pretty similar, but instead of testing a method, we will check if our code is rendering the label with the correct text. To do that, we need to create our test inside the androidTest/kotlin/path/to/your/package/. For this test, I'll name it as ExampleInstrumentedTest.

@RunWith(AndroidJUnit4::class)
class ExampleInstrumentedTest {

    @get:Rule
    var activityScenarioRule = activityScenarioRule<MainActivity>()

    @Test
    fun textView_rendersHelloAndroid() {
        Espresso.onView(withId(R.id.text_view))
            .check(ViewAssertions.matches(isDisplayed()))
            .check(ViewAssertions.matches(withText("Hello, Android!")))
    }
}

The process for running Instrumentation tests is very similar to Unit tests, but before running, remember to start an emulator (or connect a device) and wait for it to complete the boot. Otherwise, your tests are going to fail. The command for running in the terminal is ./gradlew :androidApp:connectedCheck.

This is the basic Android setup. For more details about testing an Android Application, check out the official android testing documentation here.

Configuring your iOS Suite

To configure the iOS test suite, we need to open the project in the XCode. After opening your project, click on the root node from your project on the left, and you will see that your project has only one target.

To add the test target, click on the + button at the bottom, search for the Unit Testing Bundle, and add to your project.

After creating it, you will have a new target, and you will notice a new group on your project navigator on the left. It's probably named iosAppTests, but this can change according to what you defined while creating the testing bundle.

With the testing target created, link the shared module to our test target. In this project, I'm using Cocoapods, and to add this dependency, edit your Podfile. Inside the iosApp target, add the iosAppTests target. In the end, it should look like this:

target 'iosApp' do
  use_frameworks!
  platform :ios, '14.1'
  pod 'shared', :path => '../shared'

  # Add this
  target 'iosAppTests' do
    inherit! :search_paths
  end
end

Now, quit Xcode, run pod install inside your project, and open it again. With that ready, we can start writing some unit tests.

First, right-click in this new group, and select New File. It will prompt you with a box for choosing which file template you want. Select Unit Test Case Class. We can name it ExampleUnitTest to reproduce what we did on the Android side. In the final step, Xcode will launch a prompt to select the saving location. For now, you can save it in this same folder. Just make sure that the iosAppTests is selected in the targets list.

You can delete all that boilerplate code inside the class. Add a testable import from the shared module, create the subject under test, and a testing function.

import XCTest
@testable import shared

class ExampleUnitTest: XCTestCase {

    private let sut = Platform()

    func testPlatform_returnsCorrectName() {
        let name = sut.platform
        XCTAssertEqual(name, "iOS")
    }
}

To run this test, you can click on the "diamond" icon on the side of the class name or run the following command on your terminal.

xcodebuild \
  -workspace iosApp.xcworkspace \
  -scheme iosApp \
  -sdk iphonesimulator \
  -destination 'platform=iOS Simulator,name=iPhone 13,OS=15.0' \
  build test

For UI Tests, you need to add another target. Search, and add the UI Testing Bundle to your project.

And then, add the target to your Podfile, as shown below.

target 'iosApp' do
  use_frameworks!
  platform :ios, '14.1'
  pod 'shared', :path => '../shared'

  target 'iosAppTests' do
    inherit! :search_paths
  end

  # Add this
  target 'iosAppUITests' do
    inherit! :search_paths
  end
end

The process is very similar to what we've done for the Unit Test to create a UI test, but this time we will add a UI Test Case Class. The name can be ExampleUITest, and we will do the same as we did on Android Instrumented Tests. Don't forget to check the target at the end of the creation. It should have the iosAppUITests selected.

Here, you can delete everything except the setupWithError. It has some code responsible for launching the application under tests and stopping the test suite if some error was found in this class. Knowing that, let's start working on the test. We will reproduce what we did on the Android side and check if the text Hello, iOS! is present. Here is the code for that:

import XCTest

class ExampleUITest: XCTestCase {

    lazy var application = XCUIApplication()

    override func setUpWithError() throws {
        continueAfterFailure = false
        application.launch()
    }

    func testApplication_shouldRenderHelloText() {
        let text = application.staticTexts["Hello, iOS!"]
        XCTAssert(text.exists)
    }
}

To run the tests, the process is the same as Unit Tests. You can run from the diamond icon or with the same command line command.

For more details about iOS testing, check the official docs page.

Configuring your Shared Test Suite

Finally, we will set up tests for the shared module. This module is a mix of what we've seen before. The KMP project created by the KMM plugin is composed of two different platforms (Android + iOS) and a shared source set that allows you to write (and test) code that works on both platforms. This module will have a lot of source sets. It will have the implementation folders (commonMain, androidMain, and iosMain) and at least one test folder (commonTest, androidTest, and iosTest).

Be aware that we have a small trap. As I've mentioned before, Android tests can be divided into Integrated and Unit tests. The same still happens in the shared module. For example, an Android project lets you implement the integration tests inside the androidTest folder, but in the KMP project, this folder is for unit tests. Therefore, we should implement android instrumentation tests inside the androidAndroidTest source set. This is only required if you need access to the context or any other Android SDK class.

Another quick thing that I need to mention is that we will not require a simulator for the iOS tests. Here, your tests will run directly on your machine, but you will not lose access to the platform classes. So everything should still work fine.

To start writing tests, if you hadn't checked the "Add shared tests" checkbox while creating a new project, you would need to add the testing dependencies to the shared module. Here they are:

kotlin {
    sourceSets {
        val commonTest by getting {
            dependencies {
                implementation(kotlin("test-common"))
                implementation(kotlin("test-annotations-common"))
            }
        }

        val androidTest by getting {
            dependencies {
                implementation(kotlin("test-junit"))
                implementation("junit:junit:4.13.2")
            }
        }

        val androidAndroidTest by getting {
            dependencies {
                implementation("androidx.test.ext:junit:1.1.3")
                implementation("androidx.test.ext:junit-ktx:1.1.3")
                implementation("androidx.test.espresso:espresso-core:3.4.0")
            }
        }
    }
}

After syncing the project, you should be good to go. Let's start writing some tests. To make things quick here, we will use the default Greeting class from the project setup.

class Greeting {
    fun greeting(): String {
        return "Hello, ${Platform().platform}!"
    }
}

For the Shared tests, we can check if the Hello is mentioned, as it is the same for both parts:

class CommonGreetingTest {
    @Test
    fun testExample() {
        assertTrue(
            Greeting().greeting().contains("Hello"),
            "Check 'Hello' is mentioned"
        )
    }
}

For the Android tests, we can check if the Android name is mentioned in the text:

class AndroidGreetingTest {
    @Test
    fun testExample() {
        assertTrue(
            Greeting().greeting().contains("Android"),
            "Check Android is mentioned"
        )
    }
}

iOS is the same as Android. We check that the platform name was mentioned:


class IosGreetingTest {
    @Test
    fun testExample() {
        assertTrue(
            Greeting().greeting().contains("iOS"),
            "Check iOS is mentioned"
        )
    }
}

Now that all tests are implemented, we can run them. You can run using the IDE button on the side of each class name or using gradlew from the command line. The command is ./gradlew :shared:allTests. If the build succeeds, all tests have passed. If it fails, there are some issues with them.

The tricky part comes next, the Instrumentation Tests. As I said before, if your subject needs access to the context (or any SDK class) on Android, you will have to implement it on the androidAndroidTest source set. If you implement them on the androidTest source set, you will receive a Runtime Exception.

As we don't have any android instrumentation tests for this project, I implement a test to ensure that the context is available and that the SDK classes work correctly.

@RunWith(AndroidJUnit4::class)
class ExampleInstrumentedTest {
    @Test
    fun useAppContext() {
        val appContext = InstrumentationRegistry.getInstrumentation().targetContext
        assertEquals(
            "dev.valvassori.kmp.test.test",
            appContext.packageName
        )
    }

    @Test
    fun parseUri() {
        val uri = Uri.parse("https://google.com")
        assertEquals("https", uri.scheme)
        assertEquals("google.com", uri.host)
    }
}

The command is the same as for the Android app: ./gradlew :shared:connectedCheck and will require the android emulator to run instrumented tests.

Final Thoughts

KMM projects have a complete and robust test suite. You can have Unit and Integration tests for both the shared module and the platform code. There are some tricky parts, like the naming in the common code, but now that you know them, it will be easy. Last, If you want to configure a CI environment for your project, all required build and test commands are mentioned here in this article.

If you want to see the whole project, it's available in this Github project. Check it out if you need to review something.

Thanks for reading! Let me know in the comments if you have questions. Also, you can reach out to me at @faogustavo on Twitter, the Kotlin Slack, or AndroidDevBr Slack. And if you find all this interesting, maybe you'd like to work with or work at Touchlab.

Compose Animations beyond the state change

Gustavo Fão Valvassori — Tue, 24 Aug 2021 17:14:23 +0000

Jetpack Compose hit 1.0 a few weeks ago, and it came with a wonderful and robust animations API. With this new API, you will have total control over animations when the state changes. But when it comes to more complex scenarios, you may face some non-obvious paths. This article will explore some of these scenarios and help you understand how you can achieve your goal.

I'm about to discuss the problems I found when trying to implement the AVLoadingIndicatorView library in Compose. And to guide you through this journey, I'll use the following loading indicators as examples.

Also, all the code we discuss in this article is available in this repository:

faogustavo / loading-indicator-demo

BallScaleIndicator

Let's start with some simple animation. The animation consists in reducing alpha while increasing the scale from a circle. We can do that with just one value that will move from 0 to 1. So the scale will be the current value, and the alpha will be the complementary value (1 - currentValue). As this is a loading animation, we will have to configure it to repeat forever.

TL;DR; we would have to do something like this:

@Composable
fun BallScaleIndicator() {
    val animationProgress by animateFloatAsState(
        targetValue = 1f,
        animationSpec = infiniteRepeatable(
            animation = tween(durationMillis = 800)
        )
    )

    Ball(
        modifier = Modifier
            .scale(animationProgress)
            .alpha(1 - animationProgress),
    )
}

But when you run your app, this is the result:

Nothing happens. Why? In the first lines from this article, we said that Compose has an awesome API to animate state changes, but this is not some state change. We would have to add one variable to control the target state and change it to start the animation. Also, when the view is rendered, we would have to change the value to start the animation.

@Composable
fun BallScaleIndicator() {
    // Create one target value state that will 
    // change to start the animation
    var targetValue by remember { mutableStateOf(0f) }

    // Update the attribute on the animation
    val animationProgress by animateFloatAsState(
        targetValue = targetValue,
        animationSpec = infiniteRepeatable(
            animation = tween(durationMillis = 800)
        )
    )

    // Use the SideEffect helper to run something
    // when this block runs
    SideEffect { targetValue = 1f }

    Ball(
        modifier = Modifier
            .scale(animationProgress)
            .alpha(1 - animationProgress),
    )
}

And now, everything works 🎉

But we have another problem now. The SideEffect will run every time the view is recomposed. So as the animation changes the state value on each iteration, we will run this effect many times. It makes the animation work, but it may not scale nicely and cause some UI issues.

Compose also provides a way to animate values using transitions. One type of transition is the InfiniteTransition. It provides you a syntax with the initial and final values as parameters and it's automatically started when created (no need for SideEffects). To use it, you need to create an instance of it using the rememberInfiniteTransition method and call the animateFloat function to have an animated state.

After a small refactor, this is the result.

@Composable
fun BallScaleIndicator() {
    // Creates the infinite transition
    val infiniteTransition = rememberInfiniteTransition()

    // Animate from 0f to 1f
    val animationProgress by infiniteTransition.animateFloat(
        initialValue = 0f,
        targetValue = 1f,
        animationSpec = infiniteRepeatable(
            animation = tween(durationMillis = 800)
        )
    )

    Ball(
        modifier = Modifier
            .scale(animationProgress)
            .alpha(1 - animationProgress),
    )
}

And the result animation is the same, but without using side effects on this function.

BallPulseSyncIndicator

Alright, we got the first one. Let's try something more complex. This one consists of three balls jumping in synchrony. The easiest way to achieve this is to delay the start of each animation. We can have an animation time of 600ms and start it with a delay of 70ms for each ball.

On a quick search into the compose animation API, we find that the tween animation has a property delayMillis that we can use to implement this behavior. And to animate the values, we can keep the InfiniteTransition. So let's start working with it.

@Composable
fun BallPulseSyncIndicator() {
    val infiniteTransition = rememberInfiniteTransition()
    val animationValues = (1..3).map { index ->
        infiniteTransition.animateFloat(
            initialValue = 0f,
            targetValue = 12f,
            animationSpec = infiniteRepeatable(
                animation = tween(
                    durationMillis = 300,
                    delayMillis = 70 * index,
                ),
                repeatMode = RepeatMode.Reverse,
            )
        )
    }

    Row {
        animationValues.forEach { animatedValue ->
            Ball(
                modifier = Modifier
                    .padding(horizontal = 4.dp)
                    .offset(y = animatedValue.value.dp),
            )
        }
    }
}

Sound good, right? But when we see the animation, we will notice something weird.

You can see that, after some running time, the animation loses synchrony and starts behaving weirdly. The reason for that is the property that we used to delay the animation. It applies the delay to each iteration, not just the first one.

The solution to this is to use the Coroutines Animation API. It's provided by the Compose animations and has a method called animate. It has a syntax pretty similar to the animateFloat from transition. With that in mind, we can use the delay function from Coroutines before starting the animation. This will guarantee the correct behavior.

@Composable
fun BallPulseSyncIndicator() {
    val animationValues = (1..3).map { index ->
        var animatedValue by remember { mutableStateOf(0f) }

        LaunchedEffect(key1 = Unit) {
            // Delaying using Coroutines
            delay(70L * index)

            animate(
                initialValue = 0f,
                targetValue = 12f,
                animationSpec = infiniteRepeatable(
                    // Remove delay property
                    animation = tween(durationMillis = 300),
                    repeatMode = RepeatMode.Reverse,
                )
            ) { value, _ -> animatedValue = value }
        }

        animatedValue
    }

    Row {
        animationValues.forEach { animatedValue ->
            Ball(
                modifier = Modifier
                    .padding(horizontal = 4.dp)
                    .offset(y = animatedValue.dp),
            )
        }
    }
}

Now, the animation will keep synchronized, even after some time.

TriangleSkewSpinIndicator

Alright, let's go to the next one. This triangle indicator has two animations (rotation on the X-axis and Y-axis), but you need to wait for the previous one to execute to start the next one. So if we put that in a timeline, we will have something like this:

The easiest way to evaluate something like this is to handle the animation as one thing with groups. Each group will be formed by the value and the next item in the list and take the same amount to evaluate.

Rewriting the image in Kotlin, we would have something like this:

@Composable
fun animateValues(
    values: List<Float>,
    animationSpec: AnimationSpec<Float> = spring(),
): State<Float> {
    // 1. Create the groups zipping with next entry
    val groups by rememberUpdatedState(newValue = values.zipWithNext())

    // 2. Start the state with the first value
    val state = remember { mutableStateOf(values.first()) }

    LaunchedEffect(key1 = groups) {
        val (_, setValue) = state

        // Start the animation from 0 to groups quantity
        animate(
            initialValue = 0f,
            targetValue = groups.size.toFloat(),
            animationSpec = animationSpec,
        ) { frame, _ ->
            // Get which group is being evaluated
            val integerPart = frame.toInt()
            val (initialValue, finalValue) = groups[frame.toInt()]

            // Get the current "position" from the group animation
            val decimalPart = frame - integerPart

            // Calculate the progress between the initial and final value
            setValue(
                initialValue + (finalValue - initialValue) * decimalPart
            )
        }
    }

    return state
}

With this one implemented, the animation process will be pretty simple. Just create two variables to hold the X and Y rotation, and update the view using the .graphicsLayer modifier.

@Composable
fun TriangleSkewSpinIndicator() {
    val animationSpec = infiniteRepeatable<Float>(
        animation = tween(
            durationMillis = 2500,
            easing = LinearEasing,
        )
    )
    val xRotation by animateValues(
        values = listOf(0f, 180f, 180f, 0f, 0f), 
        animationSpec = animationSpec
    )
    val yRotation by animateValues(
        values = listOf(0f, 0f, 180f, 180f, 0f), 
        animationSpec = animationSpec
    )

    Triangle(
        modifier = Modifier.graphicsLayer(
            rotationX = xRotation,
            rotationY = yRotation,
        )
    )
}

And this is the result:

Final Thoughts

The Jetpack Compose comes with an incredible animation API. It provides you many ways to implement all kinds of animations you may need. But, the current API is a bit different from the imperative version, and some paths will not be that obvious.

To help you have a smooth transition to compose, Touchlab has started a project to help you with all these non-obvious paths.

touchlab / compose-animations

Group of libraries to help you build better animations with Compose Multiplatform

Compose Animations

Group of libraries to help you build better animations with Compose Multiplatform

See docs at Multiplatform Compose Animations

License

Copyright 2024 Touchlab, Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

View on GitHub