KOMP - Kotlin Model Provider

Long Story Short

Nowadays, I’m working on a KMP project. During testing, I realized the need to generate model classes because manually filling in data each time felt tedious.

After a quick search, I didn’t find any existing solutions for this. So, after a quick POC, I decided to adapt my solution from my faking Swift library, called Mimic.

Luckily, since the two languages are quite similar, with only slight differences in advantages and hindrances, the main logic and solution could remain the same.

That’s the story of how and why I created the KOMP library.

How Does It Work?

The whole library is heavily built on the internal behavior of the kotlinx.serialization library, and the solution only works on classes that are annotated with @Serializable.

The main concept is simple: I create an empty JSON object and try to convert it to the desired class. Since this won’t succeed due to missing values, an exception is thrown, indicating the missing properties and their types. Based on this information, I generate the necessary values, add them to the JSON, and repeat the process until all the missing values are provided and the conversion succeeds.

Why Is It Ugly?

As I mentioned earlier, this library is built on the internal behavior of another library. Therefore, if anything changes there, this library will stop working correctly. Many recommendations and principles, like SOLID or the Law of Demeter, state that you should not do this, and I totally agree. This is why I don’t recommend using it in production code.

On the other hand, its functionality to create a whole complex model class for testing purposes with only an annotation is handy enough to use during testing—at least in my opinion.

How Could It Be Better?

• If it were part of the serialization library instead of a standalone one, it would be able to access the property names and types directly, rather than extracting them from exception messages. However, this functionality may not fit well within a serialization library.

• If the serialization library exposed the property names and types, as Swift does, then this functionality would become a documented feature. Building on this functionality would be much safer and cleaner. Implementing this would probably require a PR to expose these values. If accepted, merged, and released, KOMP could be updated accordingly.

• Using another serialization solution in the library could open up other possibilities to solve this in a more elegant way.

Why I Leave It As It Is (At Least for Now)

For me, it was a small and fun project to create and solve an issue that annoys me. To be honest, since it satisfies my requirements, I don’t feel the need to change it anymore, at least not until a new issue or function comes along that inspires me to do so.

What Is the Lesson from All of This?

If you can’t find a library that satisfies your needs, consider creating one yourself because it can be fun.

If you need to make compromises, do so, but always keep them in mind and make sure to warn about them in the documentation.

The best solution is not always the nicest; it’s the one that solves your issues.