So far, the data in the view layer has been kept in the Fragments and Activitys. Since these can be destroyed and recreated when the Android system decides to do this, the serialization and deserialization into a savedInstanceState must be done manually. Moving to ViewModels has the following advantages:
-
It's less error prone, possibly also less code. The data is not bound to the view lifecycle and hence does not have to be manually re-created
-
It provides a better separation between view logic and view data. Thus, the latter is likely mostly platform independent and could be re-used on other platforms with less effort. (View model patterns exists for iOS too, there is at least one kotlin multiplatform library in development that one might switch to in the future).
-
It will likely simplify some of the "talks to parent via listener" pattern, because some, or most of it(?) can probably be done with shared view models instead (i.e. a view model that is shared between a fragment and its parent fragment / activity).
-
It's what the cool kids use! Joking. It is actually pretty standard to use since many years and the more standard things are used in StreetComplete, the easier it is for new contributors to join
So far, the data in the view layer has been kept in the
Fragments andActivitys. Since these can be destroyed and recreated when the Android system decides to do this, the serialization and deserialization into asavedInstanceStatemust be done manually. Moving to ViewModels has the following advantages:It's less error prone, possibly also less code. The data is not bound to the view lifecycle and hence does not have to be manually re-created
It provides a better separation between view logic and view data. Thus, the latter is likely mostly platform independent and could be re-used on other platforms with less effort. (View model patterns exists for iOS too, there is at least one kotlin multiplatform library in development that one might switch to in the future).
It will likely simplify some of the "talks to parent via listener" pattern, because some, or most of it(?) can probably be done with shared view models instead (i.e. a view model that is shared between a fragment and its parent fragment / activity).
It's what the cool kids use! Joking. It is actually pretty standard to use since many years and the more standard things are used in StreetComplete, the easier it is for new contributors to join