You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's some scenarios in which we are sharing the livedata between different operations (getShares, createShares, removeShares()) , triggering some sort of duplicated calls when there's a successful operation for example. The app works fine so far but I think this approach may be improved.
The basic implementation of a viewmodel is based on a livedata that is explicitly used to get the data, not to edit or even delete it, since for those cases the changes should be automatically propagated to that livedata.
Why are we using livedata for more cases apart from getting shares? Because we need to propagate network errors to UI for instance and that's not a basic case.
It would be great to work on splitting up the class responsible for warning the active observers into different ones so that creation and edition/deletion/other operations can be easily distinguishable and do not interfere between them.
Duplicate NetworkBoundResources: separate getShares and other operations
There's some scenarios in which we are sharing the livedata between different operations (getShares, createShares, removeShares()) , triggering some sort of duplicated calls when there's a successful operation for example. The app works fine so far but I think this approach may be improved.
The basic implementation of a viewmodel is based on a livedata that is explicitly used to get the data, not to edit or even delete it, since for those cases the changes should be automatically propagated to that livedata.
Why are we using livedata for more cases apart from getting shares? Because we need to propagate network errors to UI for instance and that's not a basic case.
It would be great to work on splitting up the class responsible for warning the active observers into different ones so that creation and edition/deletion/other operations can be easily distinguishable and do not interfere between them.
PR
App: #2569
The text was updated successfully, but these errors were encountered: