Hm, there should be no reason to re-create the widget.  All that is needed
is an update of the widget, so the launcher gets a new RemoteViews object
with the new app version's resources.

2011/2/20 Kostya Vasilyev <[email protected]>

> 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
>



-- 
Dianne Hackborn
Android framework engineer
[email protected]

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.

-- 
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

Reply via email to