Workflow issue

[Fabien Chaillou]

Hi,

First thank you for this really great application.
Second, i'd like to explain an issue in the workflow that i
discovered. Here is the story on how to reproduce it :
- In the settings, tell newsrob to only show unread articles
- Go to an article, read it
- decide you wanna do something
-> follow a link from the article or decide you wanna see it in the
browser.
-> do something else, for example change the currently playing song
or open a new activity starting from a notification.
- Press the back button to go back to newsrob.

At this point, the logical thing a user would expect to see is the
last article he was currently reading. Instead, i get the next unread
article (or the previous, i'm not sure of which one !)

I think it has to do with the article being marked as read between its
first reading and the moment you come back to newsrob but that is
quite confusing.

Don't hesitate to ask if you have a question, i'll try my best to
answer :)

Thank you

[Mariano Kamp]

Fabien,

thanks for the detailled description.

You see this behavior all the time?

Well, I can relate to your experience, but unfortunately I can't solve this easily. 

Usually NewsRob should act as you described as desired, but it can't do this always, at least I don't see how.

Let me explain. When you open the article detail view (where you can read the article) I open a database cursor for your selection, this includes in your case the setting "unread only". I let the cursor become stale right away, i.e. it will not be updated when new articles are imported by a running sync or, more importantly, when you read an article. The latter is important, because otherwise a read article would directly be removed from the article detail view, which at least would prevent you to go back to a read article. 

So having this stale cursor has a draw back: I can't easily re-create it.

Hence when Android resumes my activity (the article detail view) right away all is well. But there a couple of things that can happen that will prevent that, e.g. the OS killed my process and with that my stale cursor.

And even if I stored the id of the article and we leave aside the inconsistency with the un/read handling this wouldn't work efficiently with a re-created cursor for the remaining articles as I would have to move the cursor to the same position as before in order to re-enable the next/previous navigation. A naive approach would be to just go through the cursor until the article from the saved id is found, but consider this scenario. Capacity 1,000 articles, user selected "all articles" and reads the oldest article ... when I would resume to that article I would have to go through 999 articles and at least read the id column from each record and if I don't want to add more complexity to this activity than I would actually instantiate each article, which would totally kill the performance (at least a couple of garbage collections when this happens).

I could go on and on, but I just don't see a clean solution here. This might be just me, but nevertheless ... 

Anyway, I am not sure if I lost you here, but the bottom line is: Don't expect a solution from me anytime soon.

Btw. I mark an article as unread if I might have to come back to it. I do this in the web app and in NewsRob.

Cheers,

Mariano

--

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.

[Henrik Heimbuerger]

Can you tell whether the user has 'left behind' (sorry, I still haven't studied the Android activities terminology ;)) NR to a notification or to the home screen?

In that case, I wonder if it would make sense to automatically flag the currently opened article as 'unread' when you're leaving to a notification *and* it was automatically flagged as read by NR due to opening it (i.e. it was *not* already flagged read and it was *not* manually marked read).

The reasoning would be as follows: when you press 'back' to get back to the article list, when you select 'next/previous article' or if you press the home button, you intentionally left the article and/or NR to do something else. In this case, if the article has automatically been marked read, you were aware that this sticks.
However, if you left to an incoming call or to a notification (e.g. SMS) which required your immediate attention, you were basically interrupted from reading, and NR should do what it can to preserve your state without requiring additional activity (i.e. remembering to mark the article as unread manually).

Dunno, I'm not convinced yet. Just an idea.

In pseudo code:
ON EVENT userLeftNewsrob:
  IF articleWasFlaggedReadWhileOpeningView:
    IF userLeftForIncomingCall or userLeftForNotification:
      markArticleUnread()

[Fabien Chaillou]

Hello,

thank you both for your input.
Your answer is cristal clear to me :)

And yes, it happens pretty often because my phone lacks ram (i blame
vodafone for making a version of the my touch 3g in europe with only
188mb of ram !) and i still haven't found a way to add new cheaps of
ram ;).

I'll try to think about the problem, and i'll tell you if i ever have
an idea popping, not so likely though as i neither know the Activity
code nor am i used to android programming (still thinking about an
idea before i start !)

Thank you !

Fabien

On 21 déc, 14:17, Henrik Heimbuerger <hheimbuer...@googlemail.com>
wrote:

> Can you tell whether the user has 'left behind' (sorry, I still haven't
> studied the Android activities terminology ;)) NR to a notification or to
> the home screen?
>
> In that case, I wonder if it would make sense to automatically flag the
> currently opened article as 'unread' when you're leaving to a notification
> *and* it was automatically flagged as read by NR due to opening it (i.e. it
> was *not* already flagged read and it was *not* manually marked read).
>
> The reasoning would be as follows: when you press 'back' to get back to the
> article list, when you select 'next/previous article' or if you press the
> home button, you intentionally left the article and/or NR to do something
> else. In this case, if the article has automatically been marked read, you
> were aware that this sticks.
> However, if you left to an incoming call or to a notification (e.g. SMS)
> which required your immediate attention, you were basically interrupted from
> reading, and NR should do what it can to preserve your state without
> requiring additional activity (i.e. remembering to mark the article as
> unread manually).
>
> Dunno, I'm not convinced yet. Just an idea.
>
> In pseudo code:
> ON EVENT userLeftNewsrob:
>   IF articleWasFlaggedReadWhileOpeningView:
>     IF userLeftForIncomingCall or userLeftForNotification:
>       markArticleUnread()
>

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

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/newsrob?hl=en.
>
> >  --
> > 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<newsrob%2Bunsu...@googlegroups.com>

[Fabien Chaillou]

Just for the record,

you are using an SQLiteCursor if i'm not mistaken ?
I guess you are doing subsequent sql calls to update the rows (if i'm
not mistaken i can't see any way to update the underlying data using
the cursor) so how about keeping the cursor request and all the update
in a transaction and rollbacking it when leaving in an unwanted way ?

Hmm... after some thinking, i guess the problem is more about how to
know if the user will come back to the activity or not and have a
consistent result depending on it. Because if it is even possible to
do what i suggested if the user quits newsrob because of a
notification and only come back later the articles he should have read
will be still marked as unread.

I think i'm also a little to vague on the Activity lifecycle notion.

[Mariano Kamp]

On Mon, Dec 21, 2009 at 6:55 PM, Fabien Chaillou <fabien....@gmail.com> wrote:

Just for the record,

you are using an SQLiteCursor if i'm not mistaken ?

I do.

I guess you are doing subsequent sql calls to update the rows

I do.

 

(if i'm
not mistaken i can't see any way to update the underlying data using
the cursor)

Sure, but when my ArticleManager updates something in the database I also issue a notification that the registered listeners pick up and for example refresh lists, and I deliberately don't do this in this case to keep the cursor stale, or more specifically I keep the "now read" articles in the unread-only-cursor.

 

so how about keeping the cursor request and all the update
in a transaction and rollbacking it when leaving in an unwanted way ?

It's neither possible nor wanted to have a long lasting transaction, but maybe that's not what you meant.

What I tried, but way very messy, is to buffer the deltas for my records in memory and only save it to the database when leaving the article detail view. This is very messy and adds a lot of unwanted code. But my main problem was race conditions and having to implement everything twice then. I always had keep my then called shadow store in memory and query first the cursor, then the shadow store before I can show something like for example the unread indicator or if something is starred.

I think I tried that six months ago and that was the time when I didn't publish an update for weeks. It got complicated very quickly. I don't have the details in my head anymore, but one thing was that I only had the shadow store in the article detail view and this locality would be ordinarily a good thing, but it meant that other stuff wouldn't know the actual status of some articles. But I can't remember what this was actually about.

Anyway I did this for performance reason. The use case that you expect wouldn't be properly supported, because when I get an onPause() (something else gets into the foreground OR my activity is left) I don't know if I should flush the shadow store and can't go back to this state or if this is only temporary and I should keep it. I had a solution for that, but this left me with the problem then where to keep the transient shadow store? If I just keep it in an instance variable and the process gets killed I lost user data (the changed read states). Of course I could go deeper and deeper and implement a serialization mechanism that stores this state and some restore mechanism. 

But I could also take a hammer and bang it on my hands. Same effect ;-)

Hmm... after some thinking, i guess the problem is more about how to
know if the user will come back to the activity or not and have a
consistent result depending on it.

Yes, absolutely. Maybe disconn3ct or another seasoned Android Dev can jump in here?!

At the end of the day it doesn't matter. There is just too much infrastructure to be implemented here for the full solution.

I will describe the workaround in another reply after I am finished with this one.

Because if it is even possible to
do what i suggested if the user quits newsrob because of a
notification and only come back later the articles he should have read
will be still marked as unread.

Exactly. Typical problem with me. Before starting to answer I should've read your answer completely ;)

I think i'm also a little to vague on the Activity lifecycle notion.

Who isn't? ;-)

Anyway I am not re-opening this can of worms. There is so much other stuff I can do with the time. With or without a hammer.

[Mariano Kamp]

On first glance this sounds like a clean solution to me. It is so obvious that I am disappointed I didn't think of it myself.

This would only automate my workaround, but that might be better than nothing. What do other people think about the functionality?

On second glance it is a mess too, but not too messy to implement. But let me outline what I mean, maybe my thinking is to complicated.

Some background. When an Android activity is left onPause() is called. I think this method is always called. Well, almost always, when the process is killed it wouldn't be called. But when the OS starts killing the foreground app we have other issues anyway.

There is a couple of events that can cause onPause() to be called. (a) BACK button is pressed, (b) HOME button is pressed, (c) Activity itself calls finish(), (d) another activity comes to the foreground (think from a notification/phone call).

I would need to one more states to the article detail view: leavingTheActivity. This state would be initially (onResume) populated with "false". I could then override the onKeyDown method and check for BACK and HOME key. I will not consume the key events, but will instead only set leavingTheActivity to "true". This I will also do before calling finish().

So in onPause() I should be able to query leavingTheActivity and if it is "false" then I can mark the article as unread again.

What do you guys think?

If that is the solution why doesn't the framework provide me with the leavingTheActivity flag? Or maybe I just don't know about it?

My experience from the past is that it's really hard to win a battle against the framework. The framework is very explicit about what it wants and every time I tried to deviate from this I got seriously punished.

[Fabien Chaillou]

Hi,

it seems pretty good to me :)
And the use case feels solid here so with some luck the framework
should be ok with you ;)

So what you will implement is only put the current article to unread
again, am i right ?
I think it is enough for the use case, if you really want to read back
other articles that you have read before in the same feed, you mark it
manually as unread (that's what i do).

Anyway, keep us posted about what you decided.
Glad if i could help you in any way.

> hheimbuer...@googlemail.com> wrote:
> > Can you tell whether the user has 'left behind' (sorry, I still haven't
> > studied the Android activities terminology ;)) NR to a notification or to
> > the home screen?
>
> > In that case, I wonder if it would make sense to automatically flag the
> > currently opened article as 'unread' when you're leaving to a notification
> > *and* it was automatically flagged as read by NR due to opening it (i.e. it
> > was *not* already flagged read and it was *not* manually marked read).
>
> > The reasoning would be as follows: when you press 'back' to get back to the
> > article list, when you select 'next/previous article' or if you press the
> > home button, you intentionally left the article and/or NR to do something
> > else. In this case, if the article has automatically been marked read, you
> > were aware that this sticks.
> > However, if you left to an incoming call or to a notification (e.g. SMS)
> > which required your immediate attention, you were basically interrupted from
> > reading, and NR should do what it can to preserve your state without
> > requiring additional activity (i.e. remembering to mark the article as
> > unread manually).
>
> > Dunno, I'm not convinced yet. Just an idea.
>
> > In pseudo code:
> > ON EVENT userLeftNewsrob:
> >   IF articleWasFlaggedReadWhileOpeningView:
> >     IF userLeftForIncomingCall or userLeftForNotification:
> >       markArticleUnread()
>

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

> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/newsrob?hl=en.
>
> >>  --
> >> 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<newsrob%2Bunsu...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/newsrob?hl=en.
>
> >  --
> > 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<newsrob%2Bunsu...@googlegroups.com>

[Mariano Kamp]

I implemented this and found out that even API wise it looks like I could trap the HOME key, I cannot do that. And this makes sense, if you consider the case of UI consistency.

Anyway, so now the rules are as follow:

- An article is marked as read automatically when it is viewed in the article detail view

- When the article detail view gets paused (thrown out/closed/covered 100% by another dialog) the article will be reset to unread when

  - the article was not already read when viewing the article

  - the user didn't leave the article detail view with BACK (i.e. HOME, open something from notification, incoming call, user "show in browser")

Is this easy enough? Even for somebody who didn't read the rules, but needs to explore them?!

To unsubscribe from this group, send email to newsrob+u...@googlegroups.com.

[Mark Otway]

Oi, Mariano, forget about newsrob for today and go and enjoy your Christmas!

On 25 Dec 2009 12:36, "Mariano Kamp" <marian...@gmail.com> wrote:

I implemented this and found out that even API wise it looks like I could trap the HOME key, I cannot do that. And this makes sense, if you consider the case of UI consistency.

Anyway, so now the rules are as follow:

- An article is marked as read automatically when it is viewed in the article detail view

- When the article detail view gets paused (thrown out/closed/covered 100% by another dialog) the article will be reset to unread when

  - the article was not already read when viewing the article

  - the user didn't leave the article detail view with BACK (i.e. HOME, open something from notification, incoming call, user "show in browser")

Is this easy enough? Even for somebody who didn't read the rules, but needs to explore them?!

On Wed, Dec 23, 2009 at 10:47 AM, Fabien Chaillou <fabien....@gmail.com> wrote: > > Hi, > > i...

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

[Disconnect]

This works great btw, tripped over it this morning and it took reading 2 more articles before I realized it works now :)