Snackbars queued when deleting downloads instead of flushing immediately

[ix5]

Checklist

• I am using the latest version - x.xx.x
• I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
• I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• This issue contains only one bug. I will open one issue for every bug report I want to file.

Steps to reproduce the bug

1. Download multiple videos/audio files
2. Go to download page
3. Delete multiple videos quickly one after another

Actual behaviour

Snackbars at the bottom of the UI keep queuing up. You need to wait for all of them to dismiss themselves for files to actually be deleted. If you close NewPipe before all snackbars are dismissed, your files will not be deleted and show up again next time you start NewPipe.

Expected behavior

Deleting a second, third etc. file should flush the handler queue and immediately delete the previously marked-for-deletion file and dismiss its snackbar.

Screenshots/Screen recordings

See this screen recording

Logs

(This bug is not about crashes)

Device info

• Android version/Custom ROM version: Android 11
• Device model: Any, e.g. emulator

---

Now that this newbie template is filled out, let's get down to the actual issue.

Codepath:

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

Line 690 in 1f77e00

mDeleter.append(h.item.mission);

NewPipe/app/src/main/java/us/shandian/giga/ui/common/Deleter.java

Lines 57 to 62 in 1f77e00

	public void append(Mission item) {
	mIterator.hide(item);
	items.add(0, item);
	show();
	}

NewPipe/app/src/main/java/us/shandian/giga/ui/common/Deleter.java

Lines 71 to 78 in 1f77e00

	private void show() {
	if (items.size() < 1) return;
	pause();
	running = true;
	mHandler.postDelayed(rNext, DELAY);
	}

This causes next() to be posted with a delay of 350ms (doc: Handler.postDelayed)

NewPipe/app/src/main/java/us/shandian/giga/ui/common/Deleter.java

Lines 80 to 91 in 1f77e00

	private void next() {
	if (items.size() < 1) return;
	String msg = mContext.getString(R.string.file_deleted).concat(":\n").concat(items.get(0).storage.getName());
	snackbar = Snackbar.make(mView, msg, Snackbar.LENGTH_INDEFINITE);
	snackbar.setAction(R.string.undo, s -> forget());
	snackbar.setActionTextColor(Color.YELLOW);
	snackbar.show();
	mHandler.postDelayed(rCommit, TIMEOUT);
	}

A message with commit() as runnable is then posted to the handler queue with a timeout of 5 seconds.

NewPipe/app/src/main/java/us/shandian/giga/ui/common/Deleter.java

Lines 93 to 115 in 1f77e00

	private void commit() {
	if (items.size() < 1) return;
	while (items.size() > 0) {
	Mission mission = items.remove(0);
	if (mission.deleted) continue;
	mIterator.unHide(mission);
	mDownloadManager.deleteMission(mission);
	if (mission instanceof FinishedMission) {
	mContext.sendBroadcast(new Intent(Intent.ACTION_MEDIA_SCANNER_SCAN_FILE, mission.storage.getUri()));
	}
	break;
	}
	if (items.size() < 1) {
	pause();
	return;
	}
	show();
	}

Only commit then really hard-deletes the file.

---

Possible solution

My idea would be to flush the queue when running append() by calling commit() directly before inserting into items and cancelling all current callbacks via removeCallbacks

Tokens in some kind of form might be required?

Hopyfully some Android wizards more familiar with this codebase can chime in. I see @TiA4f8R @Isira-Seneviratne touched this whole GigaGet-imported component last.

[ix5]

@kapodamy maybe you have an idea

[kapodamy]

@ix5
yes, when you leave the download activity all pending files are deleted, but, if instead you switch another app the file deletion is "paused"