Filtering original list in 2 modes: use the existent internal list or with user list

[davideas]

Initial internal list will be by default the original source list to filter items.
Alternatively, user can provide a new list from which the filter is applied (current mode).

[davideas]

Unfortunately, it will brake the functionality of UNDO just after Filter and viceversa. Then it is too complicated to recalculate the correct position on the original Items too.

[tprochazka]

I just stuck on it. This is exactly what I need. I need to allows users search in huge list for desired item by name and then allows to delete it, allows to undo the delete and still search. And this is really hard with the current implementation. Problem is that filtering now override original mItems list and all delete and undo is based on it. Filtering should not modify the original adapter data, there should be a copy just for display and until filtering is active every update of the original data should result in re-filtering all items and display filtered result again.

[tprochazka]

I did quick and very ugly workaround working in my situation

	private List<AbstractFlexibleItem> getCurrentItems() {
		try {
			Field f = FlexibleAdapter.class.getDeclaredField("mItems");
			f.setAccessible(true);
			return (List<AbstractFlexibleItem>)f.get(this);
		} catch (NoSuchFieldException e) {
			DebugLog.wtf("RecordingsAdapter.getAllItemsCopy() failed", e);
		} catch (IllegalAccessException e) {
			DebugLog.wtf("RecordingsAdapter.getAllItemsCopy() failed", e);
		}
		return new ArrayList<>();
	}

	public void filterItems(@IntRange(from = 0L) long delay) {
		if (mItemsCopy == null) {
			mItemsCopy = new ArrayList<>(getCurrentItems());
		}
		super.filterItems(mItemsCopy, delay);

		if (getSearchText().length() == 0) {
			mItemsCopy = null;
			mItemsCopyBeforeDelete = null;
		}
	}

	@Override
	public void removeRange(@IntRange(from = 0L) int positionStart, @IntRange(from = 0L) int itemCount, @Nullable Object payload) {
		if (mItemsCopy != null) {
			mItemsCopyBeforeDelete = new ArrayList<>(mItemsCopy);
			for (int position = positionStart; position < positionStart + itemCount; position++) {
				mItemsCopy.remove(getCurrentItems().get(positionStart));
			}
		}
		super.removeRange(positionStart, itemCount, payload);
	}

	@Override
	public void restoreDeletedItems() {
		super.restoreDeletedItems();
		mItemsCopy = mItemsCopyBeforeDelete;
	}

[davideas]

@tprochazka, that is not good, better to delete all.

With current snapshot, you can still filter > delete > undo until a new filter or an update occurs!
Please read issues #341 & #342 opened by me.

For the moment what you need to provide is the original list, same as the one you initialized the adapter. I will evaluate if this issue can now be reopened.
I also added a new method getCurrentItems() but I would not use to re-filter the list, it won't work when search text is reduced in length!

[tprochazka]

Yes. I know that I must provide original list, but the original list is affected by delete/undelete. So I create copy of the current items when filtering starts, then update it by delete items or restore it by undo and then after filtering is finished I delete it. Ideal would be when getCurrentItems() will return still the all items in the list and will be not affected by filtering.

[davideas]

I see, the Adapter should help you in this case because:

• Filtering again or resetting the filter won't show the deleted items.
• With the new Snapshot version, every new filter will ask to commit the deleted items. Normally, we remove the undo after a while (5 seconds), but if the user starts a new filter use case, I believe we should close the previous undo use case.
• Alternatively you can implement the bin use case, which moves the deleted items into that folder and later (any time) the user can restore them manually.

How many times and how long you allow the user to undo after 3-5 changes of filter?

[davideas]

@tprochazka, with the resolution of the issue #362, this issue is also resolved.
You will be able to filter without providing the original list, since a new overloaded method of filterItems() will preserve it.

[tprochazka]

I'm just testing it on the RC2.
It looks good.
Fantastic work! Now it is much easier. Thanks a lot!