https://kotlinlang.org logo
Join Slack
Powered by
Is there any doc or project which uses Android com...
# compose
a
Is there any doc or project which uses Android compose with Android architecture components( like livedata, viewmodel, retrofit, web service) ?
r
retrofit / webservice arent architecture components, its a 3rd party Lib. LiveData doesn't really make sense in jetpact compose, neither does viewmodel.
a
Yes retrofit/web service isn't the part of architecture components. I want to know which architecture to follow and how to achieve it. Is there any documents or demo project which I can follow ?
c
@rkeazor how does viewmodel not make sense? just because there is the @Model annotation? that doesn’t solve the same problem as it will be stuck in a single activity or controller right?
r
@codeslubber Viewmodel in android architecture component was ment to replace RetainInstanceState api, which was ment to use as mechanisms to maintain object instance during configuration change. Jetpack compose is a framework redesign , so I dont think they will have the same issue
If your just talking about of Viewmodel in term of a Mvvm architecture. Than sure , you can do what you want , even create a presenter If you , because it's just a architecture decision.
👍🏻 2
a
current thinking is that there will be some sort of 
memo {}
-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 hood
I suspect that hybrid UIs between compose and views will be with us for quite some time though, and using 
ViewModel
directly might still make a lot of sense as a bridge between things
👌 2
in any case we've been working with having activities and fragments register more components with their respective view trees that things can tie into, and the viewmodel provider may be another good one to make easily accessible from compose in general
this will make it easier for compose to perform some basic service discovery of this sort of thing
as for LiveData, there's a lot to be said for using something like 
Flow
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
and it's easy enough to use an effect in compose to perform the subscription management and bridge over to an 
@Model
object or 
state {}
for compose to read from
there's some debate on the team of whether or not that's enough, or what we should learn from 
LiveData
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()
my personal feeling on it at the moment is that it's better to say nothing on the topic and wait and see for now, and let observable subscription effect calls fill the gap rather than adding more features to 
@Model
just yet. We can always add more capabilities later if the need is overwhelming.
➕ 1
the tension to resolve there is that there are two very different abstractions presented: 
@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 observed
but this causes some problems for 
LiveData
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 invoked
so when you have a 
LiveData
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
and 
@Model
is basically only 
getValue()
semantics in the form of property reads
so I'd like to not repeat this tension with 
@Model
unless we have a good answer for this gotcha, and one way to not repeat it is to omit the subscription awareness
👍 1
tl;dr: 
Flow
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.
👍🏻 5
r
Interesting ! I didn't think there would be much of a usecase for it in jetpack compose. Will things like constraint layout/motion layout be ported to compose?
a
yeah there's work already in progress around them. The constraint and motion solvers are already quite portable outside of a view context, it's more about working on the API and developer experience around the tooling
a
I am trying to call web service using retrofit (asynchronously) and bind the data in 
state
. 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 ?
a
Not sure what you mean precisely; you should only trigger side effects in a commit or active effect and configure the onDispose to cancel any work
5 Views
Open in Slack
PreviousNext
Powered by