{ "version": "https://jsonfeed.org/version/1", "title": "capyreader on jocmp", "icon": "https://avatars.micro.blog/avatars/2026/14/52207.jpg", "home_page_url": "https://jocmp.com/", "feed_url": "https://jocmp.com/feed.json", "items": [ { "id": "http://jocmp.micro.blog/2026/04/30/reworking-sync-for-better-offline/", "title": "Reworking sync for better offline support", "content_html": "

Capy version 2026.05.1208 includes improvements to better support offline reading. Previous attempts relied too heavily on Android background tasks for state management. Background tasks worked well on good connections but drifted on spotty networks. Even when statuses did sync, they would sync outside the refresh interval, if ever.

\n

Now, statuses are always added to an “outbox” controlled by the app, not the OS. This is a SQLite table that tracks “read” or “starred” states. This is pulled from NetNewsWire’s sync status model which is battle tested and works across many platforms.

\n

So if 100 articles are marked as read, all 100 will be pushed to the server before new statuses are pulled. This does assume that the offline client is the most up-to-date based on current sync systems. Regardless, this is a necessary trade-off that either clobbers client statuses or server statuses since there are no timestamp or conflict resolutions shared for FreshRSS, Feedbin or Miniflux.

\n

The new system is drastically simpler and means statuses always move in one direction via one outbox as opposed to two competing background jobs. Let me know how it works the next time you lose connection in a tunnel!

\n

Before

\n

If this graph looks painful, that’s because it is, and was always difficult to debug.

\n\"Auto-generated\n

After

\n

One way to sync, in a straight line, start to finish.

\n\"\"\n

Other Updates

\n

BazQux is now supported via the Reader API account. There were a few bugs in the way that have now been squashed.

\n

There are more bandwidth checks on local feeds to ensure that duplicate updates are skipped. This is to avoid a scary issue where the app consumed multiple gigs of data for one user.

\n

The bottom bar in the reader has been condensed to take advantage of the new floating toolbar design in Material 3 Expressive. This gives back more space to the article itself.

\n\"\"\n

What’s Next

\n

There are a few improvements up for consideration in the next development cycle. Offline mode isn’t there yet. I plan to start exploring support for offline full content articles and media (discussion).

\n

E Ink optimization is another area of investigation. I want to explore article pagination as well as immersive mode for E Ink devices specifically. If that works out, I also want to tweak the Monochrome theme to use up less full colors and more outlines to avoid ghosting.

\n
\n

Capy Reader is a solo project supported by readers like you. Show your support by leaving a tip on Ko-fi, or by sharing the app with a friend. Thanks!

\n", "date_published": "2026-04-30T22:31:00-05:00", "url": "https://jocmp.com/2026/04/30/reworking-sync-for-better-offline/", "tags": ["capyreader"] }, { "id": "http://jocmp.micro.blog/2026/02/03/capy-log-miniflux-and-more/", "title": "Capy Log: Miniflux and more", "content_html": "

I’m excited to announce initial Miniflux support in Capy Reader in version 2026.01.1189. While it was possible to use Miniflux via the Google Reader API, this latest version of the app calls Miniflux’s API directly. Right now the feature set is just the essentials

\n\n

These should cover all the same features as the Google Reader API, but let me know! If you notice anything missing, let me know on GitHub or if you have feature suggestions that are specific to the Miniflux API. I’m already planning to investigate Miniflux’s save feature for example.

\n

Enabling Miniflux

\n

To get started, select “Miniflux” on the account screen and enter your username and password.

\n

If you’re signed in to Google Reader API, just sign out in Settings > Account > Log Out, and then select Miniflux on the account screen. Note that API Keys are not yet supported, but I’m open to feedback on this, especially if you know of any other apps that have this feature already.

\n\"Auto-generated\n

Other Tweaks

\n

I’ve enabled the audio player by default in the latest version. The audio player has been behind an experimental flag for the past few versions, and is now ready for general use. This version includes improvements for FreshRSS by de-duplicating enclosures and showing counts for “My Labels.”

\n

If you enjoy these updates consider leaving a tip on Ko-fi or sharing the app with others! As ever, thanks for using Capy Reader.

\n\"Auto-generated\n\"Auto-generated\n", "date_published": "2026-02-03T22:33:07-05:00", "url": "https://jocmp.com/2026/02/03/capy-log-miniflux-and-more/", "tags": ["capyreader"] }, { "id": "http://jocmp.micro.blog/2026/01/17/podcasts-in-capy/", "title": "Podcasts in Capy", "content_html": "

I released audio enclosures in version 2026.01.1186 of Capy Reader. The goal is to enable audio on supported feeds to provide the full experience of any post. By no means am I trying to build a full podcast experience!

\n

I’m looking for any and all quirks or bugs you may find. If you run across any issues with the feature, please let me know in the announcement thread on GitHub or by emailing me at support@jocmp.com. Screenshots and crashlogs are most helpful, along with detailed steps on how to reproduce the bug.

\n

Happy listening!

\n

How to opt-in

\n

These are opt-in under Settings > General > Audio player. Demo below.

\n

\n", "date_published": "2026-01-17T14:57:17-05:00", "url": "https://jocmp.com/2026/01/17/podcasts-in-capy/", "tags": ["capyreader"] }, { "id": "http://jocmp.micro.blog/2025/08/22/the-guts-of-a-new/", "title": "The Guts of a New Machine", "content_html": "

ReadYou just released v0.15.0 this past week. I’ve been waiting to see their take on one very specific feature: large screen support. I tried it out. It’s great! There’s a subtle animation for article filters in the list column. There’s also an expand/collapse option to view the article in full screen. This is a new paradigm that Google has been pushing in Keep and Gmail. In the face of these improvements, I’ve been thinking to myself, why did I build Capy Reader when ReadYou has such an advanced UI?

\n

In retrospect, I set out to build Capy Reader for two reasons: exploration and compatibility. I wanted to explore how RSS readers worked under the hood, how they looked up feeds, and why they made the trade-offs they made. NetNewsWire’s technotes were a major help here since they delve into sync strategies and software architecture. Needless to say, there’s no shortage of information.

\n

I built Capy Reader for compatibility with Feedbin too. There are plenty of readers available that work with Feedbin, sure, but none of them are exactly a pleasant experience. So when I built Capy, I built it for that. From there, I thought I could skirt around the need for Feedbin sign-in credentials in Google Play’s review process by building out Local accounts. That wasn’t the case. Before I knew it, I was supporting Local accounts, Feedbin, and Google Reader (both Miniflux and FreshRSS). This was a far cry from the original, simple vision of Capy as a Feedbin-only client.

\n

This brings me back to ReadYou’s latest improvements. I’m now considering forking ReadYou and using it as the basis of Capy Reader going forward. There are a few goals I have in mind that would make this unique:

\n\n

There are two more considerations I want to highlight if I go this route. Capy Reader would be relicensed under GPLv3, and I’d also want to build any revisions in a way that could be upstreamed to ReadYou.

\n

All of this is preliminary. These are untested ruminations, and talk is easy. If you have any reasons why you use ReadYou over Capy, or Capy over ReadYou, drop me a line on Mastodon!

\n", "date_published": "2025-08-22T16:18:34-05:00", "url": "https://jocmp.com/2025/08/22/the-guts-of-a-new/", "tags": ["capyreader","rss"] }, { "id": "http://jocmp.micro.blog/2025/08/02/capy-log-open-in-browser/", "title": "Capy Log: Open In Browser, Article List Tweaks", "content_html": "

Summer in the midwest is careening towards autumn, and version 2025.08.1153 of Capy Reader is in review for the Play Store. I haven’t been adding huge feature changes lately. Instead, I’ve been trying to pick apart the app and understand some underlying jank that exists. More on that later. While there aren’t huge changes in this release, I did get around to adding “Open in browser” as an option to view articles.

\n

Open In Browser

\n

“Open in browser” by default has been a long outstanding feature. It was first requested in January of this year. I feel bad sometimes when there’s a huge delta between time requested and time implemented, but I spent a lot of time waffling on this feature.

\n

It’s deceptively simple but the “open in browser” requires two key expectations

\n
    \n
  1. The article opens in the browser
    2. \n
  2. The article is marked as read
    3. \n
\n

This second expectation prevents a direct call to an ACTION_VIEW intent since there is not a way to simultaneously launch two actions from a widget RemoteView. The trade-off then is to create a trampoline activity which first opens the app with a transparent view, and then opens the browser. The trampoline activity can be avoided when the “open in browser” action is initiated within the app since the article state is already within context.

\n

Putting it all together, the new “open in browser” feature in Capy does what it says on the tin:

\n

\n

Feed Selection UI Improvements

\n

One outstanding problem in Capy Reader has been feed list transitions. To spot the bug in previous versions:

\n
    \n
  1. Scroll part way down a page, note the status and toolbar change color
    2. \n
  2. Open the feed list and select another feed
    3. \n
  3. Jank! The previous article list will scroll - or teleport - to the first index, and then the next feed will load in
    4. \n
\n

Here’s an example of the problem at 4x speed. The top bar state jank is noticeable at the 10 second mark when it still appears as the changed color when the list has already switched to the next feed.

\n

\n

The solution I found was to rebuild the article pager in the view layer. This in turn invalidates the list state which simultaneously invalidates the scrollbar state.

\n
import androidx.paging.Pager\nimport androidx.paging.PagingConfig\n\n// In View Model\nfun buildPager(): Pager {\n    return Pager(\n        config = PagingConfig(\n            pageSize = 50,\n            prefetchDistance = 10,\n        ),\n        pagingSourceFactory = {\n            findArticles(...)\n        }\n    )\n}\n\n// Pager is now in Compose view layer\nval articles = remember(...) {\n   viewModel.buildPager(...)\n}\n

The last wrinkle with this approach is pager updates in response to in-feed actions. One example of this is swipe-to-refresh on the “Unread” filter. When the refresh finishes, articles that have been read disappear. If the invalidation flag - in this case a timestamp - is passed to the remember function then the feed will flash causing the list to flicker and jump back to the first index. Instead the solution is to track a separate variable within the view model. When the timestamp changes, the view-level articles variable is refreshed which triggers a new call to the pagingSourceFactory.

\n

Here’s a demo putting it all together:

\n

\n

Something so subtle that you might not have even noticed, but your brain did.

\n

What’s next

\n

In the next few updates I hope to add more settings around “open in browser” based on early feedback. Additionally, I have an outstanding UI tweak around the local blocklists that I really want to wrap up and deliver.

\n", "date_published": "2025-08-02T14:49:32-05:00", "url": "https://jocmp.com/2025/08/02/capy-log-open-in-browser/", "tags": ["capyreader","rss","programming"] }, { "id": "http://jocmp.micro.blog/2025/07/06/the-next-version-of-capy/", "title": "Capy Log", "content_html": "

The next version of Capy Reader will reintroduce the “Mark All Read” button to the toolbar.

\n

The floating action button will still be an option, but I want to free up space for more complex UIs, specifically audio playback which will occupy the same bottom bar area.

\n\"\"\n", "date_published": "2025-07-06T20:23:28-05:00", "url": "https://jocmp.com/2025/07/06/the-next-version-of-capy/", "tags": ["capyreader"] } ] }