Thanks for the clarification on the extras. WRT the ImageView, I tested it with setting null followed by setting the URI, and that fails with an NPE somewhere during marshalling the RemoteViews into a Parcel. It doesn't like the null URI. Setting the image resource id to zero first is just as good and works. I'm still confused by how the widget service decides which views to recycle and in what way.
When I'm developing the app, I set the update interval for the widget to 30s and the rate at which calls are made to my provider is steady (every 30s within handful of milliseconds each time). When I log out the intents being received by my provider, it is clear that I'm receiving a perpetual string of updates that include the id that should be delete, here's a simple summary, the widget with id 36 has just been added: (time, action, ids) 04-20 22:01:55.859: APPWIDGET_UPDATE [36] 04-20 22:02:08.709: APPWIDGET_UPDATE [30, 32, 33, 34, 35, 36] 04-20 22:02:17.828: APPWIDGET_DELETED [36] 04-20 22:02:38.718: APPWIDGET_UPDATE [30, 32, 33, 34, 35, 36] 04-20 22:03:08.720: APPWIDGET_UPDATE [30, 32, 33, 34, 35, 36] There's another odd thing that I've noticed too (don't know if it's my mistake, but I'm starting to think not), when my widget is added, the APPWIDGET_UPDATE broadcast is received _before_ the configuration activity is displayed. If I cancel the activity (ie. return a RESULT_CANCELED as the result) I will continue to receive update events for this new phantom widget - it's not visible anywhere but continues to be included in update requests. Any ideas? Tom 2009/4/20 Jeff Sharkey <[email protected]> > > > There's one definite bug: AppWidgetProvider fails to > > handle ACTION_APPWIDGET_DELETED actions properly. > > Good point, the backend service is sending the wrong extras--fixing that > now. > > Another simple way to fix would be to override onReceive to handle > this special-case early before passing to AppWidgetProvider through > super. > > > Additionally (and I haven't investigated this yet) there appears to be a > > possible deficiency in the timeliness of ACTION_APPWIDGET_UPDATED > > broadcast cessation. > > Hmm, that seems odd. It might be related to how updates are > scheduled; what interval are you using? Widget updates are handled > using the new AlarmManager.setInexactRepeating(), which can help save > battery, but can be a little unpredictable. > > > The image is not requested again. What is causing > > this, over-aggressive optimization in the handling of RemoveViews by the > > widget framework, or something else? > > It might be an optimization in ImageView, since it already has that > Uri loaded. It might be enough to have two RemoteView actions, one to > unset it and another to set it back. > > > (Again the workaround is simple: decorate the Uri with something > distinctive > > like a timestamp so that the Uri is unique on each request.) > > That sounds like a good solution too. > > > -- > Jeff Sharkey > [email protected] > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
