IssueTracker

PagedLists aren't mutable, the only modifications you can make are by sending a refresh signal, and reloading data.

To remove an item, you can do one of a few things:

1) Remove it at the DataSource.Factory level. You can potentially wrap your DataSource.Factory with another, which will hold items in memory. Then route modifications to modify the in-memory copy in your wrapper source.

This is probably a lot of code to do it this way.

2) Remove it at the adapter level. Use AsyncPagedListDiffer, and intercept events going to the adapter to act as though the item is missing (e.g. report size = pagedList.size -1 , wrap get() to do:
    index = index < removeIndex ? index : index - 1

It's a lot of possibilities for off by one errors, but this is the approach I'd generally recommend (if you don't want to do the two below).


3) Use a database to make local modifications to data that comes from network, and page from the database (this is generally what Paging expects, but if you're not using a database I know it could be a lot of code)

4) Wait for paging 3.0 in a couple months or so, which is planned to support filtering items, essentially:
    liveDataPagedList.map { pagedList.filter { !myRemovedItems.contains(it) }  }

In paging 3.0, you do not need to reload data for that filtering. As long as you've declared a cache (generally in your ViewModel) with `cachedIn`, you can do something like the following (this example is with flow, but you could do something similar with LiveData):

flowPagingData
    .cachedIn(viewModelScope)
    .combine(flowOfRemovedItems)
    .flatMapLatest(flowOfRemovedItems) { pagingData, removedItems ->
        pagingData.filter { !removedItems.contains(it) }
    }

any operations that occur after 'cachedIn' will allow downstream collection to reuse previously loaded data (including any transforms that happened prior to the cache operation). This pattern can also be used for any updated items, by using 'map' instead of 'filter'.