Streamline Your Compose Multiplatform Library Development with The Template: Seamless Environment Setup, and Automated Documentation and Package Deployment
When I first learned about Compose Multiplatform, I was eager to try it out on my local machine. However, I couldn’t find a pre-built template in Android Studio for creating new projects with Compose Multiplatform. Building it from scratch would be time-consuming and tedious, and I was afraid my excitement would diminish before I could even get started.
Thankfully, JetBrains anticipated this issue and provided an excellent project template. It comes with the necessary Compose library dependencies and establishes the basic architecture for Compose Multiplatform projects. Additionally, it includes sample projects for each supported platform and is set up correctly. With these templates in hand, we can quickly run the sample projects and experience the magic of Compose Multiplatform.
Action Needed
After experimenting a bit, I decided to expand my existing Compose library to make it compatible with Compose Multiplatform. Initially, I decided to write shared UI components directly in the shared module using the official application template and it worked well during testing. However, I encountered issues when it came to packaging and releasing the project. The shared module contained both our sample code and the UI library code that needed to be published. This resulted in increased package size and a leak of sample codes. Additionally, when generating API documentation with Dokka, we noticed that it included irrelevant APIs as well.
Upon encountering these issues, I recognized the need to restructure the project. Thus, I reconstructed the project structure based on JetBrains’ CMM template. I also added support for document generation, automated deployment, and Maven automatic release capability. This template allows developers to focus solely on implementing core functions. Once development is complete, they can use the pre-configured tasks in the template to publish the library and deploy documents to GitHub Pages.
Refactoring project
The first major change is to restructure the project by completely isolating the sample code from the project code.
The two pictures above provide a comparison of the project structure before and after reconstruction. Three main changes are evident.
- Created a new Sample folder and moved all * Apps to this file
- Move the shared module from the original root directory to the sample file for the * App that depends on it.
- A new “lib” module has been created in the root directory to store the logic related to externally released libraries.
The advantage of this reconstruction is that it separates the code for the library into its own module, ensuring that the private code for example is completely isolated from the public code for the library. We will only apply documentation and release-related plugins in the lib module. This means we can freely add example logic in the sample directory without impacting external products.
Publish plugin configuration
The second change is the automated release of the project. The release of the project can be said to be the most commonly used feature by third-party library developers. After completing development, we need to release a new version and upload it to third-party platforms for other developers to download and use. The most popular platform is Maven Central, but its release process can be complicated. Besides creating an account and configuring local keys, the following steps are required for each new version release:
- In the project, package and push the project code to the Maven platform by calling the publish task provided by the maven-publish plugin
- Log in to the Maven platform and manually submit the package just pushed for release.
- After waiting for the Maven platform to pass the review, manually release the new version of the package
For projects that require frequent releases, the current process is cumbersome. It involves logging into the Maven platform and manually performing the release each time. To simplify this process, we commonly use third-party release plugins during development. The most popular one is Vanniktech’s gradle-maven-publish-plugin. This plugin automates the drop and release process on the Maven platform. All we need to do is provide the project’s POM information, and we can easily perform a one-click release.
Therefore, I have also introduced the plugin and completed the configuration in this template project. Developers can directly use the plugin to publish projects by simply replacing the POM information in the template with their own project information.
mavenPublishing {
// publishToMavenCentral(SonatypeHost.DEFAULT)// or when publishing to https://s01.oss.sonatype.org
publishToMavenCentral(SonatypeHost.S01, automaticRelease = true)
signAllPublications()
coordinates("com.example.mylibrary", "mylibrary-runtime", "1.0.0")
pom {
name.set(project.name)
description.set("A description of what my library does.")
inceptionYear.set("2023")
url.set("https://github.com/username/mylibrary/")
licenses {
license {
name.set("The Apache License, Version 2.0")
url.set("http://www.apache.org/licenses/LICENSE-2.0.txt")
distribution.set("http://www.apache.org/licenses/LICENSE-2.0.txt")
}
}
developers {
developer {
id.set("username")
name.set("User Name")
url.set("https://github.com/username/")
}
}
scm {
url.set("https://github.com/username/mylibrary/")
connection.set("scm:git:git://github.com/username/mylibrary.git")
developerConnection.set("scm:git:ssh://git@github.com/username/mylibrary.git")
}
}
}Document Automation Deployment
The third change is the addition of documentation support. Documentation is often something that developers tend to avoid or postpone. Personally, I also tend to neglect it at the beginning of a project and only focus on it once the overall functionality is developed and a stable version is released.
However, it is important to note that not having complete documentation is a detrimental habit. Insufficient documentation can greatly diminish the user experience and even lead them to abandon the use of our library. As a result, it is crucial that we provide at least one basic API document upon the release of the initial version of our project. By doing so, users will be able to comprehend the purpose and usage scenarios of each API. This will not only enhance the reputation of our project but also facilitate its subsequent promotion.
To solve this problem, I automated the generation of API documentation by configuring the Dokka plugin in the project template. I also configured GitHub’s Action and combined it with GitHub Pages to automatically deploy the API documentation to the GitHub homepage.
Developers can use this template to create a project and simply add basic comments to the API they have written. GitHub Action will automatically generate the documentation and deploy it on the GitHub homepage. Whenever there is an update to the main branch code, GitHub Action will be triggered to update and deploy the API documentation. This zero-cost approach greatly reduces resistance to documentation writing and improves the coverage of API documentation.
Future plan
Lint checking and auto-formatting
The first follow-up plan is to implement Lint checking. This will involve two steps. First, we will introduce automatic formatting during code submission using githook to ensure consistent local code formatting standards. Second, we will set up automatic Lint checking through GitHub action to ensure that project code formatting standards are maintained when multiple people collaborate on development.
CI Build Automated Validation
The purpose of this plan is to ensure project stability in Multiplatform projects, which require support for at least two platforms (Android and iOS) and potentially three with Desktop. Manual project verification on each platform after developing new features can be cumbersome. Additionally, separate verification of packaging capabilities in debug and release modes for each platform is time-consuming and requires significant manpower. To address this, my plan is to configure platform verification actions in a template and build a comprehensive CI system for automated project packaging verification.
Sample
Please refer to the following repositories for detailed examples.
Summary
The overall intention of designing this template is to simplify the development of third-party libraries for Compose Multiplatform. The introduced improvements are based on the requirements I encountered while developing my own WebView project. I hope it can be helpful to everyone. Thank you!
Following Readings：
Thanks for your reading！
