Releasing version 1.0.0¶

Some stories and contexts of how this codebase is developed from the start and maintained to what is it today, and some other things i learn along the way while doing that during this past year

September 13, 2021 · 15 min read · 1.0.0

So it's been roughly one year since i start developing this codebase, what a journey has it become. This codebase has its' ups and down through the year, And many many changes with each versions. Some people might ask why there's no major releases, but as maintainer, i'm tempted not to release any new version with major version number until it's been officially acknowledged by DEV Chapter lead.

So a week ago, the official memo is released and we can finally say that this is the official codebase for Android.

Thanks for everyone that contributed to the codebase, everyone that gave their opinions of how the codebase should be come, or even the developers that using it.

Why codebase?¶

When i started working here, i'm still a college student with much more too learn. So before joining here, i started to wonder what technologies and libraries used around here, and from that what i already knew and what i need to learn. The fact is there's no such thing as orientation here, so i just learn it as i dive in to project.

After working for three projects here using different tech stacks for each one, made me realize that we have no standardization what so ever. Every projects have their own way to do things, and that's fine if the developers will only work for a single projects.

But sometimes developers asked to move to other projects, and because the structure and even the technologies used is different, the developer back to square one which is to learn before developing for the projects.

The other problem is for every new project, they don't have any blueprint or even foundation to start developing a new application. So they will literally build from scratch (well may be not from scratch, most likely they copy-paste stuff around from past projects).

After a while, not even someone in here is talking about it. So just like what mighty Thanos said:

How it all started?¶

My second project actually have a codebase, and it is the backbone of this codebase early stage. I referenced to it a lot when building this codebase. Some changes made to it to adjust our infrastructure, like for integration with back-end, RX transformer should able to handle how our Back-End's codebase.

After sharing it with other developers and lead developers, i started maintaining it and made some configuration to the repository to support contribution from other developers. At first, i really want to use Gitlab features as much as possible. For CI/CD i implemented Gitlab CI, for distribution i used Gitlab Packages, for documentation i used Gitlab Wikis (or even Gitlab Pages if possible but our Gitlab doesn't support it yet), etc.

But later on, IDG staffs reach out to me and told me to stop all the operation and to treat our Gitlab only for code repository. So in between version 0.3.+ and 0.4.+ there's some big migration going on to the repository. The final version is:

After that comes the hard part, actually developing the codebase.

Modularization¶

In the early stage, the codebase is just one massive Android module with different functionality. But after discussing with other Developer here, one of our Developer (Edwin Nurwansyah) gave an idea about modularization. He told me migrating to codebase will be really hard with so many things that the codebase offer and it will be such a waste for add really big codebase but not using it completely.

In my mind, i know i need to separate functions of the codebase to each module. Other than shorter import package name, it's actually really good advice. I keep it to TODO list until i find the right way to distribute the modules to projects.

Until i stumbled upon platform plugin of Gradle, it's just a module that define versions for the other module. Reading the documentation, i realize this is what Firebase use to release their Android SDK.

What i do was built a base module as platform , and move code with the same functionality to their own separate module. At first, there's 3 modules which is data, presentation, and utils. Later on, firebase module was added in version 0.5.0.

Using that, developer will only have to remember the codebase version. The platform will define which version of the module work best with one another from given codebase version.

dependencies {
        ...
        implementation "android:codebase:someVersion"
        implementation "android:codebase-data:OtherVersionIDontRemember"
        implementation "android:codebase-presentation:HowManyVersionDoIHaveToRemember"
        implementation "android:codebase-utils:OkayThisIsTooMuch"
}

dependencies {
        ...
        implementation platform("android:codebase:someVersion")
        implementation "android:codebase-data"
        implementation "android:codebase-presentation"
        implementation "android:codebase-utils"
}

Documentation¶

"Good code document itself" - some lazy software engineer

Either you need it or not, documentation is always needed. It provides necessary explanation for people comes after us, and also helping people who in the future will contribute to the project. My vision is we can just provide a link or a list for new developers to understand the whats and hows we develop program here.

Initially, we use Gitlab Wikis as the documentation using markdown files. But after the IDG accident, we know we had to move it somewhere else.

First, i search possible ways to document this codebase. And i found mkdocs, a site generator that convert markdown files to static website that can be deployed anywhere. And using Mkdocs Material as the theme, we start building the documentation for each feature using Markdown.

To document the code itself, we're using KDocs for syntax and Dokka for documentation engine. Dokka can generate the documentation as GFM, Jekyll, HTML, and even javadoc website. But it's just easier to configure it to GFM and include it to our mkdocs directory to automatically generated as the website.

Conclusion¶

I hope this projects will keep growing, developers will contribute their code to improve it, and more projects will start to adopt it to their projects.