The workaround I did was to store the list in a va...
# android
n
The workaround I did was to store the list in a variable and then set it in
onCreateView
but it's very elegant I think
r
Store your data in a View Model , and use Android’s new Navigation Component😬
a
How would that solve the problem?
r
If you create a list in the viewmodel, and than pass it to your recyclerview, there should way your list is destroyed just because you leave the fragment. And the NavComponent makes it easy to handle the backstack
a
But we are trying to solve a problem with view bindings
One has nothing to do with the other
Oh
r
oh sorry i was answering your first question
a
I’m mixing up two things here I think
😄
r
lol
a
I was talking about @Paul Woitaschek’s problem, mixed it up, sorry!
n
yeah, I think viewmodel can't fix this. it's a view binding problem
r
Where do you create the list of data that is displayed in your recyclerview?
n
I have a livedata object in viewmodel and I subscribe to the observe callback
r
hmm than it should be fine. Unless your recreating the the livedata object or viewmodel each time you return from the fragment
a
How do you navigate from fragment to fragment?
n
Copy code
supportFragmentManager
                .beginTransaction()
                .replace(R.id.root_layout, detailsFragment, "gistDetails")
                .addToBackStack("gistsList")
                .commit()
sorry, no code identation
a
And you get the viewModel based on the fragments context I guess?
That way the ViewModel is being recreated most probably as replacing the fragment causes it to be destroyed.
Try to get the ViewModel by passing the activity to ViewModelProviders.of() instead of the fragment and see if that helps
n
oh just noticed someting, the viewmodel is being created with the activity context
that might be the problem
a
That should actually make it live
n
yes, I get it, the activity is never destroyed in this process
a
Where do you observe the LiveData?
(and fetch the ViewModel)
n
in onCreate() of the main activity
a
Wait, so the fragment does not have it’s own ViewModel?
n
should it have?
a
Well, that’s a different question 🙂
n
initially I did't use fragments, I changed to fragments later
a
So where do you observe inside the fragment?
n
I don't, i pass the list that I receive to the fragment
a
Observe it in the fragment instead
n
ok, that makes sense actually
thank you
a
Otherwise, when clicking back, you have to manually give that list to the fragment again
If the Activity then does not do anything itself with that data I would argue that the fragment should have it’s own ViewModel for that
n
exactly, that what was happening
sure, it makes much more sense
just one thing, where shoudl the viewmodel be created in the fragment? onAttach() ?
a
I usually do it in onActivityCreated IIRC
But onAttach should work, give it a try
n
onAttach works but when I press back the recyclerview is empty again
a
try onActivityCreated then
Looking at your activities/fragments and viewmodels code would help also if that doesn’t do the trick
n
onActivityCreated worked!
a
👍🏻
n
thank you so much!
the onActivityCreated is called again and the viewmodel fetchs the data again
damn, I could never realise that the fragment should have it's own viewmodel instead of the activity
a
It should not refetch the data as the same instance of the ViewModel should be returned
I would need some more of that code though
n
no, it's not refetching the data again, is just using the same instance
a
So then it works fine?
n
yeah
a
Good
n
I've moved the viewModel initialization to on Attach() and leave the observe to LiveData object in onActivityCreated()
that makes sense, right? if it was in onActivityCreated() it would create a new instance
a
No, it doesn’t. The provider of the ViewModel takes care of returning the same ViewModel
Shouldn’t matter where you call it
n
ok, it's basically a singleton under the hood
s
For best place to observe viewmodel in a Fragment, refere to https://medium.com/@BladeCoder/architecture-components-pitfalls-part-1-9300dd969808
register your observers using the special lifecycle returned by getViewLifecycleOwner() in onCreateView()
a
That was fixed in androidx 1.0.0 and suplib 28.0.0
s
Yeah and thats why it is recommended to use getViewLifeCycleOwner()
Get a LifecycleOwner that represents the Fragment's View lifecycle. In most cases, this mirrors the lifecycle of the Fragment itself, but in cases of detached Fragments, the lifecycle of the Fragment can be considerably longer than the lifecycle of the View itself. https://developer.android.com/reference/androidx/fragment/app/Fragment#getviewlifecycleowner
Either ways, it is not a big deal just to not worry about being notified for a detached fragment