Reactive Extensions (ReactiveX or Rx for short) were initially created by Erik Meijer for .NET and were revealed to the public in 2010. It was a new approach to API for asynchronous data streams that generalized observer pattern with callbacks for emitted elements (onNext), stream completion (onCompleted), and error (onError), and introduced stream-processing operators like map and filter that made working with streams of data as easy as working with collections.
Welcome to the third post of our WorkManager series. WorkManager is an Android Jetpack library that makes it easy to schedule deferrable, asynchronous tasks that must be run reliably. It is the current best practice for most background work on Android.
The SOLID principles were introduced for the first time by Robert C. Martin in the early 2000s. This paper explains the five principles even if the acronym SOLID is not used, it will be introduced later. It’s a long time ago but they are still valid today: they are the base of the Clean Architecture used in many Android applications. SOLID is an acronym: the D stands for Dependency Inversion, probably the most complicated (but also the most important) of the five principles.
I finally took the time to play with coroutines. So far I've been that person saying "I don't really see how that's easier" or "I can easily do that with some RxJava, no problem", and if it wasn't for my colleague Philipp Ebert, I'd still probably be there. But now that Room and Retrofit are fully supporting coroutines, it feels like things took a turn. Yeah, we can still stick to RxJava as much as we want, but now it's harder than ever to ignore coroutines' beauty.
With the new Android Q gesture navigation and the ever growing screen real estate, it is important to have our app displayed in full screen. Besides being awesome UX to our users, it’s also important to support the framework changes/best practices. After reading about this subject I decided to implement it on the Stinto Android App.
Metaprogramming is all around us on Android in the form of reflection, annotation processing, Gradle plugins, and standalone tools. Some of the most popular and widespread libraries in use leverage one or more of these facilities. But none of these are the perfect tool for every problem. Each has advantages and disadvantages depending on how they’re used. And choosing the wrong one can actually harm the usability of your library.
In this episode, you’ll learn all about Kotlin Sealed classes. Donn walks you through what they are, how to create them, how to use data classes, objects and regular classes to create a restricted type hierarchy.
This post expands on a section in my Writing Code That Lasts Forever talk. When I was learning object oriented programming I struggled to define boundaries between classes. Should a Chess game’s Bishop class have a move() method to reposition itself on the board? Should there even be a Bishop class? Board? Move? BishopMove? Which of these types should have interfaces? What changes if the game is online? Has undo?