When I implemented a Canvas with Kotlin and Compose for the first time, what did I gain?

It has been nearly four years since Google recommended Kotlin as the preferred language for Android development in 2019. Compose version 1.0 has also been released for nearly two years. Kotlin+Compose is still far behind in the current Android development process. Not as mainstream. Should we start experimenting with this combination? What will this combination bring us?

For me, I am an old-fashioned person who loves the new. Since the beginning of 2018, I have tried to use Kotlin to complete some Android work ( Android For Bezier ), but I have not used kotlin as my personal Android primary development language. However With the improvement of the combination community of Kotlin+Compose, more and more people began to try this combination, and added their own strength to the community construction of this combination. Calling each other, more and more people (including me) are beginning to try to add Kotlin or Kotlin+Compose to existing development projects. This article will show some of the gains and thoughts I encountered in this combination.

Start with a custom Canvas

Let’s take a look at the effect first. The original animation effect is not original, and a secondary design has been carried out in combination with the actual functional effect.

Canavs

The final result is quite satisfactory, and many additional animation effects have been added. In other words, each part of the display has its own animation.

Let's talk about harvest and thinking first

Generally speaking, I will explain the implementation process from design to code in turn, but this time I will talk about the reasons for my harvest and thinking first, mainly because the entire process from design to code implementation has nothing in essence to the original development (Java) The difference. Of course, a detailed description of this animation will still be provided later.

Kotlin and Java The comparison and relationship between Kotlin and Java I won’t go into details, but through the Canvas Coding process, I have a deeper understanding of the use and understanding of Kotlin. When comparing the two languages, although the two The relationship is very close, but in real use, it is still necessary to avoid bringing the habits of one language into another.
Compose The original project of mine was to make a gist desktop tool implemented by Compose, but various problems and lack of information at the time prevented me from completing the project. When I actually use Compose in the project, we can understand how to use Compose applications , It is completely impossible to achieve the experience effect only by the introduction of others. This is very obvious to most developers who have been deeply involved in Android.

The first thing to bear the brunt is the idea of responsive layout, which is very different from the habits brought about by the xml layout we initially used.

When we implement our layout through xml (even when we build directly through View.add() ), we first create a View, we hold the "handle" of this View, and we can use this "handle" To make any modification to this View at any time and any place.

And when we use Compose for layout, we need to define Compose (Compose is Compose, it is at the same level as View) and tell it what to do under what circumstances. Just like Yutu, on the ground You can add various tools (tracks, cameras...), but when you launch it on the moon, you can't even change the pattern on the surface.

最初的Coding过程中, 由于固有思路的原因, 想着先实现一部分的功能, 然后看下实现的效果在逐步添加相关的功能. 但是当我实现了某个效果再回来的时候, 在一小部分的情况下, 我不得不对现有的代码进行很大的修改. 同时我也确认过, 如果不使用Compose的话, 是不需要改动如此大的. 这里就是我在这个项目中对我观念转变最大的地方. "如果没有设计完成, 就不要去实现它", 平时的这个问题被我们拿住"把柄"的View所掩饰了.

换句话说, 使用Compose就像使用各种Builder一样, 当我们没有build()的时候, 我们可以做任何事情, 一旦我们完成build()了, 我们就不能这样随心所欲的控制它, 想想我们的AlertDialog.Builder().create().
Kotlin Compose和Java XML 在整个代码中, 我都尽量使用Kotlin+Compose来进行实现各种功能, 就像Kotlin和Java直接可以很方便的互相使用, Compose和View直接也可以很简单的互相融合, 在Coding过程中, 经验的不足和对Kotlin Compose的不熟悉使得很多看似简单的功能迟迟无法实现, 甚至一些效果对我来说, 不使用老方法我无法做到. (即便如此, 仍使用了一部分ValueAnimator而不是 rememberInfiniteTransition)
会让我更多的使用Kotlin和Compose么? 经过一段时间的使用后(不仅仅是这个demo, 还有在实际工作中的使用), 我认为我会尝试更多的Kotlin代码和用Compose来构建页面. 通常来说的Kotlin相对于Java来说代码量会更少, 不过现在的各种辅助开发工具(Copilot, ChatGpt)使其"写更少的代码"看起来并不是十分能吸引人, 俗话说的好"纸上得来终觉浅,绝知此事要躬行", 当你真正的使用一段时间之后, 你会发现写的少, 不仅仅是写的少, 也代表了看的少, 理解的少, 改的少, 维护的少.当然, 这些都是建立在一定基础上的, 在了解一定的特性和约定后才能达到, 不然最多的感受可能只有"这里的功能是什么? 这里为什么要这么设计?", (是吧协程).

如果说Java的学习难度是线性的, 那么Kotlin的学习难度我认为是抛物线的形状, 入门比Java更简单, 但是稍一深入, 由于有大量约定的特性, 使其中期难度比Java更难. 当然, 后期深入精通的部分都是需要不断的学习和使用的.

这导致了很多人初期使用的时候感觉很省心, 但是当尝试使用或者深入学习的时候, 会发现很多的地方都无从下手, 或者预期的功能无法实现. 一是固有思维的作祟, 二是你认为学习完成的基础知识还不足以让你进行下一步. 这可能就是"基础知识陷阱"吧. 最初的我, 认为Kotlin是Java的另一种实现形式, 认为直接的尝试是没有问题的. 但是就像是View和Compose直接的关系一样, 虽然两种之间都可以很轻易的互相使用, 但是, View就是View, Compose就是Compose, Kotlin就是Kotlin, Java就是Java. 两者之间的关系并不是替代和补充. 而是实现同一目的的不同思路. "条条大路通罗马"不是么? 所以当你使用Kotlin和Compose的时候, 放弃一下固有的思维和观念, Kotlin不是替代品, 它是另一条路.