Downsides of Firebase Realtime DB for Android

There are a couple of downsides we figured out in our daily work with Firebase Realtime Database for Android and I would like to share them with you here. All of them revolve around using the provided SDK for Android. So let’s start.

Data listeners cannot be stopped

If you initiate a listener to observe some data like this one for example:

mDatabase.child("users").child(userId).get().addOnSuccessListener {
    Log.i("firebase", "Got value ${it.value}")
    Log.e("firebase", "Error getting data", it)

Then you may need to cancel it if your user leaves the screen where this data is presented. There is a cancel() method that you can call but unfortunately, this cancel method only removes the listener callback but does not cancel the operation going on in the background and lets it run until this completes.

Now imagine if you require a good big chunk of data for the screen and the user just does not want to wait because he has a 3G connection. You call cancel but the operation is still there in the background. You can verify logcat for that. What happens is that this operation still uses RAM memory that your app may need for something else and you can easily hit an OOM exception.

So for querying big datasets, it is best if you have a dedicated server that returns only the data that you need to work with.

Continue reading “Downsides of Firebase Realtime DB for Android”

Creating a SonarQube custom plugin for Kotlin

In Android we decided that we want to implement a unit test performance monitor. The reason for it is that sometimes some unit tests would execute in more than 1 second and it was all because we would use the Schedulers.trampoline() RxJava scheduler instead of the TestScheduler which is part of the RX package.

Continue reading “Creating a SonarQube custom plugin for Kotlin”