<div dir="ltr"><div>Yeah, not a big deal. I don't see any potential blocker then<br></div></div><br><div class="gmail_quote"><div dir="ltr">Le mar. 9 janv. 2018 à 18:44, Romain Vimont <<a href="mailto:rom@rom1v.com">rom@rom1v.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Le 9 janvier 2018 17:51:47 GMT+01:00, "Geoffrey Métais" <<a href="mailto:geoffrey.metais@gmail.com" target="_blank">geoffrey.metais@gmail.com</a>> a écrit :<br>
>No real blocker.<br>
>VLC adapters already support filtering.<br>
><br>
>Problem would be corner cases, potentially leading to bloated code:<br>
>If a user deletes 5 files consecutively, how de we do?<br>
<br>
What's the problem, then?<br>
<br>
If it's in one action, we can delete these items from the full list, and re-apply filtering/sorting.<br>
<br>
If it's consecutively in several actions, then several deletions + filter/sorting.<br>
<br>
Note that the optimisations I talked about would avoid to apply sorting in this case (deleting an item does not break sorting), and filtering is simplified (no need to retest all items). When you say "bloated code", do you refer to these optimizations?<br>
<br>
>This is the only issue I see.<br>
><br>
>(Thus, when we'll have a ViewModel layer, it will be cleaner to manage<br>
>all<br>
>of this.)<br>
<br>
Yes, using ViewModel is probably better than not, but I think these issues are quite independant of the problems that ViewModel aims to solve (IIUC, the consequence of the fact that a single _Android activity_ may be managed successively by several java _Activity_ instances, e.g. after a rotation) (although it would probably be easier to workaround issue #404).<br>
<br>
>Le mar. 9 janv. 2018 à 17:39, Romain Vimont <<a href="mailto:rom@rom1v.com" target="_blank">rom@rom1v.com</a>> a écrit :<br>
><br>
>> On Tue, Jan 09, 2018 at 03:31:42PM +0000, Geoffrey Métais wrote:<br>
>> > Yes exactly,<br>
>> ><br>
>> > And reinserting it at a wrong position could mess up the current<br>
>sorting.<br>
>> > Or if item is added at the end of the list, user is likely to not<br>
>see it<br>
>> > showing back at all.<br>
>> ><br>
>> > I don't have any good solution for this particular case.<br>
>><br>
>> Currently, the add/remove is applied to the displayed list, and the<br>
>> filters are not persistent (they depend on the sequence of change<br>
>> events, so it's inherently racy, that's why when the list is updated<br>
>> after you filtered it, the filter is lost).<br>
>><br>
>> Instead, I propose that the adapter should store:<br>
>> - the full list;<br>
>> - the current sorting;<br>
>> - the current filter.<br>
>><br>
>> Every time the list is modified for any reason (e.g. when an item is<br>
>> added or removed), the action would be applied *to the full list*<br>
>> (always on the same thread), then the sorting and filter would be<br>
>> re-applied (some optimizations may later avoid unnecessary steps). As<br>
>a<br>
>> consequence, all add/remove requests must not be applied to a<br>
>specific<br>
>> position (which would be meaningless at the time of the call).<br>
>><br>
>> Of course, filtering and sorting should still be executed outside of<br>
>the<br>
>> main thread.<br>
>><br>
>> I started to implement this last month, as a requirement to solve<br>
>> <<a href="https://code.videolan.org/videolan/vlc-android/issues/404" rel="noreferrer" target="_blank">https://code.videolan.org/videolan/vlc-android/issues/404</a>>, but I<br>
>> stopped when I found that several asynchronous changes depended on a<br>
>> particular (outdated) position: this proposal required more<br>
>preliminary<br>
>> work.<br>
>><br>
>> Do you think this may work? Do you see any "blocker" (something which<br>
>is<br>
>> obviously incompatible with this)?<br>
>><br>
>> Thank you<br>
>><br>
>> > At least, user is now warned by a snack that deletion failed. So<br>
>user<br>
>> won't<br>
>> > be surprised to see it appear later.<br>
>> ><br>
>> > For successful reinsertion, we may use diffutil for safety.<br>
>> ><br>
>> > Le mar. 9 janv. 2018 à 16:06, Romain Vimont <<a href="mailto:rom@rom1v.com" target="_blank">rom@rom1v.com</a>> a écrit<br>
>:<br>
>> ><br>
>> > > On Tue, Jan 09, 2018 at 03:36:54PM +0100, Geoffrey Métais wrote:<br>
>> > > > vlc-android | branch: master | Geoffrey Métais <<br>
>> > > <a href="mailto:geoffrey.metais@gmail.com" target="_blank">geoffrey.metais@gmail.com</a>> | Tue Jan 9 09:51:49 2018 +0100|<br>
>> > > [5cc334ce561866ee91cab70f533732c845b78829] | committer: Geoffrey<br>
>Métais<br>
>> > > ><br>
>> > > > Fix IndexOutOfBoundsException on media delete fail<br>
>> > > ><br>
>> > > > ><br>
>> > ><br>
>><br>
><a href="https://code.videolan.org/videolan/vlc-android/commit/5cc334ce561866ee91cab70f533732c845b78829" rel="noreferrer" target="_blank">https://code.videolan.org/videolan/vlc-android/commit/5cc334ce561866ee91cab70f533732c845b78829</a><br>
>> > > > ---<br>
>> > > ><br>
>> > > ><br>
>vlc-android/src/org/videolan/vlc/gui/audio/AudioBrowserAdapter.java<br>
>> | 1<br>
>> > > +<br>
>> > > ><br>
>vlc-android/src/org/videolan/vlc/gui/video/VideoListAdapter.java<br>
>> | 1<br>
>> > > +<br>
>> > > > 2 files changed, 2 insertions(+)<br>
>> > > ><br>
>> > > > diff --git<br>
>> > ><br>
>a/vlc-android/src/org/videolan/vlc/gui/audio/AudioBrowserAdapter.java<br>
>> > ><br>
>b/vlc-android/src/org/videolan/vlc/gui/audio/AudioBrowserAdapter.java<br>
>> > > > index c0df3a9a1..a2930c820 100644<br>
>> > > > ---<br>
>> a/vlc-android/src/org/videolan/vlc/gui/audio/AudioBrowserAdapter.java<br>
>> > > > +++<br>
>> b/vlc-android/src/org/videolan/vlc/gui/audio/AudioBrowserAdapter.java<br>
>> > > > @@ -333,6 +333,7 @@ public class AudioBrowserAdapter extends<br>
>> > > SortableAdapter<MediaLibraryItem, Audio<br>
>> > > ><br>
>> > > > public void addItem(final int position, final<br>
>MediaLibraryItem<br>
>> > > item) {<br>
>> > > > final List<MediaLibraryItem> referenceList =<br>
>peekLast();<br>
>> > > > + if (position < 0 || position >= referenceList.size())<br>
>> return;<br>
>> > ><br>
>> > > IMO, providing a valid position is the caller responsability.<br>
>Here, the<br>
>> > > error is silently ignored.<br>
>> > ><br>
>> > > This method is always called from a Runnable passed to<br>
>> > > UiTools.snackerWithCancel(), relying on the position of the item<br>
>when<br>
>> it<br>
>> > > was deleted. But the list may have changed in the meantime, so<br>
>adding<br>
>> > > the item back should not rely on the position.<br>
>> > ><br>
>> > > In the worst case, the position is out-of-range (with this patch<br>
>it<br>
>> does<br>
>> > > not crash anymore, but the item is not added back); but even when<br>
>it is<br>
>> > > in-range, there is no guarantee that the position is correct.<br>
>> > ><br>
>> > > > final List<MediaLibraryItem> dataList = new<br>
>> > > ArrayList<>(referenceList);<br>
>> > > > dataList.add(position,item);<br>
>> > > > update(dataList);<br>
>> > > > diff --git<br>
>> > ><br>
>a/vlc-android/src/org/videolan/vlc/gui/video/VideoListAdapter.java<br>
>> > ><br>
>b/vlc-android/src/org/videolan/vlc/gui/video/VideoListAdapter.java<br>
>> > > > index 2f5863fcf..4ad8f091b 100644<br>
>> > > > ---<br>
>> a/vlc-android/src/org/videolan/vlc/gui/video/VideoListAdapter.java<br>
>> > > > +++<br>
>> b/vlc-android/src/org/videolan/vlc/gui/video/VideoListAdapter.java<br>
>> > > > @@ -148,6 +148,7 @@ public class VideoListAdapter extends<br>
>> > > SortableAdapter<MediaWrapper, VideoListAda<br>
>> > > > @MainThread<br>
>> > > > public void add(MediaWrapper item, int position) {<br>
>> > > > final List<MediaWrapper> list = new<br>
>ArrayList<>(peekLast());<br>
>> > > > + if (position < 0 || position >= list.size()) return;<br>
>> > > > list.add(position, item);<br>
>> > > > update(list);<br>
>> > > > }<br>
>> > > ><br>
>> > > > _______________________________________________<br>
>> > > > Android mailing list<br>
>> > > > <a href="mailto:Android@videolan.org" target="_blank">Android@videolan.org</a><br>
>> > > > <a href="https://mailman.videolan.org/listinfo/android" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/android</a><br>
>> > > _______________________________________________<br>
>> > > Android mailing list<br>
>> > > <a href="mailto:Android@videolan.org" target="_blank">Android@videolan.org</a><br>
>> > > <a href="https://mailman.videolan.org/listinfo/android" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/android</a><br>
>> > ><br>
>><br>
>> > _______________________________________________<br>
>> > Android mailing list<br>
>> > <a href="mailto:Android@videolan.org" target="_blank">Android@videolan.org</a><br>
>> > <a href="https://mailman.videolan.org/listinfo/android" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/android</a><br>
>><br>
>> _______________________________________________<br>
>> Android mailing list<br>
>> <a href="mailto:Android@videolan.org" target="_blank">Android@videolan.org</a><br>
>> <a href="https://mailman.videolan.org/listinfo/android" rel="noreferrer" target="_blank">https://mailman.videolan.org/listinfo/android</a><br>
>><br>
</blockquote></div>