amar_1995
12/25/2019, 1:10 PMrkeazor
12/25/2019, 3:47 PMamar_1995
12/25/2019, 4:13 PMcodeslubber
12/25/2019, 6:32 PMrkeazor
12/25/2019, 6:47 PMAdam Powell
12/25/2019, 9:19 PMmemo {}
-like mechanism that will automatically do the retained-instance across activity recreations for you. Ideally it'll just be anything used with memo {}
but practical concerns might end up pushing it to its own api; we'll see. Chances are it'll use the arch components ViewModel
as a transport under the hoodViewModel
directly might still make a lot of sense as a bridge between thingsFlow
in its place, but it still definitely has a place for subscription management. By contrast, @Model
is always a hot data source. We've played with the idea of adding something like LiveData's `onActive`/`onInactive` events to @Model
classes as an optional element, but the existing reactive types are already quite good for most of those related use cases@Model
object or state {}
for compose to read fromLiveData
and apply to @Model
. On one hand we'd like to avoid oversubscribing too high in the tree by manually using effect calls, but on the other adding event callbacks risks @Model
becoming a mirror of LiveData
and a few of the drawbacks it has around its active callbacks vs. its instant-read getValue()
@Model
just yet. We can always add more capabilities later if the need is overwhelming.@Model
is a plain old kotlin object that just happens to be able to notify observers when its field-backed properties change. Flow
is a reactive stream type with very well-defined subscription begin/end semantics. LiveData
exists somewhere in the middle as a data holder that has callbacks for when it is and isn't being observedLiveData
since it has an instantaneous getValue()
method - take room for example, if you get a LiveData
from a room query and just call getValue()
on it, the data will be stale or not present since the subscription active/inactive callbacks aren't invokedLiveData
you have to know whether it's just a data holder or a reactive subscription-driven instance before you access it. The behavior of getValue()
might be kind of useless to you@Model
is basically only getValue()
semantics in the form of property reads@Model
unless we have a good answer for this gotcha, and one way to not repeat it is to omit the subscription awarenessFlow
and LiveData
aren't in conflict with @Model
- they serve some different use cases in important ways and you're likely to see them side by side in compose app code.rkeazor
12/26/2019, 12:55 AMAdam Powell
12/26/2019, 1:37 AMamar_1995
12/27/2019, 6:16 AMstate
. Now the problem is that as I bind data in state
it got struck inside state closure and continuosly hitting the web-service api.
Is there any way to fix this now ?Adam Powell
12/27/2019, 4:24 PM