API discussion

[fox]

Actually bulk-loading of articles is the one single difference to the mobile-website. Everything else can be easily achieved with JavaScript and a browser, only caching lots of articles for later offline-browsing cannot.

Except for native platform UI and swipe stuff. I'd prefer those to clumsy web buttons any day of the week. For example, I'm using a special app to read xda-developers forum.

https://market.android.com/details?id=c ... rch_result

Now that I think about it it would be nice to have proper tabs and such in the ttrss-reader. That would eaily differentiate it from the barebones by design mobile/ version.

[nils.braden]

I think it still should be faster. Receiving JSON from server just has to be faster than processing data from the database into HTML and pushing it to the web browser. Unless I screwed the pooch on the API big time. :)

I spent yesterday searching for performance-related problems and did some changes to the code. This won't change speed in orders of magnitude but it should make a difference. Next thing I'll try is lazy-loading of lists, so only the first entries are loaded until you reach the bottom of the list.

Maybe it would be a good idea to add a synchronize-for-later button/offline mode? We could fit it in the existing API call by adding something like a timestamp parameter to getHeadlines (which can include article content).

E.g. you click on sync for offline mode button, app requests articles of "All articles" virtual-feed which are unread and are newer than specified timestamp. In online mode, it just does the usual song and dance with getHeadlines as I go around reading stuff while keeping background traffic to the minimum (maybe lazy-loading of article content or the articles near to the one I'm reading now or whatever). And definitely not fetching anything not related to what I'm actually trying to read in foreground since that's what could easily give the app the appearance of being unresponsive.

Actually all network-communication is done in the background, foreground-tasks only load from DB and spawn new AsyncTasks for synchronisation with the server. So when you start the app and browse articles you only have to wait for the GUI to build and all data to be read from DB.
Another new thing I introduced lately is the so called ImageCache or ArticleCache which is located in the main menu. If you start one of these the app spawns a long-living background task with a notification (with an ugly icon, sry about that ;) ) and preloads all articles for all feeds or in case of the ImageCache it also tries to fetch all stuff from img-Tags and the attached images. Afterwards all stuff should be available offline and references to the locally stored images are inserted into the article-content. Is that what you had in mind? It takes about 40 to 50 seconds for me to refresh my ~20 feeds because for every feed I have to do one call for getHeadlines and then one for getArticles with the list of articles I want...

Now that I think about it it would be nice to have proper tabs and such in the ttrss-reader. That would eaily differentiate it from the barebones by design mobile/ version.

I had a tabbed-interface once but dropped it due to no ideas how to really make use of the tabs for this data. What would you suggest putting into tabs in the reader? When I used it I had one tab for Categories and one for Uncategorized Feeds because the app didn't show them at all at this time but since I integrated them in the normal cagegories the seconds tab was just a shortcut and took too much space..

Greetings,
nils

[fox]

I had a tabbed-interface once but dropped it due to no ideas how to really make use of the tabs for this data.

I need to think about it. What I'd like is something as useful as an XDA forum app. But I have no idea how to translate that to tt-rss.

Is it hard to hack on android? I have some Java experience but never really coded anything for mobile devices. Also, last time I tried doing something in the emulator it worked ridiculously slow for some reason (core i5-750 here and it used like 0% cpu).

[nils.braden]

Is it hard to hack on android? I have some Java experience but never really coded anything for mobile devices. Also, last time I tried doing something in the emulator it worked ridiculously slow for some reason (core i5-750 here and it used like 0% cpu).

Generally its plain java with some special stuff for the layout. At first you don't have to worry about mobile devices too much, only in UI-Design of course. Later on you need to look for performance-impacts like unnecessary invocations and memory-issues but that is only if you fell it is too slow. The emulator is not a good way of testing the performance since it emulates the cpu-architecture and is really slow most of the time, so benchmarking should be done on the mobile-device. I guess if you put your app which was slow in the emulator in your device it will probably run fine :)

[fox]

