Ok now, for what the article is about, Koin! I have a project where I use Koin for dependency injection (or service location for the DI snobs), and I’ve been on version 2 for a long time, just because I didn’t feel like migrating. But this week I finally had the time, and decided lets go to Koin 3, fix any problems that pop up, and then after that we’ll go to Koin 4.

So I updated my grade dependencies to v3, synced, and built the app. A lot of problems appeared as expected. But overall they could be categorized into a few main problem groups.

koin.createRootScope() no longer exists

Usually in your application subclass, you have a bunch of setup code in your startKoin block, something like this:

startKoin {
    androidLogger()
    androidContext(this)
    val modules = // Some list of modules
    koin.loadModules(modules)
    koin.createRootScope()
}

In Koin 3, this method was removed, and we no longer need to create a root scope in our Application class. So you can simply delete that line.

get() is no longer available as a top-level import

In a lot of classes that extend KoinComponent. I was using the top-level get() function to satisfy dependencies.

class SomeClass: KoinComponent {
    fun saveSomeState() {
           get<LocalRepository>().saveSomeState(SomeState())
    }
}

The recommended way to fix this is to replace such usages by using inject() to provide the dependencies, as you always have in other situations.

 SomeClass: KoinComponent {
   private val localRepository: LocalRepository by inject()
    fun saveSomeState() {
           localRepository.saveSomeState(SomeState())
    }
}

If that is not possible though, as it wasn’t for me in some situations, you can still get access to get() by using getKoin().get() in any subclass of KoinComponent. So now you have something like
getKoin().get().saveOnboardingState(OnboardingState())

Changes to how to provide a ViewModel

Honestly, this was the biggest one based on how many places in the codebase needed to be refactored. The app uses the MVVM architecture with one ViewModel per activity. It is sort of enforced with a BaseActivity like this:

abstract class BaseActivity<VM : BaseViewModel> : AppCompatActivity() {
    protected lateinit var viewModel: VM
    protected abstract val viewModelClass: KClass<VM>

    open fun provideViewModel(): VM = getViewModel(viewModelClass)
}

And I can hear a few of you booing from behind. Pardon me, this is from back when inheritance in Android development was cool. The point is though, you need to provide a viewModel class and we use getViewModel() to provide it for you if it’s a regular viewModel with no runtime or assisted parameters. If you have parameters however you can just override provideViewModel().

getViewModel() is deprecated.

Ok, this brings us to the first change getViewModel() is deprecated. Instead prefer using Koin’s viewModel() delegate. Something like:
private val viewModel: AnnouncementViewModel by viewModel()

or if you have parameters
private val viewModel: AnnouncementViewModel by viewModel { parametersOf(param1, param2) }

Pretty easy, which is the reason why people love Koin in the first place!

Ok, but there’s a problem here, this doesn’t really fit in with the existing structure and architecture here, with a BaseActivity where I don’t know the exact class yet. So in order to fix this, we rely on our good friend getKoin(). And basically all usages of getViewModel(viewModelClass) become

getKoin().get<viewModelClass>() // If you have no parameters or 

// If you have some parameters to inject
getKoin().get<viewModelClass>(
        parameters = {
            parametersOf(
                  intent.getStringExtra(COMMUNITY_ID_EXTRA)
            )
        }
}

The parameter version of the above example was super important because that was a common pattern in the app. If there was a runtime parameter to be injected in an Activity or Fragment. Usually, I override provideViewModel() and use getViewModel(viewModelClass) to provide the param in the actual Activity since it should be available at that point.

getSharedViewModel is deprecated.

I have scenarios in the app where multiple fragments in the same activity are using the activity’s viewModel. In those cases, the viewModel was usually provided using
getSharedViewModel(viewModelClass). That is now deprecated, and I have replaced such usages with getActivityViewModel<viewModelClass>() instead.

Yeah, that was pretty much it! At least for my use case. Overall the migration wasn’t much work, the biggest challenge was finding the information for what is the proper replacement for certain things. Once those were figured out, everything was straightforward! I’ll probably make another post when I migrate to Koin 4, whenever I’m able to finally get to it! 😁

So, I set up the custom view/layout like so:

Nothing out of the ordinary, right?

Now the “create account” screen(or fragment, I use them interchangeably), needed to have about 10 or 11 of these input fields. I lay them out in a Constraint layout like so:

Then I run the app and notice that it takes about 1.5 seconds to load and display this screen (but why? I ask myself). I also notice that anytime I clicked on the input field and then dismissed the keyboard, it left an ugly blank space where the keyboard used to be before, and it took about a second for the layout to resize and display properly(Now, this I could not forgive).

So after searching for answers everywhere, a kind man on a discord forum was nice enough to point out that I was nesting(layering) 3 layers of ConstraintLayouts, where one of the layers was really just a wrapper and not needed, and this was possibly what was wrecking my UI performance.

The unnecessary layer in question was the ConstraintLayout in line 7 of layout_input_field.xml above.

layout_input_field with superfluous ConstraintLayout

That layout here is just a wrapper, and I don’t need it, because I’m creating an InputField(which extends ConstraintLayout) in the create account fragment XML. And inside this InputField class ‘init’ block on line 17, I’m inflating my custom input field XML whose root is a ConstraintLayout and attaching it to its parent which is “this”(the InputField object).

InputField.kt init block

The above statement becomes clear when we look at the parameter list of DataBindingUtil.inflate()

Parameter list of DataBindingUtil.inflate()

But, how do we fix this?

So here comes the tag to the rescue.

What is the merge tag?

To quote the android documentation:

The <merge /> tag is a tag used to help eliminate redundant view groups in your view hierarchy when including one layout within another. For example, if your main layout is a vertical [LinearLayout](https://developer.android.com/reference/android/widget/LinearLayout) in which two consecutive views can be re-used in multiple layouts, then the re-usable layout in which you place the two views requires its own root view. However, using another [LinearLayout](https://developer.android.com/reference/android/widget/LinearLayout) as the root for the re-usable layout would result in a vertical [LinearLayout](https://developer.android.com/reference/android/widget/LinearLayout) inside a vertical [LinearLayout](https://developer.android.com/reference/android/widget/LinearLayout). The nested [LinearLayout](https://developer.android.com/reference/android/widget/LinearLayout) serves no real purpose other than to slow down your UI performance.

So, to use it, I swapped out the ConstraintLayout for the merge tag, like so:

Don’t forget to include tools:parentTag in your merge tag, this helps you retain the design preview that you would have with the parent layout, you inflate into.

Doing something as simple as this, reduced the fragment load and display time by more than 50%, it also eliminated the keyboard ugly blank space issue, because the layout could resize faster.

The End

Can’t believe I’ve spent this much time writing about an XML tag 😂. But sometimes little things can make a big difference, as this did for me, and I’m usually only motivated to write about stuff I figure out after going through a fair bit of trouble to find or fix. Which would explain why it took me over a year to write my second article(that and procrastination). Anyway, it's good to be back.

A common usage of listeners that you likely have come across, if you’re a bit experienced in Android development, is the built-in onClickListener of a button. We usually set the onClickListener on a button, with the code that should run when the button is clicked, which is the event in this case. In Java, it usually looks like this:

Button button = findViewById(R.id.example); button.setOnClickListener(new View.OnClickListener(){ @Override public void onClick(View view) { //Do some work here } });

But besides what I described above, we can create our custom listeners with callbacks attached to events that are fired from certain areas of our code.

But why?

Here are some cases where we might need to create a custom listener:

• When we need to emit an event up from a fragment to an activity

• When we need to emit an event up from within an adapter to an activity or fragment

In general, a listener is useful when you have a “child object” and a “parent object” or handler, where a parent object is an object that creates a new instance of the child object. And we have some work that needs to be done in the parent object, but also needs to be done only when a certain event occurs in the child object. So we have to find a way to communicate the fact that the event in question has occurred in the child object, to the parent object.

So how do we create a custom listener?

1. First, define an interface in the child object (adapter, fragment, POJO). Then define the events that will be fired up to the parent. These events are represented by methods in the interface. An example of how this may look like in Java is:

public interface CustomListener{

void onDataReady(Data data);

void onSubmitForm();

}

In the above example, onDataReady(Data data) and onSubmitForm() are method signatures/callbacks that represent events that may occur in the child object.

2. Next, set up a listener variable to store a particular implementation of the callbacks in our interface. The implementation of the callbacks will be defined by the parent object. So inside the child class, you can make the variable as well as a public setter method which allows the listener callbacks to be defined from the parent, like so:

private CustomListener mListener;

public void setCustomListener(CustomListener listener){ mListener = listener; }

You don’t have to use a setter method, as there are several methods to pass the listener callback implementation into the child object, such as passing it through the constructor or passing it in via a lifecycle event(such as the onAttach() event of a fragment when dealing with activity/fragment communication).

3. Now that we’ve created the listener variable, we can implement the interface on the parent class, override the methods, and put in our implementation of those methods, then set the listener implementation(which is our parent class that implements the interface), on the child object.

public class Parent implements Child.CustomListener{

//Some code

...

@Override public void onDataReady(Data data){ //some fancy implementation }

public void onSubmitForm(){ //code we want to run when this event occurs }

childObject.setCustomListener(this);

}

The above is a very common way of creating an implementation of the listener in the parent class. Another way of doing the same thing we did above is to create an instance of the custom listener inside the parent class (instead of making the parent class itself implement the interface) and setting that implementation as the custom listener for our child object, like so:

Child childObject = new Child();

Child.CustomListener listener = new Child.CustomListener(){ @Override public void onDataReady(Data data){ //some fancy implementation }

public void onSubmitForm(){ //code we want to run when this event occurs }

}

childObject.setCustomListener(listener);

Just kidding, almost there though.

4. Now the child object can fire up events to the parent using the listener, when they happen, and pass along data if any, to the parent object. For example, in the child object, this can look like:

//The event "onDataReady" has occurred in the child object and we //fire up the event to the parent using the listener

public void OnSuccess(Response response){

Data data = response.getData;

listener.onDataReady(data);

}

And that’s it, we are done setting up the custom listener! I hope you’re able to start making and using your custom listeners if you haven’t already. Or at least have gained a better understanding of them.