NewsRob 4.2 / August Release / Pin

[Mariano Kamp]

Hi,

first preview of 4.2 contains pin articles: https://newsrob.uservoice.com/forums/35624-general/suggestions/468366-pin-articles-for-later-reading?ref=title

In the pro version you can now swipe Right-To-Left (RTL) to mark an unread article "pinned". This article will not automatically marked as read when using mark all read/mark read until here and will also not automatically marked as read when opening the article.

It will be marked as read when you swipe LTR (or from the menu) and also when the article is marked as read on the server side.

Here it is: http://groups.google.com/group/newsrob/web/newsrob412-2.apk

Cheers,

Mariano

[Patrick Staber]

This is great.  I love the functionality.  Works great for me.

 

Thanks a lot.

 

Pat

--
You received this message because you are subscribed to the Google Groups "NewsRob User Group" group.
To post to this group, send email to new...@googlegroups.com.
To unsubscribe from this group, send email to newsrob+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/newsrob?hl=en.

[Michael Richardson]

It's cool, but I'd like a way to invoke it from the article display
itself.

[Patrick Staber]

While in the article display, swipe right-to-left twice and it will pin the article. 

 

 

On Thu, Jul 22, 2010 at 4:31 PM, Michael Richardson <m...@sandelman.ca> wrote:

It's cool, but I'd like a way to invoke it from the article display
itself.

[Henrik Heimbuerger]

What is the reasoning behind marking a pinned article that is swept LTR as read?

Intuitively, I would have expected this to be three-state, arranged horizontally: pinned <-> unread <-> read. So LTR-swiping a pinned article once would make it unread again, swiping it LTR once more make it read. (You could express the current implementation as: pinned <- unread, unread <- read, pinned -> read, unread -> read.)

But I guess I'm missing a use case here that saves you one swipe if it is implemented like this.

[Patrick Staber]

I like that when swiping left-to-right on a pinned article in becomes read.  Why would you want to just change in back to unread?  I defiantly want this functionality when in the article detail view.  So when I've read the article I don't have to swipe twice to mark an article read.

I did notice a couple of weird happenings. Let me explain.

1. When in folder with a list of feeds and having read articles hidden the pinned articles are also hidden.  Example, if I go to the article list view of a feed with 3 unread articles and pin all three and then back out to the folder view that feed disappears as if all the articles are read.  However, when I'm in the article list view of that feed the pinned articles are shown when I have read articles hidden.

2. When at the home view and choosing a folder that says 1 unread article (read articles are hidden) I'm taken directly to the first pinned article (in detail view) of a feed above the feed that has just 1 unread article. 
Example:
Inside folder "Weird" I have three feeds; "A" and "B".  "A" has three pinned articles and "B" has one unread article.  At the home view with read articles hidden it shows me that I have 1 unread article for in my folder "Weird".  When I click on that folder I'm taken to the first pinned article in "A" not the unread in "B".  Then when using the back button I'm taken to the home view again and it still shows me 1 unread article in "Weird".

3. In a folder view I have 4 feeds.  When showing read articles the first feed had a read but starred article.  I when into that feeds article list view and pinned the article.  Backed out to the folder feed view and found that that feed was now gone completely.  So the folder feed view wasn't showing that I had any articles (unread or read) for that feed.  I had to go to the 'all articles' for that folder.  I found the pinned article, changed it to unread (green) backed out and then the feed was shown having one unread article.

Sorry for the long email.  Let me know if I'm not making any sense. This is on my Moto Droid.

Pat

[Mark Otway]

I have to say, the whole swiping thing seems unintuitive and clumsy to me. Why not just have a map-style pin icon in the article next to the 'star' that can be tapped to toggle pinning? IMO, swiping should only be used to sweep the article offscreen and move to the next article.

Swiping in the article list is also so inaccurate that it's not something I'll ever use regularly. Too many times i swipe and the wrong article disappears, or the swipe isn't registered properly. I'd prefer an icon I can tap on the left of each article, in the same way I'd multi-select with a checkbox.

The swiping thing seems contrived to me at the moment, I'm afraid.

[Patrick Staber]

Swiping keeps the title space uncluttered.  It keeps the focus on the article title without the distractions from a bunch of other items.  But then again, I have few if any problems swiping.  And if you put a check box on the left side of title in the article list view, people are going to complain that they open the article by accident when attempting to check the box.  Also, currently to star an article one must to go to that articles detail view, it can't be done from the list view. 

