Skip to content
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

Conversation

cypressious
Copy link
Contributor

Closes #101


override fun onReceive(context: Context, intent: Intent) {
super.onReceive(context, intent)

val entry = runBlocking {
Copy link
Contributor Author

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.

Copy link
Owner

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!

Copy link
Contributor Author

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.

@cypressious
Copy link
Contributor Author

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.

@cypressious
Copy link
Contributor Author

@alisonthemonster how should we proceed with this?

@alisonthemonster
Copy link
Owner

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Don't notify if I've already made an entry for the day?
2 participants