Anki-android: Bug: The reminders in the deck options don't work on time

[snowtimeglass]

Research

Enter an [ x ] character to confirm the points below:

[x] I have read the support page and am reporting a bug or enhancement request specific to AnkiDroid

[x] I have checked the manual and the FAQ and could not find a solution to my issue

[x] I have searched for similar existing issues here and on the user forum

Reproduction Steps

1. Set a reminder at "Reminders" in the deck options.

Expected Result

The notification is displayed on time

Actual Result

The notification is displayed several minutes (7 or more minutes) late.

ver: 2.8alpha5

[madhead]

Not sure why this happens, maybe because setInexactRepeating() is used for notifications. As it is guessable from its name, it does not guarantee exact time to save the battery.

[timrae]

According to the API documentation for setInexactRepeating():

long: time in milliseconds that the alarm should first go off, using the appropriate clock (depending on the alarm type). This is inexact: the alarm will not fire before this time, but there may be a delay of almost an entire alarm interval before the first invocation of the alarm.

[timrae]

In this case, the interval is one day, so we basically can't expect the time to be obeyed at all.

Let's add a string to the checkbox summary field saying something like: Notification time is inexact to save battery

[snowtimeglass]

Isn't there really a more suitable measure for reminder notifications, instead of the setInexactRepeating()?
On my device, the reminder notifications of all other apps work punctually as a matter of course.
Why does AnkiDroid have to be left behind all alone?

[timrae]

Which apps?

On 26 Jan. 2017 23:33, "snowtimeglass" [e-mail] wrote:

Isn't there really a more suitable measure for reminder notifications,
instead of the setInexactRepeating()?
On my device, the reminder notifications of all other apps work punctually
as a matter of course.
Why does AnkiDroid have to be left behind all alone?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ankidroid/Anki-Android/issues/4525#issuecomment-275402288,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACsA4h_spNakgzMY8LP7QUz9HhpJiTspks5rWK7GgaJpZM4Lal2M
.

[snowtimeglass]

For example,

GoalTracker

HabitHub

Evernote

[timrae]

@snowtimeglass
Thank you for that.

I checked the API documentation, and it looks like we can customize the amount of error we're willing to accept on Android 4.4+, so maybe we could use this function with an error window of 30s:

The documentation also says:

If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time

We can add a setWindow() function to the compat classes which falls back on set() on older Android versions.

[timrae]

I think we have two choices here... We can either pull the feature from the release to allow more time for beta testing, or we can clearly label it as being an "experimental" feature and include it in the release as is. We previously did something like this for the "advanced" editor.

@madhead
Which do you prefer, and when do you think you could find time to implement a fix for this issue and #4546?

[madhead]

Let's mark it as experimental?

[timrae]

@madhead
When would you expect to address the issues I mentioned though?

[madhead]

Not sure, pretty busy now.

[timrae]

Hmmm OK in this case I think it's better for us to pull the feature from the current release, as I also don't have time to maintain it and I don't want to keep it "experimental" for an extended period of time.

[timrae]

Why did you close it? Please provide explanation when closing issues.

[snowtimeglass]

I read this comment, and thought developers regard this as an excessive demand, a nuisance.

[timrae]

The comment wasn't directed at you... Reporting problems during alpha/beta period is actually very useful and important. The problem is the flood of people who start complaining after we go live with a new version, so I feel it's better to fix it now to prevent that.

[snowtimeglass]

Thanks. I hope so too.

[mikehardy]

If I'm reading this correctly, the proposed change is to stop using setInexactRepeating (which handles recurrence automatically), and instead use setWindow (with a window of, say 30s) then any time the notification fires and we chain through NotificationReceiver to NotificationService, we should add logic to implement the recurrence by having NotificationService use BootService to call setWindow fresh for the next day?

As a simplifying proposal - why not let the OS handle the battery optimization and use the middle-ground API that handles recurrence, "set()"? (vs setExact() - a no-no unless you are an alarm clock - and setInexact() which isn't accurate enough and generated this issue).

Support for the idea: The documentation indicates that set() will allow Android system to be a little inexact and optimize battery for alarms automatically after API 19 (4.4 KitKat / API 19), while remaining exact for devices <19. While we will support 4.0 Ice Cream / API 15 with the next release, that's a cost of 6.7% of the user base (c.f. Android Developer Dashboard) that may see degraded battery usage with a once-daily wakeup, with the benefit of not having to handle recurrence internally. Seems like an easy win to me?

[timrae]

Sounds good to me

[mikehardy]

@timrae I haven't noticed any problems with this since the commit, this likely may be closed?