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:
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.
Server-driven UI is not a new concept. Neither for Android, iOS, or the web. It is quite popular in recent years, especially with the introduction of component-driven architectures such as Flux / Redux and others. Now three projects ahead with server-driven architecture in place, I want to share with you some of the challenges that we faced, and the different approaches to solving them. And I will be really happy if you share your experience too.
KtLint & Detekt are tools that help us keep our code formatted in the same way and sometimes even help us spot errors before they are actually merged to master or develop.
Most of the CI integrations already include a detekt step before the unit tests are run. To avoid waiting for the CI, you can easily integrate ktlint as part of Git hooks. So every time when you decide to commit, Git hooks run and ktlint analyzes the committed files and prevents you from pushing until you fix your errors.
We had a project where we were aiming to reuse the same codebase across mobile and TV. You have this care very often and there is this consideration of:
Should we use the Leanback Fragments?
The experienced Android TV developer
that is always ignored. We give the project a quick go and check how it works on the Android TV emulator and decide it is not worth the effort to work on TV specific codebase that may require additional devs to support it. And this is where hell breaks loose.
Let’s admit – the Android navigation library is a really cool thing but it has its own issues and drawbacks. One of the issues you can have is the TransactionTooLargeException. And here is how it happens.
Setting a toolbar title on the activity should be easy, right? But what about if you want do it through a fragment? Still easy? Well, not exactly.
The issue is that you may try to touch the toolbar in a moment where the activity is actually still not inflated. This will cause an exception immediately and your app will crash. What is the exact issue?
Gson is outdated a bit with the last commit done quite some time ago. We also had implemented the Moshi library in our Gradle dependencies and these are the 2 reasons why we decided to move away from GSON.
Recently I played around with a library that is used in multiple projects. This library has a huge list of dependencies like: coroutines, rxjava, navigation library from Google, material library, custom edit texts that come from 3rd party libraries and many more. Basically this library has also a rich set of screens available to the users that open given certain conditions. But our issues was bigger.