amar_1995

    amar_1995

    2 years ago
    Is there any doc or project which uses Android compose with Android architecture components( like livedata, viewmodel, retrofit, web service) ?
    rkeazor

    rkeazor

    2 years ago
    retrofit / webservice arent architecture components, its a 3rd party Lib. LiveData doesn't really make sense in jetpact compose, neither does viewmodel.
    amar_1995

    amar_1995

    2 years ago
    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

    codeslubber

    2 years ago
    @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?
    rkeazor

    rkeazor

    2 years ago
    @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.
    Adam Powell

    Adam Powell

    2 years ago
    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
    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.
    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
    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.
    rkeazor

    rkeazor

    2 years ago
    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?
    Adam Powell

    Adam Powell

    2 years ago
    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
    amar_1995

    amar_1995

    2 years ago
    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 ?
    Adam Powell

    Adam Powell

    2 years ago
    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