-
-
Notifications
You must be signed in to change notification settings - Fork 81
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
Don't send reminder notification when entry for today is already available #115
Don't send reminder notification when entry for today is already available #115
Conversation
|
||
override fun onReceive(context: Context, intent: Intent) { | ||
super.onReceive(context, intent) | ||
|
||
val entry = runBlocking { |
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.
I tested this on the emulator and it seems to be fine. Not sure if there's a better way.
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.
Hiya! I've thought about doing this before but was hesitant because I didn't want to do any blocking work in the BroadcastReceiver since it runs on the main thread.
Another option would be to reschedule the notification to the next day whenever the user writes for the current day. I think there's probably some rewriting that should be done to make that code more testable and easier to work with, but its doable!
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.
I'm wondering if it's worth the effort and complexity to handle this in the entry saving logic. You would introduce a coupling between the entry saving and the notification logic when it's not strictly necessary.
One database query shouldn't block long enough to be noticeable.
Also, you would introduce corner cases like: The user wrote something, then removed it. Do we still want to show a reminder? If yes, we would have to reschedule again.
Just some food for thought. Let me know, what you think.
I stumbled on goAsync() and I think this is the way to go. We're not blocking the main thread while querying the repository and we don't have to add complexity to the entry saving logic. |
@alisonthemonster how should we proceed with this? |
So sorry to leave you hanging on this one for so long! After thinking this approach over some more I think it would be best to close this PR for now and look into alternative approaches. I don't want to be doing any work in the broadcast receiver, I really don't want to block the UI thread for disk IO. Additionally its not recommended to launch work with a global scope. You can read more about that here. Thank you again for taking the time to tackle this one! There's a good reason its been on my backlog for so long! I really really really appreciate you taking the time to contribute to Presently and hope we can continue to work together! |
Closes #101