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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
