6cbcf3eef0Do 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. |
||
|---|---|---|
| .. | ||
| schemas/com.keylesspalace.tusky.db.AppDatabase | ||
| src | ||
| build.gradle | ||
| getGitSha.gradle | ||
| lint-baseline.xml | ||
| lint.xml | ||
| proguard-rules.pro | ||