If you have ever worked with LiveData you probably have written code similar to this:
class MyViewModel: ViewModel() { val loading: LiveData<Boolean>
get() = _loading private val _loading = MutableLiveData<Boolean>()}
This seems nowadays the typical way developers would expose some immutable LiveData, while being able to have a mutable version inside the implementation we would write data into.
Every time I saw, or even had to write, this kind of code something cringed inside me. As I quoted in one of my talks this feeling in our brain is for real:
And why you should avoid using the “NewApi” suppression!
The idea of “Compat” libraries was probably one of the key aspects of Android dominating the mobile space. Other than with iOS, Android users often could not update their operating system after a new version launch, simply as their phones won’t allow them to, the Android problem of fragmentation. But developers still wanted to use the latest features to compete. The solution was simple: instead of adding new APIs to the operating system, you shipped those directly with your app by using a “backport” version Google gave you.
The idea of LiveData was an interesting one. Based on the idea of reactive streams, that was on the peak at that time with RxJava plus adding automatic lifecycle handling — a problem on Android. LiveData had bad timing though. It arrived just before Kotlin made its impact in the Android community and sometimes both don't play that nice together. Let’s explore why and what can happen!
The good and the bad
The idea of LiveData was pretty simple: a lifecycle-aware implementation of the Observable pattern. In addition, if you resubscribe, you will get the last emitted value again. …
Even if you live on the Kotlin side of things maybe once in a while you also check Swift code. If you do, you probably noticed how similar both languages are. To me, Kotlin looks more concise but I’m also biased as I work with Kotlin daily. On the other hand, Swift has some great features too. One is the guard keyword, a really nice tool Swift developers have that we are missing. Can we bring it to Kotlin?
What is guard?
guard is used to exit a block of code early, if a given condition is not met. …
I guess many of us love Elvis, both the artist and the operator in Kotlin. But it can lead to some hidden pitfalls if you are not aware of how it works.
I only realized recently when Vladimir Zdravkovic put some code on twitter and ask us to guess what it’s printing:
Avoiding implicit connections and learn how extension functions can help you writing good APIs
Writing your classes with a good API is hard but important. As the writer is trying to make it easy for the user, we sometimes tend to repeat ourselves by adding convenient methods.
Think about the List interface in Java. To check if there are no elements in the list we could check list.getLength() == 0 or we simply ask for isEmpty().
The 2nd one reads much better. But it also adds a duplication and implicit connection between the two: If the list is empty, it can’t contain any elements! This must be respected by every implementer of the interface!
…
How tools made us forget how to write sane constructors
In an ideal world, developers get smarter every day. The code we write this year should be better than the code we wrote 10 years ago, which in turn should be better than the code 20 years ago. Today we have better tools, more modern languages, and better practices.
But as often in life, we realize we are not living in that ideal world. In nearly every codebase I see today, there are things that would shock a developer two decades ago. …
A pragmatic guide to dependency injection on Android
Over the years many of us used different frameworks for dependency injection (DI). I remember writing an article about Transfuse a couple of years ago for a German magazine. Before that when I was working for eBay Kleinanzeigen we had a complete self-written DI approach. There was no magic and therefore it taught me a lot about the internals of those frameworks. Later at Groupon, I introduced Dagger1 in the Merchant app, which at some point was migrated to Toothpick aligning with the consumer app, who moved there from RoboGuice. At Sporttotal.tv…
Android’s ViewModel was a game-changer. Not only did it solve the problem of configuration changes like rotation, but it also showed to many in the community how to write more testable code. You can now test your ViewModels with simple unit tests. You might need a JUnit Rule or Extension in case you use LiveData but normally there is no need for slower Robolectric or even heavy Instrumentation tests.
Dagger
In the early days of ViewModel developers often used Dependency Injection to inject their viewModels:
@Inject lateinit var viewModel: MyViewModelIn a test that is super easy to replace as it…
Parameterized tests are a very powerful feature. Those are tests that are taking method parameters. This is very useful if we need multiple runs of the same test but with different input arguments.
JUnit5 has built-in support (similar can be achieved on JUnit4 and a specific Runner). The API provides various ways to supply the method parameters like a list of strings or the values of an enum.
Let’s look at the enum version. Let’s also assume that we have some code that allows various ways to log-in and those are summed up in this enum:
enum class Method {…
Danny Preussler
Android @ Soundcloud, Google Developer Expert, Goth, Geek, writing about the daily crazy things in developer life with #Android and #Kotlin
