1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
# Backlog
## Feed health: recency/frequency tracking + dead-feed detection
**Motivation:** migrating 108 feeds from Inoreader surfaced ~19 feeds the
user had manually flagged "dead?" over there — there's currently no way
for this app to tell that on its own. Want automatic detection instead of
relying on manual tagging carried over from another tool.
**What's needed:**
- Track each feed's normal posting cadence (e.g. median interval between
the last N articles' `publishedAt` — already stored on `ArticleEntity`,
no new fetch required, just a read-side computation).
- Surface a "stale" indicator on the feed list when a feed has gone
quiet for meaningfully longer than *its own* historical cadence — not
a fixed global threshold. A feed that normally posts yearly shouldn't
be flagged after 3 quiet months; a feed that normally posts daily
should be flagged after a couple of quiet weeks.
- Treat "feed URL itself is broken" as a distinct, stronger signal from
"author's just gone quiet": `FeedEntity.lastError` already records
fetch failures (404s, parked domains, etc.) — a feed with several
consecutive failures is a different case than a live, fetchable feed
that simply has no new posts.
**Rough shape (not yet built):**
- Compute per-feed on read (no new table needed at first): take the last
N `publishedAt` values for a feed, find the median gap, compare against
time since the most recent post. Flag if the current gap is some
multiple (e.g. 3x) of the historical median.
- `FeedListScreen`: a small badge next to the feed row when flagged,
distinguishing "quiet" (posting-cadence signal) from "broken"
(`lastError` signal) since they call for different user action (wait
it out vs. go look for a replacement feed).
- Out of scope for now: any automated "find where the author moved"
logic — that's a manual research task when a feed's actually declared
dead, not something to build detection for.
## YouTube embeds
**Motivation:** the reader's WebView runs with JavaScript off (feed/extracted
content never needs it, and it keeps articles from running arbitrary
scripts) — so a YouTube iframe embedded in an article currently just shows
as a broken/blank box instead of a playable video or thumbnail.
**Rough shape (not yet built):** detect a YouTube iframe/embed URL in the
extracted or feed-provided HTML and swap it for a tap-to-play thumbnail
(image + play button) that opens the video in the YouTube app/browser on
tap, rather than trying to make the embed actually play inline (which would
mean turning JS back on for untrusted third-party content).
## Bug report button
**Motivation:** every crash/bug so far has been diagnosed by manually pulling
logcat and querying the on-device DB over adb -- fine on tungsten's emulator,
not available from the user's actual phone in the moment something breaks.
**Rough shape (not yet built):** a "Report bug" action (article overflow
menu, or a dedicated crash-handler hook) that gathers what's needed to
reproduce in the emulator -- the current article's URL/id, a short
user-typed description, and whatever we've already instrumented internally
(feed id, reader-mode state, isReaderMode/extraction state, recent logcat
lines if reachable) -- and copies it to the clipboard as one block of text,
ready to paste back into a message.
## Smaller title text
Article titles in the reader's top bar (and the list rows) read too large
relative to everything else. Reduce the type scale -- exact size TBD by eye
once tried.
## Bottom action strip
**Motivation:** the reader's top bar is getting crowded (reader-toggle,
open-in-browser, bookmark, Stash, overflow) and it's a top-heavy layout for
a one-handed phone -- reachability, not just tidiness.
**Rough shape (not yet built):** move the action icons + overflow menu into
a bottom strip (title/back stay in the top bar). Auto-hide both the top and
bottom strips together on scroll (hide on scroll-down, reveal on scroll-up
or tap), matching the common "immersive reading" pattern other reader apps
use. Needs to coexist with the existing scroll-vs-swipe gesture handling in
ReaderScreen without reintroducing the jank/interception problems already
fought through there.
|
