Thanks, thats a real HELP,
- Roman Guy.. I like your Info, but please its not enough to know that
a bug,
would be great you all help us with Turnarounds.
Now Jeff, one Question, i did not implemented you code right now.
But does this remove still the Problem, that the broadcasts are still
firing
thanks
but what is this extras.getInt when I copy your code extras is
not defined
maybe you have a short workaround for that:
@Override
public void onUpdate(Context context, AppWidgetManager
appWidgetManager,
int[] appWidgetIds) {
ok.. i am a bit further (extras = Bundle extras = intent.getExtras
();) :)
but as i understood, So i just can handle when a widget come deleted.
But that doesnt change anything in the fact, that the internal
int[] appWidgetIds
still list them all. Could I delete the deleted Widget from that
:) now step by step i come closer.
I can catch when a widget come deleted
but still the phantom widgets are in the appWidgetIds listed
Is there any way to delete this phantom widgets from my list
or get a working list of the active installed widgets?
or is the only way to make my own list of
There are basically two ways to end up with phantom widgets being supplied
to your WidgetProvider.
In the first instance, its because the user chose to add a widget, but then
cancelled its configuration. To partially overcome this problem, you can
keep a list of all the widgets you know have been
Hi Jeff (and all),
On Apr 24, 4:02 am, Jeff Sharkey jeffrey.shar...@gmail.com wrote:
So just a heads up that we won't be able to fix the onDeleted() bug
for the 1.5 SDK. Here is a quick workaround that you can patch
against your class that extends AppWidgetProvider to correctly catch
and
hi all.
can anyone please help me in this.
i wish to update a view of an application from another.
eg i wish to change the text of a textview in a layout from another
application of mine.. is it possible.??
On May 3, 6:33 pm, AndroidApp zl25dre...@gmail.com wrote:
Cupcake is really coming out
Cupcake is really coming out :-D~~
On May 2, 9:11 pm, Romain Guy romain...@google.com wrote:
Same thing, won't be fixed in the cupcake update.
On Sat, May 2, 2009 at 6:02 PM, AndroidApp zl25dre...@gmail.com wrote:
'won't be able to fix' for 1.5 SDK, what about on the cupcake update?
'won't be able to fix' for 1.5 SDK, what about on the cupcake update?
Dont really care about whether it's fixed for the SDK.
On Apr 23, 2:02 pm, Jeff Sharkey jeffrey.shar...@gmail.com wrote:
So just a heads up that we won't be able to fix the onDeleted() bug
for the 1.5 SDK. Here is a quick
Same thing, won't be fixed in the cupcake update.
On Sat, May 2, 2009 at 6:02 PM, AndroidApp zl25dre...@gmail.com wrote:
'won't be able to fix' for 1.5 SDK, what about on the cupcake update?
Dont really care about whether it's fixed for the SDK.
On Apr 23, 2:02 pm, Jeff Sharkey
So just a heads up that we won't be able to fix the onDeleted() bug
for the 1.5 SDK. Here is a quick workaround that you can patch
against your class that extends AppWidgetProvider to correctly catch
and handle the onDeleted() event.
@Override
public void onReceive(Context context, Intent
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
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
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
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
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
In onActivityResult(), the cancellation is checked for request
code REQUEST_PICK_APPWIDGET whereas it should be checking
for REQUEST_CREATE_APPWIDGET.
Oops, you're right, thanks for catching that. For the example widgets
I've been writing that use configuration steps, I've been keeping an
17 matches
Mail list logo