I use the swiping all the time and find it to be very efficient in my personal work-flow.  I'll agree it isn't 100% intuitive but now it's second nature for me.  After using it I for 6 months I find it to be a really ingenious method of input for a touch screen. 

I read all the time about people complaining about it being clumsy and swiping the wrong article.  The swipe only take a little motion, it doesn't have to be across the entire screen.  The problem with selecting the wrong article could be due to vertical space the title uses (1, 2, 3 or 4 line title).  The larger the space the easier it is and decreases the chance of swiping the article above or below incorrectly. 

Can you tell this is one of my favorite features of NewsRob?

[Mark Otway]

I disagree about the checkboxes. I use plenty of apps where checkboxes are used to great effect within lists. A 3-state icon (read/pinned/unread) would work really well and is also discoverable by new users. Using swiping within the article view itself would be an obvious next/prev navigation idiom that is used throughout Android and so becomes immediately intuitive and discoverable. Having a 'pin' icon on the title within the article makes more sense and is stateful, discoverable and intuitive; all key tenets of good UI design.

The problem with swiping is that it's hit and miss. Sometimes when I try and swipe and end up marking an article as read, sometimes I don't - often I get the angle wrong and mis-swipe meaning nothing happens. It's just too hit-and-miss for me.

That said, I don't really understand why pinning is needed; I just star articles I want to read later or keep on the device, and the "keep my recently starred on the device" feature in Pro means I have pinning by default. And the fact that it's a Google reader function and so my starred articles are kept/grouped on the web GUI too means it's the best workflow for me. So as long as any pinning-related swiping doesn't intrude on my current workflow, it's not an issue for me *personally*.

On 23 Jul 2010 05:20, "Patrick Staber" <pdst...@gmail.com> wrote:
Swiping keeps the title space uncluttered.  It keeps the focus on the article title without the distractions from a bunch of other items.  But then again, I have few if any problems swiping.  And if you put a check box on the left side of title in the article list view, people are going to complain that they open the article by accident when attempting to check the box.  Also, currently to star an article one must to go to that articles detail view, it can't be done from the list view. 

I use the swiping all the time and find it to be very efficient in my personal work-flow.  I'll agree it isn't 100% intuitive but now it's second nature for me.  After using it I for 6 months I find it to be a really ingenious method of input for a touch screen. 

I read all the time about people complaining about it being clumsy and swiping the wrong article.  The swipe only take a little motion, it doesn't have to be across the entire screen.  The problem with selecting the wrong article could be due to vertical space the title uses (1, 2, 3 or 4 line title).  The larger the space the easier it is and decreases the chance of swiping the article above or below incorrectly. 

Can you tell this is one of my favorite features of NewsRob?

On Thu, Jul 22, 2010 at 10:53 PM, Mark Otway <ma...@otway.com> wrote:
>

> I have to say, the whol...

[Mark Otway]

To illustrate that fact, I was just playing with the pinning functionality, and swiped left-to-right to mark an article read, and it took me into the article view..... :-/

[Henrik Heimbuerger]

I didn't say I want it. I just said it is what I expected and what I consider intuitive. :)

I definitely see your point, though. And I think convenience (one action instead of two) should be worth the higher learning effort here.

[Mariano Kamp]

I think I understand what you described and all of the issues seem bugs. Pinned article should be counted as unread articles in the overviews.

Please keep an eye on those three issues in the next release. I will try to fix them.

[SergioA]

Great feature Mariano, I was eagerly waiting for it.
Just downloaded and will try!
Thanks & ciao
Sergio

[Mariano Kamp]

You're right. It would be more "symmetric" if swipes in both directions would do the same thing, just in opposite directions.

But I don't see a use case for the pinned -> unread, except correcting an accidentally pinned article. I expected that over time the consistent implementation (that would've been much easier to implement) would become annoying as it is one additional step that normally isn't needed. 

[Mariano Kamp]

Reading the discussion on uservoice on this feature it became very clear that some people don't have any use for this feature and some people are excited to get it. 

I think that this is ok and so this feature is implemented in a way that shouldn't get in the way of the people who don't want to use it and still is easily accessible for the people who do. In this release it is even completely invisible for the people who don't use it.

With the upcoming introduction of an action bar in the article detail view this will change a bit, because there will be a pin icon/action button. But at least in Mark's case he falls into both groups: people who don't want pinning and who don't want the action bar. As the action bar can be turned off, all should be good ;)

On the use of checkboxes in general. I only really see that in Gmail (and RTM?) happening and it is visually appealing. But there are a couple of draw backs. I'll list them in descending order of their importance:

They take away space on the screen, even if not used at the moment, or never used at all.

It is a mess. There is some controversy about having an iPhone like touch-only interface or the Android way that also supports alternatives such as a trackball. Unfortunately this whole thing is not very consistent and not very well thought out. In a list view you are not supposed to have other controls. Try the GMail app, you cannot select an article with the trackball, you can just open it, because there is only one action you can reach with the trackball. In touchmode you can also select the articles. 

As far as I understand there are currently discussions on adding a List2 to Android that can only be used in touchmode ...

Last not least and the only reason that is very important to me: This concept is bigger than a list or a 10 seconds time span.

A checkbox list means that your workflow must be to quickly scan over some headlines, make a decision for those headlines and execute the decision. 

That's not the way I see this feature. It is much more fluid. You can walk over the list, mark some articles as pinned, open some other articles and have a closer look, make them pinned too or leave them read, go back to the list, maybe change to another app, return to the list and then hit Mark All Read / Mark Read Until Here. 

At no point were you forced then to think about your "unit of work", you never needed to tell NewsRob when you were entering selection mode, resuming it, changing to reading, leaving the app etc. 

When coming to a different view, like only a particular feed, you will see the articles as pinned, even though you pinned them in another view (try that with GMail).

I like this style of working.

Also the pinned state will make the article detail view not mark the article as read.

Btw. there is one thing that I like about the checkboxes list and that is that you can do "mass transactions", like starring a lot of articles at once ... but it seemed more of a theoretical use case to me and wasn't that strong anyway.

--

[Mark Otway]

I guess the point is that using checkboxes to mark a random selection of articles as read is a neat workflow. I find I use the "mark-read-until-here" option a lot, but as soon as I see an article title I am interested in, that model breaks down. With checkboxes I could zip down the list, tap-tap-tap and then hit "mark selected as read".

Using a swipe to do this is a) too inaccurate (i frequently end up marking the wrong article as read with a swipe, meaning it disappears and b) has no undo if I change my mind a split second afterwards about a particular article.

>> newsrob+u...@googlegroups.com<newsrob%2Bunsu...@googlegroups.com>

[Disconnect]

I have to agree with this. Without restating what others have said, my thoughts are:
 - not every device has a trackball or keyboard (sigh, galaxy). so it can't be depended on for features. a good touch layout works with or without. (I understand many of the limitations are in the underlying listview type)
 - in the article view, having pinning on the left and starring on the right makes sense and fits the existing layout/workflow.
 - swiping is a mess (especially on the galaxy, where db transactions are -SLOW- and so you have to wait 5-10 seconds to see if it worked or not before trying again) and swiping in lists is basically not doable on any device I've tried it on. swiping an entire article around makes more sense, and seems less prone to accidents.
 - read-until-here is GREAT. unless you have seen something earlier you didn't want to mark read, at which point you are back to opening dozens of articles just to mark them read, or blindly swiping and hoping you don't hit the one you liked.
 - some users use newsrob for high-volume feeds/folders, and that is just a fact. the only way to get rid of them (us) is limit the article count to something insanely low. in the meantime, you are going to keep hearing about usecases that don't exactly match yours..

That looks very negative, but in reality newsrob has one of the more usable interfaces of an android app that I've seen yet :)

[Mariano Kamp]

 - some users use newsrob for high-volume feeds/folders, and that is just a fact. the only way to get rid of them (us) is limit the article count to something insanely low. in the meantime, you are going to keep hearing about usecases that don't exactly match yours..

Do you mean me with this? I don't try to get rid of people with high traffic feeds at all?!

Anyway, regarding the swiping. Have you recently tried it on the list view? I am not using onFling() anymore, but implemented this myself and it works very, very well for me. The only thing is that you must really do a longer swipe at the moment, but I will reduce that necessary length for the next build.

Other than that it works 100% of the time for me.

FWIW The gesture will be executed on the row that the gesture was started on.

[Disconnect]

On Fri, Jul 23, 2010 at 10:46 AM, Mariano Kamp <marian...@gmail.com> wrote:

 - some users use newsrob for high-volume feeds/folders, and that is just a fact. the only way to get rid of them (us) is limit the article count to something insanely low. in the meantime, you are going to keep hearing about usecases that don't exactly match yours..

Do you mean me with this? I don't try to get rid of people with high traffic feeds at all?!

I know you aren't trying to get rid of users.

You have expressed a few times that you didn't intend newsrob's "normal" use case to be high-volume feeds where you open only a few of the articles, pick-and-choose from the middle, etc. (I have an insanely high volume feed, plus several merely stupidly large :) so I brought up those issues off and on for a while.)  Also:

Btw. there is one thing that I like about the checkboxes list and that is that you can do "mass transactions", like starring a lot of articles at once ... but it seemed more of a theoretical use case to me and wasn't that strong anyway.

It's not theoretical to some of us :)
 

Anyway, regarding the swiping. Have you recently tried it on the list view? I am not using onFling() anymore, but implemented this myself and it works very, very well for me. The only thing is that you must really do a longer swipe at the moment, but I will reduce that necessary length for the next build.

I've used it with some success, but I'll try it again and pay more attention.. (Just did a quick test - worked as expected, except for the galaxy lag. 2 tries did nothing - probably too short - and the third worked, but I tried again while it was stalled and it marked the next article read as well.)

On the stalling front, I know it is a hack but is there a way to let galaxy users use the external SD? To get around the android 1-sd limitation they mount the removable one under /sdcard/sd and feed /sdcard as the programatic sd location. The built-in storage is incredibly slow, and moving the newsrob db to the (potentially faster) external sd would make life a lot better. (Stalls can be up to 30 seconds long, and just moving from article-no-images to article-no-images can routinely take 10 seconds.)

Other than that it works 100% of the time for me.

FWIW The gesture will be executed on the row that the gesture was started on.

..unless it is stalled and that row is actually already gone :) Not a newsrob problem though.
 

[Mariano Kamp]

Oh. I wasn't aware of that sd card thing. Yes, sure, please add it to
uservoice.

On Friday, July 23, 2010, Disconnect <dc.dis...@gmail.com> wrote:
> On Fri, Jul 23, 2010 at 10:46 AM, Mariano Kamp <marian...@gmail.com> wrote:
>
>  - some users use newsrob for high-volume feeds/folders, and that is just a fact. the only way to get rid of them (us) is limit the article count to something insanely low. in the meantime, you are going to keep hearing about usecases that don't exactly match yours..
>
> Do you mean me with this? I don't try to get rid of people with high traffic feeds at all?!
>
> I know you aren't trying to get rid of users.
>
> You have expressed a few times that you didn't intend newsrob's "normal" use case to be high-volume feeds where you open only a few of the articles, pick-and-choose from the middle, etc. (I have an insanely high volume feed, plus several merely stupidly large :) so I brought up those issues off and on for a while.)  Also:
>
> Btw. there is one thing that I like about the checkboxes list and
> that is that you can do "mass transactions", like starring a lot of
> articles at once ... but it seemed more of a theoretical use case to me
> and wasn't that strong anyway.
> It's not theoretical to some of us :)
>
> Anyway, regarding the swiping. Have you recently tried it on the list view? I am not using onFling() anymore, but implemented this myself and it works very, very well for me. The only thing is that you must really do a longer swipe at the moment, but I will reduce that necessary length for the next build.
>
>
> I've used it with some success, but I'll try it again and pay more attention.. (Just did a quick test - worked as expected, except for the galaxy lag. 2 tries did nothing - probably too short - and the third worked, but I tried again while it was stalled and it marked the next article read as well.)
>
> On the stalling front, I know it is a hack but is there a way to let galaxy users use the external SD? To get around the android 1-sd limitation they mount the removable one under /sdcard/sd and feed /sdcard as the programatic sd location. The built-in storage is incredibly slow, and moving the newsrob db to the (potentially faster) external sd would make life a lot better. (Stalls can be up to 30 seconds long, and just moving from article-no-images to article-no-images can routinely take 10 seconds.)
>

