So I just tried the api on two entries https://your.site//tt-rss//public.php?op=feed_icon&id=193
And one returned me an image in the middle of the screen. The other, which I notice in the phone doesn’t have a logo, tried to download a bmp file.
Unsure how (or if ) this would be handled by the ios app.
fox
7
there’s isn’t an API-specific endpoint at the moment, I can add one if needed.
the generic endpoint which web UI is using is not authenticated so you can you use that one for the time being. basically just change the URL in the app.
tried to download a bmp file.
fox
8
how does this API endpoint look? i’d rather not return the icon as an encoded JSON payload, it seems wrong.
function getFeedIcon(): bool {
$id = (int)$_REQUEST['id'];
$cache = DiskCache::instance('feed-icons');
if ($cache->exists((string)$id)) {
$cache->send((string)$id);
} else {
return $this->_wrap(self::STATUS_ERR, array("error" => self::E_OPERATION_FAILED));
}
}
you’ll need to check if returned data is error JSON or image binary, which you then save or do whatever else with.
e: Comparing c30b24d09f...b10e54ecca - tt-rss - Tiny Tiny RSS gonna wait for feedback on this.
I can’t comment on it too much being the end user of an app, rather than the developer.
Yeah same here I assume that’s all good but @Tiberius would need to update the app to utilize it I suppose. I never bothered to reach out for support because I wasn’t all that worried about it. But if fox is going to put in the effort to do something about it I think we’d need to get Tiberius to comment.
For now, I retrieve the icon path in the “icons_url” of the getConfig.
Then I download the icon with this url icons_url/feed_id.ico
Of course, if @fox adds getFeedIcon I’ll need to update the app to use this new function depending on the API level. I’m checking API level with getApiLevel but don’t use it for now (I think we are still at level 1 ?)
fox
12
Hi, any potential new builds for the iOS app on the horizon?
Thanks
I’m using an old version of Tiny Tiny RSS (with API 14) and I’m not going to updated it for now.
So, for testing, if someone could provide me with a test instance, I could update and test the iOS app.
@fox the problem is if I use this endpoint, there is no local cache, so every time I download a feed, I need to get it’s icon. Perhaps if the getFeeds return the icon in the JSON this should avoid multiple calls to the API ?
fox
16
what do you mean? you can save the resulting data to file and refresh it at your own leisure.
1 Like
Yes, I can save the data locally, but how can I know if I need to update the data ?
Or I can just let the user to force the refresh if he wants (there is already an option in the app for that)
When you say “image binary”, what is the format of the result ? a json containing base64 image data ?
Because every API call returns a JSON, so sending the image in a base64 JSON is logical. Otherwise, it will break the logic of my software because all calls are made the same way and the JSON decoding is automatic.
fox
19
an image.
it would be incredibly idiotic to return an image as a JSON (how? base64 encoded? why?)
i’m sorry to hear that.
p.s.
sounds like ios developers live in some kind of nightmarish world i want no part of.
it would be incredibly idiotic to return an image as a JSON (how? base64 encoded? why?)
To keep the logic of returning a JSON. For small images, you can easily base64_encode your file to send it in a JSON message. This is one of the ways that is used in the Rest APIs for transfering binaries. And with a JSON, you can also sent other data with this file if you want, a comment for example, or whatever you want, with just one JSON.
I’m not saying that getting the file is difficult, but I’m working on this app on my spare time, if I can easily add this call, i’ll do it, otherwise, I won’t, at least for now, until I find time to work on it.
fox
21
maybe it’s a generational difference at work here but imagine this: we’re not going to wrap everything into JSON simply because we can.
people do all sorts of stupid things.
at work, i have to deal with an application (not just some random little thing, a major part of our production infrastructure) which - among other things - exchanges a lot of images between frontend and backend using base64-encoded messages sent through federated rabbitmq.
predictably, it works like absolute shit. it doesn’t scale. it’s also rather impressively fragile.
i’m not sure what went through deranged brains of people who invented this abomination but i suppose it was something like this: we’re already using rabbitmq to pass some data around, let’s use it for everything. oh it doesn’t support binaries? we’ll wrap them into base64. why not.
well, turns out, there were many reasons why not.
so yes, even though we’re using JSON on other api endpoints which provide structured text data, it doesn’t mean we should use it everywhere simply for the sake of uniformity.
the only kind of metadata for a favicon that would actually matter would be cache-ttl / last-modified information which is already sent through HTTP headers.
imgx64
22
You can use something like SDWebImage to load the images. I haven’t used it, but I used a similar library (Picasso) in Android and it was pretty easy.
I’m using SDWebImage which works fine, but you can only GET an URL. To call getFeedIcon you need to POST data to the API which send back an image (or an error JSON).
I think I can update my code, but I’ve not updated the app since 2 years (but the app works fine, I’m using it every day 
) and I need to refresh/update the code, so it will take some time.
As I said previously, I’m not going to update my server for now, so, for testing, if someone could provide me with a test instance with the latest API, that will be helpful for me. Thanx.
I might be able to help here, since I did ask for an update. I’ll have to pm you @Tiberius for an up address as I’ll add an exception to cloudflare.
@fox I assume there are changes you have or are making? How do I check if I have the api version with these feed icon changes?
