Re: Newsrob log

[Mark Otway]

Hi Mariano,

Background apps I run are locale, twidroid shakeawake, and that's about it. Foreground apps are really newsrob and facebook. My Magic is running unrooted 1.5.

Strikes me that what would work well would be if the update ends unexpectedly, schedule another to run in 5 mins - but only to continue caching seen articles (otherwise you'd end up downloading forever...). I usually caremore about the offline caching than having the latest list of articles...

On Sep 16, 2009 8:31 AM, "Mariano Kamp" <marian...@gmail.com> wrote:

Thanks for testing the zoom feature. I will release it tonight then.

"<09 16 05:58> The synchronization started at Wed Sep 16 04:54:09
GMT+01:00 2009 was ended prematurely."
It seems that the job is shut down by the OS and doesn't end as it should.
(Because of this issue I store the start time of a sync on the phone
and remove it when the sync is done, so that when a sync is triggered
and the start date is still set the previous sync was killed by the
OS. That's what you see above and when you look upwards of this
message you can also see that the process is shut down very early,
before fetching any new articles, leave alone downloading anything."

This is the issue I discussed here:
http://groups.google.com/group/android-developers/browse_thread/thread/76f66fa4e1e39cd
And where I don't see a good solution for.
But before talking about the bad ones, let's do some more analysis first.

Do you use a stock Android or have you got a rooted phone?

The OS doesn't shut down background processes at random. Somebody else
wanted more memory. As you were sleeping, it was probably not a
foreground app, but a background app.
Can you list what Background apps you have? I am in particular
interested if you have Brightkite installed.

When you put down your phone tonight could you leave NewsRob as the
last app on the screen and then turn it off?

One more thing. I don't see any personal information in the log. Would
you mind moving the discussion back on the mailing list with your next
reply?

On Wed, Sep 16, 2009 at 8:27 AM, Mark Otway <ma...@otway.com> wrote: > Hi Mariano, > > Here's a news...

[Mariano Kamp]

Could you please disable the other background apps for tonight? Just
to humor me.

A log (collected with Log Collector) would be great too. I really
don't get why NewsRob was shutdown. At the point it was shutdown it
wasn't really allocating any serious amount of RAM, so it wasn't
competing for resources.
You don't happen to have the SDK installed so that you can capture a
longer log?

I could use the Service.setForeground() (see the link I posted), but I
tried to avoid that so far. But as a self defense this might be the
right thing to do. Donut will null the implementation of this call
anyway.

Re-Scheduling is a slippery slope. One thing is to find the right
re-entry point as you mentioned and the other one is if it would work
at all. In your log the process is shut down so early that NewsRob
would run down the battery with re-scheduling before I would get all
articles.

One thing is for sure though. It will make this whole scheduling/sync
mechanism much more complex. I would need to schedule a wakeup for all
two minutes, that then checks if the sync was interrupted, run it
again, otherwise re-schedule for in two minutes, and at the end of the
sync it needs to be unscheduled. Also the sync needs to learn
different re-entry points also.

[Mark Otway]

I'll try and remember to reboot and kill background apps.

On Sep 16, 2009 9:15 AM, "Mariano Kamp" <marian...@gmail.com> wrote:


Could you please disable the other background apps for tonight? Just
to humor me.

A log (collected with Log Collector) would be great too. I really
don't get why NewsRob was shutdown. At the point it was shutdown it
wasn't really allocating any serious amount of RAM, so it wasn't
competing for resources.
You don't happen to have the SDK installed so that you can capture a
longer log?

I could use the Service.setForeground() (see the link I posted), but I
tried to avoid that so far. But as a self defense this might be the
right thing to do. Donut will null the implementation of this call
anyway.

Re-Scheduling is a slippery slope. One thing is to find the right
re-entry point as you mentioned and the other one is if it would work
at all. In your log the process is shut down so early that NewsRob
would run down the battery with re-scheduling before I would get all
articles.

One thing is for sure though. It will make this whole scheduling/sync
mechanism much more complex. I would need to schedule a wakeup for all
two minutes, that then checks if the sync was interrupted, run it
again, otherwise re-schedule for in two minutes, and at the end of the
sync it needs to be unscheduled. Also the sync needs to learn
different re-entry points also.

On Wed, Sep 16, 2009 at 9:50 AM, Mark Otway <ma...@otway.com> wrote: > Hi Mariano, > > Background a...

[Mark Otway]

Okay, so I revolted, killed some apps, removed some widgets and it looks like every article that should have downloaded has done so. I fess it must be resource related, and something we just have to cope with until donut (which, I gather, will dramatically improve device efficiency and responsiveness).

Out of interest, Mariano, you mentioned making the app foreground as a last resort. Can you elaborate on the implications of this (both +ve and -ve)?

On Sep 16, 2009 11:07 AM, "Mark Otway" <ma...@otway.com> wrote:

I'll try and remember to reboot and kill background apps.

> > On Sep 16, 2009 9:15 AM, "Mariano Kamp" <marian...@gmail.com> wrote: > > > Could you please d...

On Wed, Sep 16, 2009 at 9:50 AM, Mark Otway <ma...@otway.com> wrote: > Hi Mariano, > > Background a...

> > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you a...

[Mark Otway]

Oops - rebooted obviously!

On Sep 16, 2009 11:07 AM, "Mark Otway" <ma...@otway.com> wrote:

I'll try and remember to reboot and kill background apps.

> > On Sep 16, 2009 9:15 AM, "Mariano Kamp" <marian...@gmail.com> wrote: > > > Could you please d...

On Wed, Sep 16, 2009 at 9:50 AM, Mark Otway <ma...@otway.com> wrote: > Hi Mariano, > > Background a...

> > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you a...

[Mariano Kamp]

Hi Mark,

  sounds good. So it is at least not unexplainable. Could you do this again this night, just to see that it's not a coincidence? How was it the last weeks? Did you always have that problem?

  What is +ve -ve? 

  Anyway, the story goes like this. On Android you don't exit apps, you just open them. At some point there are no more resources (ram) and the OS will kill some previously started processes to make more ram available. When a GUI was attached to the killed process and you go back some screens to this GUI then the process will be started again and the GUI knows how to restore itself. So this stopping and starting is transparent to the user. Well, it is slower to start a process than to just switch to it, of course. E.g. returning to the home screen sometimes takes ages, that is when it's restarted, I think.

  Anyway, so how does Android decide what to kill? The least likely to be killed is the foreground app that is also visible to the user, the most likely is a background process that eats up lots of resources (btw. killing and restarting vms is Android's way to compact memory, or so I hear). Of course there are shades of grey in between.

  Now consider an audio playing service. It would be unfortunate if it would be killed, so the Android API has a backdoor for background services to increase their importance to the user (or the way the OS sees it): You can call Service.setForeground(true) to indicate that the background service is needed by a foreground app. This way the background process is less likely to be killed. Other background processed without the foreground flag will be killed first.

  Currently you don't even need a permission or anything to set this flag and it is a known practice that some developers just boost the importance of their background process, which is cheating and unfair to the well behaving services.

To prevent this in Donut you can't do that anymore. I haven't researched yet, what Dianne implemented to replace that, but she outlined her idea in the thread I linked previously.

  The cheating approach is like the cold war, everybody else needs to set the flag too in order not to be killed. I would like to stay away from that, but to most users I don't have a communication channel, so it might still be the right thing to do. Otherwise the users are just annoyed by NewsRob inability to download articles ;-( 

  But let's think about the morale issue after we see if it would really make such a difference. I can send you a NewsRob version by mail that uses the flag and we can see if this works. If on your phone all the widgets and background services already use the cheating approach that wouldn't help much then I suppose.

  

Cheers,

Mariano

[Mark Otway]

Positive and negative.....

All makes sense. I'll see how it goes tonight.

On Sep 17, 2009 10:57 AM, "Mariano Kamp" <marian...@gmail.com> wrote:

Hi Mark,

  sounds good. So it is at least not unexplainable. Could you do this again this night, just to see that it's not a coincidence? How was it the last weeks? Did you always have that problem?

  What is +ve -ve? 

  Anyway, the story goes like this. On Android you don't exit apps, you just open them. At some point there are no more resources (ram) and the OS will kill some previously started processes to make more ram available. When a GUI was attached to the killed process and you go back some screens to this GUI then the process will be started again and the GUI knows how to restore itself. So this stopping and starting is transparent to the user. Well, it is slower to start a process than to just switch to it, of course. E.g. returning to the home screen sometimes takes ages, that is when it's restarted, I think.

  Anyway, so how does Android decide what to kill? The least likely to be killed is the foreground app that is also visible to the user, the most likely is a background process that eats up lots of resources (btw. killing and restarting vms is Android's way to compact memory, or so I hear). Of course there are shades of grey in between.

  Now consider an audio playing service. It would be unfortunate if it would be killed, so the Android API has a backdoor for background services to increase their importance to the user (or the way the OS sees it): You can call Service.setForeground(true) to indicate that the background service is needed by a foreground app. This way the background process is less likely to be killed. Other background processed without the foreground flag will be killed first.

  Currently you don't even need a permission or anything to set this flag and it is a known practice that some developers just boost the importance of their background process, which is cheating and unfair to the well behaving services.

To prevent this in Donut you can't do that anymore. I haven't researched yet, what Dianne implemented to replace that, but she outlined her idea in the thread I linked previously.

  The cheating approach is like the cold war, everybody else needs to set the flag too in order not to be killed. I would like to stay away from that, but to most users I don't have a communication channel, so it might still be the right thing to do. Otherwise the users are just annoyed by NewsRob inability to download articles ;-( 

  But let's think about the morale issue after we see if it would really make such a difference. I can send you a NewsRob version by mail that uses the flag and we can see if this works. If on your phone all the widgets and background services already use the cheating approach that wouldn't help much then I suppose.

  

Cheers,

Mariano

On Thu, Sep 17, 2009 at 6:32 AM, Mark Otway <ma...@otway.com> wrote: > > Okay, so I revolted, kille...

--~--~---------~--~----~------------~-------~--~----~

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