It takes about 40 to 50 seconds for me to refresh my ~20 feeds because for every feed I have to do one call for getHeadlines and then one for getArticles with the list of articles I want...

btw, you know that you can set include_content to receive article content with the headlines?

Reinstalled the app. Looks well so far and works fast on wifi. I have a feature request, though, can I browse the categories directly, instead of going category -> feed -> headlines? It has been recently requested for mobile/ and I find it to be much more usable.

Is it possible to disable any sort of background transfers? Not sure if that's even enabled, I didn't see any notifications.

Uncategorized feed always is shown when I set it to display unread feeds only.

Personally I would rename "All read" to "Catchup", although maybe the term won't be familiar for those who didn't use the nntp clients.

When I go back from the only unread article back to the feed, it shows me a confusing blank page. Perhaps it would make more sense to display the already read headlines instead. E.g. set it to work like the Adaptive view in tt-rss - show unread only when unread articles are available, show read articles when there are no unread ones.

Got my first error in about 2 minutes of using the app (attached).

[nils.braden]

btw, you know that you can set include_content to receive article content with the headlines?

Didn't use it because it doesn't include the attachments so I would have to fetch them separately later. Any chance of including them in getHeadlines?

Can I browse the categories directly, instead of going category -> feed -> headlines? It has been recently requested for mobile/ and I find it to be much more usable.

That would mean open a category and see all articles right away? Should work with long-press on a category and then "Show all articles".

Is it possible to disable any sort of background transfers? Not sure if that's even enabled, I didn't see any notifications. :)

In the main-menu there is a button for offline/online, this disables all background data (one exception: If you call ArticleCache/ImageCache it loads the data for those who want to stay offline all the time and use only the cache). In the last update I also disabled loading images or other external data in offline-mode which leads to "no data needed at all" but articles with img-Tags dont show images (unless they are already cached). Do you think that is the right behaviour?

Uncategorized feed always is shown when I set it to display unread feeds only.

Strange. I'll have a look at this.
edit: done

Personally I would rename "All read" to "Catchup", although maybe the term won't be familiar for those who didn't use the nntp clients.

I just got familiar with the term because you used it in the API, so I have no idea if other people know it :P
Problem with the buttons is, you need very short terms for the things they do, so "Mark all articles as read" is just too long.
edit: I couldn't find a usable translation for "Catchup" with google-translator so I don't think its a commonly known term.

When I go back from the only unread article back to the feed, it shows me a confusing blank page. Perhaps it would make more sense to display the already read headlines instead. E.g. set it to work like the Adaptive view in tt-rss - show unread only when unread articles are available, show read articles when there are no unread ones.

That would indeed be a good idea, just show all articles when there are no unread articles in a feed.
edit: done

Got my first error in about 2 minutes of using the app (attached). :)

Dammit! Thought I had this one fixed a month ago. But it might be nice at least to catch the SQL-message in the API, because there it comes from. As far as I can see it is a call to getArticle with an empty ID-List.
edit: done

[fox]

Any chance of including them in getHeadlines?

Done.

That would mean open a category and see all articles right away? Should work with long-press on a category and then "Show all articles".

I would've never guessed it was there. Maybe add an option for default behaviour. Well, maybe not. The dropdown is somewhat confusing though, "Read" and "Show all articles". I would've named it differently, I suppose. Maybe "Browse category" for the first option. Dunno.

No qualms with offline mode behaviour you're describing.

edit: I couldn't find a usable translation for "Catchup" with google-translator so I don't think its a commonly known term.

Maybe not. It was commonly used in NNTP clients as a substitute for "mark everything as read".

http://www.merriam-webster.com/dictionary/catch+up

[fox]

Also, I have added support for passing parameters using JSON in raw POST data instead of this whole HTTP query thing. It's available in trunk.

[nils.braden]

Also, I have added support for passing parameters using JSON in raw POST data instead of this whole HTTP query thing. It's available in trunk.

Thats nice, I implemented the connector to use it and it works fine. Will be rolled out when you released the official version containing this code.

I renamed the entries in the long-press-menu so they contain more information about what is going to happen :)

