You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of #87 — Blog: read posts in-app and manage the email subscription
No public JSON endpoint exists for blog content, so this is a routing decision rather than a
data-layer one.
Simplest honest option: a Blog entry in the Account hub that opens /blog in a Custom Tab,
themed to match the app.
If in-app rendering is wanted, it needs a server-side listing endpoint — raise that with the
owner rather than scraping HTML.
Deep-link blog URLs so a shared post opens sensibly from Android.
Tests: entry point routes; deep link handled.
Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Implemented in the PR above (branch issue/88-blog-reach). Closing here — review and any follow-up happens on the PR.
The routing decision this issue asked for: the app deliberately does not claim https://interlinedlist.com/blog/.... With no in-app renderer, claiming it would mean intercepting a browser-bound URL only to hand it back to a browser — and since the no-Custom-Tabs fallback is a plain ACTION_VIEW on that same URL, being a registered handler would make it resolve back into MainActivity as a loop. Only interlinedlist://blog is registered. The parser already understands the web form, so the claim can be switched on with no code change once there is something to render.
I have posted a concrete spec on #87 for what a public GET /api/blog endpoint would need — the decisive point being that the post body must be Markdown, not HTML, since raw HTML forces a WebView and defeats the purpose of in-app rendering.
Activity
Adron commentedon Sep 16, 2026
Implemented in the PR above (branch
issue/88-blog-reach). Closing here — review and any follow-up happens on the PR.The routing decision this issue asked for: the app deliberately does not claim
https://interlinedlist.com/blog/.... With no in-app renderer, claiming it would mean intercepting a browser-bound URL only to hand it back to a browser — and since the no-Custom-Tabs fallback is a plainACTION_VIEWon that same URL, being a registered handler would make it resolve back intoMainActivityas a loop. Onlyinterlinedlist://blogis registered. The parser already understands the web form, so the claim can be switched on with no code change once there is something to render.I have posted a concrete spec on #87 for what a public
GET /api/blogendpoint would need — the decisive point being that the post body must be Markdown, not HTML, since raw HTML forces a WebView and defeats the purpose of in-app rendering.merge: #88 blog entry point + Custom Tab (PR)
merge: #29 tag-filtered feed (PR #122)