> Other than that it works 100% of the time for me.FWIW The gesture will be executed on the row that the gesture was started on.

[Mark Otway]

The lag is half the problem. On my nexus, it's so hit and miss that combined with the delay on the DB updating, it takes about 1.5s to swipe an article read. So let's ignore the times when the swipe doesn't register and I end up in the article view) imagine how long it's going to take me to knock out 200 of the 250 slashddot articles in my queue ring now. If it was checkboxes, in portrait mode, I reckon I could check about 3-4 *per second*. So including scrolling (which I'd have to do because the items wouldn't disappear until I did "mark selected as read) I reckon the swipe mechanism will take me between 4-6 times longer than doing it via taps (remember there's no lag because no DB activity happens until I submit the selection to be processed). Add a few mis-swipes and suddenly there's a whole lot of frustration and wasted time.

And Mariano, if you never mis-swipe and end up in an article then you clearly have a far more delicate touch than me.

On 23 Jul 2010 16:12, "Mariano Kamp" <marian...@gmail.com> wrote:
Oh. I wasn't aware of that sd card thing. Yes, sure, please add it to
uservoice.

On Friday, July 23, 2010, Disconnect <dc.dis...@gmail.com> wrote:

> On Fri, Jul 23, 2010 at 10:...

[Disconnect]

Is that the right place for bugs? I thought that was mainly for feature request. (It isn't a newsrob bug -exactly-, but neither is it a feature request...)

[Mariano Kamp]

New update: http://groups.google.com/group/newsrob/web/newsrob412-3.apk

- Progress indicator now small

- Fixed the bugs in "pinning"

Patrick, I am not sure if I understood all your cases exactly. Could you please retry them?

Thanks!

[Patrick Staber]

Mariano,

 

Thanks for the update.  It appears all the bugs I was seeing have been fixed.  I'll test more later today and report back if I see anything strange.

 

Thanks again for a great app.

 

Patrick

[Mariano Kamp]

Great, thanks for the confirmation.

--

[Travis Tabbal]

I really like the smaller progress indicator. Thanks! :) 

[Alan J Robertson]

Ditto, a big improvement :-) (off to a corner would be even better, but appreciate that might be more difficult).

A.

On 27 Jul 2010 21:10, "Travis Tabbal" <tra...@tabbal.net> wrote:

I really like the smaller progress indicator. Thanks! :) 

--
You received this message because you are subscribed to the Google Groups "NewsRob User Group"...

[Mark Otway]

+1. Massive improvement, so much more elegant.

[Paul Chiorean]

On Tue, Jul 27, 2010 at 22:32, Patrick Staber <pdst...@gmail.com> wrote:

Thanks again for a great app.

I know that everyone here loves NewsRob, but I want to restate that

<shameless promotion>
    This is the most used application on my phone*.
</shameless promotion>

Thanks. :)

Paul

* On my Hero I don't use as many apps as I did on my iPhone. Not even 10%.

[Mariano Kamp]

Great. Thanks ;-)

Written on a mobile device

[Disconnect]

I like the smaller notifier, but I think it is tooo small. (At least on a galaxy, I missed it completely the first couple of times it appeared.)

I think a title-bar-sized spinner across the title bar would make the most sense, visually, but I may be in the minority :)

I can x2 the list-position bug - after mark-read-until-here, it doesn't jump to the top (either pos 0 or last-pinned).

I also have a little more info on the lag: with 250 articles, it is significantly faster than 500. (Like, 1/3 the delay.) And with 500, on good wifi (and then decent 3g), it took over an hour and a half to sync yesterday before I finally cancelled it. Much of that time was in deleting overflow entries.

I trashed the cache this morning and a resync of 250 articles took less than 20 minutes (not sure exact time, it ran while I was getting ready for work.)

I am about to do a from-scratch sync test, using the onboard storage. 500, offline-use on, default articles. (2 feeds have downloadPref=1, 2 have =3, using instantpaper.)

The all-articles count is climbing very fast - 200 within 90-120 seconds. I'll report back when it finishes.

[Mariano Kamp]

When you enable the log you can see the time certain phases do in the resulting log.

In general the deletion of the cached articles takes a serious amount of time. Erasing flash is very slow.

[Disconnect]

(using 'date' on the phone to get time, activity based on notification bar)
Wed Jul 28 11:03:33 EDT 2010 - start
Wed Jul 28 11:07:07 EDT 2010 - downloading articles (504 total)
Wed Jul 28 11:10:49 EDT 2010 - 250/504
Wed Jul 28 11:15:47 EDT 2010 - 443/504
Wed Jul 28 11:17:41 EDT 2010 - complete (501 articles showing, not 504?)

Is articles+images supposed to be that much worse? 15 mins articles, 90+ for articles+images.. (Once I send this, I'll set it back to +images, wipe the cache and rerun..)

Paging through some articles (left/right arrows) takes between 1 second and 5 seconds (feed setting was forced to 'articles')
Opening an instapaper article showed a blank page. (Ooooh. night/day mode makes a difference. In day mode it shows "class java.io.FileNotFoundException:null".) "Refresh content" worked.

Feature: I'd like to see day/night settings in the 'more' menu everywhere so that I don't have to mark an article read and back out to switch.
Bug: Instapaper stylesheet warning. (Screenshot attached) Also, "night" breaks on instapaper - grey-black on grey is bad. grey/white on black is better :)

Looking at the screenshot again, I withdraw my request to put the 'pin' on the left. Perhaps by overloading the star though..? Nothing -> Star -> Pin -> Both -> Nothing..

[Disconnect]

Looks like articles ("best for battery") is not the same as the articles part of "articles+images".. instead of just images it seems to be downloading the entire article:
<07 28 12:05> Timing: Downloading page http://www.macrumors.com/2010/07/27/apple-agrees-to-honor-mis-priced-mac-mini-orders-in-taiwan/ took 1105 ms.
<07 28 12:05> Timing: Downloading page http://go.theregister.com/feed/www.theregister.co.uk/2010/07/28/automated_check_counterfeiting/ took 1481 ms.
<07 28 12:06> NewsRobHttpClient: http://images.apple.com/downloads/dashboard/status/images/xboxnxegamercard_20100727110849-thumb.jpg-> HTTP STATUS: 200 HTTP/1.1 200 OK length=5536
<07 28 12:06> Timing: Downloading page http://www.apple.com/downloads/dashboard/status/xboxnxegamercard.html took 472 ms.

[Mariano Kamp]

I cannot reproduce the performance issues.I don't know much about the
SD card issues you were talking about before either. I can dig into
that, but as I said before please submit to uservoice. That's what I
use to gauge interest in a topic before I invest large amounts of
time. You can add "Galaxy S" to the title if you think that this is a
special issue there.

The Instapaper integration is experimental for exactly that reason and
to not get bogged down with many many bug reports I will likely pull
it again before the next release or show a warning that it is provided
"as is". The guy from Instapaper stopped talking to me (it's a free
service and fully within his rights of course) and there isn't much I
can do without investing huge amounts of time, which are probably
better spend on other stuff.

I don't see what the difference is between "articles+images" and "+images".
Pinning is already on the left. (if that is what you mean). A pin icon
will not be introduced in this version, but with another version that
comes with an action bar then.

[Mark Otway]

