Forem: ZhiBo Geng

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

ZhiBo Geng — Thu, 27 Apr 2023 06:02:27 +0000

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.

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.
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().
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.
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.
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.
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

What different between drawable and mipmap in Android

ZhiBo Geng — Thu, 23 Feb 2023 10:11:42 +0000

In old project code, some images were use in the 'drawable' folder, and other in the 'mipmap' folder. Occasionally, I had doubts and searched for articles. But I an not understand enough. Recently, I try to find it. so I checked the content of the article one by one and found that the actual results were far from the conclusion.

Several common conclusions

Case 1 drawable will remove other densities, mipmap will retain all (the final conclusion is related to this)

When a xhdpi density phone loads this apk, Google has an optimization that will remove the other density files in the drawable folder, Just leaving only a basic drawable and the drawable-xhdpi folder, But mipmap will retain this all.

The detection method is also relatively simple. Put the same type of image (with image text for tag) in the folders to different densities folder of drawable and mipmap, Then check this installation package and application size

Case1.1 Installation package and application size

	Installation package size	Application size
drawable	13.3 MB (14,016,841 bytes)	14.04MB
mipmap	13.3 MB (14,017,191 bytes)	14.04MB

Conclusion1.1

From this, although the size of two installation packages is slightly different, considering the size of image itself (each image is more than 1MB), it can be considered that there is no difference between the images placed in the drawable and mipmap folders after the installation of the application.

Case1.2 In-app performance

Excluding the installation package situation, let's take a look at the performance in the app (use adb shell wm density to ensure density without change other info).

	100	420	800
drawable
mipmap

Conclusion1.2

From this, it can be seen that no matter which folder the file is placed in, it will be correctly displayed as its matching image resource on the phone.

Case 1.3 In-app scaling

If an imageView have scaling animation, using the image under drawable, one image will be continuously used to scale the image to achieve imageView scaling animation.

If you use the image under mipmap, the image with the closest resolution to the current resolution and larger than the current resolution will be automatically selected for scaling according.

This conclusions may be not is an common conclusions, but since there is shuch a saying, let is test it.

drawable

Small Scaling Ratio	Large Scaling Ratio

mipmap

Small Scaling Ratio	Large Scaling Ratio

Conclusion 1.3

It can be seen that the same animation is displayed throughout the scaling animation process.

Case 2 Application Performance

Google has optimized the performance of mipmap images to make them perform better.

drawable

Performance Overview	MEMORY	Average time for loading 10 images
		146

mipmap

Performance Overview	MEMORY	Average time for loading 10 images
		151

Conclusion 2

It can be seen that in the case when system loading a single image, their performance is basically the same, except for the case where this image is too small or too few to optimize the performance obviously. However, even in the case of repeated loading of images, the performance is still similar. Perhaps the optimization is only for specific types of images? If you know more details, feel free to communicate with me.

Case3 Launcher icons

While researching, it was found that the minmap folder is often recommended to only include the launcher icon of the application, this way can make performance optimize better.

	100dpi	420dpi	800dpi

Conclusion 3

It can be seen the display of application icon is consistent across different dpi settings, and the boundary value for switching the application icon is also consistent. As for the situation why this display effect is same for 420dpi and 800dpi, because app icon need to be enlarged by about 25% when selecting image resources for various reasons. ¹

At this point, you may have the same doubts as me. Since the performance of the images under drawable and mipmap is the same, whether it is in installation package or in application itself, and even the official documentation says so, why do various test results show that the performance of the two is basically consistent?

The Culprit: Bundle (.aab)

If you do not use Google Play to pushing you apk(like me), you will unfamiliar adbout this. and even many who have previously published app on Google Play are not very familiar with it. This actually appears every time we manually package an app.

Simply put, the .aab package is generally used for the Google Play store. When you download an app from the Google Play store, it will download resources from different drawables based on your phone's actual usage to reduce the size of the installation package. (In general, the phone's dpi does not change, and other resources densities will not be used until the app is uninstalled.)

The tool used in the following test is bundletool ², which simulates the process of downloading and installing an app from Google Play.

Comparison of installation packages

	Installation Package (apks) Size	Application Size
drawable	5.91 MB (6,201,543 字节)	6.22MB
mipmap	12.6 MB (13,230,670 字节)	13.26MB

In-app performance

	100	420
drawable
mipmap

It can be seen that when the image is used on the drawable folder, the application installed through the .aab package will be smaller than the one used under minmap folder, and when changing the DPI in the application, it not can longer automatically select the corresponding image according to the current DPI.

Conclusion

Based on the above tests, we can get the following conclusions.
The following conclusions do not involve performance optimization related to mipmap (mainly because we have not yet designed a clear comparison test)
The test phone model is Pixel 7, and the tested Android version is 13

When the application is built as an .apk, there is no difference between drawable or mipmap folders, whether it is in the application or in the launcher (application icon).
When the application is built as an .aab, the resources in the drawable folder will look for matching device density to keep, and unmatched resources will be deleted to ensure the size of the .apk. However, all resources files in the mipmap folder will be kept.

Can we place the images used in the application in any directory?

If your application is distributed and installed through .apk, there is no difference in principle. However, Google also has recommended instructions for the related directories, as shown below:

As we can see, mipmap directory can only save application icons in principle. Similarly, their official projects and single density resource projects also use these two folders in this way.

Is the retention mechanism of the mipmap folder in the .aab package only applicable to application icons?

After testing, it can be found that the retention mechanism of mipmap is applicable to all image resources under mipmap, whether they are application icons or not.

Related code can be accessed on my GitHub.