Android-SingleSignOn

Android-SingleSignOn copied to clipboard

this is more a question than an issue ...

I'm trying to become acquainted with this library and I have noticed that in the examples Observable is used as a return type. I was wondering why Observable was chosen instead of LiveData? LiveData is lifecycle aware, integrates nicely with ViewModel, Room, etc. and appears to be the recommended data type for data holders (https://developer.android.com/jetpack/docs/guide)

First of all, thank you for showing interest in the library! :)

Honestly, I haven't heard of LiveData yet. It looks like it's a new concept (kind of similar to observable I guess). In the docs there is a little paragraph about using rxjava / rxjava2 and LiveData. I think it would be awesome to see some integration here! Since I have limited time right now and I'm still fixing some core-issues of this library, feel free to create a PR if you're able to create an example using LiveData. Would love to add support for LiveData to this library as well! :)

If you have any more questions, feel free to send me an email or text me on matrix (@david-dev:matrix.org)

We use LiveData in the Deck-app a lot. I have some methods written, that could come handy, when you are going to implement the support: https://github.com/stefan-niedermann/nextcloud-deck/blob/master/app/src/main/java/it/niedermann/nextcloud/deck/persistence/sync/adapters/db/util/LiveDataHelper.java

e.g. you can turn anything into a LiveData and stuff. Maybe this helps. If you have questions about it, you know how to contact me :wink:

AFAIK it is not possible to make network requests directly via LiveData. One would need to perform the actual Calls and map them into a new MutableLiveData instance - or transform an Observable into LiveData.

My understanding of a good Android app architecture is, that the Repository layer is responsible of delivering results from a local store (aka database) and synchronizing the contents of the database with unreliable remote resources in the background. LiveData is therefore understandable needed to watch the data of a database via repository, but since the synchronization with remote sources should be handled in the background, there is no dependency to the current state of the Activity / Fragment here in my opinion.

@schaarsc are you aware of any app which is using LiveData in the Remote Data Source layer? Maybe i am missing something here, but i have never seen something like this in the wild yet.

However, i think a valid point is to make the current SingleSignOnAccount available as a LiveData which then can be used in combination with Transformations#map or Transformations#switchMap. I therefore created a PR which adds this feature and deprecates the usage of (un)registerSharedPreferenceChangeListener.

I have not been active for quite some time, so I'm not sure how this would fit into the current state of implementations ...

The idea behind the original request was to handle all data with LiveData (local and remote). The UI would be connected to MediatorLiveData and does not need to know where the data comes from.

References:

• https://developer.android.com/jetpack/guide#addendum
• https://developer.android.com/topic/libraries/architecture/livedata#merge_livedata