Also being in the background scheduling class makes absolutely no difference unless there are foreground threads together needing to use near 100% of the CPU. One would hope that this rarely happens.
On Fri, Oct 30, 2009 at 1:49 PM, Loki117 <[email protected]>wrote: > > Damn ok seems i'll need to bite the bullet and rearchitect. Thanks for > your help both of you. > > On Oct 29, 4:46 pm, Dianne Hackborn <[email protected]> wrote: > > Sorry it's "you can't do that". If the receiver is in the manifest, it > is a > > top-level component not associated with any of your other components. > > > > On Thu, Oct 29, 2009 at 1:20 PM, Loki117 <[email protected] > >wrote: > > > > > > > > > > > > > Agreed going forward this is a better plan and something which I am > > > moving towards but with my current inherited code base this is not a > > > possible so "don't do that" isn't really an option for the moment. > > > > > On Oct 29, 4:15 pm, "Mark Murphy" <[email protected]> wrote: > > > > > Because the service implements an interface to which I require > access > > > > > to by casting the context to it's type. > > > > > > Then don't do that. > > > > > > One solid pattern for AlarmManager is to have alarms trigger a > > > > manifest-registered broadcast receiver, that in turn calls > startService() > > > > on an IntentService that processes whatever work needs to be done > > > > periodically. This allows the work to be done on a background thread > and > > > > shuts the IntentService down when there is no more work, minimizing > > > memory > > > > impact. > > > > > > Conversely, I really do not recommend trying to use AlarmManager with > a > > > > receiver registered in Java code, because that receiver hopefully is > > > > rarely around, because the service that hosts it hopefully is rarely > > > > around. > > > > > > -- > > > > Mark Murphy (a Commons Guy)http://commonsware.com > > > > Android App Developer Books:http://commonsware.com/books.html > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see > and > > answer them. > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -~----------~----~----~----~------~----~------~--~--- > > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
