-
Notifications
You must be signed in to change notification settings - Fork 17
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
feat: Persist notification filtering decisions locally #1196
Open
nikclayton
wants to merge
66
commits into
pachli:main
Choose a base branch
from
nikclayton:cached-notifications
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Need to hook this in to the viewmodel
In the middle of trying to use relations between the NotificationEntity and the Account and Status entities it references. NotificationData is the class the rest of the app is supposed to use.
Means the adapter doesn't need to know the current account or local domain. Start tracking content and account filtering viewdata in a new NotificationViewDataEntity
This reverts commit 7d1b0d8.
The adapter data is driven by the database, which is updated as necessary.
Delete the old NotificationsPagingSource code
# Conflicts: # app/src/main/java/app/pachli/components/notifications/NotificationsViewModel.kt # app/src/test/java/app/pachli/components/notifications/NotificationsViewModelTestBase.kt
# Conflicts: # app/src/main/java/app/pachli/components/timeline/CachedTimelineRepository.kt # core/database/schemas/app.pachli.core.database.AppDatabase/11.json # core/database/src/main/kotlin/app/pachli/core/database/AppDatabase.kt # core/database/src/main/kotlin/app/pachli/core/database/dao/RemoteKeyDao.kt # core/database/src/main/kotlin/app/pachli/core/database/model/RemoteKeyEntity.kt # core/database/src/test/kotlin/app/pachli/core/database/dao/AccountEntityForeignKeyTest.kt
… newest notifications)
nikclayton
changed the title
wip: Cached notifcations
feat: Persist notification filtering decisions locally
Jan 17, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Persist the user's notification filtering decisions (i.e., the decision
to show a filtered notification) by caching all notification data,
including the filtering decision, in the database.
Structure changes
This means re-writing the notification management system to use Room and
the Paging library to manage the notification data.
Implement a repository and remote mediator for notifications that does
this, with knock on effects for the viewmodel and the fragment. Take the
opportunity to rewrite these to reflect (current understanding of) best
practice for state management.
Active account information is included in the viewdata for each
notification when sent to the adapter. This allows the adapter to be
created before the fragment knows the active account from the view
model.
RemoteKeyDao
is extended to support sorting the "refresh" key fora timeline. This is used to persist the notifications refresh key
instead of the
lastNotificationId
property in the account (which hasbeen removed).
UX changes
A linear progress bar is used to show progress when notifications are
refreshed, as part of the ongoing effort to migrate the UI.