The Top 3 State Management Mistakes On Android
Вставка
- Опубліковано 13 січ 2024
- In this video I will show you the Top 3 State Management Mistakes On Android.
💻 Let me be your mentor and become an industry-ready Android developer in 10 weeks:
pl-coding.com/drop-table-ment...
⭐ Courses with real-life practices
⭐ Save countless hours of time
⭐ 100% money back guarantee for 30 days
⭐ Become a professional Android developer now:
pl-coding.com/premium-courses/
Get my FREE PDF about 20 things you should never do in Jetpack Compose:
pl-coding.com/jetpack-compose...
Regular programming advice on my Instagram page: / _philipplackner_
Join my Discord server:
/ discord - Наука та технологія
In the part you talk about the _state.update (between 5:00 and 6:00) it's better to also use it.counter instead of state.value.counter.
True, thanks!
Your saved SavedStateHandle implementation has the same race condition bug as the previous example.
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 for the video. One note. There will not be any race condition in the first case demo. That's because both coroutines run in the main thread and there are no any suspending calls between read and write of the state. However, in case of the alternative dispatcher, such as IO or some suspending call between read and write there will be the race condition.
thanks, i was just thinking that as well.
agreed
Pretty much basics and official recommendations.. good job
Thx for the video. Tip 2 was very helpful for me.
Third one actually helped me understand a problem we've been facing for quite a long time.
SavedStateHandle API is good enough to work with, but it would be great if it's type-safe. On top of it, you have to use a synchronized block or Mutex to make it thread-safe
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...
Thanks you! Interesting way, before i did it with mutex, but now i see that more direct way.
For those trying to recreate first one, create a textfield, update it's value via viewmodel, use copy method and then try typing quickly.... I learned it the hard way... 😅
Thanks a lot Philipp for helpful tips. Your videos improve my Android Dev skills and my English as well.
Bro, u r the GOAT of Android :) great tips as always! Here is my video request: How to handle google ads/ custom ads in our apps properly
thank you philipp, i didnt know about the options shown by the right click on the logcat window xd
Very important concepts thank you, people very often encounter in this scenarios in real world projects.
One thing to consider is that if you save a token in persistent storage, you need to make sure it’s in a secure fashion (encrypted for example). Depending on the token, they may have a shorter or longer lifetime. It becomes an easy attack vector. If the default is null, we could simply ask the user to re-login?
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.
thanks for the knowledge bro!
And what about the multithreading problem on the second topic using the approache of the third topic?
Hey philip, please make video related to KMP
Let me ask: running two separate coroutines from the viewmodel scope will run the frim the context of the main thread by default, right? In this case how a race conditon will occur?
Thank you sir ❤
is any one know what Philipp did you move the bloc inside the viewModelScope using the keyboard ?
You are awesome!
hey Philip, in the first example both coroutines are running on Main thread and since none of them perform a suspend operation, they will always run one after the other and there will never be a race condition in this particular example. am i wrong somewhere? i am pretty new to coroutines so please let me know if i am wrong. thanks!
Thank You !
Hi, what about such kind of update, is it better to change as example _contactUiState.value = ContactUiState.Loading to _contactUiState.update { ContactUiState.Loading }? Similar situation as with copy, but probably happens once? Thanks
Thank You BRO
Can you please make a video on mvvm with firebase and pagination 3
This is a very interesting video. I'll try to apply these solutions in my code base.
I have a personal request, Philipp. Can you make an updated video related to preferences datastore? Shared preferences is sorta deprecated right and it would be nice to have a new guide on how to apply preferences datastore nowadays
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
Good question, where can I find resources where I can learn Android in more depth? I kind am proficient (making apps), but I realized that I lack the fundamentals.
Hi Phillip, I have a question Should we have to use mutableStateOf or mutableStateFlow for state managing?
mutableStateOf can be used inside composable.
mutableStateFlow can be used in view model.
But technically you can use both inside view mode.
Hi Philipp. I wanted to start learning kotlin and I saw that ur playlist was from 4 years ago. Is it still possible to learn from there or is it too outdated?
The basics never change much :)
Hi Philipp, can you make a video on how to make an app with an OnBoarding screen using Datastore to save onBoardingCompleted?
//
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)
}
}
i always wonder about defining all the states in a data class and copy the data class when we want to update it . doesn't it causes memory leak issues ? isn't it better to define each state as a separate stateflow and set each of their value whenever we want the state to be updated!? instead of copy the whole data class just to change one of its property each time!
Thank you
Third case can lead to an issue even without process death because the sessionTOken variable is not thread safe(memory visibility issue)
Quick question: can we pass arguments from one destination to another using parcealble data classes also?
Not without doing it the hacky way. Why not just save whatever you are trying to pass into a db?
I keep saying that savedStateHandle and whatever process API Google created to recover from process death is unscalable and not necessary.
You forgot to mention there is a limit in the amount of data you can save and the fact that it needs to be serializable makes it hard to deal with big state classes. Better off using regular preferences or a database. Also you should have mentioned that in modern devices that is very unlikely to happen.
That API is one of Google's worst API designs ever created.
Looking at your mentorship program for Feb. There still spots open?
Yes, but not many. Feel free to apply
7:50 recently i read some articles. Saved state handle can store 1mb size of data. It's true???
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
Both Coroutines were run on the Main thread. How is it possible to be in a race condition?
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.
Green -> Red Thumbnail
A counter app in Android? Flutter is ruining the world. 🤣
in reality, there could be many more errors