Hey, I'm just seeing this video, I'm glad I've helped create more reliable apps! At times, talking about process death can feel like fighting windmills (just the other day some guy on Twitter said "onSaveInstanceState for legacy applications" what? modern apps crash when put to background?!), so happy to see this tutorial video that shows just what can happen if you're not careful :)
I literally had no idea how to test for this before you opened an issue on my github repo. onSavedInstanceState seems like the only reliable way to do this. What is he talking about legacy? lol
@@24035709 SavedStateHandle uses onSaveInstanceState internally, the guy was effectively saying that you just don't have to care about saved instance state at all (supposedly because ALL user input is ALWAYS immediately stored in the database? but I haven't really seen anyone doing that)
Note: lt applies to all members of a fragment (not just viewmodels), in case if someone misunderstood. Basically you should save all the data required to re-initialize it.
Hey Mitch. I know this is one year old video. You could also use "SaveStateHandle" to save the data during process death instead of onSaveInstanceState. Just removes your boilerplate code in activities and fragments and does the same work as onSaveInstanceState.
Hey Mitch you should check out an Android Studio plugin called "ADB Idea". You can trigger process death, clear app data, start app, restart app, and many more from just one command. Very useful!
Isn't the app loading from saved instance Everytime the app goes to the background and opens again ? .. that will prevent from loading from viewmodel right?
Yes it does load from the saved instance. But you need to save the data that you're displaying in the view. Then set it when the state is restored. And no that is not preventing loading from the viewmodel. The viewmodels data is lost. That's why we need to restore it
can someone tell me where should we initialise adapter inside fragments, most codebase shows it in either onCreateView or onViewCreated, but i think it should be initialised on onCreate since adapter is not related to android view class its just a generator of view right? and also onCreate is called once so we save on performance too, and the above code leak can also be solved using the same right? please help!
Can you make a video about jackpack navigation on modular app how to navigate on different modules? Like your app let's say you have a module call :login and you want to navigate to :blog list but is in other package how would you do?
Watch the powerful Android apps course. I do that. Also maintain a separate backstack for entries on the bottom nav codingwithmitch.com/courses/powerful-android-apps-with-jetpack-architecture/
Hi mitch , can you please also discuss a bit about App Signing from Google Play and how it works? ...as far as i got to understand is that it uploads your app with a new SHA1 key to google play store and that clashes with your original package key in database and as a result no data is loaded if you are using firebase, any idea on how to fix this ? Thanks in advance
Edit. The problem I have is with myself. I started Android development in 2009 using Eclipse and I knew all about process death lmao... I took a few year detour in enterprise Web and it was the best years:( I am caught up now finally but for a while resented you being more knowledgeable about Android. I actually don't think you are anymore so thats good ;) ... but more importantly it doesn't matter. Stupid ego bullshit:) Great video and way to be man, way to be!
This is wrong, that will destroy the activity NOT the app process. The closest approach is to set "background process limit" to "no background processes" but this is not guaranteed to happen in all devices.
`Don't keep activities` does NOT simulate process death. Static variables (and if I know correctly, even ViewModels) survive, so it's not equivalent behavior. Also, `don't keep activities` pretty much only happens if that option is enabled.
I mentioned this in the video. By the time OnViewCreated is called the views have already been restored so it's too late. The data needs to be in the viewmodel before the views are restored
Also, the `savedInstanceState` in `onViewCreated` can actually be out of date if you are returning to the Fragment via back navigation (it can run multiple times, but savedInstanceState will contain the last execution of `onSaveInstanceState`).
@@codingwithmitchi would like to point out even after process death fragment stack can be retained if you add frag as if (savedInstanceState == null) fragmentManager.beginTransaction().add(rootLayout, fragment).commit(MainFragment.newInstance())
ill be honest i have no idea what you are talking about but i still watch your videos and subbded liked many videos just to watch you talk so gorgeous beautiful beast
@@codingwithmitch I think this is the way to save state via ViewModel : Persist ViewModel state across process recreation (beta) codelabs.developers.google.com/codelabs/android-lifecycles/#6
I actually tested on a OnePlus one I literally couldn't get the process to die. Of course I mean by trying to overload it, not manually triggering it from android studio. And my OnePlus 5 is awesome to. What OnePlus have you tested with?
@@codingwithmitch I've got the 5 too More so referring to how OxygenOS kills apps wayyyyyyyyyy too fast through regular use truth be told i never tried to artificially induce a process death in this way though, all i know is how the only 2 messengers i have keep dying out of nowhere It happens on my 3 and 5, not noticed on 7t just yet because i didn't install anything on it yet
@@BRUHItsABunny Hmm interesting. My guess is that this isn't because of low memory conditions. Prob some other random thing. I can't think of any time my apps have done that and I've been using OnePlus for about 4 years. Check this out, this is what I did TRYING to get OnePlus one to kill a process. Lol I tried everything and it still wouldn't. github.com/mitchtabian/Open-API-Android-App/issues/4#issuecomment-561421167
I hate android because of this thing. I knew it from the very beginning when i've started developing. I'm so jealous for all ios devs, if the system runs out of memory it's just restarting the whole app and no problems whatsoever. and they don't even care about screen rotation. A lot of work we are doing as android devs has already been taking care of in ios. I'm thinking to switch and never come back to android again. It's 2020 now and i can't still store my data in ram. I should create some persistent secure storage solution. Room doesn't provide any security and encryption. The hacker can steal all the data from room just having root access to the user's device.
