-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show notifications even when app is in background (fixes #4615) #4697
Conversation
51eb3c4
to
273c93c
Compare
Fixed, just need to handle settings changes now. |
Should be complete now, assuming I understood the settings right. |
Would you be able to review this? |
Regarding the
In case of fresh installation there will be no existing notification preferences. Not sure about application updates, but maybe the existing alarms will work?
But it implies that the device already booted, so the alarms are in place. Regarding to the SO answers and articles I've read, boot (completed) event is enough for the notifications to work after reboots: 1, 2. Also, I see this code touches existing logic for the widget, isn't it? What is the purpose? Thanks! |
@madhead One easy way to break it is by running the app from Android Studio. That's not a boot, so the receiver will not be called (verified with logs). The same thing should happen if the app is updated from Google Play, or if the app is force stopped from app settings, and started again. Regarding the widget, it was starting the NotificationService on every update. Now that the service is started automatically via the BootService, there's no reason to start it from the widget any more. |
7 minutes delay is ok with me, but you know some of our users are Anki fanatics, and they don't like it... Also, people who were testing the feature for the first time will keep opening issues to say that it's "broken", which wastes our time as well :-/ when I looked into it, it seemed very easy to make it more exact, you just have to set a new alarm each time it gets fired |
Honestly I'm not super knowledgeable about services in Android, and haven't looked through the code in detail, but a pre-requisite for accepting this PR is that it doesn't noticeably impact battery usage, so I'm worried that the service is gonna be permanently running. |
Its the same service that was there before, and its only started once (doesnt run in background). Using exact alarms would increase battery usage in theory, but that's probably not noticeable if its only once per day. |
public BootService() { | ||
super("BootService"); | ||
} | ||
|
||
@Override | ||
protected void onHandleIntent(Intent intent) { | ||
final AlarmManager alarmManager = (AlarmManager) getSystemService(ALARM_SERVICE); | ||
if (sWasRun) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use braces with your one-line if
statements
public static void scheduleNotification(Context context) { | ||
AlarmManager alarmManager = (AlarmManager) context.getSystemService(ALARM_SERVICE); | ||
SharedPreferences sp = PreferenceManager.getDefaultSharedPreferences(context); | ||
if (Integer.parseInt(sp.getString("minimumCardsDueForNotification", "1000001")) <= 1000000) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's time we separated this into two settings instead of using the "magic number" 1000000 to represent "pending messages available"? We originally did this in an attempt to minimize the number of settings, but it's kind of counter-productive here.
I think it's a bit confusing having two different places where notifications are set... Maybe we can merge these two similar features to some extent? Is the main motivation for #4530 to allow opting-out of notifications for specific decks? Or is it to have a separate reminder (with a separate notification time) for each deck? |
Yes I think it makes sense to seperate the notification settings. But I'm don't think it necessarily belongs into this PR. Also, like I said, I'm not really familiar with the settings. |
The original idea was this. Each deck can remind about itself at some time of the day, independently of others. |
At the moment it's done on a per-note-type rather than per-deck basis though, right? |
I fixed the failing build issue, so if you could also rebase onto the latest master that would be appreciated! git fetch --all
git rebase upstream/master
git push origin background-notifications -f |
ca315a1
to
681392f
Compare
done ;) |
Thanks! Can you add the missing curly braces as well? |
Right, I missed your comment before. |
Finally got around to this. There seems to be some bug left, as I couldn't get the Notification to show during my testing. This might have to do with the behaviour of
setInexactRepeating()
, according to the documentation, "there may be a delay of almost an entire alarm interval before the first invocation of the alarm" (so almost 24 hours delay in our case). We might have to use a different method to schedule the alarm instead.By the way, I noticed that
BootService
would only get started by a device boot. In the following cases, it would never run:I've added the line
startService(new Intent(this, BootService.class))
inAnkiDroidApp
to make sure it is always started.