Tiny feature / change request
Mark Otway
Coould NR not begin a sync when the phone reboots? When I reboot it's usually to stop the phone running slowly, so starting a sync just kills it unless I remember to start the app and cancel the job.
I know you were thinking of changing it so the timer is reset by a manual or locale sync too, that would really help.
Good post re CM this morning, BTW.
Mariano Kamp
you're still using 1.5? Could you wait and see if the need to reboot your phone is still there in 1.6?
I use the boot event to establish the sync schedule, because Android doesn't persist "alarms". I currently leave the phone another minute to get up and running, before the first sync kicks in, and there is some room here, but I don't want the first sync to be started just 20 minutes after the boot.
The possible changes to the scheduling that I described in the other mail would also not help as there I wouldn't persist the alarms, which I otherwise would need to implement.
Let's see what 1.6 brings you? I don't need to reboot anymore.
Btw. did you try to toggle GPS? That worked for me with 1.5.
Regarding CM, there is a comment from Bungabo, that he will care for those bugs and that there is a bug tracking system (bts) in place. Funny thing is that I read about BTS often. I just didn't know what the acronym stands for and assumed it was a scheduler for Linux ;-)
Mark Otway
If 1.6 stops the phone from ever slowing Dow then that'll be great, but I'll be surprised. I know they've adjusted the background sync priority, but I've not heard of anything that'll significantly reduce performance degradation long-term. I'll be happy to be proven wrong though.
It makes sense to init the sync schedule on reboot, but why not just set the timer rather than actually do a sync? :-)
On Oct 10, 2009 7:59 PM, "Mariano Kamp" <marian...@gmail.com> wrote:
Hey Mark,
you're still using 1.5? Could you wait and see if the need to reboot your phone is still there in 1.6?
I use the boot event to establish the sync schedule, because Android doesn't persist "alarms". I currently leave the phone another minute to get up and running, before the first sync kicks in, and there is some room here, but I don't want the first sync to be started just 20 minutes after the boot.
The possible changes to the scheduling that I described in the other mail would also not help as there I wouldn't persist the alarms, which I otherwise would need to implement.
Let's see what 1.6 brings you? I don't need to reboot anymore.
Btw. did you try to toggle GPS? That worked for me with 1.5.
Regarding CM, there is a comment from Bungabo, that he will care for those bugs and that there is a bug tracking system (bts) in place. Funny thing is that I read about BTS often. I just didn't know what the acronym stands for and assumed it was a scheduler for Linux ;-)
On Sat, Oct 10, 2009 at 12:50 PM, Mark Otway <ma...@otway.com> wrote: > > Coould NR not begin a sy...
Mariano Kamp
If 1.6 stops the phone from ever slowing Dow then that'll be great, but I'll be surprised. I know they've adjusted the background sync priority, but I've not heard of anything that'll significantly reduce performance degradation long-term. I'll be happy to be proven wrong though.
It makes sense to init the sync schedule on reboot, but why not just set the timer rather than actually do a sync? :-)
Mark Otway
I use a task killer, but the browser and other things can't be killed. Like you say, we'll see.
If you only start the timer, how come NR started to sync 2 mins after I rebooted? I have auto-sync set to run every 24 hours... :-)
On Oct 10, 2009 9:21 PM, "Mariano Kamp" <marian...@gmail.com> wrote:> If 1.6 stops the phone from ever slowing Dow then that'll be great, but I'll be surprised. I know ...
1.5 has a serious performance bug. Anyway, you may wanna use a task killer otherwise.Well, lets see what happens.
> > It makes sense to init the sync schedule on reboot, but why not just set the timer rather than ...
That's what I do. To one minute after I receive the boot message.
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are sub...
Mariano Kamp
Because Android OS does not persist the alarms.
Written on a mobile device
On Oct 10, 2009 9:21 PM, "Mariano Kamp" <marian...@gmail.com> wrote:
> If 1.6 stops the phone from ever slowing Dow then that'll be great, but I'll be surprised. I know ...
> > 1.5 has a serious performance bug. Anyway, you may wanna use a task killer otherwise. > Well, l...
> > It makes sense to init the sync schedule on reboot, but why not just set the timer rather than ...
> > That's what I do. To one minute after I receive the boot message. >
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are sub...
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are s...
Mark Otway
Sure, I know that. What I mean is that if i have 30 mins set up as the sync time, surely after a reboot at 5pm, when you initialize you'd set the next sync time for 5:30pm? Likewise, with my 24-hour setting, if I rebooted right now I'd expect your startup routine to schedule the first sync for 21:45 tomorrow night. See what I mean?
On Oct 10, 2009 9:38 PM, "Mariano Kamp" <marian...@gmail.com> wrote:
Because Android OS does not persist the alarms.
Written on a mobile device
> > On Oct 10, 2009 9:21 PM, "Mariano Kamp" <marian...@gmail.com> wrote: >
> > If 1.6 stops the phone from ever slowing Dow then that'll be great, but I'll be surprised. I kno...
> > 1.5 has a serious performance bug. Anyway, you may wanna use a task killer otherwise. > Well, l...
> > > > It makes sense to init the sync schedule on reboot, but why not just set the timer rather t...
> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are...