Architecture components - solving the lifecycle problem (Google I/O '17)
Why Stack Overflow recommends it
Stack Overflow users link it when explaining LiveData, ViewModel and lifecycle-aware components, and why Android lifecycle handling should not live in Activity callbacks.
Recommended by 3 people across 3 different months, 2017 to 2022.
What it is
A Google I/O 2017 session from the Android team introducing the Lifecycle and LiveData parts of Architecture Components. It shows how lifecycle-aware observers replace overridden Activity and Fragment callbacks, cutting fragile lifecycle code.
What people said
Recommends guglhupf · 2017-11 · Stack Overflow · on “Force LiveData Observer inside a Fragment to receive a change after coming visible again?”
Actually your activity should receive the latest state from LiveData when it is visible again, as explained in this video [this video] and described here [LINK] : Always up to date data: If a lifecycle becomes inactive, it receives the latest data upon becoming active again. For example, an activity that was in the background receives the latest data right after it returns to the foreground. I just tested it in my own application, works as described. So there must be another error in your application: Do you set the LiveData correctly from your repository class? Maybe a different thread / postValue problem?
Recommends Paresh · 2018-03 · Stack Overflow · on “How Lifecycle-Aware Components is usefull in android”
Lifecycle-aware components perform actions in response to a change in the lifecycle status of another component, such as activities and fragments. These components help you produce better-organized, and often lighter-weight code, that is easier to maintain. You should read the documentation further, It's not that lengthy though ;-) If you look at snippets written there [LINK] , it states that, in a real time application we write plenty of code which depends on life-cycle of component( e.g. Activity and Fragment ). So managing these considerable amount of code inside life-cycle method such as onStart() , onStop() is difficult to maintain. Further, there is no guarantee that, code written in o
Recommends Stephan Branczyk · 2022-01 · Stack Overflow · on “The code causes a malfunction in some phones and works on the emulator. Is there an explanation?”
Short answer: You need to place the part below inside onResume() LoadingDialog loadingDialog = new LoadingDialog(MainActivity.this); loadingDialog.StartLoadingAlertDialog(); Handler handler = new Handler(Looper.getMainLooper()); handler.postDelayed(loadingDialog::dismissDialog,3000); With that done, the splash screen will appear every time the UI thread resumes, which is going to be annoying, so you'll need to have a flag that tells you whether the splash screen was already shown, or not, and check for that condition before you execute that block of code inside onResume() Longer answer: You need to watch some videos on youtube from Google IO about the Activity lifecycle. Those Android fundam
Cites alexpfx · 2017-05 · Stack Overflow · on “Sharing data between fragments using new architecture component ViewModel”
Hmm.. I thought the viewmodel would allow us just attack the problem explained in that paragraph, using the viewmodel for communication, and not the activity, as was said in this video: [this video] But I think you're right, I still have call it using activity.
Cites EpicPandaForce · 2019-03 · Stack Overflow · on “In a fragment, how to find a view defined in the activity's layout?”
In my activity's layout, I have a view which I'd want to access from its attached fragment. No, you don't want to. How could I do it? getActivity().findViewById(R.id.blah) , but you shouldn't. But since my view is defined in the activity's layout, I can't do this. Technically you can, you just shouldn't. Could I use getActivity().findViewById? Yes, but you shouldn't. As for the correct answer, this is why they created Android Architecture Components: ViewModel / LiveData - so that you wouldn't be tempted to access views directly. You could modify the data/state shared via ViewModel in one place, and thanks to LiveData all observers would be updated with it. Therefore you never have to touch