Background Refresh disabled by default

[brokoli18]

This being disabled will mean that the app will never refresh in the background unless the user goes in and explicitly changes this value in the settings. Although it isn't an outright bug i would think that most users would want this kind of application to update in the background by default

[leschbenedikt]

I agree. As a user I would assume that a task created in the web version with due date will result in a notification in the android client.
At the moment this will only be the case if the app was opened at least once afterwards.

I will need to look into that more deeply as there is more to that than simply changing the default.
I'm thinking of battery drainage and background work restrictions.

From a user perspective what do you think a good default value would be?

[brokoli18]

I think 15 minutes is the minimum, but I don't know the impact that would have on battery. If its severe 30 minutes perhaps?

[RXTX4816]

I don't think putting a default >0 is beneficial.

It would be possible by calling updateWorkManagerDuration() at initial launch, but then we'd also need some sort of popup to the user that indicates he must setup his operating system in such a way to respect background app activity:

• Handle Android battery optimization/background restrictions (some manufacturers aggressively kill background tasks)
• Possibly request battery optimization exemptions
• Handle the case where existing users already have "0" stored

Do we really want that as default? IMO a more user friendly way would be to leave it at 0, but have some sort of "Help" screen (Would be also great for other features Ig) that explains how to correctly activate Background Refresh (In-app and In-System).
This Help screen could have a more compact minimal-help-screen that would show up on initial app launch with a tick box "Never show again".

If I compare this to other open-source apps I always need to manually enable background refresh if I want it, this goes for small impact apps as well as e.g. Email apps.

[brokoli18]

@RXTX4816 Without background refresh the application will never update unless it is manually updated. For example for email I would like to be notified if I receive a new email when the application is in the background. I cant imagine most people would want something like a task reminder to only work when they manually go in and refresh it.

[RXTX4816]

@brokoli18 Yes I totally get your point and I share your opinion. But isn't this how the app currently works? If you set a background refresh to X greater than 0 minutes then the app automatically fetches new content every X minutes. Or do you mean that this functionality is currently broken and, although a value X>0 is set, the notifications are not coming through?

If you use an Email app its probably using Google Play Services under the hood to run the background task. I was talking specifically about open-source de-googlified Email applications. In the latter case, by default, in my experience no Emails are fetched in the background when the app is not running (Wrong, see Edit below) The solution to that is, go into app settings and set the background refresh to enabled.. if you want it. I would say most do want that, so they enable it manually once and then it works until you uninstall the app.

I hope I could clarify my point. My question remains: What is the actual problem here? That the background refresh is broken, or that it must be enabled once and that it should be enabled by default? (And should work for users who don't have any Google and work for all System configurations (battery optim) for all supported Android versions, which requires disabling ALL battery opitimizations for that app and stopping the OS from killing it)

Edit: I just checked with my Email app and I was wrong, by default it does background activity, but it also has a pinned Notification Blob that always stays there 24/7 in order to show notifications in order to have a foreground service running.. which can be hidden of course. Maybe Email was a bad comparison from my side.

EditEdit: Gotify also uses a 24/7 notification blob as a foreground service to reliably check for updated push messages and show notifications for them

Concluding I believe setting the background refresh only updates task, but the background process will get killed by OS nevertheless. We would need a foreground service that does notifications on alerts that automatically adapts to the background service pulling new/edited tasks from the server.

More info:
https://m66b.github.io/FairEmail/#faq2
https://m66b.github.io/FairEmail/#faq39

[brokoli18]

@RXTX4816 Background refresh currently does work if its set to a non zero value. My point was that by default its 0 and a new user would not know to go and set it there without digging through the settings. At the very least we should have a popup at login saying that background refresh is disabled and if you want to have notifications/updates this should be set to 15 mins or more. Does that make sense?

[GlassedSilver]

UX-wise it's not smart to not have background-refresh. That should be a deliberate opt-out and users coming to a new version with the value set to zero should be asked if that's the intended behavior or whether the value should be set to the new default.

Average Joe expects stuff like this to "just work" and if the system throws sticks in the way then this can be mitigated. I've seen countless of apps ask me to verify my permissions and battery optimization exemptions, even deep-linking me to the specific settings, so I guess even that part can be just copied from projects that already do this. Affects plenty of them as it is. (alarms, todo apps, calendar apps, communication apps, ... basically what isn't affected by it at this point lol)

[RXTX4816]

Thank you both @brokoli18 @GlassedSilver for the clarifications! I was wrong, after reading your explanations I also think we should put a default of 15 minutes to increase user experience.

I did some testing to better understand the current behavior:

