Sadly, supplying the widget id on the intent doesn't fix the problem - the cancellation of widget creation is never broadcast back to the provider. It's actually a pretty obvious bug in Launcher (when you're looking for it that is): In onActivityResult(), the cancellation is checked for request code REQUEST_PICK_APPWIDGET whereas it should be checking for REQUEST_CREATE_APPWIDGET.
Line 338 in: http://android.git.kernel.org/?p=platform/packages/apps/Launcher.git;a=blob;f=src/com/android/launcher/Launcher.java I'd judge it to be a fairly significant issue. Do I need to start adding a workaround now (a dead list of widgetIds that my provider ignores?) or will a fix be quick coming? Tom. 2009/4/20 Tom Gibara <[email protected]> > 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 -~----------~----~----~----~------~----~------~--~---
