Oh, and regarding application updates. Resource ids can change with a new application version. The launcher (which hosts your widget) in this case can still refer to the old values and this means it's necessary for the user to recreate widgets after an application update.
This makes the question of whether widget ids are stable almost irrelevant - they are, but unless you take special measures to ensure that their resource references are stable, it does more harm than good. I usually put this info in the changelog (which is shown to the user with each new version), and haven't had any complaints. 20.02.2011 19:49 пользователь "Jake Colman" <[email protected]> написал: >>>>>> "MM" == Mark Murphy <[email protected]> writes: > > MM> On Fri, Feb 18, 2011 at 12:44 PM, Jake Colman <[email protected]> wrote: > > >> My service no longer updates the widget and the widget's data area > >> remains blank. This indicates (at least to me but I'm still > >> learning) that either the widget is not getting its notification > >> to start the service or the service is ignoring its start method. > > MM> I'd add some logging or breakpoints. Depending on how you are > MM> using AppWidgetManager from your service, it's also possible that > MM> the service is running but just not updating the app widget > MM> (e.g., you're using the ID-based app widget update and the ID > MM> changed). > > >> So could it be that the notifications are "confused" between old > >> and new instances of the widget? > > MM> That is decidedly possible. I haven't played around with > MM> supporting multiple app widgets much, so I have no idea how > MM> stable those app widget IDs are. > > MM> If this is for your sunrise app widget from your other thread, > MM> unless you are supporting monitoring sunrise from multiple > MM> geographic locations, I would not worry about supporting multiple > MM> app widgets. Use the updateAppWidgets() that just takes a > MM> ComponentName and update the lot of 'em in one shot. > > So we have already discussed that we are talking about my sunrise > widget, that we have only a single widget instance, and that my code, in > any event, would have updated all instances. > > I have also confirmed that the widget is still receiving notification > broadcasts and starting the service accordingly, and that the service is > getting started. The "only" issue is that the widget is not painting an > update! > > So what about a UID mismatch? The docs say that the service can only > update the RemoteViews if the UID of the appwidget and the service are > the same. Can the UID change if I download a new version of the APK > while the app is still installed on my homescreen? If that happened, it > might explain why the widget remains blank - the service has a different > UID so it canot update the widget. If so, when the widget is disabled > and the services are stopped why wouldn't that clean things up? It > seems that once I am in this state, I have to kill the emulator and > start a new one. Furthermore, if this is, indeed the problem, how I > protect against it. I suppose I can tell the user to be sure to delete > the widget from the homescreen prior to updating but that is not a very > satisfactory solution. > > Thanks! > > -- > 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 [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 -- 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