Current:

• Background refresh 0 min

  • Tasks never update, only if user refreshes the view manually ✅

• Background refresh less than 15 min (I tested with 1 minute background refresh)

  • App open:
    • Tasks refresh every minute ✅
    • Notification is shown for reminder created externally (As long as its at least 2 minutes in the future) ✅
  • App minimized:
    • Tasks do not refresh every minute ✅
    • No notification was shown for an external reminder 5 minutes in the future ✅
    • Note: Android has a WorkManager API (AOSP) limitation of at least 15 minutes for background tasks, thus this is expected behavior. Other apps mitigate this by using a foreground-always-on notification to have real-time updates
  • App minimized for a few mins then opened and being open (Maybe bug, this case could be tested further):
    • Tasks do not refresh every minute with opened app (I had to wait 4 minutes for an update!?) ❌
    • No notification was shown for external reminder 7 minutes in the future with opened app ❌
    • Note: It should have updated the task (every minute), I was constantly checking if the external reminder was pulled -> Missed notification. After about 4 minutes checking it got updated. In that time I was switching between Task overview and Task edit. To be fair, the setting clearly suggests a minimum of 15, so strange behavior must be expected.

• Background refresh >=15 min (I tested with 1 minute background refresh, but default Android WorkManager already limits to >=15mins for minimized apps)

  • App open test skipped since should work the same as < 15 mins ❓

  • App minimized: (External reminder set 20 minutes in the future while being in the Android homescreen)

    • The task was correctly updated in the background and its notification was correctly shown exactly 20 minutes later from the Android homescreen ✅

  • Device asleep: ToTest ❓

Concluding I would say the background refresh works as expected and can be trusted, but it fundamentally suffers from the 15 minute minimum limit of the Android WorkManager API, which is still perfectly fine tbh.

To be / Expected

• I expect when able to set 0<X<15 background refresh interval to be informed why I can set such a number if the input-setting has a note saying "Minimum 15".

  • Reason to expect that: Important task reminder created externally for in 10 minutes might not show a notification if user has app not explicitly open -> User misses important notification.
  • Solution:
    • Have a foreground service like FairEmail or Gotify to always get updates (Pull-based (idk about that) or serverside Push-based)
    • OR tell the user a warning that setting it to 0<X<15 does not count if the app is not explicitly open
    • OR disallow setting a value between 0 and 15.

• I expect that setting reminders/due dates externally will trigger a notification in the app if Background refresh is enabled and

  • The app is minimized (indefinetly, at least a few hours) -> ToTest ❓
  • The Device is in sleep mode (screen off, indefinetly, at least a few hours) -> ToTest ❓
  • The app is closed (killed) -> ToTest ❓
  • The user has configured the operating to allow Vikunja Background service for battery optimizations -> ToTest (idk much about this one in combination with the WorkManager API Vikunja app is using) ❓

Conclusion

Yeah lets set it to 15 minutes default, but also tell user if he sets it to less than 15 minutes that it does not count if the app is not open. Additionaly define the term "Background Refresh" clearly (I.e. does it mean background refresh while app open or while app not open or both).

[leschbenedikt]

The main problem remains the hard battery optimizations of some vendors.
A short test may succeed but after a day or two it stops working.
That's a least what happens on my phone so I disabled the optimizations.

I think we should still show some kind of hint to disable battery optimization.

Also I think it could be a good idea to just have some predefined intervals in a dropdown.
Like 15 mins, 1 hour, 2, 4, 8 ... and so on. Whatever makes the most sense.
I don't think a user needs to set an interval by the minute

[GlassedSilver]

The main problem remains the hard battery optimizations of some vendors. A short test may succeed but after a day or two it stops working. That's a least what happens on my phone so I disabled the optimizations.

I think we should still show some kind of hint to disable battery optimization.

This.

Also I think it could be a good idea to just have some predefined intervals in a dropdown. Like 15 mins, 1 hour, 2, 4, 8 ... and so on. Whatever makes the most sense. I don't think a user needs to set an interval by the minute

IDK about that...
Feature regression sucks and there's nothing stopping UI to have a slider for pre-configured intervals to choose from with a small text box to override next to it. It's a well-known thing to bring simplicity and flexibility together. IMHO whenever you can have both, you should have both.

[kolaente]

I think this is the strongest argument for a default:

Average Joe expects stuff like this to "just work" and if the system throws sticks in the way then this can be mitigated.

I went ahead and opened a PR that adds a default refresh period of 60 minutes and cleans it all up a bit: #250

Let's start with that, then we can still worry about battery optimization later.