Re-use of the RemoteViews is clear to me now. I wasn't passing back the widget id when configuration is cancelled (the widget example in the SDK doesn't do this either when the back button is pressed). The APPWIDGET_UPDATE broadcast before configuration doesn't surprise me, but having to pass the widget id back does. It seems like state that my caller should be retaining. Also the result of not passing back the widget id is very surprising: an application performs a misdemeanour (forgetting to include an intent extra) and the consequence is an invisible widget that leaches resources but cannot be removed by the user nor the application. Thanks for all the help,
Tom. 2009/4/20 Jeff Sharkey <[email protected]> > > > I'm still confused by how the > > widget service decides which views to recycle and in what way. > > It recycles entire layouts. If you send a RemoteViews with the same > layout, it just applies the new set of actions over the top of the > existing layout, including any current state. So to be safe you'll > want to cover all cases when pushing an update. For example, if you > hide a view in one special case, you'll want to explicitly set it > visible again for all other cases, because you can't know the current > state you're recycling against. (Or you can just use a different > layout for each case, possibly taking advantage of <include /> as > needed.) > > > > I'm receiving a perpetual string > > of updates that include the id that should be delete, > > Yes, that does look like a bug. It looks like the extras bundle in > that broadcast lagging behind because we're not resetting it on > delete. If you /add/ a widget, it should force a refresh of that > broadcast bundle and remove any deleted IDs. > > > > when my widget is added, > > the APPWIDGET_UPDATE broadcast is received _before_ the configuration > > activity is displayed. > > Yes, that's correct. The configure activity is launched by the > AppWidgetHost (in this case Launcher), instead of by the > AppWidgetService. This allows a custom AppWidgetHost to have > pre-configuration placement on their home screen. Also, it forces > developers to push an explicit update when their configuration is > finished. (This makes sure they are ready for AppWidgetHosts that can > launch configure at any time, not just during first-insert.) > > > > 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. > > Are you passing back the appWidgetId in the result extras bundle when > sending back the RESULT_CANCELED? Launcher should try cleaning up any > "canceled" widgets like that, but only if the EXTRA_APPWIDGET_ID is > passed back. > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
