Finally, indeed. But I will be really glad only after Google ditches altogether this stupid memory management scheme from Android, which essentially randomly kills background processes. The system never knows what the *user* really wants to run and what not. And when user intentionally leaves processes running in the background, they are the ones *user* doesn't want to be killed. When RAM is getting low, a professionally designed system should always refuse to start more processes (ie. throw low RAM error and prompt user to close running processes *of user choice* to proceed), instead of killing running processes without user's consent. This is exactly how every OS worked, until Google came, invented stupidity and made it a new normal. Furthermore, to add insult to injury, Android *always* has loads of processes running which user doesn't want - eg. pre-installed Facebook app and many others I have *never* used, as well as some apps that I have installed for need but absolutely not needed nor used for a while at the particular moment when some really needed background app gets killed for sake of frustration. Hope the Google, with ever-more horrible UIs and ever-more bloated code will face end of its glory soon. And Apple and Microsoft too. We need something better, beginning from simplicity again.
@@TheSimoc the end of process death handling would be the end of Android itself, it's a very deeply ingrained core functionality. But I do agree it makes things difficult from time to time.
@@Zhuinden For Google, if it had will, it would be extremely easy to replace the memory management core functionality with traditional, user-controlled pre-emptive system. But because Google is famous to value stupidity and narcissistic ego with all their "new normal inventions" over customer demand, I have to agree that such change is unlikely to happen before Google goes bankrupt and Android ends. And it will happen as soon as some rival company comes up with proper, user-controlled pre-emptive memory management and bloatless software.
Hey Philip, at 1:41 The button you press on the Logcat window has been removed in the more recent releases of Android Studio. It is gone in Giraffe and (I think)) Flamingo. Perhaps even Eel, but I cannot remember. In Giraffe, it is replaced with a right-click in the actual log message area, bringing a popup menu that includes "Kill Process".
Hi Philipp, I was searching for a video on android process death and this came out on top. Great! However, I'm not going to watch this video as it's already 2 years old. In the few weeks that I've been learning Android development I quickly discovered that info, even on the official website, is rapidly outdated. Anything older than a year will probably need some "transpilation" to the present and anything older will only cause confusion and frustration. But I want to be clear that this is not your fault and I realise that you are probably suffering from that problem yourself. I really appreciate your content and in fact, I actually have a suggestion for a video, yes! I would really appreciate a video about the following topics: 1. How to freeze a public API for at least a couple of years. 2. How to have ONE public api (OEM standard library) and not a gazzillion libraries, each with their own different version and let developers only have to manually include 3rd party libraries. 3. How to contain your excitement as an engineer when you've developed a new feature and not rush to make it public as an @Experimental novelty and definitely not (though no sane person would do that) promote it as Recommended Practice. 4. How to avoid presenting a PhD level complex pattern in your API, only to realize that everyone is taking the easier but technically wrong shortcut on StackOverflow and then having to quickly introduce a new API to contain the damage. 5. How to avoid that people who write tutorials, to their dismay, find out by the time they are ready to publish an article, that the technology they used has just been deprecated. (This actually happened, I wish I had kept the url) Thanks in advance! Please send it to the Android project management. Thank you.
Thanks for doing this Philip! +1 for the "Mr. Death" video thumbnail. This example would be more effective if you demonstrated a practical way to handle realistic states in the ViewModel. Adding an update of SavedStateHandle to each variable change seems messy in a more complicated ViewModel. You alluded to the formal use of a State class - it would be awesome to demonstrate that solution while maintaining clean architecture and the observable states that the ViewModel exposes.
Hey, Philip love content always to the point.It would also nice if you have videos on services, notification, work manager broadcast receivers in conjunction with compose.
Let me tell you Phillip two days ago i was searching for "process death in android Phillip lackner" as i always search like this 😂😂about every topic in android..and i was not able to find any video...so thanks for this man
Is it possible to save the navigation state of our application? Like for example if I have 3 screens A->B->C and I have navigated till C, is there any way to save this navigated state so that whenever I return to my app, it doesn't start over from screen A?
If you use the default toolings for navigation instead of just "having a List globally in the app and then hoping for the best", then those libraries generally already save the backstack state for you, same for Activities and Fragments.
i'm trying to make a spotify clone approximately 2 months, and the biggest problem i have is killing a service when the app is getting killed (i mean, when user swipes the app on recent apps bar just like how SPotify does it.). still cannot find any answers, i wanna stop the music playing when the app is getting destroyed and also get rid of the notification. and sometimes my app is completely dying dude. i can't even explain whats going on with my app, how am i supposed to finish it
There is an 1 MB limit on bundles sent between processes, including sending them to the Android OS for it to keep it across process death (read: onSaveInstanceState).
It makes sure you can only assign a new value to the state from within the ViewModel, but you can read it from anywhere. Only the VM should be able to change the state, not the UI
Or just avoid polluting your ViewModel with compose-specific classes and use StateFlow. With the benefit of also gaining access to much more powerful filtering etc methods coming from Kotlin flows.
Hey I want to say something. Soon your channel will grow big so we will loose our network with you because then there will lot of people there so. Can you please make some group or something similar only for currently active subscribed people out there so that we stay in touch later on.
I think he has thought that the default counter value is 0 in the case when the saved state handle is empty or does not return anything... if I know it well then the general purpose of the elvis operator ?: is to be able to add default values. It was a little confusing to hear that if not null... I have been scared a bit when I heard that, my feelings were ou sh*t it looks like perhaps I missed something about the topic :-D But thank you for the video Philip, it was valuable lesson :-)
How To Make The App Keep Running In The Background Without Getting Killed By Android OS. Even If App Gets Killed Which Is Most Likely To Happen In Latest Android Versions - How To Restart The App Automatically When It Gets Killed (Without Using A Foreground Service) Can You please Make A Video On This Topic - Using Your Counter App As Example
@@Zhuinden It Seems Impossible To Keep Running The App In The Background Without Foreground Service In Latest Android !! But There Should Be A Way To Restart The App Using WorkManager or Something Like That - or May Be Broadcast Recievers
Edit: This is actually not the case, see the replies for clarification. Original comment: There is a better way (in my opinion) to simulate process death. You can enable "Don't keep activities" in the phone's developer options. This will always initiate process death every time when you put your app in the background and it will also clear the previous Activity's state so when you press back it will also be empty. Just don't forget to disable it after testing! An embarassingly big number of apps don't handle process death so those apps will malfunction and it also makes apps a little bit slower.
This isn't process death, as the process keeps running even if Android kills the Activity. This can even happen when you launch a second activity on top of a first one, where the first one will be killed as soon as the second one is launched. This does make a difference when you use dagger and singleton patterns as those singletons retain their state, while with process death even those singletons will have to be initialised again. So actually two different scenarios.
@@shlusiak That's an important distinction to make for sure, but I still think that the "dont keep activities" option actually simulates process death and thus is kinda misleading in its name. If you have a viewmodel then your activity won't lose its state on getting killed thanks to the viewmodel (if used properly ofc), but on process death, the viewmodel dies as well, thus making the activity lose state even with a viewmodel. That's why you need the saved state handle to keep the viewmodels state even on process death. Now, the thing is, if you create a simple activity with a simple viewmodel, but without a save state handle, then if you activate 'dont keep activities' and put the app in the background, the activity loses state (which should only happen on process death).
@@BapeRuLLZ False. "Don't keep activities" simulates a completely different scenario than process death, one that only happens if 'don't keep activities' is enabled. Parcelable-related errors such as BadParcelException will not occur with 'don't keep activities', and static variables / state of singletons would not be null (but after process death, they are).
@@BapeRuLLZ that is not true, the option does in fact cause activities to be destroyed if they are not in foreground, but the process does not die. You can easily test this by launching activity B from activity A and watch activity A to be destroyed while activity B is shown. The ViewModel does not survive this destruction as it is tied to the lifecycle of activity A, which is destroyed, so you lose state if you don't persist it in onSaveInstanceState() (which would call through to the SaveStateHandle). Then when you return from activity B, activity A is created again with the original savedInstanceState, but it'll get a new ViewModel, so you need to feed the saved state back in. But in either case the process itself (the App instance) stays alive and all singletons would remain loaded in memory.
Glad to hear people finally taking note of process death as an important occurring thing that must be handled
Yeah I waited with learning that way too long haha! Let's spread some awareness
Finally, indeed. But I will be really glad only after Google ditches altogether this stupid memory management scheme from Android, which essentially randomly kills background processes. The system never knows what the *user* really wants to run and what not. And when user intentionally leaves processes running in the background, they are the ones *user* doesn't want to be killed.
When RAM is getting low, a professionally designed system should always refuse to start more processes (ie. throw low RAM error and prompt user to close running processes *of user choice* to proceed), instead of killing running processes without user's consent. This is exactly how every OS worked, until Google came, invented stupidity and made it a new normal.
Furthermore, to add insult to injury, Android *always* has loads of processes running which user doesn't want - eg. pre-installed Facebook app and many others I have *never* used, as well as some apps that I have installed for need but absolutely not needed nor used for a while at the particular moment when some really needed background app gets killed for sake of frustration.
Hope the Google, with ever-more horrible UIs and ever-more bloated code will face end of its glory soon. And Apple and Microsoft too. We need something better, beginning from simplicity again.
@@TheSimoc the end of process death handling would be the end of Android itself, it's a very deeply ingrained core functionality. But I do agree it makes things difficult from time to time.
@@Zhuinden For Google, if it had will, it would be extremely easy to replace the memory management core functionality with traditional, user-controlled pre-emptive system.
But because Google is famous to value stupidity and narcissistic ego with all their "new normal inventions" over customer demand, I have to agree that such change is unlikely to happen before Google goes bankrupt and Android ends. And it will happen as soon as some rival company comes up with proper, user-controlled pre-emptive memory management and bloatless software.
Not even kidding, I too was searching for this three days back, while handling payment gateway integration. You have our back !
I love your good appearance, nice accent, and practical content. Keep going!
Please teach us about Optimization and Benchmarking techniques. I have tried learning it but I would like your point of view on this.
Hey Philip, at 1:41 The button you press on the Logcat window has been removed in the more recent releases of Android Studio. It is gone in Giraffe and (I think)) Flamingo. Perhaps even Eel, but I cannot remember. In Giraffe, it is replaced with a right-click in the actual log message area, bringing a popup menu that includes "Kill Process".
Hi Philipp, I was searching for a video on android process death and this came out on top. Great!
However, I'm not going to watch this video as it's already 2 years old. In the few weeks that I've been learning Android development I quickly discovered that info, even on the official website, is rapidly outdated. Anything older than a year will probably need some "transpilation" to the present and anything older will only cause confusion and frustration.
But I want to be clear that this is not your fault and I realise that you are probably suffering from that problem yourself.
I really appreciate your content and in fact, I actually have a suggestion for a video, yes!
I would really appreciate a video about the following topics:
1. How to freeze a public API for at least a couple of years.
2. How to have ONE public api (OEM standard library) and not a gazzillion libraries, each with their own different version and let developers only have to manually include 3rd party libraries.
3. How to contain your excitement as an engineer when you've developed a new feature and not rush to make it public as an @Experimental novelty and definitely not (though no sane person would do that) promote it as Recommended Practice.
4. How to avoid presenting a PhD level complex pattern in your API, only to realize that everyone is taking the easier but technically wrong shortcut on StackOverflow and then having to quickly introduce a new API to contain the damage.
5. How to avoid that people who write tutorials, to their dismay, find out by the time they are ready to publish an article, that the technology they used has just been deprecated. (This actually happened, I wish I had kept the url)
Thanks in advance!
Please send it to the Android project management. Thank you.
Thanks for doing this Philip! +1 for the "Mr. Death" video thumbnail. This example would be more effective if you demonstrated a practical way to handle realistic states in the ViewModel. Adding an update of SavedStateHandle to each variable change seems messy in a more complicated ViewModel. You alluded to the formal use of a State class - it would be awesome to demonstrate that solution while maintaining clean architecture and the observable states that the ViewModel exposes.
Thanks for the feedback 😊
Hey Phillip, I just Love your content and the way you explain concepts. we understand all the things very quickly.
Best Tutor Forever 😊👍
Hey, Philip love content always to the point.It would also nice if you have videos on services, notification, work manager broadcast receivers in conjunction with compose.
Let me tell you Phillip two days ago i was searching for "process death in android Phillip lackner" as i always search like this 😂😂about every topic in android..and i was not able to find any video...so thanks for this man
please consider making video about -> compose custom layout and custom modifier ...
when you have free time for demo with workmanger and keystore ?
We really need it!
Great explanation
Can you make a video on implementing pagination and live updates together from room, Firebase etc
He doesn't use Firebase anymore.
@@s-w Okay ,I don't like Firebase too but I wanna know how to implement pagination and live updates together
I think you can use Paging 3, there are some Medium posts using Pagin 3 with Firebase
Is it possible to save the navigation state of our application?
Like for example if I have 3 screens A->B->C and I have navigated till C, is there any way to save this navigated state so that whenever I return to my app, it doesn't start over from screen A?
The backstack doesn't get cleared on process death so you will be on the same screen after returning to the app, you don't have to bother with this.
If you use the default toolings for navigation instead of just "having a List globally in the app and then hoping for the best", then those libraries generally already save the backstack state for you, same for Activities and Fragments.
Understood.. thanks guys!
loonking forward for kmm
Hallo Phil, don't you wanna make tutorial video about in apps review and in apps update?
i'm trying to make a spotify clone approximately 2 months, and the biggest problem i have is killing a service when the app is getting killed (i mean, when user swipes the app on recent apps bar just like how SPotify does it.). still cannot find any answers, i wanna stop the music playing when the app is getting destroyed and also get rid of the notification. and sometimes my app is completely dying dude. i can't even explain whats going on with my app, how am i supposed to finish it
Great. I most like the testing process.
Thank you for the nice explanation 👍
You are welcome!
do you recommend save huge parcelables?
There is an 1 MB limit on bundles sent between processes, including sending them to the Android OS for it to keep it across process death (read: onSaveInstanceState).
thanks to jetpack compose we don't need to write a lot of boilerplate using rememberSaveable {}
I recommend managing your state in a viewmodel instesd
@@PhilippLackner Is there a reason for this?
But where did you get that matrix theme for your device though?
What's that "private set" that stands alone on line 14 ? I assume its a part of the above line but can't tell what it does actually..
It makes sure you can only assign a new value to the state from within the ViewModel, but you can read it from anywhere. Only the VM should be able to change the state, not the UI
It makes the Setter private, while the Getter remains public
Or just avoid polluting your ViewModel with compose-specific classes and use StateFlow. With the benefit of also gaining access to much more powerful filtering etc methods coming from Kotlin flows.
Hey I want to say something. Soon your channel will grow big so we will loose our network with you because then there will lot of people there so. Can you please make some group or something similar only for currently active subscribed people out there so that we stay in touch later on.
I have a discord server, check the video description
Thanks, But how to pass saveStateInHandle in ViewModel? or we don't need that
for example you can use Hilt
3:58
I think you meant there if it is not null, right?
I think he has thought that the default counter value is 0 in the case when the saved state handle is empty or does not return anything... if I know it well then the general purpose of the elvis operator ?: is to be able to add default values. It was a little confusing to hear that if not null... I have been scared a bit when I heard that, my feelings were ou sh*t it looks like perhaps I missed something about the topic :-D But thank you for the video Philip, it was valuable lesson :-)
How To Make The App Keep Running In The Background Without Getting Killed By Android OS.
Even If App Gets Killed Which Is Most Likely To Happen In Latest Android Versions - How To Restart The App Automatically When It Gets Killed
(Without Using A Foreground Service)
Can You please Make A Video On This Topic - Using Your Counter App As Example
Can't. Especially not without a foreground service.
@@Zhuinden It Seems Impossible To Keep Running The App In The Background Without Foreground Service In Latest Android !!
But
There Should Be A Way To Restart The App Using WorkManager or Something Like That - or May Be Broadcast Recievers
Edit: This is actually not the case, see the replies for clarification.
Original comment: There is a better way (in my opinion) to simulate process death. You can enable "Don't keep activities" in the phone's developer options. This will always initiate process death every time when you put your app in the background and it will also clear the previous Activity's state so when you press back it will also be empty. Just don't forget to disable it after testing! An embarassingly big number of apps don't handle process death so those apps will malfunction and it also makes apps a little bit slower.
This isn't process death, as the process keeps running even if Android kills the Activity. This can even happen when you launch a second activity on top of a first one, where the first one will be killed as soon as the second one is launched. This does make a difference when you use dagger and singleton patterns as those singletons retain their state, while with process death even those singletons will have to be initialised again. So actually two different scenarios.
@@shlusiak That's an important distinction to make for sure, but I still think that the "dont keep activities" option actually simulates process death and thus is kinda misleading in its name. If you have a viewmodel then your activity won't lose its state on getting killed thanks to the viewmodel (if used properly ofc), but on process death, the viewmodel dies as well, thus making the activity lose state even with a viewmodel. That's why you need the saved state handle to keep the viewmodels state even on process death. Now, the thing is, if you create a simple activity with a simple viewmodel, but without a save state handle, then if you activate 'dont keep activities' and put the app in the background, the activity loses state (which should only happen on process death).
@@BapeRuLLZ False. "Don't keep activities" simulates a completely different scenario than process death, one that only happens if 'don't keep activities' is enabled. Parcelable-related errors such as BadParcelException will not occur with 'don't keep activities', and static variables / state of singletons would not be null (but after process death, they are).
@@BapeRuLLZ that is not true, the option does in fact cause activities to be destroyed if they are not in foreground, but the process does not die. You can easily test this by launching activity B from activity A and watch activity A to be destroyed while activity B is shown. The ViewModel does not survive this destruction as it is tied to the lifecycle of activity A, which is destroyed, so you lose state if you don't persist it in onSaveInstanceState() (which would call through to the SaveStateHandle). Then when you return from activity B, activity A is created again with the original savedInstanceState, but it'll get a new ViewModel, so you need to feed the saved state back in. But in either case the process itself (the App instance) stays alive and all singletons would remain loaded in memory.
I think iphone apps always do this, my iphone 5s always reset my opened apps :')
anyway, what version that AS support private set??? thats really cool
i'm sorry, how to fixe this problem : "Unresolved reference viewModel " ?
😿
was it Vysor instead of emulator?
How to DI savedstatehandle in viewModelFactory? And how to test this using unit test?
Depends on your DI system
How different is this from persistence? Is this cleared with the app cache data?
When you normally relaunch the app it's cleared