Back to Basics - App Bar

Going back to the very basics of Android development

Guowei Lv

2 minute read

We often hear 3 words: app bar, action bar and tool bar. Let’s make clear of them first: - app bar: the name of the UI element/bar at the top of the app. - action bar: the previous implementation of app bar, comes with some themes by default. But should not really be used anymore. - tool bar: the current implementation of app bar. Should be used in replacement of action bar.

Guowei Lv

2 minute read

Here is one clean solution of how to combine Dagger + ViewModel + SavedStateHandle. The only difference now is that inside our ViewModel has access to SavedStateHandle. We capture this through a abstract class: abstract class SavedStateViewModel: ViewModel() { abstract fun init(savedStateHandle: SavedStateHandle) } And the ViewModel now looks like this: class MyViewModel @Inject constructor( private val fetchQuestionsUseCase: FetchQuestionsUseCase ) : SavedStateViewModel() { private lateinit var _questions: MutableLiveData<List<Question>> val questions: LiveData<List<Question>> get() = _questions override fun init(savedStateHandle: SavedStateHandle) { _questions = savedStateHandle.

Guowei Lv

2 minute read

Previously, we created a centralized ViewModelFactory which can create all ViewModels in the app: class ViewModelFactory @Inject constructor( private val myViewModelProvider: Provider<MyViewModel>, private val myViewModel2Provider: Provider<MyViewModel2> ): ViewModelProvider.Factory { override fun <T : ViewModel?> create(modelClass: Class<T>): T { return when(modelClass) { MyViewModel::class.java -> myViewModelProvider.get() as T MyViewModel2::class.java -> myViewModel2Provider.get() as T else -> throw RuntimeException("unsupported ViewModel type: $modelClass") } } } But with more and more ViewModels being added to our app, this class will grow quickly, is there a way to mitigate this?

Dependency Injection in Android With Dagger2 (12)

Centralized Factory for ViewModels

Guowei Lv

1 minute read

It is a bit cumbersome to create a Factory for each ViewModel we have. Actually, we can just create one Factory that is responsible for creating all ViewModels in the app. The Factory is very straightforward: class ViewModelFactory @Inject constructor( private val myViewModelProvider: Provider<MyViewModel>, private val myViewModel2Provider: Provider<MyViewModel2> ): ViewModelProvider.Factory { override fun <T : ViewModel?> create(modelClass: Class<T>): T { return when(modelClass) { MyViewModel::class.java -> myViewModelProvider.get() as T MyViewModel2::class.java -> myViewModel2Provider.

Dependency Injection in Android With Dagger2 (11)

ViewModel with Dagger (basic version)

Guowei Lv

1 minute read

The main advantage of using ViewModel is: it can survive configuration change. That means if you associate a ViewModel with an Activity, then after configuration change, the activity will get the same instance of that ViewModel. Of course that comes with some setup work to do on developers side. But it is not that bad, basically the activity gets its ViewModel through ViewModelProvider. If your ViewModel has empty constructor, then you can simply use: