Live activities

[BPerlakiH]

Fixes: #1037

The live activity:

• is displaying the currently downloading item with it's title, and progress
• if we have multiple downloads, it displays a single item titled "Downloading..." (localised), and the summary of the progress for all items
• so far it is without a pause / stop button, that can be added separately, as it requires more work on deep-linking (and navigating back) to the download section of the app.

I've tested it on my iPhone, so far it looks good on the Lock Screen, and in (portrait) StandBy mode. Also tested it for both Light and Dark mode.

There are still some rare cases where it stops updating an existing live activity,
worth to test on more devices.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 14.72868% with 110 lines in your changes missing coverage. Please review.

Project coverage is 35.35%. Comparing base (c075371) to head (5a45273).

Files with missing lines	Patch %	Lines
Views/LiveActivity/ActivityService.swift	21.42%	66 Missing ⚠️
Common/DownloadActivityAttributes.swift	0.00%	31 Missing ⚠️
App/App_iOS.swift	12.50%	7 Missing ⚠️
Model/DownloadService.swift	0.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1096      +/-   ##
==========================================
- Coverage   35.70%   35.35%   -0.35%     
==========================================
  Files         132      134       +2     
  Lines        7605     7732     +127     
==========================================
+ Hits         2715     2734      +19     
- Misses       4890     4998     +108     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kelson42]

@BPerlakiH What you discribe is a very minimal version missing indeed core features... but maybe this is better to start with this and see how people will react. @rgaudin What do you think?

[BPerlakiH]

@BPerlakiH What you discribe is a very minimal version missing indeed core features... but maybe this is better to start with this and see how people will react. @rgaudin What do you think?

I think it's a bit the other way around.

I see 2 scenarios:

1. user starts downloading something, and lock the screen (or the device times out and locks the screen itself)

2. the user starts downloading, but navigates somewhere else in the app, and then locks the screen (while the downloading is still happening)

In scenario 1) tapping on the live activity, the user is taken back (where the user left off) and can easily pause / cancel the downloads. So in this case it's a 1 tap difference between having a button on the live activity or not having it.

In scenario 2) we need to implement a solution to get the user back to the download section.
This is in fact would be more helpful for the user, not needing to find the downloads section again, and cancel from there. The question is how often would this really happen...

There's yet another aspect here. We don't have the screen space to display multiple downloads. So in case of 2 or more downloads, we still display 1 item, which summarises the progresses. We can still add the pause / cancel button, but in this case it would pause / cancel all downloads.

Furthermore, the live activity is optional (even if supported by the user device), the user needs to opt-in, by agreeing to receive them, and can opt-out any moment (by changing the system settings).

For these reasons, I would like to break this feature into 2 parts, one is having the progress displayed for the user (this PR), we can test it and see if it needs more improvements on its own. For example, I am not convinced about the notification frequency (and UI updates), eg. it's not fully consistent between an iPhone and an iPad.
I think once we have this part fully solved, we can think about adding more interactivity to it. We can pack both into one as well if you think that's better.
For me it's more important to see more testing for this feature with real devices (even if it's internal testing only) not just my (2) devices.

In my opinion the stakes are higher than usual in this case. There's one thing to make something look bad within our app by accident, but making something look bad on someone's lock-screen (where users usually have their family photo set as a background) is a whole different user "experience" if not a downright "insult".

[rgaudin]

I am fine with the incremental approach ; we need actual tests to understand what could be improved and how

[kelson42]

@BPerlakiH Thx for your last comment. It amkes sense. We can go forward for now with what you have done.

[kelson42]

@BPerlakiH A screencast would have been helpful here in the PR description. I will merge it and please make straight a testfligh release.