I also added a check for the attachments so only if they are not included in the response to the call to getHeadlines the second call to getArticle will be made so there is no compatibility-break.

[nils.braden]

Hi,

I did just hit an issue with getCounters when Categories are disabled. I always had this enabled so I didn't care much for non-category-stuff but it seems theres happening some strange stuff.

I noticed all Feeds have a category-id but the corresponding category is only visible if you enable categories. The imported feeds nevertheless are inserted in a category and with my reader (which ignores the possibility of feeds without category or disabled categories) you have to use the categories. Its a thing i should perhaps tackle some day but at the moment its not easy to put Feeds in a list of categories like in main-view of the webinterface (All Articles etc are handled as categories in the android-app).

Strange thing now is, the getCounters api-call seems to ignore categories when they are disabled so the reader doesn't display any categories at all (i delete categories, then fetch new ones to make sure deleted categories are removed some day). So when getCounters doesn't provide categories the categories are only displayed when I subsequently call getCategories (and it must be in this order).

I am thinking about decoupling the getCounters call completely because it is the slowest api-call (not sure yet if it is the server or JSON-parsing) but this would lead to unpredictable behaviour when it comes to the order in which calls are made. Any ideas about that? Do you think it would make sense to include categories in getCounters no matter if they are enabled or not? Or should i somehow make sure getCategories is called afterwards and include the feeds in the main view as the webinterface does? Guess thats the way to do it in the future..

Greetings,
nils

[fox]

Yeah, I think that including categories in the API call is the way to go here. I'll try to fix this when I have some time.

btw, I have found an issue with ttrss-reader. It seems that headlines can get stuck in the feed view, e.g. I open the feed, some headlines load. I close it since there was nothing interesting. Open it a week later to see several new headlines load and those that have been loaded before staying there still apparently unread. They are no longer in the API reply, I guess, so the reader never figures out that they should be long gone.

To be honest I would really like to be able to disable any client caching altogether and make it work like mobile/ with a prettier native UI.

[nils.braden]

btw, I have found an issue with ttrss-reader. It seems that headlines can get stuck in the feed view, e.g. I open the feed, some headlines load. I close it since there was nothing interesting. Open it a week later to see several new headlines load and those that have been loaded before staying there still apparently unread. They are no longer in the API reply, I guess, so the reader never figures out that they should be long gone.

Yeah I experience this too sometimes. A while back when I implemented this stuff it seemed impossible to know if articles are still unread but now I think I could just use getCounters, then fetch with limit=unreadCount&view_mode=unread and then mark the rest as read for every feed. Except the "marking as read" this is exactly what happens anyway.

To be honest I would really like to be able to disable any client caching altogether and make it work like mobile/ with a prettier native UI. :)

Problem is, i fetch stuff from JSON and directly write it to the DB because a) this is the fastest way to handle large numbers of objects and b) i can build a DB-backed-list which means the List-View just gets a Cursor on a DB-Query and displays everything it finds. So the only way do "disable" caching is purging, but I think this should be possible. I could add a switch that resets the DB on every launch for example or cuts off articles older then 1 or 2 days or whatever.

As a workaround you could set the number for the article-store-preference to a lower value, it purges old articles when the number of articles is reached.

[fox]

Can you just (optionally?) delete stored feed data before saving whatever got received? That should solve the problem of having potentially expired, I guess.

Edit: well yeah or delete everything on launch, that would work too.

[nils.braden]

Do you think it would be enough if I just fix the problem with the unread articles so you can ignore the caching? It shouldnt make a difference if it caches and shows the right articles or if it doesn't cache and shows the right articles, should it? Another guy wants exactly the same except it should be done on-demand so ther would be a button for purging everything, a preference for purging everything on launch and a preference for purging everything in a feed on update. And all this while I don't see why we need it at all =)

[fox]

Well obviously my idea is superior and you should implement it and only it. j/k

Anyway, as long as the articles won't stay in the headlines view anymore, as far as I'm concerned this will be fixed.