OSS Beta 11

[Travis Tabbal]

Okay, Newsblur got back to me on the ability to get articles by date. So I added that. It seems to work well. They just allow you to get the timestamps back with the hashes, so I have to store them. So this is also a test of my ability to upgrade the database schema. There's a new column, but it should upgrade fine. I don't have the volume of articles some of you do, so those with that issue, please test this and let me know. From some basic tests, it looks good.

I also updated the user data collection to send data to an account I made, and upgraded the library that supports it. The upside is I can see that info now, and get better error reporting than the old library, at least that's what they claim, but the downside is that the app got bigger. It's not huge, 1.2MB, but it is almost double the size. I'll see what the data looks like, and if it doesn't look like it's worth the size bump, I might drop it. As before, you can disable this. It just tells me some basic info about what people do with it and sends me some error reports for crashes.

[taufeq...@gmail.com]

Hi,

Please to inform that the issue where beta10 unread count does not sync with newsblur unread count is not beta10 issue.

i have mark as read all of the feed except for a few. beta10 sync correctly.

I post this in beta11 thread because the finding is consistent with beta11 test

thanks Madox for pointing out the old unread stuff burried in the list and Keep up the good work Travis

Thanks

Taufeq AR

[Alan J Robertson]

Still sounds pretty compact as apps go :-)

Did the NB team have any hints re switching tracked changes off when accessing via the API? That's my only (minor!) issue with things at present. Otherwise it's working brilliantly for me!

A.

On 16 Jul 2013 07:50, "Travis Tabbal" <tra...@tabbal.net> wrote:

Okay, Newsblur got back to me on the ability to get articles by date. So I added that. It seems to work well. They just allow you to get the timestamps back with the hashes, so I have to store them. So this is also a test of my ability to upgrade the database schema. There's a new column, but it should upgrade fine. I don't have the volume of articles some of you do, so those with that issue, please test this and let me know. From some basic tests, it looks good.

I also updated the user data collection to send data to an account I made, and upgraded the library that supports it. The upside is I can see that info now, and get better error reporting than the old library, at least that's what they claim, but the downside is that the app got bigger. It's not huge, 1.2MB, but it is almost double the size. I'll see what the data looks like, and if it doesn't look like it's worth the size bump, I might drop it. As before, you can disable this. It just tells me some basic info about what people do with it and sends me some error reports for crashes.

--
You received this message because you are subscribed to the Google Groups "NewsRob User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to newsrob+u...@googlegroups.com.
To post to this group, send email to new...@googlegroups.com.
Visit this group at http://groups.google.com/group/newsrob.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[mul...@gmail.com]

Dang, just posted on 10.1b thread :P

Downloaded 11b, installed without an issue, check every article as read and sync.
Looks like it did it great.  The only downside is that, at least for me, it syncs the articles in reverse order.  I mean it downloads the older articles first instead the newer ones first.  Am I wrong?

Thanks a lot for your great work, keep it going, please!!

[Travis Tabbal]

Do you set your read preference to newest first as well? I could use that to decide which order to use when syncing as well...

[Travis Tabbal]

Just what HTML elements to not use. I haven't looked into it more. I think CSS can be used to deal with it, if not, regex should work.

[Travis Tabbal]

I had 220 articles in the web UI.

Synced, got 185 in NR.

Synced again a minute later, got 220.

A later sync got 226, but the web showed 222. The web updated a couple minutes later to match.

It's not unusual for large setups like Newsblur to use another set of database servers for things like API calls that might be a little lagged. For example, they might replicate the database in 5 minute batches to keep transactions down. I can't guarantee they are doing something like that, but it fits with the results I get. And occasionally, NR ends up seeing more articles than the web UI as well. So I guess the thing to take away from all this, is not to worry about it too much, because we can't know who's right. :)

However, when I make a call to get hashes, then do the filtering and such, I do get all the articles the API told me about at the moment I asked about them. That's about as accurate as I can expect to be I suppose.

[Alan J Robertson]

Excellent :D

Sent by Alan J Robertson (a...@alanjrobertson.co.uk)
Tel: +44 (0)7939-558-403

[Alan J Robertson]

