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

Properly summarize all notifications #4848

Merged
merged 2 commits into from
Jan 12, 2025

Conversation

Lakoja
Copy link
Collaborator

@Lakoja Lakoja commented Jan 4, 2025

Do summary notifications like the Api defines it:

  • Schedule and summarize without delay (in order for summerization to work)
  • Always have a summary notification: simplify code with this and make more reliable
  • Do not care about single notification count (the system already does that as well)
  • Bugfix: Schedule summary first: This avoids a rate limit problem that (then) not groups at all

Testing this is probably the most difficult part.
For example I couldn't get any notification to ring with older Api versions in the debugger. (Same as for current develop)
However one hack to always get notifications: Fix "minId" in "fetchNewNotifications()" to a somewhat older value.

Next possible step: Have only one summary notification at all (for all channels/notification types). You can still configure single channels differently.
Or: For very many notifications: Only use a true summary one (something like "you have 28 favorites and 7 boosts").

Generally: The notification timeline must be improved now. Because that must be the go-to solution for any large number of notifications. It must be easy to read. E. g. with grouping per post.

@Lakoja Lakoja force-pushed the only-one-notification-per-type branch from b0eb031 to d4157fc Compare January 6, 2025 09:44
Copy link
Collaborator

@connyduck connyduck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, works for me.

@Lakoja Lakoja force-pushed the only-one-notification-per-type branch from d4157fc to 5b872a1 Compare January 8, 2025 21:08
Comment on lines 109 to 112
notificationManagerCompat.notify(newNotifications)

// NOTE this can schedule multiple (summary) notifications in short succession (normally 1-3).
// They can "collapse" to only one audible one if fast enough.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be outside of the notificationsByType.forEach loop as well?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@Lakoja Lakoja force-pushed the only-one-notification-per-type branch from c585e25 to 0fa77a1 Compare January 12, 2025 09:35
@Lakoja
Copy link
Collaborator Author

Lakoja commented Jan 12, 2025

Tested this now on my (Android 14) device. Seems to work reasonably well.

There are of course still odd edge-cases. For example if there are a very many notifications of different types, you will only get one summary. For example "25 favorite notifications" but nothing more.

@connyduck connyduck merged commit 6cbcf3e into tuskyapp:develop Jan 12, 2025
1 check passed
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.

2 participants