nilsbraden
commented
7 years ago I can't remember the exact cause for these decisions of course, its been some years. But I remember having trouble with the API, I just didn't find a safe way to get all the necessary updates without guessing some numbers and trying to load just a bit more the absolutely necessary. So I traded some bandwith for easier implementation.
But I know there are some cases where this doesn't work as expected:
- Large amounts of unread articles are a problem, there is a hardlimit of some ~500 articles iirc
- Starred/Published articles behave strange, pressing refresh several times seems to toggle visibility of some articles
- ...
I guess this whole updating business could be simplified and fixed but since it kinda works and I don't have the time it will have to wait.
I have been using this Android client with a custom server implementation (implements TT-RSS API level 6) for multiple years now. Recently, I tried updating the app to 1.19.1 (from 1.178), and found that the client was no longer able to interact with the server. After implementing support for category id -4 in the getFeeds() API method, I was able to make it retrieve categories and feed information. (Previously it used the getCategories API method, which is a much more likely to exist part of the API).
Upon further investigation, it would appear that the client now seems to rely heavily upon the caching system to issue getHeadline API calls to category -4, with the view modes of unread and all_articles hoping to just retrieve everything and sort it locally back into the correct categories and feeds.
Previously, the client issued the appropriate getFeeds(feed_id) inside a category, and getHeadlines() for each particular feed.
I have looked at this codebase, and these API methods do still seem to partially implemented, items in FeedHeadlineActivity.FeedHeadlineUpdater do make calls to updateArcticles() which looks like it should do the appropriate thing, but the app does not seem to issue these calls over the network, suggesting the caching system is preventing these being issued.
My knowledge of modern Android app development is limited, so I hope you could clarify from here as to whether this was a conscious development decision to retire use of these API methods, or whether it is a subtle bug that would not be immediately apparent on the TT-RSS stock server.