That reflects my experience as well.  As long as you don't need an instant update between the two and are happy that at some point over 15 min or so that they'll sync up then it works pretty well :)

[Samuel Clay]

NewsBlur uses the same API for both the website and all third-party client apps. So the website (and by extension iOS app) can be considered the source of truth. There is no caching and no slave lag. What I do in iOS-land is keep an unread_hashes table that gets wiped everytime I download the /reader/unread_story_hashes endpoint. Before I make that call, though, I upload any read stories kept in another table. 

[Samuel Clay]

You should be able to use CSS to hide track changes. Just hide your dels and show your ins.

[Samuel Clay]

This is the reason I provide include_timestamps=true in the unread_story_hashes endpoint. I download stories in order based on the user's global order preference. Oldest first starts at the bottom, newest first (default) starts at the top.

[Alan J Robertson]

Ah sorry - just saw this reply, please ignore my other post.  Sounds like a good option to add to NR to be able to toggle this on/off, Travis :D

A.

[Travis Tabbal]

Hi Samuel, thanks for joining us.

The method you describe is basically how I'm doing the sync run. I have a local table I clear, then load up with the unread hashes data. I then delete the hashes I already have stories for, and use the remaining hashes as the download list. I added the timestamp and order based on that now. I do think it will be useful to have it asc/desc order based on the user preference though. The differences in unread counts really just seem to be related to the refresh intervals between the NR app and the web UI not being exactly the same. I don't think there is a problem with either.

One thing I've thought about doing, I have another sync job that marks locally cached articles read that were read from another client. It's doing it's own unread_hashes call, usually just before the main sync one does. I could probably cache that data and be more efficient, at the least it would put less load on the server and data connection. Some of my users seem to keep loads of stories. :)

[Travis Tabbal]

Thanks for confirming that. I'll look into injecting the CSS for that. We have some already being done, so I should be able to add it to that. I'd like to make it optional as some users like it.

[Alan J Robertson]

Thanks, Travis - sounds good.  Thanks also to Samuel for joining in here - I know you've got an official NB Android app but some of us are too addicted to NR to let it go - great to have your input here though!

A.

[Rod Nayfield]

Samuel,

I have a site which shows up in newsrob via the api but does not show up in the site.  I believe I unsubscribed on the web but I still get updated items via NR.  Any ideas on how this happens? (Account Nayfield / site is upstart businesses journal).

[Samuel Clay]

Oh, you'll love this endpoint. Send unread_story_hashes to /reader/river_stories?h=hash1&h=hash2. It's not documented yet, although it will be when I launch offline. You can send up to 100 at a time. That way you can just keep track locally of stories you have and don't have. It's much quicker.

I also added an image_urls key to each story, so you can easily cache images for offline use.

[mul...@gmail.com]

Do you mean UI option "Newest on Top"? Yes, I have it enabled

My feeds are most from Newspapers, wich I read daily while I travel, so I have limited time for about 200 articles or so.  That leads for some unread feeds every day. 

Everytime I sync it download the older feeds first, so to get today feeds I have to resync a few times and mark everything as read.

I suppose every kind of usage is unique in some way.  What one person finds ok might not work for another.  If I read blog feeds I suppose it is wise to read older feeds until I get all of them, so that order seems logic.  But if you look it from a news perspective, the important information is the newest one so if it could use that setting to determine if the order is ASC o DESC it would be totally awesome.

[mul...@gmail.com]

Just as sugestion (and a request :) ) another approach could be to implement the "Mark everything as read" from the NB api:

/reader/mark_all_as_read

It allows to mark as read everything older than X days

[cteeee]

Hi Travis, 

Thanks for all your effort over the last month to keep Newsrob alive.

I have been using the beta versions since end of June. 

Not sure if you can replicate this bug or not. The Cache folder is not clearing out. ie the cached articles just continue to build up. I first noticed that when my phone started to run out of storage. Then when I look at the newsrob folder within the sdcard, it is over 1gigabyte in size.

I have upgraded to the latest version (beta 11) and still, the cached articles do not clear out after I have read the articles.

Interested to know if you can replicate this bug.

thanks

CT

[Travis Tabbal]

I'm already using it!  :D

You mentioned it in the github thread. Works great. I'll look into the image urls key. That sounds interesting.