DEV Community: alaje

JetBrains IDE Plugin Development: Migrating from Gradle IntelliJ Plugin to IntelliJ Platform Gradle Plugin

alaje — Tue, 28 Jan 2025 15:33:55 +0000

The title of this article is not more confusing than suddenly upgrading your IntelliJ IDEA version and discovering all the reds in your plugin project.

Now, I knew something had changed, but I didn’t know exactly what. When I finally discovered the cause, fixing it was just a matter of following the documentation

Step 1: Update the `plugins` block in your build.gradle file

plugins {
    id("java")
    id("org.jetbrains.kotlin.jvm") version "1.9.21"
    id("org.jetbrains.intellij.platform") version "2.2.1" // [visit here to see latest version](https://github.com/JetBrains/intellij-platform-gradle-plugin/releases)
}

We've replaced id("org.jetbrains.intellij") version "1.16.1" because as of version 2, the IntelliJ plugin now goes by the name IntelliJ Platform Gradle Plugin.

Step 2: Add the migration plugin

Me thinking I was in the clear after step 1:

Then this happened:

When the documentation said that there were significant breaking changes, I should have expected it; I really should have. I carried my sorry self back to the documentation and discovered that the team over at JetBrains was so helpful that they provided another plugin to help us through the migration. How sweet of them! (Sarcasm, for all my folks on the slower side). I mean, I was dreading what was to come now. If they went the mile to provide an entire plugin to help, does it not mean the worst?

So, let’s update the plugins block again with our new plugin:

plugins {
    ...

    id("org.jetbrains.intellij.platform") version "2.2.1"
    id("org.jetbrains.intellij.platform.migration") version "2.2.1"
}

Step 3: Replace the `intelliJ` block

We got Unresolved reference: intellij for our intelliJ block is because the intelliJ block has now been replaced with the intellijPlatform block. When we load the new script configuration and then sync our Gradle changes, we now see that the migration plugin is doing its thing already.

It tells us we should do a couple of things instead. How it’s rendered in the pop-up isn’t making the migration plugin’s suggestion as helpful as it is, so I’ve copied it below so that we can make sense of it:

/*
Define the IntelliJ Platform dependency in `dependencies {}` block instead:
repositories {
    mavenCentral()
    intellijPlatform {
        defaultRepositories()
    }
}
dependencies {
    intellijPlatform {
        create(type, version)
    }
}
IntelliJ Platform Extension: https:// plugins. jetbrains. com/ docs/ intellij/ tools-intellij-platform-gradle-plugin-dependencies-extension.
*/

Now we can see what we have to do.

Step 4: Add the `intellijPlatform` blocks

We must add two types of intellijPlatform blocks, one for the repository and another for the dependencies.

In the repository:

repositories {
    ...

    intellijPlatform{
        defaultRepositories()
    }
}

In the dependencies:

dependencies {
   ...

    intellijPlatform {
        create("IC", "2024.1.1") 
    }
}

The values I passed into the create function are the same values that were previously being set for the version and type in the old intelliJ block:

intellij {
    version.set("2024.1.1")
    type.set("IC") // Target IDE Platform

    ...
}

Step 5: Add `plugins` and `bundledPlugins` functions

At this point, I was facing my last red line.

After formatting the migration plugin’s suggestion, this is what we have:

/* Using 'plugins: ListProperty<Any>' is an error. 
Define dependencies on plugins or bundled plugins in `dependencies {}` block 
instead: 
repositories { 
    mavenCentral() 
    intellijPlatform { 
        defaultRepositories() 
    } 
} 

dependencies { 
    intellijPlatform { 
        plugins(providers.gradleProperty("platformPlugins").map { 
            it. split(',') 
        }) 
        bundledPlugins(providers.gradleProperty("platformBundledPlugins").map { 
            it. split(',') 
        }) 
    }
} 

Note that bundled plugins are now separated from plugins available in JetBrains 
Marketplace. 
IntelliJ Platform Extension: https://plugins.jetbrains.com/docs/intellij/tools-intellij-platform-gradle-plugin-extension.html 
Migration guide: https://plugins.jetbrains.com/docs/intellij/tools-intellij-platform-gradle-plugin-migration.html

It’s clear that our intellij.plugins is no longer available, but even though we know what to do, we need to understand why we now have two functions to add.

An IntelliJ IDE comes with bundled plugins, which are plugins out of the box, and then we have plugins that don’t come with an IntelliJ IDE, so if you want to use them, you have to get them from, say, the Marketplace. Before IntelliJ Platform Gradle Plugin, you declared your plugins the same way irrespective of their source, but now you actually have to determine which of your plugins are bundled or not and then use either the plugins function or the bundledPlugins function for them.
The arguments: providers.gradleProperty("platformPlugins").map { it. split(',')} and providers.gradleProperty("platformBundledPlugins").map {it. split(',')} being passed into the functions in the snippet above is simply a way to access your list of plugins from your project’s gradle.properties file and then transform it into an appropriate value. So, unless your plugins are defined in your gradle.properties file, we can ignore that.

I had three plugins in my project:

...
"com.intellij.java",
"org.jetbrains.kotlin",
"Dart:241.15989.9"
...

Already, I knew which ones came with IntelliJ and which ones I had to get from the Marketplace. You can quickly know which is which when testing your IDE plugin in the IDE development instance, because you don’t have to install the bundled plugins for the target IDE. Another way to know this is by running the printBundledPlugins task to see all the bundled plugins for the IDE. Here are some of the ones packed into the IntelliJ IDEA Community Edition:

So now I have:

dependencies {
    implementation(files("libs/svgSalamander-1.1.4.jar"))
    intellijPlatform {
        create("IC", "2024.1.1")
        plugins("Dart:241.15989.9")
        bundledPlugins("com.intellij.java", "org.jetbrains.kotlin")
    }
}

Step 6: Do away with `patchPluginXml`, `publishPlugin` and `signPlugin` tasks

At this point, when building and running my plugin, it works!

But there’s this ugly warning the migration plugin was sharing whenever I ran my plugin:

And reading through it, I saw it was more advice for the kind of changes I should make for my migration to 2.x, so of course, it made sense to do as instructed:

intellijPlatform {
    pluginConfiguration {

    }
    publishing { 

    }
    signing {

    }
}

The problem was that after I added the above code, the migration plugin didn’t offer any further steps. I didn’t know what was supposed to go into my functions. The IDE's suggestions helped me guess what went where, but I wanted either the docs or the migration plugin to tell me exactly what to do.

Since the migration plugin wasn’t doing that, I went back to the documentation, but that specific migration documentation page did not provide the answer. It instead redirected me to the IntelliJ Platform Extension page, where I saw this:

intellijPlatform {
  buildSearchableOptions = true
  instrumentCode = true
  projectName = project.name
  sandboxContainer = "..."

  pluginConfiguration {
    // ...
  }
  publishing {
    // ...
  }
  signing {
    // ...
  }
  pluginVerification {
    // ...
  }
}

Before we go on, you should see what my tasks block for my free plugin was looking like:

tasks {
    buildSearchableOptions {
        enabled = false
    }

    // Set the JVM compatibility versions
    withType<JavaCompile> {
        sourceCompatibility = "17"
        targetCompatibility = "17"
    }
    withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile> {
        kotlinOptions.jvmTarget = "17"
    }

    patchPluginXml {
        sinceBuild.set("241")
    }

    signPlugin {
        certificateChain.set(System.getenv("CERTIFICATE_CHAIN"))
        privateKey.set(System.getenv("PRIVATE_KEY"))
        password.set(System.getenv("PRIVATE_KEY_PASSWORD"))
    }

    publishPlugin {
        token.set(System.getenv("PUBLISH_TOKEN"))
    }
}

Unfortunately, on that site’s page, we didn’t have one exact place to see what we had to change into what, so reading through was a must. Finally, we ended up several changes:

Move buildSearchableOptions to the intellijPlatform top-level function
Remove the patchPluginXml **task and add the sinceBuild with the ideaVersion function
Remove the signPlugin task and add the certificateChain , privateKey and password with the signing function instead
Remove the publishPlugin **task and add the token with the publishing function

The result:

intellijPlatform {
    buildSearchableOptions = false

    pluginConfiguration {
        ideaVersion {
            sinceBuild = "241"
        }
    }
    publishing {
        token = System.getenv("PUBLISH_TOKEN")
    }
    signing {
        certificateChain = System.getenv("CERTIFICATE_CHAIN")
        privateKey = System.getenv("PRIVATE_KEY")
        password = System.getenv("PRIVATE_KEY_PASSWORD")
    }
}

tasks {
    // Set the JVM compatibility versions
    withType<JavaCompile> {
        sourceCompatibility = "17"
        targetCompatibility = "17"
    }
    withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile> {
        kotlinOptions.jvmTarget = "17"
    }
}

After doing this, it turns out the ugly warning is still there:

But by now, I think it’s just the migration plugin guy acting up.

Step 7: Remove the `setupDependencies` task (Optional)

Just because I don’t like ignoring warnings, I went a step further to respond to this warning from the migration plugin:

The setupDependencies task is no longer required in 2.x, so I removed it per the steps outlined in documentation:

Conclusion

The last thing I did was remove the migration plugin, and c’est fini! I successfully migrated my IntelliJ IDE plugin project to the IntelliJ Platform Gradle Plugin (I think 🤔). Overall, I don’t think the migration plugin was helpful much since I still had to rely on the documentation to carry out many of the changes. The experience would have been much better if quick fixes had been incorporated into it. All in all, all’s well that ends well. I hope this helped!
Kindly take note that these steps should work for free plugins, but if your plugin is of the paid or freemium type, extra steps that were not covered in this article are required.

Jetpack Compose Tidbits: The first dance with JC - Learning the steps

alaje — Wed, 29 Dec 2021 12:07:16 +0000

^{Image by} ^{Gordon Johnson} ^from ^Pixabay

With Android's fresh way of developing UI, there's little to no XML which was formerly the primary way of designing UI for Android apps. With Jetpack Compose, you just declare what you need for creating your UI by calling functions and Jetpack Compose handles the implementation. When you need your UI to reflect come changes with the user's data, the functions you created just get called again with the new data.
Jetpack Compose comes with Android Jetpack, a collection of software components launched in 2018 that work to make developing Android apps easier and more efficient. Before JC, using views was the primary way of creating UI in Android, thus, many of the apps already existing are built with views, that is why Compose can exist in harmony with views so you can be sure that you don't need to throw away all your old code with views when starting out with Compose. Instead, you can make the shift to Compose in a way that suits you best.

If you've ever programmed with Flutter, chances are, you're going to fit right in with Jetpack Compose since Compose comes with a reactive style of programming.

Setting up the dance floor

To get started with Compose you must have Android Studio Arctic Fox.
After downloading Android Studio and successfully launching it, we can create a new compose project by clicking New Project,

And then click Empty Compose Activity to start creating your Compose app,

A pop-up titled "Empty Compose Activity" appears, and we can go ahead to change our project's name to something more fitting:

The save location is where your project will locally be stored on your machine, and the package name uniquely identifies your app. The value supplied for the save location will be slightly different depending on your choices when installing Android Studio, and although you can change it and the package name, it would be better to leave it as is since the explanation given from this point is done in accordance with these exact values.

The process is smooth and free of hitches if your internet connection is enabled and stable.
If you were unable to follow along with the above steps, you can visit Android developer's official site to see more info about the setup process.

Getting to know your partner, JC

After Android Studio finishes setting up your project, you should have a file with the name MainActivity.kt automatically shown in the editor window (the space available in Android Studio where the details of files are seen and interacted with).
You should also be able to see this sample bit of code:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            FirstComposeAppTheme {
                // A surface container using the 'background' color from the theme
                Surface(color = MaterialTheme.colors.background) {
                    Greeting("Android")
                }
            }
        }
    }
}

code snippet: 1.0

This file belongs to the launching activity of your app called MainActivity. The class name also points to this. An activity, is the primary component of any android app that involves continuous interaction with the user. It serves as the entry point of your app in which you can let the user interact with your app. It, most commonly, shows UI as a single screen in the app. A more in-depth explanation can be found in the Android docs. MainActivity is your launching activity because it was automatically set as so in the AndroidManifest.xml upon the creation of your project. AndroidManifest.xml is a manifest file. It describes your app to Android systems, therefore, every app project you create must have it. To see what the manifest file looks like, go into the project window and double-click the manifests directory:

This opens up the manifest file in the editor window:

The highlighted part focuses on MainActivity. For an activity to be visible to the Android system, it must be declared in the manifest file using the <activity> tag. And this piece of XML

<intent-filter>
                <action android:name="android.intent.action.MAIN" />

                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>

makes it the activity that the will be launched from the launcher screen.

Back to this piece of code:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            FirstComposeAppTheme {
                // A surface container using the 'background' color from the theme
                Surface(color = MaterialTheme.colors.background) {
                    Greeting("Android")
                }
            }
        }
    }
}

If you've worked with views, the code should be slightly familiar. In here, our first visible step into compose starts from setContent which has a content parameter that takes in a composable function that returns Unit as its argument. This content value becomes the root view of the given activity.
Take a look at setContent's definition:

public fun ComponentActivity.setContent(
    ...
    content: @Composable () -> Unit
) {
    ...
}

Before moving ahead, let's slide into what a composable function is.

A Jetpack Compose app will primarily be made up of composable functions which serve as the building blocks of your app’s UI. You’ll create your UI With composable functions or composables for short. A composable function looks like any other normal function you can find in your code, except now it's marked with an
annotation @Composable. This annotation serves as a tag on your function that tells Compose that it is specially made for producing UI. Let's look at a very basic composable function:


@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!")
}

We can see the annotation @Composable, and as previously pointed out, this makes Greeting a composable function. Let's notice how we started our function name with a capital letter following a PascalCase format. Anytime your composable function returns Unit, you are advised to use PascalCase in writing its name, and also to use a noun as the name. Focusing on the function we are calling next, Text(...), is a composable function that comes by default with Jetpack Compose. It prints the String value that was passed as an argument to its parameter "text" on-screen.
We've passed in a string template that references the parameter name, thus, whatever value will be called with Greeting will be what gets shown on-screen.
The Text function’s declaration looks like this:

@Composable
fun Text(
    text: String,
    ...
) {
    ...
}

If you’ve ever used views to create apps, this is similar to TextView.

Now that we know what composable functions are, let's waltz back into analyzing the piece of code in our MainActivity.onCreate method.

From here, our next step comes with FirstComposeAppTheme which provides our app's theme. We can use a theme to style our app by providing a pool of colors, typography, and shapes that we can use to not only fuse our brand into the app but also grant it a uniform look and feel that looks aesthetically pleasing and is also coherent. Jetpack Compose provides MaterialTheme as the default theming system, but for more control over our app's look an feel, we can choose to build something of our own from scratch.
In our case FirstComposeAppTheme, automatically created upon the creation of own new project, sits atop MaterialTheme.
See the definition of FirstComposeAppTheme :

@Composable
fun FirstComposeAppTheme(darkTheme: Boolean = isSystemInDarkTheme(), content: @Composable() () -> Unit) {
    val colors = if (darkTheme) {
        DarkColorPalette 
    } else {
        LightColorPalette
    }

    MaterialTheme(
        colors = colors,
        typography = Typography,
        shapes = Shapes,
        content = content
    )
}

Let's focus on the part about MaterialTheme, where clearly, our FirstComposeAppTheme just wraps around MaterialTheme.
Now back to our code in our activity's onCreate function, we can see that setContent is a higher-order function, so is FirstComposeAppTheme and Surface since they take in functions as parameters. Notice the FirstComposeAppTheme was passed as an argument to the content parameter, using the trailing lambda syntax. Composable, Greeting, is called in the lambda passed into Surface with the parameter "Android". Since we have “Hello $name” already set, this should later show "Hello Android" on-screen once it is run.
The comment above the invocation of Surface,

// A surface container using the 'background' color from the theme
                Surface(color = ...

tells us that we are creating a surface container and passing in the background color set in our theme.
This surface container is a Material surface, meaning that it follows Material Design language where it serves as a depiction of physical surfaces having attributes like color, elevation, opacity and shape. See it’s definition:
@Composable
fun Surface(
modifier: Modifier = Modifier,
shape: Shape = RectangleShape,
color: Color = MaterialTheme.colors.surface,
contentColor: Color = contentColorFor(color),
border: BorderStroke? = null,
elevation: Dp = 0.dp,
content: @Composable () -> Unit
) {
…
}

You might have noticed by now how a composable is passed into another composable as its content's argument.

Treading down our MainActivity file allows us to see the declaration of Greeting. Below it we can see another composable function DefaultPreview which takes no parameter but instead has an extra annotation Preview. The Android Studio you installed comes with a preview window that allows you to view the UI built by a composable. This Preview annotation marks a function that contains no parameter to allow its UI be shown in the Android Studio preview.

@Preview(showBackground = true)
@Composable fun DefaultPreview() {
    FirstComposeAppTheme {
        Greeting("Android")
    }
}

In the DefaultPreview function, FirstComposeAppTheme function is called and the same thing done in the onCreate function of the MainActivity is repeated. We can pass in several arguments to Preview that control how the UI created by the composable functions we call will look like in the preview window. For example, we can supply showSystemUi = true.

@Preview(showBackground = true, showSystemUi = true )

At the moment, we are only tweaking the values of showBackground and showSystemUi, to see more info about the annotation, place you mouse icon over the annotation text and wait for a pop-up to appear showing the documentation details of Preview. If nothing appears, place your input cursor in the midst of its characters, go up to toolbar area, click View > Quick Documentation. You should probably take note of the shortcut for this action.

The preview window should be open by default,

but if it isn't, you can split the window.

Using the preview window, you can always create composables and then see how they look before deploying to your device.

Main Sources: Android source code

5 top sites to find written tutorials on Android development in 2022

alaje — Sat, 25 Dec 2021 16:37:34 +0000

So you've been procrastinating since 2021, and now that 2022 is in sight you're laced up and getting ready to start your android journey. Even if this scenario doesn't match your situation, as long as you need to learn more about Android, go through these gems on my list and you'll end up adding them to your list of favorites for anything android development-related.

Raywenderlich
This happens to be my number one go-to for iOS, Flutter, and Android.
Though there's a price tag on their content made by their contributors, Raywenderlich comes first on my list because even their free content is awesome. An android developer of any level can easily benefit from their posts, and for programmers who do not have English as their first language, you notice how some of their posts are simplified when compared to other sites'. Additional points for them when you consider their learning paths, and the books they provide. If you rather enjoy lengthy articles then this might just end up being your soul-site.
ProAndroidDev
Hosted on Medium, I don't think many know about this site, but then a gem remains a gem whether tons of people know about it or not. On this site, you can find blog posts about android development, and the editors here have notable work experiences so you can be sure that you're getting content you can rely on.
Android's Official Developer Site
"Why oh why", you might ask, "is android's official site for developers at number 3?". Well, that's because, for some reason only known to the Android team, their docs are not beginner-friendly. Maybe it could be their choice of words?
I could have placed them at number 1 because their codelabs are enough to get them that seat, but... 😒
GeekForGeeks
This site's delivery would undoubtedly appeal more to beginners and non-native speakers. Though you would find it slightly difficult to find advanced topics here, this remains one of the best places to get your feet wet with android development in 2022.
StackOverflow
While you might not find "articles" about android development in StackOverflow since it happens to primarily be a platform where you ask questions and possibly have them answered by an army of developers, be rest assured that the mountain of information gotten from these answered questions will leave you more informed than you previously were. If you can't find an already answered question that is similar to yours, then you can always just ask yours. As a bonus, you could even come across links to other sites where you can find knowledge.

If you think you have a better list with your top five sites to learn android development in 2022, you can always choose to make a comment sharing them.

To Pair Or Not To Pair: Benefits

alaje — Sat, 25 Dec 2021 07:52:57 +0000

This post serves as the continuation of a previously written piece with the link https://dev.to/ulimicreator/to-pair-or-not-to-pair-introduction-1n9

Like many other processes, the implementation details of pair programming are left to the entity that intends to implement it. This is so because all effects are eventually carried and borne by the entity.
And whiles one can't properly quantify the productivity of programmers in a workplace, when done well, pair programming could provide these benefits:

Programmers get to learn easily from experienced developers and the knowledge flow is constant and all-encompassing to all participants.
Better code writing, since the one typing the code, i.e. the driver, justifies their code as they type by explaining why they are writing it in such a manner, and a probable input from the navigator could produce a better option.
More communication between programmers in the workplace since programmers who have been paired together would have been placed in the situation where they have to "program out loud" and express their opinions.
Programmers get to understand each other's workflow and habits, and this can serve as a fertile ground for
relationships.
Real-time feedback on the programmer's code is received since with pair programming, the driver literally has someone "watching their back" and this eventually leads to less future code refactoring and reduces the chances of repeating smelly code.
Programmers tend to realize when paired with their fellow programmers that everyone makes mistakes, and understanding this fact is essential to a healthy mind.
Bonds are formed fast and relationships are established easily. This can be extremely beneficial to new employees. And whiles you don't need to be friends to work with someone, most of the boundaries that exist with acquaintances are removed and this produces more efficiency.
With pair programming, when new programmers are paired with programmers more familiar with the codebase they are initiated quite easily and efficiently.
Participants grow to be able to accept feedback and work on them fast, and being able to learn from your mistakes in due time makes you a better programmer and ultimately, a better human being.
Pair programming could be fun.

All suggestions and criticisms on any of my posts are accepted as long as they are not provided in a disparaging manner

To Pair or Not to Pair: Introduction

alaje — Thu, 23 Dec 2021 18:57:54 +0000

Pair programming, aka pairing, is more than what you're probably thinking it is even if you have a good grasp on the words pair and programming.
When we have two people working together on the same computer... on the same code, we have a setup for pair programming. Due to reasons, these individuals might find themselves at different locations, when this is so, it is a popular move to use video conferencing tools to accomplish this process.
Now, just putting two people together, in front of a machine displaying some code is not pair programming. With pair programming, you find a situation where two people constantly communicate with each other about the code, find each other's errors and try to bring out the best possible code to write that accomplishes their sought after goal. These programmers are expected to work as a team.

So things might seem weird at this point, like how does a person actually share a machine with you?

How does this actually work ?

There are two roles, one for each person, obviously. We have the navigator and the driver.

What does the driver do?
Just like how a driver interacts with a car, the driver in this case works directly with the machine to actually type in the code.

What does the navigator do?
The navigator exists to give pointers, answer questions from the driver, ask their own questions about the code being written, and intensively read the code as it is typed so that mistakes are noted fast. With a navigator, the driver not only has a pair of eyes on the code, but also another brain on it.

Both continuously communicate about the project and the best way to do it. The driver can explain -out loud- what is being typed, and the navigator can keep track of what has been done and what is suppose to come next.
There is no designated person for a role, and participants can and should switch roles as many times as they deem fit so that both programmers can learn from each other.
Some more common pairings might involve:
A junior programmer and a senior programmer, to allow an easier onboarding process by letting a person more familiar with the code base to serve as a navigator.
or
Developers of the same rank so that they can properly learn from each other.

Like every practice, pair programming can be adjusted to fit the company's workflow.

Learn more with my next post To Pair or Not to Pair: Benefits https://dev.to/ulimicreator/to-pair-or-not-to-pair-benefits-7e

Jetpack Compose Tidbits: Idempotent and Free of Side Effects

alaje — Sun, 19 Sep 2021 04:14:13 +0000

When Jetpack Compose was introduced, it came with the ability to define functions annotated with "@Composable" that describe how we want our UI to look. When defining these functions we call composables, they should be fast, idempotent, and free of side-effects.
There are times when it is absolutely necessary to include side-effects in our composables because we might want to make certain changes to the state of our app, when doing so, it is advised to implement such in a "controlled environment".
Read:
https://developer.android.com/jetpack/compose/side-effects

Quoting from the docs:
"This function is fast, idempotent, and free of side-effects.

The function behaves the same way when called multiple times with the same argument, and it does not use other values such as global variables or calls to random().
The function describes the UI without any side-effects, such as modifying properties or global variables."

The usage of side-effects here is referring to any change that composable functions make directly on entities that exist outside its local environment. This includes writing to or updating any object that exists externally. The objects are visible to other parts of our app and as such can be accessed at any point in time and changed. The internal workings of Composables does not favor this (except when using Effects API) and additionally the declarative approach of Compose insists that data flow down and events go up. If you want to implement a side-effect do it through a callback. A very common and basic example of what this means can be seen is a user clicking a button. In Compose, once the user clicks said button, you should create your composables in a way that allows the events to notify the app logic. You can do that normally by passing a lambda to your composable as an argument, this lets the app logic make the necessary changes and then the composable is recalled with the new data that will determine how it will be drawn on screen. In this manner, data climbs down the compose hierarchy and events go up.
In the button clicking example, I pointed out that the composable would be redrawn, the android docs calls this recomposition.

Idempotence describes an object's ability to not change its behavior beyond how its state was the first time it was called, even if the same operation was applied on it many times. Note that this definition is based on how it was used in the android docs. In the case of our composable function, it should always have the same effect in our environment no matter how many times we call it as long as we pass it the same input. Additionally, it should be free from side effects like using global variables which are available to other parts of our app. Using random values in our composable function also means that if we were to run our composable function several times with the same input, it would give us different results. According to the android docs, this destroys the idempotence of our composable.
When creating your composables most at times, think of a way to make them reusable top-level functions. If you can do this, then you are most likely following the android docs' advice to make the majority of your composable functions idempotent and free of side-effects.