What did I gain when I first coded a Canvas using Kotlin and Compose?

When I first coding a Canvas using Kotlin and Compose, what did I gain?

Since Google recommended Kotlin as the preferred language for Android development in 2019, nearly four years have passed, Compose 1.0 version has been released for almost two years now. However, Kotlin + Compose is not yet the preferred choice in Android development. Should we still consider trying this combination? What benefits will this choice bring us?

For me, I am both conservative and open to new things. Since early 2018, I have experimented with using Kotlin to develop some Android projects (Android For Bezier), but it has never been my preferred language for Android development. However, with the growing Kotlin and Compose community, more and more people trying this combination and contributing to its ecosystem. Thanks to seamless integration of Kotlin and Java, more developers, including myself, are experimenting with Kotlin or Kotlin+Compose to existing development projects. In this article, I will share some of these gains and thoughts I have encountered while using this combination.

Staring with Custom Canvas

I would like to show you a Gif first. The animation design is not created by me, but I redesigned it with some modifications to better suit the actual functional requirements.

I am quite satisfied with the final result as I added many other animation effects.

First to show my gains and thoughts.

Usually, I explain my design-to-code progress step by step. However, this time I would like to first share the insights and reflections I gained from this project because the overall process of designing and coding has no fundamental difference from my past Java development. Of course, I will still provide a detailed explanation of this Canvas code later on.

1. Kotlin and Java
   I won't go into much detail about the comparison and relationship between Kotlin and Java, but through coding this canvas, I gained a much deeper understanding of Kotlin's usage and concepts. While the two languages have many similarities, it is important to avoid bringing habits from one language into the other when using them.

2. Compose
   Initially, I attempted to build a desktop tool for Gist using Compose, But I encountered various issues and couldn't complete the project due to a lack of resources. It wasn't until I actually used Compose in a real project that I fully understand how it can be applied. It's clear that this experience is common among developers who have focused on Android development for a long time. Simply relying on others' explanations is not enough to fully grasp the benefits of Compose.

   One of the biggest differences is the reactive layout approach that Compose uses, which is very different from the habits we develop when working with traditional XML layouts.

   When we use XML to build our layout(or even build directly using View.add()), we first create a view and hold its "handle". We can use this handle to make any modifications to the view at any time and in any place.

   When we use Compose for layout, we first define the Composables(which are on the same level as Views) and tell them what should do in certain situations. This can be compared to the YuTi moon explorer car, where you can add various tools(such as tracks and cameras) while it is on the ground. However, once it's launched to the moon, even a small change to its surface pattern is no longer possible. Similarly, Composables in Compose are defined upfront and can't be modified on the fly like Views.

   During the initial stages of Coding, I had a traditional way of thinking where I would implement functionalities first and gradually add related features while checking their effects. However, when I returned to some of the functionalities, I have to make significant changes to the existing code in a few cases. I realized that this issue is often hidden when we work with Views and have their handles. Here is my biggest mindset shift that took place during this project: "Don't implement something if you haven't designed it yet."

   To put it differently, using Compose is similar to using other Builders. We can freely manipulate Composeables before calling the build() method. However, after we call it, we can no longer control them as we please. This is similar to the behavior of AlertDialog.Builder().create().

3. Kotlin Compose and Java XML
   I attempted to use Kotlin+Compose throughout the entire codebase to implement various functionalities seamlessly, much like how Kotlin and Java can easily interoperate with each other. Compose and View are also easy to integrate with each other. However, due to my lack of experience and unfamiliarity with Kotlin Compose, I encountered difficulties in implementing some seemingly simple features. In some cases, I had to resort to using older methods to achieve certain effects. Despite this, I still ended up using ValueAnimator in some parts rather than rememberInfiniteTransition.

4. Will make me use more Kotlin and Compose in this experience?
   After using it for some time(not just in this demo, but also in actual development), I believe I will continue to experiment with writing more Kotlin code and using Compose to build layouts. Kotlin generally results in less code than Java, but with the various development tools available today(such as Copilot and ChatGpt), the emphasis on "writing less code" may not be as attractive as before. However, as the saying goes "纸上得来终觉浅,绝知此事要躬行"(Chinese proverb, means "Reading books is like scraping the surface of knowledge, real understanding comes from practicing and experiencing."). After using Kotlin and Compose for some time, I have found that writing less code not only means less code, but also less complexity in understanding, modifying, and maintaining it. Of course, this is all based on a solid foundation are requires an understanding of certain features and conventions. Otherwise, we may only as questions such as "What does this place of code do?" and "Why it is designed this way?", (Sure? coroutines).

   If we were to compare the learning difficulty of Java to a linear curve, then I think the difficulty curve of learning Kotlin would resemble a parabolic shape. Kotlin is easier to get started with Java, but as you dive deep into it. its many conversions and features can make it more challenging than Java in the intermediate stage. Of course, it requires continuous learning and practice to achieve mastery in the advanced stage.

5. Basic knowledge pitfalls
   When I first started learning Kotlin, I thought of it as just another implementation of Java and figured that it would be straightforward to use. However, just like the relationship between View and Compose, although both can easily interact with each other, View is still View and Compose is still Compose. Kotlin is Kotlin adn Java is Java. They both provide different approaches to accomplish the same goals. So when using Kotlin and Compose, it's important to let go of old ways of thinking and understand that Kotlin is not a replacement for Java, but rather a different path to achieving similar outcomes.

6. If you don't want to keep modifying your code repeatedly, complete your design first.

Look us Canvas

It is the background, Sun cloud, Night star, Sun, and Moon.

To clearly present the design of the canvas, the background is not restricted in terms of the display range. Here we have used four circles with different radii but centered at the same point to simulate the effect of light at different levels.

For ease of visibility, the sun clouds have been changed to blue. The cloud consists of 7 2-level circles of different sizes and positions.

Night stars are also simple, and can be displayed as a diamond shape at random positions.

The density of the sun is very simple, with just a color-changing effect added.

The design of the moon is also simple, with just a rotating effect added.

The code is in GitHub