I know that the Paging3 library was designed to work together with RecyclerView, however I have a use case where the paged results are also presented on a map. If you look inside the PagingDataAdapter class, you will notice that it is backed by AsyncPagingDiffer. So for now, I'm trying to make it work using the AsyncPagingDiffer class, which in turn receives a ListUpdateCallback, so that UI is notified when data updates occur. Thus, as soon as ListUpdateCallback dispatches any update, I should be able to retrieve the data just by calling AsyncPagingDiffer.snapshot().
This snippet illustrates well what I'm trying to do:
class MapAdapter : ListUpdateCallback {
private val differ = AsyncPagingDataDiffer(MapDiff(), this)
suspend fun submitData(pagingData: PagingData<Foo>) {
differ.submitData(pagingData)
}
override fun onInserted(position: Int, count: Int) {
val data = differ.snapshot()
// Update UI
}
// Other callbacks...
}
but the snapshot is always empty or out of date when trying to recover it this way. In other words, the snapshot is actually available only after the callback has already been notified, which to me is unwanted behavior.
I can confirm that this approach works with Paging 2 (or whatever it is called), but I wish there was some way to use it with Paging 3 as well, as I am reluctant to downgrade other features that are underway with Paging 3.
Related
I have a BaseViewModel that basically has the function to get the user data like so:
abstract class BaseViewModel(
private val repository: BaseRepository
) : ViewModel() {
private var _userResponse: MutableLiveData<Resource<UserResponse>> = MutableLiveData()
val userResponse: LiveData<Resource<UserResponse>> get() = _userResponse
fun getUserData() = viewModelScope.launch {
_userResponse.value = Resource.Loading
_userResponse.value = repository.getLoggedInUserData()
}
}
In my Fragment, I access this data by just calling viewModel.getUserData(). This works. However, I'd like to now be able to edit the data. For example, the data class of UserResponse looks like this:
data class UserResponse(
var id: Int,
var username: String,
var email: String
)
In other fragments, I'd like to edit username and email for example. How do I do access the UserResponse object and edit it? Is this a good way of doing things? The getUserData should be accessed everywhere and that is why I'm including it in the abstract BaseViewModel. Whenever the UserResponse is null, I do the following check:
if (viewModel.userResponse.value == null) {
viewModel.getUserData()
}
If you want to be able to edit the data in userResponse, really what you're talking about is changing the value it holds, right? The best way to do that is through the ViewModel itself:
abstract class BaseViewModel(
private val repository: BaseRepository
) : ViewModel() {
private var _userResponse: MutableLiveData<Resource<UserResponse>> = MutableLiveData()
val userResponse: LiveData<Resource<UserResponse>> get() = _userResponse
fun setUserResponse(response: UserResponse) {
_userResponse.value = response
}
...
}
This has a few advantages - first, the view model is responsible for holding and managing the data, and provides an interface for reading, observing, and updating it. Rather than having lots of places where the data is manipulated, those places just call this one function instead. That makes it a lot easier to change things later, if you need to - the code that calls the function might not need to change at all!
This also means that you can expand the update logic more easily, since it's all centralised in the VM. Need to write the new value to a SavedStateHandle, so it's not lost if the app goes to the background? Just throw that in the update function. Maybe persist it to a database? Throw that in. None of the callers need to know what's happening in there
The other advantage is you're actually setting a new value on the LiveData, which means your update behaviour is consistent and predictable. If the user response changes (either a whole new one, or a change to the current one) then everything observeing that LiveData sees the update, and can decide what to do with it. It's less brittle than this idea that one change to the current response is "new" and another change is "an update" and observers will only care about one of those and don't need to be notified of the other. Consistency in how changes are handled will avoid bugs being introduced later, and just make it easier to reason about what's going on
There's nothing stopping you from updating the properties of the object held in userResponse, just like there's nothing stopping you from holding a List in a LiveData, and adding elements to that list. Everything with a reference to that object will see the new data, but only if they look at it. The point of LiveData and the observer pattern is to push updates to observers, so they can react to changes (like, say, updating text displayed in a UI). If you change one of the vars in that data class, how are you going to make sure everything that needs to see those changes definitely sees them? How can you ensure that will always happen, as the app gets developed, possibly by other people? The observer pattern is about simplifying that logic - update happens, observers are notified, the end
If you are going to do things this way, then I'd still recommend putting an update function in your VM, and let that update the vars. You get the same benefits - centralising the logic, enabling things like persistence if it ever becomes necessary, etc. It could be as simple as
fun setUserResponse(response: UserResponse) {
_userResponse.value?.run {
id = response.id
username = response.username
email = response.email
}
}
and if you do decide to go with the full observer pattern for all changes later, everything is already calling the function the right way, no need for changes there. Or you could just make separate updateEmail(email: String) etc functions, whatever you want to do. But putting all that logic in the VM is a good idea, it's kinda what it's there for
Oh and you access that object through userResponse.value if you want to poke at it - but like I said, better to do that inside a function in the VM, keep that implementation detail, null-safety etc in one place, so callers don't need to mess with it
The ideal way to update userResponse you should change/edit _userResponse so that your userResponse we'll give you the updated data.
it should be something like this
_userResponse.value = Resource<UserResponse>()
I am trying to develop a client for Hacker News using this API, just for learning how Android works, as a personal project. I tried following some tutorials, but I am stuck at a certain point.
I want to retrieve the top N stories' titles, upvotes, etc. This would be done, using this api by:
Making a request to the api to retrieve the ID's of top posts (500 of them, to be exact)
For each ID, make a request to the api's posts endpoint to retrieve the details.
It seems that I am stuck on how to create N different network requests for the posts that I want, retrieving them and putting them on a List, then displaying them on my Fragment.
I am trying to follow an MVVM pattern, with Repositories. The relevant files are here:
NewsApi.kt:
interface NewsApi {
#GET("topstories.json")
fun getTopStories() : Single<List<Int>>
#GET("item/{id}")
fun getItem(#Path("id") id: String): Single<News>
}
MainRepository.kt (I):
interface MainRepository {
fun getTopStoryIDs(): Single<List<Int>>
fun getStory(storyId: Int): Single<News>
fun getTop20Stories(): Single<List<News>>
}
The News object is a simple data class with all the JSON fields that are returned from item/{id}, so I am omitting it.
Here is my Repository, the implementation:
class DefaultMainRepository #Inject constructor(
private val api: NewsApi
) : MainRepository {
override fun getTopStoryIDs(): Single<List<Int>> {
return api.getTopStories()
}
override fun getStory(storyId: Int): Single<News> {
return api.getItem(storyId.toString())
}
override fun getTop20Stories(): Single<List<News>> {
TODO("HOW?")
}
}
The top questions I have are:
How can I make chained API calls in this way, using Retrofit / RxJava? I have reviewed previous answers using flatMap, but in my case, using a List of Int's, I do not actually know how to do that correctly.
Is this the right way to go about this? Should I just ditch the architectural choices I've made, and try to think in a wholly new way?
Say I can complete getTop20Stories (which, as the name implies, should retrieve 20 of the news, using the result from getTopStoryIDs, first 20 elements for the time should do the trick), how would I be able to retrieve data from it? Who should do the honors of retrieving the response? VM? Fragment?
Thanks in advance.
Single as a return type in your case will not be the best option because it is designed to only maintain single stream. concatMap or flatMap on Single will not either because it will try to map list of items to another list of items which is not the case
here.
Instead you could use Observable or map your Single to Observable by using toObservable() with concatMapIterable operator which maps your single item to sequence of items.
I used concatMap operator instead of flatMap because it maintains order of the list items so your data won't be mixed up.
getTopStoryIDs()
.map { it.take(20) }
.toObservable()
.concatMapIterable { it }
.concatMapSingle { singleId ->
api.getItem(singleId)
}
.toList()
.subscribe { items ->
//do something with your items
}
This code will work but it's not the best solution because you will make 20 or more api calls which will hurt your network data and device battery so I wouldn't use it if it is not completely necessary.
If you have any questions fill free to ask :)
You where on the right track with FlatMap.
Something like this should do the trick:
getTopStoryIDs().flatMap { storyId -> getStory(storyId) }
I am using the Paging library from Android Jetpack to have a paged loading behavior in my RecyclerView. Now I want a simple thing - get a signal in my UI that there is no data and the list is empty, so that I can show a message like "there are no items".
The problem is that I'm using PositionalDataSource without placeholders since I have no idea how big the list will be. Another problem is that I can only take the loaded items from the PagedList so I have no idea if more data is being currently loaded from my DataSource.
So the question is - does the PagedList or DataSource give out a signal like "i'm done loading"? That event is clearly defined in the library, since it will stop loading once it gets less data than asked, as mentioned here: Returned data must be of this size, unless at end of the list. The question is - can I get that event signaled to me somehow?
For now I see the following solution. I have implemented my DataSource.Factory just like in the Android Guide shows in this page: giving out my DataSource as a LiveData in factory. Besides, I already exposed a LiveData object from DataSource called isLoading, I use it in the UI to show a progress bar every time DataSource loads something. I'm thinking to add another LiveData called emptyResults and then I can wire both together in my UI so that I will show my "no items" message when emptyResults && !isLoading.
I wonder if there is a better way to do this.
This solution worked for me:
Add an adapter observer:
adapter?.registerAdapterDataObserver(adapterObserver)
Detect if the list is empty and 0 items are inserted
private val adapterObserver = object : RecyclerView.AdapterDataObserver() {
override fun onItemRangeInserted(positionStart: Int, itemCount: Int) {
val count = adapter?.itemCount
if (itemCount == 0 && count == 0) {
// List is empty
} else {
// List is not empty
}
}
}
I'm currently looking into incorporating the Paging Architecture library (version 2.1.0-beta01 at the time of writing) into my app. One components is a list which allows the user to delete individual items from it. This list is network-only and caching localy with Room does not make sense.
PagedList is immutable and does not support modification. I have read that having a copy of the list which is than modified and returned as the new one is the way to go. The documentation states the same:
If you have more granular update signals, such as a network API signaling an update to a single item in the list, it's recommended to load data from the network into memory. Then present that data to the PagedList via a DataSource that wraps an in-memory snapshot. Each time the in-memory copy changes, invalidate the previous DataSource, and a new one wrapping the new state of the snapshot can be created.
I currently have the basic recommended implementation to show a simple list. My DataSource looks like this:
class MyDataSource<SomeItem> : PageKeyedDataSource<Int, SomeItem>() {
override fun loadInitial(params: LoadInitialParams<Int>, callback: LoadInitialCallback<Int, SomeItem>) {
// Simple load from API and notification of `callback`.
}
override fun loadAfter(params: LoadParams<Int>, callback: LoadCallback<Int, SomeItem>) {
// Simple load from API and notification of `callback`.
}
override fun loadBefore(params: LoadParams<Int>, callback: LoadCallback<Int, SomeItem>) {
// Simple load from API and notification of `callback`.
}
}
How would a concrete implementation of an in-memory cache (without Room and without invalidating the entire dataset) as referenced in the documentation look like?
If you want to modify your list without going all the way down to the data layer, you will need to override submitList in your adapter, and then set a callback on your PagedList object. Whenever the PagedList changes, you can then copy those changes to your local dataset. This is not recommended but it's a pretty minimal hack to get working.
Here's an example:
class MyListAdapter : PagedListAdapter<MyDataItem, MyViewHolder>(MyDiffCallback()) {
/**
* This data set is a bit of a hack -- we are copying everything the PagedList loads into our
* own list. That way we can modify it. The docs say you should go all the way down to the
* data source, modify it there, and then bubble back up, but I don't think that will actually
* work for us when the changes are coming from the UI itself.
*/
private val dataSet = arrayListOf<MyDataItem>()
override fun onBindViewHolder(holder: MyViewHolder, position: Int) {
//Forces the next page to load when we reach the bottom of the list
getItem(position)
dataSet.getOrNull(position)?.let {
holder.populateFrom(it)
}
}
override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): MyViewHolder {
val view = parent.inflate(R.layout.my_view_holder)
return MyViewHolder(view)
}
class MyDiffCallback : DiffUtil.ItemCallback<MyDataItem>() {
override fun areItemsTheSame(oldItem: MyDataItem, newItem: MyDataItem) =
oldItem.id == newItem.id
override fun areContentsTheSame(oldItem: MyDataItem, newItem: MyDataItem) =
oldItem == newItem
}
override fun submitList(pagedList: PagedList<MyDataItem>?) {
pagedList?.addWeakCallback(listOf(), object : PagedList.Callback() {
override fun onChanged(position: Int, count: Int) {
dataSet.clear()
dataSet.addAll(pagedList)
}
override fun onInserted(position: Int, count: Int) {
dataSet.clear()
dataSet.addAll(pagedList)
}
override fun onRemoved(position: Int, count: Int) {
dataSet.clear()
dataSet.addAll(pagedList)
}
})
super.submitList(pagedList)
}
}
You are correct in that a DataSource is meant to hold immutable data.
I believe this is because Room and Paging Library is trying to have more opinionated design decisions and advocate for immutable data.
This is why in the official docs, they have a section for updating or mutating your dataset should invalidate the datasource when such a change occurs.
Updating Paged Data: If you have more granular update signals, such as a network API signaling an update to a single item in the list, it's recommended to load data from network into memory. Then present that data to the PagedList via a DataSource that wraps an in-memory snapshot. Each time the in-memory copy changes, invalidate the previous DataSource, and a new one wrapping the new state of the snapshot can be created.
Source: https://developer.android.com/reference/android/arch/paging/DataSource
With that in mind, I believe it's possible to solve the problem you described using a couple of steps.
This may not be the cleanest way, as it involves 2 steps.
You can get a reference the the snapshot that the PagedList is holding, which is a type MutableList. Then, you can just remove or update the item inside that snapshot, without invalidating the data source.
Then step two would be to calling something like notifyItemRemoved(index) or notifyItemChanged(index).
Since you can't force the DataSource to notify the observers of the change, you'll have to do that manually.
pagedList.snapshot().remove(index) // Removes item from the pagedList
adapter.notifyItemRemoved(index) // Triggers recyclerview to redraw/rebind to account for the deleted item.
There maybe a better solution found in your DataSource.Factory.
According to the official docs, your DataSource.Factory should be the one to emit a new PagedList once the data is updated.
Updating Paged Data: To page in data from a source that does provide updates, you can create a DataSource.Factory, where each DataSource created is invalidated when an update to the data set occurs that makes the current snapshot invalid. For example, when paging a query from the Database, and the table being queried inserts or removes items. You can also use a DataSource.Factory to provide multiple versions of network-paged lists. If reloading all content (e.g. in response to an action like swipe-to-refresh) is required to get a new version of data, you can connect an explicit refresh signal to call invalidate() on the current DataSource.
Source: https://developer.android.com/reference/android/arch/paging/DataSource
I haven't found a good solution for this second approach however.
So I have a RecyclerView with infinite scrolling. I first do a network call to my API and get a first page of 20 items.
In my ViewModel (code below), I have an observable that triggers the network call in my repository using the page number.
So, when the user scrolls to the bottom, the page number is incremented, and it triggers another network request.
Here's the code in my ViewModel:
private val scheduleObservable = Transformations.switchMap(scheduleParams) { params: Map<String, Any> ->
ScheduleRepository.schedule(params["organizationId"] as String, params["page"] as Int)
}
// This is the method I call in my Fragment to fetch another page
fun fetchSchedule(organizationId: String, page: Int) {
val params = mapOf(
"organizationId" to organizationId,
"page" to page
)
scheduleParams.value = params
}
fun scheduleObservable() : LiveData<Resource<Items>> {
return scheduleObservable
}
In my fragment, I observe scheduleObservable, and when it emits data, I append them to my RecyclerView's adapter:
viewModel.scheduleObservable().observe(this, Observer {
it?.data?.let {
if (!isAppending) {
adapter.replaceData(it)
} else {
adapter.addData(it)
}
}
})
The problem with my current implementation is that, on configuration change, I rebind my observer, and the observable emits the last fetched data. In my case, it will emit the last fetched page only.
When coming back from a configuration change, I would want to have the full list of items fetched to this point so I can repopulate the adapter with these.
I'm wondering what's the best way to solve this. Should I have two observables? Should I create a list variable in my ViewModel to store all the items fetched and use that list for my adapter?
I checked android-architecture-components on GitHub, but it's usually overkill compared for my needs (no database, no paging library, etc) and I get lost since I am still trying to wrap my head around architecture components.