Hi friends 👋

My name is Jaewoong Eum from South Korea and I’ve been developing open source libraries and projects related to Android for more than 3 years.

I published more than 25 Android libraries and 7 open source projects related to UI/UX, Persistence, Architecture, Popup, Animations, and many other things.

skydoves@github

I’ve learned a lot of things from these activities. So I want to share what I’ve learned from open source library activities and what kind of things are important to these activities.

Software design is more important than implementation

To be honest, I thought implementation is everything because I thought I could change the architecture and software design whenever I want but I was wrong.

Open-source libraries are not just toy projects or something for just personal use. Open-source library is a product. A lot of developers and companies might use my software. So changing my library’s interfaces, naming conventions or architecture design-related things can result in every developer and company wasting their time and resources migrating.

Here is a little example of ColorPickerView which I’ve been maintaining for 3 years. 🎨

Three years ago when I made this library, I designed only one color listener interface. Because I only needed numerical hsv color values (integer).

But after a few months, some developers and companies requested issues and sent me emails about the different use cases which needed hex string values and ARGB supports.

I thought it was not easy to change because the ColorListener is already used in many functions. And handling every new case of listeners would result in spaghetti codes. Probably adding a new interface of the listener and handling only two listeners would reduce my time. But what if there are two more new listeners that should be added? hmm, I don’t want to imagine those codes. 😏

Eventually, I chose the future instead of the present. I designed a new top-tier interface and changed the interface design so that other listeners must inherit it.

We should spend more time on software design. A well-designed interface provides flexible scalability. If not, one day it would result in high-cost to anyone who uses those interfaces including me. Before we build up buildings find out if the floor is strong enough. 💪

Consider every case and environment

Especially in Android development, we should consider every target/min SDK version, device operating environment, and other device specific aspects. Some devices work in a really poor network environment and have low specifications. It means we should implement features to support those devices as well.

If we decide the minimum and target SDK version, it means we should make it works well in every version between the minimum version to the target version. Here is the ColorPickerView example again. 🤗

This library’s minimum SDK version is 15. So I must support between version 15 to 29. Whenever a new Gradle or SDK version is released I should check it works well on the new environment. If bugs or issues occur in a library, millions of devices using a product that uses the library can be affected.

Here is an example that ColorPickerView. Crashes occurred in API 28 but worked well in the lower versions.

The problem was In Android P, the call to .getBitmap() will return the size of the original bitmap size so Drawable.getDrawable() will return a drawable with the dimensions relative to whatever the display size is. Anyways, crashes occurred in the newest target SDK so I solved the problem and released a new version as quickly as possible.

The android platform changes quickly. And there are countless environments for devices and their specification is different. So we should move quickly to changes and implement features based on various environments.

Intuitive naming convention

When we use libraries, do we memorize all functionality and study how it works? Most developers will probably not. In fact, we can’t remember all of the method names. If we could remember all of them right now, there is no guarantee that we will remember them after a few months. So we should use a readable, rememberable and intuitive naming convention. Moreover making readable codes means making maintainable codes.

Let’s suppose we use the below method in our project.

I can probably remember right now what the method does but I will definitely forget it a few months later. So using readable and intuitive naming convention is not only for others. It is also for myself in the future. We rely on IDE’s auto-complete before we look for documents. If we find the right method of what we want, we could prevent wasting our valuable time.

Here is a preview example called PowerSpinner library which I published a week ago.

Let’s suppose we should name the method for if the Spinner is expanded. In most cases, people would name it “expand-collapse”, “spread-fold” or “open-close”. It’s not bad. The naming convention implies what the Spinner will do.

But how about “down-up”? It sounds quite weird. It is hard to make a prediction of what Spinner will do. “down what”?

Maybe Open Sesame! is better.

Don’t believe much of my memory and preparing for the future is my first step to naming methods, attributes, and others.

Well-written documentations

I’ve mentioned it before, the open-source library is different from an open-source project. A library is a product. A lot of developers or companies might use your software. And they are consumers, too. So I must provide readable documentation about configurations and usages to reduce consumers’ time and resources.

skydoves@ColorPickerView

In many cases, people use open-source libraries due to a lack of time.

A few years ago, my ex-boss came to me and said “Hey, this is a really easy thing. It seems you could change this feature by the end of the day.” Yeah… Moving a building one inch to the side is easy… 😅. (We should not work in this kind of company)

Anyway, we should find open source libraries to quickly implement this feature. Then are you going to check whether the code quality is good or not? No, we can’t. How well the documents are written and how quickly the library can be imported to our project is really really important in these cases for developers.

Even if it’s not the case, well-written documentation with configurations, usages, examples or generated documentation like Javadoc might reduce many people’s resources. Whether the code quality of your project is good or bad, people don’t know even what the project is if the documentation is poor.

Workspace

I think the workspace is really really important for creating something. Because it is related to concentration directly. I almost worked at my workspace or cafe for creating open source projects.

skydoves@workspace

Conclusion

I’ve learned many more things from open source library activities.

By writing this article, I hope to inspire some people to also try to write a better open-source library. Thank you for reading this article. 💗

Here is my GitHub link.

If you have any interests, follow me for my next creations! 🤩