Retrofit: LiveData Adapter

[evant]

Would it make sense to provide a LiveData adapter for integration with the android architecture components?

[JakeWharton]

As in LiveData<ResponseBodyType>? I'm not sure that's how it was meant to be used since it's supposed to expose a value over time and this would be a one-shot use.

[evant]

True it's on-shot, but it would provide a callback that you wouldn't have to worry about leaking.

[evant]

There's an example of this adapter in a Google sample https://github.com/googlesamples/android-architecture-components/blob/master/GithubBrowserSample/app/src/main/java/com/android/example/github/util/LiveDataCallAdapterFactory.java

[JakeWharton]

It's weird to me to expose an HTTP request as live data because it really isn't. I would think you would always have some intermediary class which allowed for things like refreshing the HTTP data and updating the existing LiveData.

Beyond that, there's major blocking factors here:

• We can't add support until these APIs are stable.
• Our build system is Maven not Gradle so we can't depend on or expose an AAR.

[jaredsburrows]

@evant Maybe ask @JoseAlcerreca to make the PR to retrofit?

@JakeWharton Are you open to switching to Gradle?

[JakeWharton]

I would switch if there's a compelling reason. LiveData is not a one though. It's pre-release so we can't depend on it, it's not widely used, and I don't see why you would model a one-shot resource as an otherwise contradictory LiveData.

As with the call adapters for things like Agera, Retrofit's extension mechanism allows third-party developers to publish libraries with integrations for libraries that we do not, and I think that's appropriate in this case.

[heinrichreimer]

You could expose it as a SingleLiveEvent.

[narko]

@JakeWharton I know this ticket is closed, but do you still consider this issue a bad practice? I am seeing quite a few posts about the topic [1] and not sure how to face this. To be honest, I am considering something similar in my project, but wanted to know if you came up with a better alternative.

Cheers!

[1] https://medium.com/@alvaro.blanco/playing-with-android-architecture-components-retrofit-part-1-9994d651cf3c

[AkshayChordiya]

@JakeWharton The LiveData API is now stable. I understand the concern of having LiveData for HTTP because HTTP is not live and how HTTP is one-time thing which doesn't match with idea of LiveData.
Maybe we could expose SingleLiveEvent as mentioned by @heinrichreimer

[cbeyls]

SingleLiveEvent dispatches the value only once to the first observer which is really not what you want most of the time. You want the result value to be dispatched to all future observers too, for example to the new Activity after a configuration change.

What could be interesting though, is to provide a LiveData implementation which is aware of the HTTP cache policy, and triggers a reload when the HTTP response expires (if it ever expires at some point in the future). However, the behavior in case of any error would have to be clearly defined.

[pcholt]

Maybe you have misunderstood the purpose of SingleLiveEvent. It's not for monitoring events that are fired only once, it's a subclass of MutableLiveData which notifies observers _only_ when setValue() is called and _not_ when the viewmodel is re-loaded during an activity restart.
https://github.com/googlesamples/android-architecture/blob/dev-todo-mvvm-live/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/SingleLiveEvent.java

[eugenebrusov]

Take a look at https://github.com/googlesamples/android-architecture-components/blob/master/GithubBrowserSample/app/src/main/java/com/android/example/github/api/GithubService.kt

LiveDataCallAdapterFactory is already implemented by Google team in this sample https://github.com/googlesamples/android-architecture-components/tree/master/GithubBrowserSample

[gooddaddy]

Retrofit2 LiveData Adapter
https://android-arsenal.com/details/1/6743

[fushenghua]

The LiveData API is now stable. I understand the concern of having LiveData for HTTP because HTTP is not live and how HTTP is one-time thing which doesn't match with idea of LiveData.
Maybe we could expose SingleLiveEvent as mentioned by @heinrichreimer

[VanDucit7]

https://github.com/VanDucit7/retrofit2-livedata-adapter

[shawnlinboy]

Take a look at https://github.com/googlesamples/android-architecture-components/blob/master/GithubBrowserSample/app/src/main/java/com/android/example/github/api/GithubService.kt

LiveDataCallAdapterFactory is already implemented by Google team in this sample https://github.com/googlesamples/android-architecture-components/tree/master/GithubBrowserSample

I turned this sample into a library, so our developer can easily intergrate Retrofit with Rxjava.

See it at: https://github.com/shawnlinboy/retrofit-livedata-adapter

[zakayothuku]

How I can use LiveData with Retrofit 2.6.0 with Coroutine's Suspend functions?