Ability to filter AdapterCommands

[nomisRev]

I am in a scenario where I want to filter delete commands. If I do so, I enter an inconsistent state since oldList now thinks all deletes were executed.

Since oldList is private, I cannot get away with composition. As an alternative to the PR I made providing an overload method to provide "oldList". You could also opt to make oldList protected so I could use composition to add this behaviour myself which perhaps would be less confusing for users of your library.

Hope to hear back from you.

Thanks

[sockeqwe]

I am in a scenario where I want to filter delete commands.

Couldn't you just filter out the delete commands after having calculated the difference:

List<AdapterCommand> commands = commandsCalculator.diff(newItems);
// TODO iterate over commands and remove all delete commands

or

Write your own AdapterCommandProcessor (extend from this class) and do in this something different with delete commands (or ignore them)

[nomisRev]

Yes, I could but if I filter out the DeleteCommands, DiffCalculator is left in an ambiguous state.

[sockeqwe]

Could you explain why do you think that DiffCalculator could reach an ambiguous state?
The result produced by calculator.diff() is not depending nor has any reference to newList nor oldList. So modifying the result of calculator.diff() is safe and has no side effects to the internal behavior of DiffCalculator. Am I overlooking something?

[nomisRev]

If I look at the source code, the oldList is set by the first time you calculate a diff. So lets say this is [1,2,3], this results in insertRange. Now if I calculate a diff with a new list, lets say [1,2,4] that would result in a delete and a insert if I filter out the delete the list in my RV would be [1,2,3,4] but DiffCalculator thinks it is [1,2,4] because calling diff with oldList != null sets the oldList to [1,2,4].

You assume here that all AdapterCommands get executed resulting in an ambiguous state.

oldList.clear();
oldList.addAll(newList);

There was an issue in my logic. Because in following situation it wouldn't work anymore.
[1,2,3] -> [1,3,4] => delete 2 at position 1, move 3 to position 1, insert 4 at position 2.
If I filter out the delete, I get a conflict with move 3 to position 1 because 2 is still at that position.

I'm currently working around this by manipulating my data in the data layer so that a delete will not occur instead of filtering out the delete commands. And I guess that's also a better solution instead of doing logic in my view. With my requirements it would require a lot more logic in the view to get it working, and nobody wants that :D

I'm not sure if my requirements could be solved tho, but you definitely will end up in an ambiguous state if you filter out commands! Users may be unaware of that.

EDIT: I don't think my PR will be the solution for that problem (so feel free to close it). You'd still end up with inconsistency in your RecyclerView if you for example filter out deletes. As explained above, a move might conflict and RecyclerView will throw an Exception. Perhaps changing DiffCalculator to be more open for composition could offer a solution to some. But still I think the responsibility doesn't lie with DiffCalculator for this issue.

[nomisRev]

Closed due to inactivity