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

feat: Persist notification filtering decisions locally #1196

Open
wants to merge 66 commits into
base: main
Choose a base branch
from

Conversation

nikclayton
Copy link
Contributor

@nikclayton nikclayton commented Jan 9, 2025

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 for
a timeline. This is used to persist the notifications refresh key
instead of the lastNotificationId property in the account (which has
been 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.

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
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
@nikclayton 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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant