I had similar problems with one of my apps: 1.) Application.onCreate got called multiple times in parallel. The reason was that I misconfigured a custom SyncAdapter to be launched in its own process. And each process gets its own instance of Application. That caused my app to re-create notifications that were already there. Check your app's manifest file for occurrences of android:process. There's no need for custom ContentProviders or services to run in separate processes.
2.) when the process dies and gets re-created the notifications created by the previously running instance of the app stay. But your app starts fresh and goes the default route of trying to re-create all notifications. Android provides an update mechanism of refreshing already existing notifications created by your app. However, I noticed that a "silent update" does not work with notifications that have been created by a previous instance of my application. Instead Android decides to discard the old notification and trigger the update as a "new notification" with alarm sound, ticker text and so on. That's at least the case for my available test devices. I don't know whether I missed something obvious here but I could not make a "silent" update work in case of a re-started process. I had to come up with a workaround and keep track of notifications myself. My app uses a database which contains notification alarm time stamps. When my app re-creates notifications it makes the following decision: if a notification is older than X minutes it will be re-created with no alarm and no ticker text assuming that these notifications are already visible. If it is fresher than that then it will be created with all bells and whistles. It's not a perfect solution because for a very brief moment you can see that the notification icon disappears and re-appears again. But I could not find any other solution to that problem. On Friday, January 18, 2013 10:09:17 AM UTC-6, Jake Colman wrote: > > >>>>> "MM" == Mark Murphy <mmu...@commonsware.com <javascript:>> writes: > > MM> On Fri, Jan 18, 2013 at 10:11 AM, Jake Colman > <col...@ppllc.com<javascript:>> > wrote: > > >> Am I making a fundamental mistake in how this is supposed to be > done? > > MM> No, that all seems OK. > > >> You've already told me that when the application is recreated it > >> gets a new context. If so, how are preferences persisted across > >> recreations of my application if the "key" to those preferences > >> are the context? > > MM> The "key" to those preferences is the package name. An easy way > MM> to get the package name is by calling getPackageName() on a > MM> Context. The "key" to those preferences is not the Context > MM> itself. > > MM> In this case, the "key" is used as the basis of a filename, for > MM> the XML file which contains the persisted SharedPreferences. > > Ok. That makes sense but brings it all back full circle. > > It's clear that Application.onCreate is being called multiple times for > my app. It also seems that my preferences are being reset as a result > of that happening. But from everything that I am reading in this > discussion it would seem that should not be the case. I guess I have to > add some debugging code and have my user side-load it to see if I can > get some insight into the problem. > > Incidentally, this is a fairly straighforward application with nothing > fancy. It uses an AppWidget class, one Activity, a Preference > Activity and a Service to do some work on behalf of the widget. So any > whatever is causing my problem it's not because I am being too fancy. > > -- > Jake Colman -- Android Tinkerer > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
