Elytra – Page 4 – The simple RSS Reader. This blog publishes release notes, engineering and design details.
Yes, you read that right. Thanks to the WebSub spec, Realtime RSS is not only possible, but wildly scaleable if implemented correctly. Yeti is making an attempt at that.
The implications of the above are grand.
If the above holds true, which by means of this post: I am looking for feedback on the above, I not only save money, but enable you (and myself) to get real time notifications from publications which really matter to me. As since Yeti will be paid there won’t be any add-on cost you’ll have to pay to get this. It’s all part of the package.
I look forward to hearing your thoughts on the matter in the comments section below.
RSS readers obviously have their own shortcomings as well. The firehose approach can easily overwhelm, especially when multiple outlets all publish the same news at the same time.
So introducing filters in Yeti was definitely a good idea.
The readers all have settings to help cope with these issues to varying degrees, where possible; it’s just a matter of how many hours you want to spend shaping your RSS bonsai.
And thus Yeti’s approach to get you started with the basics, yet empower you with power tools.
I believe I’m doing the right thing here. Given how much attention this post has garnered over the last couple of hours, I think the timing is just right for Yeti. I guess I’ll just have to go right into the 6th gear and ramp up production.
Another Friday, another alpha release. This is a House-keeping build required for the upcoming single feeds: Unread and Bookmarks.
Image settings now take effect. If the source does not provide alternate image sizes, the default url is used (which could be a big image).
Searching for an article has been optimised to run smoothly on older devices.
When feeds are loaded on app launch, it’ll load the full batch, and then onwards, only load new changes. This largely improves caching and networking performance.
The API has also been updated to not return responses if the local cache matches the server response.
Image views and Gallery views have been reimplemented to be faster for rendering, more performant and use less memory.
Improved text rendering for the article title & author in the article view. It should now scale gracefully with dynamic type.
The above change has also been made in the Feed view for individual cells.
All layout rendering issues in the Article renderer have been resolved. This includes stupid Xcode warnings and the like.
A) Quotes sometimes render with extra height. This is a known issue.
B) Formatted code blocks don’t scroll horizontally in the same line. This is a known issue.
Opening links externally is now partially implemented. This may still crash in some situations.
Sharing an article now adds a “space” between the title and URL. This will be in place until Apple resolves the bug and restores the correct behaviour.
Once again, let’s begin with the abstract confusing title.
But it’s a real one. Here’s some proof.
As you can see, that’s an actual commit. Well, allow me to explain why this exists in the first place.
When you going through a lot of items in a feed, you may find yourself requiring to quickly move between those items or within an item itself. This is particular useful when you’re researching something. The search (which I talk about here) feature ties into this specific bit.
So now you never have to leave the reading interface and can go for a reading spree if that’s your thing.
All of the above may contain information you could be searching for. Being stuck with trying to remember the name of the article you read last Sunday and finding it now is a b****. I’ve been in this position many times myself. Yes, bookmarking can save your bacon. But that method has a big single point of failure: what if you forgot to bookmark it?
An well produced app should save you from this situation. It should save me from this situation. Depending on your current device, you may or not be able to see the tags on this post. I’ve included Levenshtein in there. If you’ve ever heard of Levenshtein distance, you’ll be familiar with how it works. If you haven’t, it’s simply a “score” of how similar or dissimilar two pieces of text are.
Levenshtein distance is also calculated and matched against the title and summary to provide a loosely typed searching experience. So you simply need to know the “general” direction of where you’re going, and not the precise location.
You may think this is a lot for a simple text-based search operation. It isn’t. I wonder why many haven’t already done something like this.