Ferra.ru: how we made our reader of news and articles for Android
Hello! It so happened that I work at Ferra.ru. Yesterday we released our application for Android, but I still do not let go of overwhelming desire to share their joy. I think “I am PR” for this purpose will suit in the best way. We did it for a long time, many times reworked. But we liked what we put on Google Play , although, of course, we wanted more. But for a start - just right.
First of all I will answer the question: why? It is clear that there is no problem to read us via RSS. We have a separate feed of articles and even a news feed designer - there you can select individual sections. But RSS is a specific thing. We know about it, you know about it, and the masses of the people do not know. And the statistics of site visits by platforms / browsers confirms this. Plus, functions like commenting are conceived, which the RSS reader will not pull in principle. Anyway, specialized - better than universal.
The design turned out to be minimalistic: two tabs - under the news and under the article. The first are shown in a simple list with headings and text fragments. The articles are smarter: they are shown in horizontal lists for each section, with tiny pictures.
You can switch between adjacent materials with a swipe; you do not need to hook through the list. This idea, it seems, came to us independently, but, as it turned out later, this technique is common. Great minds think alike :)
Now to the technical details. Our application is mobile, and these users have one main feature: slow and sometimes expensive Internet. So I had to think about how not to drive through the air too much. The problem, by the way, was interesting!
')
Let's start with the fact that all the images are scaled on the server side. The client transmits the width of the terminal screen and receives images of the desired size. This is the main measure, and it allowed to cut off traffic in two or three times. Pictures are loaded when the material is opened and cached for later.
Our articles are voluminous, and even bare letters would have eaten a megabyte or two in one update. Well, who needs this senseless cruelty? .. In general, we have made a separate RSS feed of articles that includes only headlines and URLs (they play the role of ID) of the last ten articles from each section. The client receives them, looks at what he does not have yet, and then turns to a separate script that issues the full text of a specific article in the RSS format, giving him the ID of the desired article. How many new articles appeared - so many times will appeal.
In general, we need feedback, criticism, affection, beating and, if possible, advice on how to do better :) So far, of the optimization possibilities, only a request for all fresh articles comes in one fell swoop in order not to rape a long-ping connection.
Ferra.ru on Google Play
First of all I will answer the question: why? It is clear that there is no problem to read us via RSS. We have a separate feed of articles and even a news feed designer - there you can select individual sections. But RSS is a specific thing. We know about it, you know about it, and the masses of the people do not know. And the statistics of site visits by platforms / browsers confirms this. Plus, functions like commenting are conceived, which the RSS reader will not pull in principle. Anyway, specialized - better than universal.
The design turned out to be minimalistic: two tabs - under the news and under the article. The first are shown in a simple list with headings and text fragments. The articles are smarter: they are shown in horizontal lists for each section, with tiny pictures.
You can switch between adjacent materials with a swipe; you do not need to hook through the list. This idea, it seems, came to us independently, but, as it turned out later, this technique is common. Great minds think alike :)
Now to the technical details. Our application is mobile, and these users have one main feature: slow and sometimes expensive Internet. So I had to think about how not to drive through the air too much. The problem, by the way, was interesting!
')
Let's start with the fact that all the images are scaled on the server side. The client transmits the width of the terminal screen and receives images of the desired size. This is the main measure, and it allowed to cut off traffic in two or three times. Pictures are loaded when the material is opened and cached for later.
Our articles are voluminous, and even bare letters would have eaten a megabyte or two in one update. Well, who needs this senseless cruelty? .. In general, we have made a separate RSS feed of articles that includes only headlines and URLs (they play the role of ID) of the last ten articles from each section. The client receives them, looks at what he does not have yet, and then turns to a separate script that issues the full text of a specific article in the RSS format, giving him the ID of the desired article. How many new articles appeared - so many times will appeal.
In general, we need feedback, criticism, affection, beating and, if possible, advice on how to do better :) So far, of the optimization possibilities, only a request for all fresh articles comes in one fell swoop in order not to rape a long-ping connection.
Ferra.ru on Google Play
Source: https://habr.com/ru/post/144541/
All Articles