There is no way to abort background updates

If you tap at the background update, it should fire up a window where you can see progress full screen, and abort the update if you want.

Note: On 5.X, some notifications have a "cancel" button at the bottom. Not sure if this could be done with NotificationCompat for all the versions we support, but if it were possible, that would be better.

Added suggestion ui update labels

We now have this in APK downloads. Could this be done too for index downloads? CC @paresh

Thanks for your suggestion @est. In fact, it is not just background updates, but foreground ones too!

@mvdan, @paresh: The apk downloading already supported the concept of cancelling (from the implementation in AppDetails where users can cancel a download). The repo update has no such concept. We can do it, but it requires a little bit of work to get going. Specifically, catching InterruptExceptions throughout the UpdaterService and also the RepoUpdater and responding in kind.

We are working to make the updating very smooth and fully in the background. @pserwylo recent merge request helped a lot with that, and #649 will help even more.

Considering a fast, backgroundable, index update based on diffs, what's the use case where the user would want to cancel or even be aware of the index updates? I'd prefer to see us working towards the goal of making the whole concept of the index entirely invisible to the user.

I'd prefer to see us working towards the goal of making the whole concept of the index entirely invisible to the user.

I really like having these overarching goals for F-Droid that drive progress towards the ultimate goal of a really user friendly app. However I think we all are keen to get towards that goal, but index updates based on diffs is a big change. It should not preclude the implementation of cancelling updates at this point in time, especially as @paresh indicated on IRC he may be willing to work on it.. If not though, then this should probably stay here until those overarching goals are reached.

@paresh has already contributed some valuable code, I hope to inspire him to join us in the goal of making the index updates invisible rather than work on something that we are planning on hiding anyway :-)

and that said, I'm not yet 100% convinced that we can fully hide the index updates, that why I want to shift the discussion to use cases and user stories, so we can better understand the whole problem

@eighthave yes I agree, If we are going to hide it anyway why do we need a cancel button. Moreover implementing cancel action in UpdateService(RepoUpdate) is not as straightforward as it was in DownloaderService.

<paresh> If I add it only to be replaced in next update 
<paresh> doesn't sound a good idea
<paresh> + it requires some work 
<paresh> as IntentServices are queued 
<paresh> I know how to implement it (or have a clue)
<paresh> 1) Register a broadcast receiver
<paresh> 2) send broadcast from notification (pending intent) 
<paresh> 3) call stopSelf()
<paresh> only thing is you can't use a LocalBroadcastRecv. 
<paresh> so I need to add one to manifest 

That said, I think we need to clarify the use case for canceling if we have transparent updates. There could be one that we need to support, but I'm guessing not. For example, is there any case where the update could get stuck for a long time? Is there a time where a new index could cause problems, so the user would want to cancel?

As for implementing the cancel, if you can get the active Downloader instance in UpdateService, you can call cancel on that, and it should work. DownloaderService is based on IntentService but not a subclass because canceling from the queue is needed.

Even if the updates are diff based and therefore small, there might be a case of a hugely outdated index being updated (and the diff being big), or a first time install where the whole index has to be downloaded.

Also, the internet connection might be very bad and the user might want to retry instead to have to wait for too long timeouts.

@est imagine thinking about only the actual thing your trying to get done, without any of the technical details. F-Droid is about installing and getting information about apps. Let's take your scenario, and turn it into "I want to install an app when the internet is very bad". In that case, it doesn't matter if the update is in progress or not since the app index will already be present (unless this is a new repo that has never been used). I think this scenario would be better handled by a app downloader that keeps on trying until it fully downloads the file.

Milestone changed to %1.1

Mentioned in issue #797 (closed)