There are times, when we just need the data when the app starts, and all the functionality is just a matter of work. Or we just need the app to be independent from the network and we have the data. A simple dog-race database or cat-race database doesn’t actually need online interaction at all (if there are not too many data of course). So, Room comes with a nice solution about this.
The ViewPager2 is a pretty nice rework of the ViewPager API. Some new features you may find with the ViewPager2 are: 1- Vertical scrolling. You can simply enable it by adding: android:orientation=“vertical” in the tag in your xml file. 2- Right to left support: you can set the android:layoutDirection=“rtl” to enable this. 3- Support for DiffUtil, because it is based on RecyclerView. 4 - Fragments improved support, which we will talk about below.
Kotlin is a very a pretty nice adoptive language and user friendly. It really replaced Java from my everyday programming. However, it was not enough. We all know that groovy runs on JVM. So, why do I even need a new language just for my builds? Can’t it be Java? So Java is the basic language for the JVM, Kotlin runs on JVM, Groovy runs on JVM and my build system has a separated language from my business logic system.
Conditional navigation is a little tricky when it comes to Navigation Architecture. There are plenty of nice articles and solutions about it, but I’m sharing the way I solve this important problem. So let’s consider this use case: If you don’t put HomeFragment as a start destination, you will have some serious trouble with the fragment back stack and you would need to write the onBackPressDispatcher in every fragment.
This week, I’ve been playing with service locators in Android. I made this repo with 3 different branches. One of them is using Dagger as a DI tool, the other branches are implementation with KodeIn and Koin. The app is pretty simple, just retrieves some data from a Cat API, saves them to a local Room persistence and then renders them to the screen: The screen renders just a the list of cats retrieved by the database after the data are fetched from a remote API.
Basically, in part 3 of this series we managed to fully modularize an Android app. However there are some notes that need to be taken. We didn’t cover too much about resources (res folder) in any of our parts therefore we are handling it now. Here are some things that we should notice about resources in modularization: 1- Strings. No need there for a large file of it. It’s easier when each module has access to it’s own string values rather than accessing them all from a :core_module.