As for some previous comments about leaving the responsibility to the developer and/or SaveInstanceState being easier, it's quite the opposite. All the difference is in the viewModel being lifecycle-aware. With the saveInstanceState mechanism all the saving is done manually by the developer as the user navigates back and forth from one activity to the other. The view model, instead, not only survives configuration changes but also follows the activity's lifecycle hence saving and restoring the state accordingly.
My best way: Safe them in the C++ business layer via NDK. I share all the logic for all the 5 big operating systems via C++. Of course if you app doesn't really do something ... it's different
The first advanced case is quite interesting - a reusable UI element having a complex state (NewsSearchState) depending on a repository (NewsRepository). Since we don't use ViewModels there, it would be interesting to know what's the best practice of using that component. I assume that the repository will have suspend functions and in the UI element itself we cannot call those suspending functions with the coroutine scope available - it is a UI-bound scope but we need a view model scope to run the backend calls.
Same here. Looking for the best practices to do that. As we are developers we have a thing of keeping Ui and State less coupling in our mind with different layers of our architecture...
me parece un montón de boilerplate entre Navigation y State Holder para integrar todo, agregar funcionalidad / personalización y mantener los estados en la navegación 🤯😭 ... Pero se entiende perfectamente
Really confusing stuff, basically you are transferring the responsibility of what happens to the app when the system kills it to the developer, when this should be the responsibility of whoever kills the app in the first place. The system, Android, should be able to restore the app as it was, or at least, give the option to the developer of what to do, to restore it, restart it or personalize what to do and then yes, put it in the hand of the developer.
1:14 "it is impossible to completely opt out of activity recreation. Some configuration changes will always recreate the activity." Which ? When do they happen? As for the implementation here, it seems much much longer and complicated than what it used to be, of just using onSaveInstanceState, and the storage is also much longer and complicated compared to just SharedPreferences. What's the point in using those if the original method works fine and it's much simpler and shorter? This is true for both Compose and for the View model.
There are more ways to have configuration changes than simply orientation changes. Some android devices have mechanical keyboards that fold in and out. Some androids have screens that get bigger or smaller (Samsung Galaxy Fold, for example). Both of these are configuration changes that cannot be disabled by forcing the app to landscape or portrait mode. But you're very right--this does seem MUCH more complicated than the old method of using onSaveInstanceState and SharedPreferences. In my code, I am using a hybrid of SharedPreferences and ViewModel stuff. It's messy, but it also works in all cases. And it doesn't use any @Experimental annotations either.
@@scottbiggs8894 The examples you've mentioned are already covered if you check the available values in the configChanges. My question was: Which aren't supported? About ViewModel, it works only as long as the process is alive. Better to use onSaveInstanceState too. Of course, it depends on your needs.
At 12:45, the rememberNewsSearchState composable returns an object of type rememberSaveable. But, aren't composable functions supposed to have a Unit return type?
This is not framework, it is just crazy, you are copying ios just copy it correctly without hoisting(this is what smart naming is all about) us and your selfs.
Watch all the Android and Play Sessions → goo.gle/IO23_androidplay_pin
Amazing example of SavedStateProvider for View system!
Love the passion, and command of subject. Just wish it was a lot more dumbed down, with clear as mud explanations of what we are trying to do.
As for some previous comments about leaving the responsibility to the developer and/or SaveInstanceState being easier, it's quite the opposite. All the difference is in the viewModel being lifecycle-aware. With the saveInstanceState mechanism all the saving is done manually by the developer as the user navigates back and forth from one activity to the other. The view model, instead, not only survives configuration changes but also follows the activity's lifecycle hence saving and restoring the state accordingly.
My best way: Safe them in the C++ business layer via NDK. I share all the logic for all the 5 big operating systems via C++. Of course if you app doesn't really do something ... it's different
The first advanced case is quite interesting - a reusable UI element having a complex state (NewsSearchState) depending on a repository (NewsRepository). Since we don't use ViewModels there, it would be interesting to know what's the best practice of using that component. I assume that the repository will have suspend functions and in the UI element itself we cannot call those suspending functions with the coroutine scope available - it is a UI-bound scope but we need a view model scope to run the backend calls.
Same here.
Looking for the best practices to do that. As we are developers we have a thing of keeping Ui and State less coupling in our mind with different layers of our architecture...
me parece un montón de boilerplate entre Navigation y State Holder para integrar todo, agregar funcionalidad / personalización y mantener los estados en la navegación 🤯😭 ... Pero se entiende perfectamente
wow this was great thank you
Really confusing stuff, basically you are transferring the responsibility of what happens to the app when the system kills it to the developer, when this should be the responsibility of whoever kills the app in the first place. The system, Android, should be able to restore the app as it was, or at least, give the option to the developer of what to do, to restore it, restart it or personalize what to do and then yes, put it in the hand of the developer.
1:14 "it is impossible to completely opt out of activity recreation. Some configuration changes will always recreate the activity."
Which ? When do they happen?
As for the implementation here, it seems much much longer and complicated than what it used to be, of just using onSaveInstanceState, and the storage is also much longer and complicated compared to just SharedPreferences.
What's the point in using those if the original method works fine and it's much simpler and shorter?
This is true for both Compose and for the View model.
There are more ways to have configuration changes than simply orientation changes. Some android devices have mechanical keyboards that fold in and out. Some androids have screens that get bigger or smaller (Samsung Galaxy Fold, for example). Both of these are configuration changes that cannot be disabled by forcing the app to landscape or portrait mode.
But you're very right--this does seem MUCH more complicated than the old method of using onSaveInstanceState and SharedPreferences. In my code, I am using a hybrid of SharedPreferences and ViewModel stuff. It's messy, but it also works in all cases. And it doesn't use any @Experimental annotations either.
@@scottbiggs8894 The examples you've mentioned are already covered if you check the available values in the configChanges.
My question was: Which aren't supported?
About ViewModel, it works only as long as the process is alive. Better to use onSaveInstanceState too.
Of course, it depends on your needs.
At 12:45, the rememberNewsSearchState composable returns an object of type rememberSaveable.
But, aren't composable functions supposed to have a Unit return type?
If viewmodels can survive configuration changes , what is the newd to intergrate it with SavedStateHandle api ?
What is the mono font seen in the slides?
This is not framework, it is just crazy, you are copying ios just copy it correctly without hoisting(this is what smart naming is all about) us and your selfs.
Thanks for
Always save your states is a key
Very confusing
I won't to see look on the three