Downloader: Deleter: Dismiss previous Snackbars

[ix5]

What is it?

• Bugfix (user facing)

Description of the changes in your PR

When running append(), trigger the commit() action immediately and cancel all delayed callbacks for commit().

Snackbars no longer pile up. For previous behaviour, see #5660

(Checking if there are any tasks running via hasCallbacks() would be nice, but that method is only available in API 29+.)

For a visual comparison:

The current behaviour in NewPipe 0.20.10
Screencast (note: Snackbars keep piling up)

With this PR applied:
Screencast (note: No piling up, but users can still undo actions)

Fixes the following issue(s)

#5660

APK testing

My server
Generated from GitHub CI

Due diligence

• I read the contribution guidelines.

[ix5]

@kapodamy what do you think?

[XiangRongLin]

The idea would be fine if there were some system similar to a trashcan. Since we do not, I think this could cause accidental deletes.

See #5419

@kcpatricio since you representing the other opinion, what's your take on this.

---

On a sidenote, since you titled it WIP you can convert it to a draft PR

[ix5]

I don't remember whether converting to draft disallows inline reviews. But I've changed it.

[ix5]

As for accidental deletes: The idea is that if a user deletes one file and then proceeds to delete another file, he must be pretty sure about the first one. It takes two taps to delete the next file, which no sane person would do if they noticed they accidentally deleted the wrong file.
What is, however, very annoying is the current behaviour where deleted files do not get deleted if one closes the app before all snackbars are gone (which takes <number of items deleted> x 5 seconds)

[kcpatricio]

The idea would be fine if there were some system similar to a trashcan. Since we do not, I think this could cause accidental deletes.

See #5419

@kcpatricio since you representing the other opinion, what's your take on this.

---

On a sidenote, since you titled it WIP you can convert it to a draft PR

Yes, a trashcan would be the safest option

Clearing the download's history is a way to prevent accidental deletes since the 'delete downloaded files' only removes those that still are in history. That way you'll have to browse to NewPipe's folder with another app to access your files
Still, you are a few pixels and 2-3 seconds away from a wipe

[ix5]

You might be conflating this PR with #5419.

This PR explicitly does not address clearing all downloads. If you've cleared all downloads (deliberately or by accident), there is no possibility of triggering the codepath in this PR (no more downloads to click).

[ix5]

I've added two screencasts for people to better understand the issue, see the original post at the top.

[kcpatricio]

Here's mine

Screencast

[ix5]

Again, this has nothing to do with the Clear Download History button.

The codepath for that action, which hard-deletes or "forgets" (files still present in filesystem) all downloads, lies here:

NewPipe/app/src/main/java/us/shandian/giga/ui/fragment/MissionsFragment.java

Lines 190 to 199 in d6855a6

	case R.id.clear_list:
	AlertDialog.Builder prompt = new AlertDialog.Builder(mContext);
	prompt.setTitle(R.string.clear_download_history);
	prompt.setMessage(R.string.confirm_prompt);
	// Intentionally misusing button's purpose in order to achieve good order
	prompt.setNegativeButton(R.string.clear_download_history, (dialog, which) -> mAdapter.clearFinishedDownloads(false));
	prompt.setPositiveButton(R.string.delete_downloaded_files, (dialog, which) -> mAdapter.clearFinishedDownloads(true));
	prompt.setNeutralButton(R.string.cancel, null);
	prompt.create().show();
	return true;

NewPipe/app/src/main/java/us/shandian/giga/ui/adapter/MissionAdapter.java

Lines 599 to 623 in d6855a6

	if (delete && mIterator.hasFinishedMissions() && mHidden.isEmpty()) {
	for (int i = 0; i < mIterator.getOldListSize(); i++) {
	FinishedMission mission = mIterator.getItem(i).mission instanceof FinishedMission ? (FinishedMission) mIterator.getItem(i).mission : null;
	if (mission != null) {
	mIterator.hide(mission);
	mHidden.add(mission);
	}
	}
	applyChanges();
	String msg = String.format(mContext.getString(R.string.deleted_downloads), mHidden.size());
	mSnackbar = Snackbar.make(mView, msg, Snackbar.LENGTH_INDEFINITE);
	mSnackbar.setAction(R.string.undo, s -> {
	Iterator<Mission> i = mHidden.iterator();
	while (i.hasNext()) {
	mIterator.unHide(i.next());
	i.remove();
	}
	applyChanges();
	mHandler.removeCallbacks(rDelete);
	});
	mSnackbar.setActionTextColor(Color.YELLOW);
	mSnackbar.show();
	mHandler.postDelayed(rDelete, 5000);

[kapodamy]

@ix5 llooks good, now it's easier to delete multiple files

[ix5]

I haven't found a better or more elegant way to do this, and it seems no one else has tackled this issue so far either.
Could I get a review, please?

[Stypox]

Looks good, this will be merged in next release.

[ix5]

@Stypox any news?

[ix5]

@Stypox would you mind merging this if you have no further objections?