Gitea's own notification feed doesn't fire for plain pushes (only
issue/PR activity), so this app now periodically checks each favorited
repository's most recent push time itself and posts a local
notification when it advances past what was last seen.
- FavoritePushDetector: pure comparison logic, never notifies on a
repository's first sighting (only a real advance counts), avoiding a
notification storm the first time this feature ever runs.
- GetLatestPushEpochMillisUseCase: extracts the same 'newest branch
commit time' heuristic RepositoryListViewModel already uses for the
repository list's own last-push row, as a shared, reusable use case.
- SharedPreferencesLastSeenPushStore: one long per favorited repo, not
Room (docs/architecture.md reserves Room for offline caching).
- FavoritePushCheckWorker: 15-minute WorkManager periodic job,
network-constrained, no-ops cleanly with no session or no favorites.
- POST_NOTIFICATIONS requested at runtime on API 33+; a denial
degrades safely, the worker still runs and updates its baseline.
No deep link from the notification to the specific repository yet --
tapping it opens the app normally. End-to-end delivery (a real push
landing, 15 minutes elapsing) is unit-tested and the scheduling/
permission wiring is live-confirmed (prompt appeared, was granted, no
crash), but an actual notification firing hasn't been observed within
this same live-testing session.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Login previously left the app entirely for a separate browser task. Now uses
androidx.browser Custom Tabs, which overlays the app's own activity instead of
switching away, and returns automatically on redirect. Deliberately not a
WebView, per RFC 8252: an in-app WebView could read the Gitea login form's
credentials directly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
