So recently I was introduced to the wonderful world of Unity and its C#-based development (I will reserve my opinion about C# as a language for another day). Being mostly an Android developer, I will mainly focus on Unity over Android here. Without further delay, let’s start.
Calling Java (or Kotlin) functions from C# is pretty well documented. You mainly have 3 APIs on the Unity Engine SDK: AndroidJavaClass, AndroidJavaObject, and AndroidJavaProxy. They are pretty well documented, but I will give a quick introduction here:
Are you using Koin for dependency injection? Don’t you think it’s pretty inconvenient to manually add a Koin module to the list of loaded modules every time you create one? Have you ever forgotten to add one and then got the lovely NoBeanDefFoundException at runtime? Let’s see how to make this less error-prone by using compile-time annotations ;)
You can find repository for this project here.
If, like me, you’re a user of Koin, you know that to load Koin modules you need to either use startKoin or loadKoinModules.
So every time you declare a new Koin module, you…
If you have ever used Koin in a medium-sized project, you know that your typical Koin modules start growing ever bigger. If you have named injections as well, it’s even worse. Your Koin module definition file starts to be hundreds of lines big and pretty unreadable. So how we can refactor this?
The simplest refactor is to move each module to its own file:
However we still have some problems with this approach:
In the first part we saw how to get rid of interfaces in favor of function injection, which simplifies our code.
In this second part I will continue building on the same functional architecture, highlight some aspects missing on the first part and try to improve it.
Self-modifying code is code that can change its behavior at runtime. For example a given function can change its implementation under given circumstances. Using (and abusing) function injection can give us a lot of flexibility, almost to the level of self-modifying code without using any bytecode manipulation libraries (e.g…
Do you like clean architecture but are bored writing tens of interfaces and their impls? Instantiating tens of objects to just call their methods? Then you’ve come to the right place. Let’s get started!
A quick look at which libraries I’ll be using for this example. Nothing fancy, except maybe using Koin instead of Dagger for the sake of less boilerplate code.
Next, let’s assume we have to fetch the following color JSON from a remote API (you can find it here):
Modeling this as a Kotlin data class:
I strongly recommend making…