LiveData - To set value or to postValue?
Before the times of Jetpack Compose, we used to directly observe LiveData for changes in Android components that have lifecycle, such as for example Activity and Fragment. When writing updates to the LiveData, we have two options to choose from -
postValue. The first one is synchronous operation and has to be executed on the main thread. The second one is asynchronous and can be invoked on other threads. PostValue internally schedules an update to be executed on the main thread Looper for the next Looper cycle, similar to how we can call post or postDelayed on a view.
Kotlin standard library scope functions
The Kotlin language standard library comes with numerous very useful functions. Probably the most often used ones are the scope functions
apply. In this post we will focus only on a common use case for the function
let. For further information about the others please refer to the official library documentation available here: Kotlin standard library
Android inter-process communication (IPC)
TL;DR; if you want to get a very good understanding into how Android inter-process communication works, check out the following outstanding video about the Android Binder framework internals. It is long, but I really recommend it!
Kotlin is a great programming language and I guess all Android developers have already started adopting it in their code base. However, it has a learning curve and numerous language features, which Java does not have. In order to write bug-free code, we need to be extra careful when using these new features, simply because we might make mistakes due to our years of Java coding. The following example mistake might be an extreme corner case, but it still managed to slip through code review.
The Android SDK offers an API for scheduling one time or recurring events called alarms. This is for example how your alarm clock applications work, or how a reminder for a calendar event is triggered. It’s pretty simple to use but is has some specific behavior, which you need to take in account. In this post I will describe some of the problems I have encountered when not completely understanding how this API works.
Some time has passed since the last clean architecture post. During this time the described architecture implementation has shown some of its drawbacks. In this post I will shortly describe the problems with the current implementation and propose some solutions to these problems. As usual you can find the updated version of the demo application Carbrands in its repository at GitHub - Repository Link.
Although one could write a detailed description of the concepts and ideas behind an architecture, I believe that the easiest way to understand it is to see an example. Therefore, I have built a simple demo application, which is built with the VIPER architecture in mind. The following sections describe the application and some specifics related to Android.
Android clean architecture
The first resource I would like to present is a superb blogpost by Fernando Cejas. Link
The drama we have avoided
I guess every developer has at some point tried to come up with some clean architectural model. Most of the time, however, this happens in a late stage of the project, thus incorporating any particular architecture more often than not requires major refactoring and complete rebuild of many components. This is a pretty high cost, which the product management often does not want to pay, because it will probably not bring any direct benefit or improvement to the product’s users and the project’s stakeholders. Therefore, it never happens and the problems keep deepening until somebody burns out, screams loudly or becomes increasingly unhappy with his job and eventually quits. In order to avoid such dramatic events, our team has looked for some clean architecture from the very start of our project.
Y U NO POST
Lately I have been pretty busy visiting different meetups, having some proper social life, working on my private projects and building apps at my work, thus this huge delay since the last post I have written. I want to talk about something I am particularly proud of. At the beginning of the year I have done a whole week of experiments and have put a lot of thought in order to come up with an Android version of the architecture, which our team used while building our iOS application. The main goal was to use the same familiar “architectural language”, which we have developped in our iOS application. This way we do not have to pay too high cost when switching between developing for iOS and Android. We have tried to establish a common language understood by all mobile developers, and I believe that we have succeeded. We have managed to build a pretty complex Android application with a lots of moving parts, which still feels quite right and does not bring us a lot of headaches. I have noticed that we tend to write almost the same subtasks for both platforms when implementing new features into our apps. I consider this a vital sign, showing that we have managed to achieve a harmony between our native implementations for iOS and Android. Therefore, I have decided to share some of the know-how and experience, which we have collected throughout the last months.
Today I have given a talk at a meetup of the Google Developer Group in Munich about Material Design. I have shared some insights and hands on experience collected during the process of redesiging one of my private apps - AppDetox.
A couple of weeks ago I have been developing a new feature at my job, which included a lot of user interaction with a map. Althoug the MapView class provided with the Google Play Services SDK is really nice and easy to use, I had a case, which required me to do a very specific thing - get notified when a user interacts with the map itself without actually allowing touch events to go through in some occasions. It was crucial that I get notified before the touch event reaches the MapView itself.
When you build an app you have to think about thousand different things and probably you are like me and forget all the time the small details about a particular class of the framework. A common example is showing images in your app. Sometimes its just enough to add an ImageView to the layout and don’t care too much about all its specific parameters, but most of the time you’ll need to set up at least its ScaleType. This post does not present anything novel about this class, but I’m writing it as a reminder for myself and you about common ImageView configurations and some wanted or unwanted effects resulting from them.
If you have been paying attention when installing new apps lately, you have definitely noticed the changes in the design of the pop-up dialog with permissions, which is presented to users in Google Play. Google design and user experience experts have worked together to come up with an improved version of this piece of UI. It is no longer a simple list of scary sounding names coupled with very technical and sometimes misleading short descriptions.
Although writing posts in a Jekyll based static website is fairly simple, sometimes you might bump into an unexpected WTF situations. Typically you would build the website locally on your machine to see everything looks nice, before pushing it to Github Pages. However, you can never be 100% sure that everything will work there as well, since the server which hosts your Github page is probably a very different machine running a different OS with different configuration.
I have been dealing with adding extra features and permissions to an app I have worked on lately. Through the process I bumped into many problems since I had not fully understood a couple of concepts related to them. I would like to share some of them with you so that you do not miss them when reading the official documentation.
When Fragments were introduced a couple of years ago, they were presented as reusable UI compontents which could co-exist in the same Activity. They also provide features related to backstack, which were not available before when people did the same thing using fat custom view. I will not go into much detail about all the features Fragments provide for building a dynamic and modern App UI. In this post I will focus on another property of Fragments, which many people are not familiar with, or just forget when they build Apps.
I guess every Android developer had at some point bumped into a callback hell, where you have to propagate some callback interface through thousands of objects in order to be able to do something when a user clicks on some UI element. And it gets even worse when you for example make it work across configuration changes such as orientation change. I had a similar pain a couple of weeks ago and had to come up with some solution to do the job without polluting all my UI components with huge amount of boilerplate.
This post proposes an Android development pattern I have came up with while trying to refactor an ugly looking code (I was responsible for most of it anyway). You probably are familiar with programming a simple piece of code, which at some point after adding a ton of new options starts to get seriously cumbersome. At this point one has to do some refactoring to eliminate at least the serious code duplication which inevitably already exists.
Welcome to my personal blog. This is the very first post I have published. I hope that I will find enough time to write a lot of interesting posts. I will probably not focus on a single topic or area since I have very diverse interests. Have fun reading!