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

refactor: Update status storage, fragments #1249

Merged
merged 25 commits into from
Feb 2, 2025

Conversation

nikclayton
Copy link
Contributor

@nikclayton nikclayton commented Jan 31, 2025

Status storage

Re-work how statuses are stored and managed to separate the cached home
timeline from the cached notification timeline.

Previously, the home timeline pulled all statuses in StatusEntity.
Since that table also includes statuses that are referenced from
NotificationEntity this could show the wrong data. It also makes it
difficult to cache other timelines in the future.

To fix this:

  • Introduce TimelineStatus which associates a given timeline with the
    statuses on that timeline.

  • Use the the StatusEntity table as a general cache of statuses.
    wherever they're used.

  • Create the home timeline by joining TimelineStatus (where the
    timeline's kind is Home) with the statuses in StatusEntity.

This has a number of knock-on effects.

  • Deleting from the home timeline now deletes the association from
    TimelineStatus. The cached status is unaffected, so if it is
    referenced from another cached timeline (currently, notifications)
    there is no change.

  • Modifying a status on one timeline (translating, expanding,
    collapsing, etc) modifies it on all timelines that reference that
    status.

  • cleanup() and related functions no longer need to take limit or
    keep parameter, as it's known whether a status is referenced from a
    timeline.

Rewriting one of the queries exposed an issue where TimelineDaoTest
run locally could return different (incorrect) results to the same test
run on a device (https://issuetracker.google.com/issues/393685887).

So re-implement TimelineDaoTest as an androidTest, and update the CI
workflow to include a step to run these tests on an API 31 emulator.

Repositories

  • Allow null as an initial key.

Fragments

  • Remove unnecessary refreshAdapterAndScrollToVisibleId.

…uses

TimelineDao contained operations on timelines and statuses which made
it large and confusing.

Factor out the status-specific operations in to the new StatusDao
class to make things more understandable.
- Removing the restore-position-on-swipe-refresh code worked
- Document the new database stuff
- Modified some bits with row fetching
# Conflicts:
#	app/src/main/java/app/pachli/components/timeline/viewmodel/CachedTimelineRemoteMediator.kt
#	core/data/src/main/kotlin/app/pachli/core/data/repository/notifications/NotificationsRemoteMediator.kt
#	core/database/src/main/kotlin/app/pachli/core/database/AppDatabase.kt
#	core/database/src/main/kotlin/app/pachli/core/database/dao/TimelineDao.kt
# Conflicts:
#	app/src/main/java/app/pachli/components/timeline/viewmodel/CachedTimelineRemoteMediator.kt
#	core/database/src/main/kotlin/app/pachli/core/database/dao/TimelineDao.kt
# Conflicts:
#	app/src/main/java/app/pachli/components/notifications/NotificationsFragment.kt
#	app/src/main/java/app/pachli/components/timeline/TimelineFragment.kt
# Conflicts:
#	app/src/main/java/app/pachli/components/timeline/viewmodel/CachedTimelineRemoteMediator.kt
@nikclayton nikclayton changed the title wip: refactor: Update status storage, fragments Feb 1, 2025
@nikclayton nikclayton merged commit 1611e48 into pachli:main Feb 2, 2025
28 checks passed
@nikclayton nikclayton deleted the timeline-relation branch February 2, 2025 20:29
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