Kotlin and ExoPlayer

One of the big things that’s changed for me, while moving from Java to Kotlin development, has been how I think about “null”. In Java, sometimes things are null and it’s not really a big deal. In Kotlin, something being null is… Well, it’s mostly annoying.

When doing media playback, particularly video playback, one will eventually want to “stop” playback, which typically means calling MediaPlayer.release() or ExoPlayer.release(). At this point, the player has to be replaced with a new instance if the user wants to listen, or watch, something else.

Because media playback is more than simply sending “play” or “pause” to our preferred player, it’s common to wrap the player in our own class to handle things such as audio focus. In this article, I’ll be using ExoPlayer for playback, and the wrapper class will be called PlayerWrapper, but the same principles apply with any other player.

Wrapping 3rd party APIs is common enough, but even more so with media, where we aren’t merely concerned with memory, but also the fact that some codecs have hardware resource constraints. Because of this, it’s vital to correctly release resources when they are no longer in use.

In the case of our wrapper class, the most obvious way to do this is to make it nullable and to set the instance to “null” after the player has called .release().

Some things, such as “pause” could be easily handled with the safe operator. After all, player?.pause() works perfectly. If the player isn’t null, it’s paused. If it is null, then there’s no reason to pause it.

Unfortunately, play is another story.

Not only is it ugly, but Kotlin’s null safety is working against us here, as our playback code is single threaded, but the compiler doesn’t know this.

After deciding I really didn’t want to handle a null PlayerWrapper, I came up with another solution: Use a backing property to contain the nullable value but always return a valid instance via a val property.

This solution would address the problem of being able to free the resources used by ExoPlayer, while also ensuring that we always have access to a non-null player during normal use.

I really didn’t like the way the code was structured above, particularly having to touch the backing property directly, so I kept thinking.

The obvious answer was to avoid the whole situation by never allowing the variable to be null. This could be accomplished by replacing the PlayerWrapper with a new instance as soon as the old one can no longer be used. Unfortunately, always holding a reference to player object, even when it isn’t in use, would partially negate the benefits of having called .release().

Fortunately there’s another way!

To use this, we first go into our playback service class and change it so that after the resources have been freed by our PlayerWrapper, we immediately create a new PlayerWrapper to replace it.

Then we update PlayerWrapper to use lazy initialization for our ExoPlayer instance:

Now we get both benefits!

PlayerWrapper is never null, and we don’t need any null-safety checks when accessing it. Also, because player isn’t created immediately when a new PlayerWrapper is created, since it will be initialized lazily, resources aren’t allocated until just before something is played.

Related posts:

Did this title get your attention? Good. Since you’re here, why don’t you grab a seat, reach over and take a sip of your favorite beverage….the one located at the top right corner of your desk. Yes…

Biconomy Futures Trading. Futures trading in cryptocurrencies has become increasingly popular in recent years, with investors seeking to capitalize on the volatility….

Blockchain technology offers a lot of promise through its novel innovations. One such innovation is decentralized finance. While it has been around for a while, it was not until the DeFi summer of…