I don't get the advantage of using these over what we already have, of onSaveInstanceState for saved-state and of sharedPreferences over the storage solution presented here. It's much longer and complicated here.
Not to mention, not type-safe. It's very easy to store data in SavedStateHandle that will crash your app due to their type. For example, storing data of type Set. Set is supported (because LinkedHashSet is Serializable), Parcelable is supported, but their combination isn't! Once you use Set, your items need to be Serializable too. But due to type erasure, SavedStateHandle won't detect that the combination is invalid and the app will simply crash in runtime. The relevant comment in SavedStateHandle's code says it all: // type erasure ¯\_(ツ)_/¯, we won't eagerly check elements contents Thanks Google!
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.
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
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.
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...
At 12:45, the rememberNewsSearchState composable returns an object of type rememberSaveable. But, aren't composable functions supposed to have a Unit return type?
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.
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
![ได้เวลา! พาน้องแฝดฉีดวัคซีนครบ 1 เดือน🫣 [cc] แดนแพทตี้ SS2 | EP.52 |](http://i.ytimg.com/vi/IzeLtaXBLNE/mqdefault.jpg)
![[UNCUT] “บอสณวัฒน์” ลากไส้!! ใครหนุนหลัง "แม่ตั๊ก ป๋าเบียร์" I คนดังนั่งเคลียร์ I 30 ก.ย. 67](http://i.ytimg.com/vi/QlD7mU2KKRk/mqdefault.jpg)
Watch all the Android and Play Sessions → goo.gle/IO23_androidplay_pin
As usual, overly complex. Hopefully someone has the interest in writing an open source library that drastically simplifies how state is managed.
I don't get the advantage of using these over what we already have, of onSaveInstanceState for saved-state and of sharedPreferences over the storage solution presented here.
It's much longer and complicated here.
Well it's not complex...
Not to mention, not type-safe. It's very easy to store data in SavedStateHandle that will crash your app due to their type. For example, storing data of type Set. Set is supported (because LinkedHashSet is Serializable), Parcelable is supported, but their combination isn't! Once you use Set, your items need to be Serializable too. But due to type erasure, SavedStateHandle won't detect that the combination is invalid and the app will simply crash in runtime.
The relevant comment in SavedStateHandle's code says it all:
// type erasure ¯\_(ツ)_/¯, we won't eagerly check elements contents
Thanks Google!
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.
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
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.
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...
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.
Very confusing
At 12:45, the rememberNewsSearchState composable returns an object of type rememberSaveable.
But, aren't composable functions supposed to have a Unit return type?
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.
Amazing example of SavedStateProvider for View system!
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
If viewmodels can survive configuration changes , what is the newd to intergrate it with SavedStateHandle api ?
I won't to see look on the three
wow this was great thank you
What is the mono font seen in the slides?
Thanks for
Always save your states is a key