Tiny Tiny RSS: Community

Tiny Reader RSS iOS for iOS 13

Hi everybody,

There are some issues with tiny Reader RSS iOS on iOS 13. I’m working to update the app for iOS 13.

Since the dark mode is now available for iOS 13 and because I’m having some trouble to maintain compatibility with my own dark mode code, I’ll remove it for older version and start to use native dark mode on iOS 13.

There is a version 2.0.4 on its way, by only for add Spanish and Catalan translation.

Starting version 2.1.0, tiny Reader iOS will be fully compatible with iOS 13.

Stay tuned, I’ll post a beta link here for testing the app when available.

Here is the public link to test the latest beta : https://testflight.apple.com/join/jTfR8yMj

Thanks!

Is it possible to add a some sort of caching so that the treeview and the unread number don’t have to be refreshed each time you enter a folder or start the app?

There isn’t a mechanism in TT-RSS for checking if the feeds and categories have changed (and by change I mean a feed added/removed, a category added/removed, or a feed moved into or out of a category), short of getting the feeds and categories. Therefore, if something like that were cached on the device it would probably miss changes made server side. Might not be a big deal since most of the time it doesn’t change, but when it does it would be annoying.

e: There are some API requests for unread counts (global) and unread counts for categories/feeds, but at that point you’d just be pulling in all the data anyway.

tt-rss web ui refreshes the tree when total feed count changes, i think. i could add a similar API call. it wouldn’t most of the cases and for the rest the user could just manually refresh the tree (and/or have the app refresh it periodically)

API call could return, for example, total count of feeds and latest feed id. if any of those change, it would be a good reason to refresh the tree.

Hi,

The app is still optimised to avoid too many API calls. GetCategories is called on start (or when you refresh the list), getFeeds is called when you select a category (only the feeds of the category are retrieved) and getArticle when you select an article to read it. When you update an article (read, star or publish), all counters are updated locally (except for special categories). You can check in the app log all API calls.

Checking if the feeds/categories have been updated or calling getFeeds will give the same result because in both case, well, you make an API call :wink:

Thanks for your replies! Please bear in mind, I strictly comment from a user’s perspective.

I have a suggestion though:

When I start Tiny Reader up and start reading for e.g. the next 15 minutes (during the train ride, on the loo :wink: whatever), I think it’s not necessary to update the data during such a session automatically - it would be sufficient (and speed up the experience) if I could just manually pull and update if I thought that was necessary during such a “reading session” (I think, this is what Reeder does).

It could even be interesting to have such updates run in the background and have them not started when calling the app if they are less than X minutes old.

To clarify: I have e.g. a category “Work” and “Media” - currently, if I switch from “Work” to “Media”, “Media” gets updated. If I switch back to “Work” just 5 seconds later, “Work” is updated again. I don’t think it’s necessary from a user’s perspective. Also: https://daringfireball.net/linked/2019/07/26/mod-fast-software

I understand your point of vue.

The app don’t use any database and keep everything in memory. So, the app has in memory, at most, one category list, one feed list, one headline list and on article. When you change your category (going from Work to Media for example), the app need to reload the new feed list.
Keeping all data would require too much memory, or a database (and probably a sync mechanism) which is not the purpose of the app.

A new beta is available https://testflight.apple.com/join/jTfR8yMj

  • Fixed white list when app is returning to foreground in dark mode
  • Fixed double-tap for Category on iPad
  • Changed Article view to full screen to restore swipe gesture (iPad)
  • Fixed some UI glitches

Changes to large title behaviour and modal view that can be dismissed with a swipe are giving me headaches… :imp:

I’ve just uploaded a new beta (Build 2.1.0.5).

Large titles are definitively broken in iOS 13 (or Xcode 11/SDK 13 ?), specially when title contains diacritics.

For now, I Think this version will do the job, until the next update of the SDK, so this is probably the final candidate. Unless major bug found, I’ll submit this version to the store later this week.

Not a bug report, but would you be willing to restore the option to swap the Source and Close buttons? It just makes one handed reading easier since it keeps all taps (that I use) on the left side of the display.

Thank you!

This will come back later.

New beta :

  • Compiled with 13.1 SDK
  • Added an option to clear icon cache
  • Added an option to show article in window (like previous version). In this mode, left/right swipe gestures are not available (due to new behaviour of modal view)
  • Added an option to disable large titles (subscription, feed and headline views), if you have problems (iPad mainly)

Translator wanted:
My russian translator doesn’t seems to use tiny Reader anymore, so if you want to translate the latest version in russian, please contact me in private message. Thanks.

BTW, if you want to translate to your language, you can contact me too :wink:

Version 2.1.0 is now available on the App Store.

Good work. It’s working well. Thanks for the update.