In this series I have been talking about the problems with Android development and things we use to solve them. They were chronic problems and some of them are solved by the community. I think by the time Google was busy solving problems facing user side. Improvements on the development tools was limited. Release of Android Studio eased some of the pain but there were other problems.
About two years ago Google released the first Android Architecture Component which is Lifecycle. Since then more Android Architecture Components(AAC) are released to solve different problems. I think they have easy to use, well thought api. They also work together really well. The bad thing about them is some of them shouldn’t be existed and some of them should be part of the Android OS, in the first place instead of being external libraries. They are a layer above problematic parts of the system. The problems are there but if you use the architecture components you can avoid dealing with those problems. Using AAC requires a new layer of knowledge on top of Android application development most of the time.
I think I have talked about the LiveData and ViewModel with enough detail in the first and second parts of this series so I won’t cover Lifecycle and ViewModel components in this post. Let’s see what other components we have in an order of familiarity to me:
Navigation
I think navigation is my favorite. At CitizenMe we started to use navigation when we introduced new login and registration screens with magic link. The best part of it is; it prevents you to use nasty Fragment transactions if you use multiple fragments with a single activity. Fragment transactions were my nightmare on Android development. Even though I exactly know how they work there are some cases I cannot implement without going through a lot. I think I can write a whole new post about problems with fragments and fragment transactions but I will hold off for now and just advice junior devs to use this instead of trying to figure out how fragment transactions work.😞 At the moment you cannot really do it because fragment transactions are probably used in most of the current Android applications.
With Navigation Component you have enough control to do things you need without struggling with great deal of detail. You can check out the Navigation developer guide for things it can do and I think it can fulfill everything it offers nicely. If you look at the benefits it provides, you can conclude the actual problems on Android navigation without using it.
Data Binding
In early days of Android development to access views in an XML layout file from java code we had to use findViewById(id:Int) method for every single view. This introduced a lot of boilerplate code. Later on libraries like Android Annotations and Butterknife popped up and helped us to avoid findViewById(id:Int) and use annotations to do this work. Google decided to address this problem with a different approach. With Data Binding you can bind data to views from the XML definitions of the views instead of finding views. So it is opposite of finding views and setting the properties of the views.
I think the best thing about databinding is it can bind views to LiveData so when it is updated view gets updated automatically. Even though it is a cool library I am in favor of using Kotlin Android Extensions View Binding because it is easier and cleaner to use.
WorkManager
In good old days we had Service(we still have) to do things in background without getting affected by activity lifecycles. Combining them with BroadcastReceiver and AlarmManager we could schedule things to happen even the app is not working on the foreground. What can go wrong right? It turned out a lot. This allowed developers to wake up the device any time and this causes apps to drain battery and data without any restrictions. In Android API’s 19 and 23 background restrictions put in place. These restrictions caused apps not work properly and new tools introduced for background work were not backward compatible. To fix this problems WorkManager is introduced. WorkManager handles jobs with the tools available with the API level. It also allows developers to have constraints like connectivity and charging status to run the tasks.
Room
Room is one of the components that I haven’t got chance to use but I look forward to use it. It has an api similar to Jdbi which is one of my favorite libraries in Java. Room provides an api on top of SQlite for more robust database access. It saves us from trouble of dealing with cursors and creating Data objects. All we need to provide interfaces with functions taking query parameters with annotations providing SQlite queries. All the implementation and execution is done for us which is always great.
Paging
Loading huge chunks of data into memory is not ideal in a mobile device. It takes longer to fetch from a database or an API, it takes longer to deserialize data and it uses more memory. So it is a good idea to fetch enough data to show and request more when it is needed. On Android with RecyclerView this was done by listening scroll with OnScrollListener and requesting next batch of data which could be hard if you don’t know what you are doing. With Paging this is a lot easier.
As you can see it is possible to do Android development without AAC and the areas they cover are core parts of development stack. Don’t get me wrong I am not critical of the Architecture Components, they solve a lot of problems for us. But I have to say and probably I am not really fan of the out of the box Android development and thankful Architecture components for this.
Android has a really big and strong developer community which I am proud that I am a part of. Community solved some of the problems well ahead of Google. I am really happy for the constant feedback loop for the Architecture Components and I think this is the reason they are so good. We also see this interaction of Google and developers in the development of Compose. I am really hopeful that it will turn great and will see more fundamental changes like Compose in Android development.
You can find first and second part of this series here:
📝 Read this story later in Journal.
👩💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.
