The Top 3 State Management Mistakes On Android 

True, thanks!

yea came to ask that, seems like that suffers from the same mistake as example 1? Or is there something I'm missing?

Yep what do you think about that Philipp?

For solving this I did the following but I am not sure if it works in all conditions, but should fix the race condition, let me know your comments: I created these extension methods for SavedStateHandle: fun SavedStateHandle.getUiStateFlow(initialValue: T): StateFlow = this.getStateFlow("uiState", initialValue) fun SavedStateHandle.updateUiState(uiState: StateFlow, function: (T) -> T) { synchronized(uiState) { val prevValue = uiState.value val nextValue = function(prevValue) this["uiState"] = nextValue } } now in my viewModel, I can do this to get the uiState: val uiState = savedStateHandle.getUiStateFlow( MyUiState( title = "test") ) and if I want to update the state: savedStateHandle.updateUiState(uiState) { it.copy(title = "updated") }

thanks, i was just thinking that as well.

agreed

I noticed the sync issue too. In fixing mistake 2 he reintroduced mistake 1!

To me the Android saveStateHandle API and the whole ceremony created around process death is unavailable and just not necessary. Use sharedPreferences or a database and everything should be ok.

​@@pablovaldes6022well you don't need persistent storage for everything. SaveStateHandle and persistent storage has different usecases. You simply can't blindly store everything...

There's EncryptedSharedPreference and there's also SQLCipher for database encryption and it can work with Room.

Do you want to relogin everytime you kill the apps ? That would be annoying

​@@fardalakter4395no! Create two tokens. One is an access token for a short life span and another one is a refresh token that has a long time span. When your access token expires then don't logout, just hit another api that has a refresh token in the header and it will return a new access token and refresh the token and hit that API again with the new access token... Point to note that Access token is used for authentication and authorisation of all the APIs Refresh token is used only to get new access token and new refresh token...

@@fardalakter4395 could be a fingerprint, pin to re-authenticate? That’s what normally secure apps do.

Often you can refresh an expired access token without having to login again using *drumroll*... a refresh token. I'd generally be very careful what to persist.

Shared preferences isn't deprecated :)

@@PhilippLackner this guy says it is deprecated: *"Preferences DataStore in 10min (SharedPreferences deprecated)"* by Philipp Lackner, Nov 27 ,2020 🙂

​@@ubersticks😂

@@PhilippLackner Thanks for the answer. I'll do my research to avoid questions like that. But if that said, I'm wondering if there's any advantage of learning preferences datastore over shared preferences...

​@@ccmonkey1106for simple lightweight solution shared preference is enough but for complex data and better performance especially for larger dataset data store is better as it works asynchronously so it is good for IO operations

The basics never change much :)

mutableStateOf can be used inside composable. mutableStateFlow can be used in view model. But technically you can use both inside view mode.

// class AppDataStore(context: Context) { private val dataStore: DataStore by context.dataStore(name = "app_settings") private val ONBOARDING_COMPLETED_KEY = preferencesKey("onboarding_completed") val onboardingCompleted: Flow = dataStore.data .catch { exception -> if (exception is IOException) { emit(emptyPreferences()) } else { throw exception } } .map { preferences -> preferences[ONBOARDING_COMPLETED_KEY] ?: false } suspend fun setOnboardingCompleted(completed: Boolean) { dataStore.edit { preferences -> preferences[ONBOARDING_COMPLETED_KEY] = completed } } } // class MyApp : Application() { lateinit var appDataStore: AppDataStore private set override fun onCreate() { super.onCreate() appDataStore = AppDataStore(this) } } // @Composable fun OnboardingScreen(appDataStore: AppDataStore) { val onboardingCompleted by appDataStore.onboardingCompleted.collectAsState() if (onboardingCompleted) { // Show your main app screen // ... } else { // Show onboarding screen Button(onClick = { lifecycleScope.launch { appDataStore.setOnboardingCompleted(true) } }) { Text("Finish Onboarding") } } } // class MainActivity : AppCompatActivity() { private val appDataStore by lazy { MyApp.instance.appDataStore } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { MyAppTheme { AppMainScreen(appDataStore = appDataStore) } } } } @Composable fun AppMainScreen(appDataStore: AppDataStore) { val onboardingCompleted by appDataStore.onboardingCompleted .collectAsStateWithLifecycle(lifecycle = LocalLifecycleOwner.current.lifecycle) if (onboardingCompleted) { // Show your main app screen // ... } else { // Show onboarding screen OnboardingScreen(appDataStore = appDataStore) } }

Not without doing it the hacky way. Why not just save whatever you are trying to pass into a db?

It's explained. He said both coroutines may be in the same thread. Boths coroutines first read the initial value before it is updated

​@@christianricardo4058then it's synchronized because it's executed line by line

Phillipp could you make another video explain this more?

@@christianricardo4058 I know l, but it's impossible to have race condition on the same thread.

Try changing the dispatchers and update the counter.

Yes, but not many. Feel free to apply

I think it was 2 mb (I could be wrong tho). But yes it has limited capacity.

It throws ParcelTooLarge exception when it gets full