One thought re: instapaper to resolve support issues (other than my "make it an optional pro feature because people who buy NR are likely to be more rational and less vitriolic) would be to make the mobilizer customisable. So you would default to get, but have an optional "mobillizer URL prefix". Then people can use whatever they like, with the relevant "no guarantee, YMMV" caveat. This is how is worked in the old days (via the debug file) and was quite a neat solution. People can use instapaper if they like (and bug Marco Arment directly to fix the encoding quirks) so the support burden is immediately removed from your shoulders.

[Disconnect]

I think there is some nomenclature confusion on my part.

I'm looking at the settings, and I don't see any way to say "Just download the rss feeds and any embedded objects." It seems like "article" and "webpage" are used interchangably (but if so, why would you want article+images+simple page? Wouldn't "simple page" cover all that?) And feed + full webpage doesn't seem like it would be "easiest on the battery".

I guess I would expect the defaults list to be "Feed" "Feed+Images" "Feed+Webpage" "Feed+Simple Webpage".  (Since presumably the webpage includes any images.)

As to performance, with the storage set to local (2 gigs of "internal sd" on /data) here are some timing results from yesterday. (I can send the whole log to you if you want, but here are the bits that stand out..)

There are some serious sqlite performance problems:
(Part of a sync after delete-cache)
<07 28 11:44> Timing: isMarkAllReadPossible - total took 18 ms.
<07 28 11:44> Timing: DB.insert for 20 records. took 22968 ms.
<07 28 11:44> Timing: Dashboard::requery took 193 ms.
<07 28 11:44> Timing: isMarkAllReadPossible - total took 45 ms.
<07 28 11:44> Timing: DB.insert for 20 records. took 18553 ms.

About 1 second per record. It is pretty stable.

The articles+images doesn't seem to do what I would expect it to do. Instead of rss-feed plus embedded images, it seems to be loading the full webpage for each article:
<07 28 11:45> Timing: isMarkAllReadPossible - total took 1065 ms.
<07 28 11:45> Timing: Downloading page http://twitter.com/NASA_Hubble/statuses/19748051376 took 3779 ms.
<07 28 11:45> Timing: Dashboard::requery took 145 ms.
<07 28 11:45> Timing: isMarkAllReadPossible - total took 1264 ms.

That is the place it spends most of its data acquisition. The other part that is incredibly slow:
<07 29 07:30> Existing Articles (before Deleting oldest entries over capacity)=559
<07 29 07:30> reduceToCapacityAboutToBeCalled
<07 29 07:30> Timing: isMarkAllReadPossible - total took 65 ms.
<07 29 07:30> Timing: getOverCapacityAtomIds took 159 ms.
<07 29 07:30> Timing: Dashboard::requery took 33 ms.
<07 29 07:38> Timing: UnreadWidgetProviderrequestWidgetsUpdate took 60 ms.
<07 29 07:38> noOfEntriesReduced=55
<07 29 07:38> Timing: Dashboard::requery took 241 ms.
<07 29 07:38> Timing: isMarkAllReadPossible - total took 23 ms.
<07 29 07:38> Timing: Dashboard::requery took 37 ms.
<07 29 07:38> Existing Articles (after Deleting oldest entries over capacity)=504

8 minutes to remove 55 articles. Clear-cache took -much- less time:
<07 29 10:19> Existing Articles (before Clear Cache)=506
<07 29 10:19> setGRUpdated=-1
<07 29 10:21> Timing: FeedList::requery took 6 ms.
<07 29 10:21> Timing: isMarkAllReadPossible - total took 14 ms.
<07 29 10:21> Timing: isMarkAllReadPossible - total took 6 ms.
<07 29 10:21> Timing: Dashboard::requery took 2 ms.
<07 29 10:21> Timing: UnreadWidgetProviderrequestWidgetsUpdate took 36 ms.
<07 29 10:21> Existing Articles (after Clear Cache)=0

Deleting read articles was very slow this morning:
<07 29 06:45> External triggered refresh.
<07 29 06:45> SynchronizationService - start
<07 29 06:45> NOTIFICATION: Running: set
...
<07 29 06:45> Existing Articles (before Deleting read articles)=500
<07 29 06:45> deleteReadArticlesAboutToBeCalled
<07 29 06:45> Timing: getReadArticlesAtomIdsForDeletion took 39 ms.
<07 29 07:15> Timing: UnreadWidgetProviderrequestWidgetsUpdate took 11 ms.
<07 29 07:15> noOfArticlesDeleted=221
<07 29 07:15> Existing Articles (after Deleting read articles)=279

Then another series of 15-20 second 20-record inserts. (I had to cancel the sync before it finished because it makes the phone unusable and I needed to check weather, calendar, etc..)

Overal interactivness is still pretty laggy - I'm still seeing large delays moving between articles, but the 'mark as read until here' seems comparatively fast (eg marking 1 article takes 5 seconds but 40 only takes 15-20)

[Travis Tabbal]

Note that the "lag fix" on XDA makes NR *FLY* on a Vibrant. It's not the main cache, it's the database. The NR data directory is only a few K, /sdcard/newsrob has all the big stuff. I'm not sure Mariano can change where that goes, I've never tried that in my Android development. I did the version that symlinks directories around and uses the NAND flash in the phone to store data. I hope a kernel comes out soon with ext-fs support so I can move all that to my external class 6 SD card ext partition. The NAND is very space limited, but there's enough for what I'm doing right now. 

[Disconnect]

I moved just the newsrob databases (I don't have enough room to move everything) and got some much better numbers:
<07 29 11:43> Timing: EntryManager.updateReadState(3) - updateReadState took 83 ms.
(instead of 5 seconds!)
<07 29 11:42> Timing: DB.insert for 20 records. took 199 ms.
(instead of 20 seconds)
<07 29 11:42> Timing: Synchronization Runnable took 56309 ms.

Newsrob -could- solve this though, with custom storage locations: http://uservoice.com/a/4M3RI
The db depends on the cache, so they should travel together. The sd card may well be as fast or faster than onboard storage (even on platforms where the onboard storage isn't as brain-damaged as the galaxy.)

[Mariano Kamp]

I agree, the users of the pro version tend to be **much** more reasonable than the users of the lite version and interestingly enough the users of the paid version seem to feel less entitled than the users of the free version.

However I don't want to put anything into the pro version that directly uses work of somebody else. 

Making it configurable would very elegantly solve my issue and I have seen twitter clients do it that way. The downside I see is convenience and the sheer universe of possible misspellings of the mobilizer url ;)

I currently think of calling the feature unsupported and see how people react (or hopefully not react). If I still get complaints about fit-to-width not working or the background color, or the JavaScript controls or whatever I could use your other recommendation and show a screen explaining that. 

And if that doesn't work either go back to the variant with the pro version.

[Travis Tabbal]

I'd like to slap someone at Samsung upside the head for the retarded onboard storage. It's fine for media, but WTF were they thinking putting databases and such on there? 

I agree it would be nice if NR could let me choose somewhere else to store the database. I'm just not sure about the Android DB API. I think it allows that, and if it does, NR would get a huge speed boost for non-root users with a simple tweak. I voted for the issue, I hope it makes the cut. :) 

[Mariano Kamp]

But why is the onboard storage so much slower? Isn't it also flash? And what do you do with so slow storage? Long time archival?

[Travis Tabbal]

I honestly don't know why it's so slow. It seems to work fine for even the NR cache, and music. I expect video would work, but haven't tried it. It is flash, but it's really slow. Slow enough I have to think it might be a bug. I suspect they just didn't think things through when they put the databases there, if it's supposed to be that slow. 

I understand your reasons for wanting to keep the DB in onboard flash. It does make a HUGE difference in performance in the case of the Galaxy S though. I can't think of any other way to speed it up right now that doesn't involve a lot more work. There's stuff like more caching, background threads to write the DB, etc.. But those are labor intensive for the developer and come with their own possible issues. 

[Tim Wood]

Maybe NR could perform a quick and dirty speed test and assessment (size) of all available storage mediums and make an informed decision for the user then present to them what it figured out and let them override if they wanted.

-Tim

[Disconnect]

See, the thing is they saw that it was slow. That is why /dbdata carries all the built-in databases....

Yeah. They moved all their apps to faster NAND. (It isn't totally insane, since they can control what and how much is stored there.)

It is probably a cost issue, plain and simple. They learned from the g1 mistake (super small storage) and provided a reasonable amount of app storage, they just didn't expect it to be so heavily used during normal operation. (And since dbdata has the built-in apps on faster nand, they might not have caught it during initial testing - by the time they got to wider tests, it was way too late to change.)

[Mariano Kamp]

New update: http://groups.google.com/group/newsrob/web/newsrob412-4.apk

- Mark Read Until Here / Mark All Read return to the top of the current list.

- Added Unsubscribe Feed.

Undecided about Instapaper, but with this exception 4.2 is feature complete and I intend to release it on Thursday/Friday.

Afterward I will go on vacation and it will be the first vacation where I will try to stay off the internet for as much as possible and clear my head. That will include support etc. So this release needs to be out on the next weekend, so that it gets some time to mature before my vacation (21st of August until 13rd of September).

[Mark Otway]

Mark-read-until-here jump-to-top functionality works nicely so far. :-)

Have a great vacation!

On 1 Aug 2010 16:10, "Mariano Kamp" <marian...@gmail.com> wrote:
> New update: http://groups.google.com/group/newsrob/web/newsrob412-4.apk

>>> newsrob+u...@googlegroups.com<newsrob%2Bunsu...@googlegroups.com>

[Mariano Kamp]

Glad to hear that. I'll keep the "better" solution in mind for the future.

Thanks!