Fyi, you don't need to use different URIs. Any of the filterable parts of the intent (action, categories, MIME type, URI, component name) can be used. Also the request code when creating the pending intent is part of the unique identity of that pending intent.
Further, if you are using PendingIntent, there should be no need to add a data intent filter to your manifest -- in fact you probably don't want to do that. If you set an explicit component name in the intent that your component will always be launched, ignoring the intent filter completely. On Fri, Oct 9, 2009 at 3:00 PM, Pablo <[email protected]> wrote: > > Thank you very much :) > > Thats is exactly what I was looking for. > > for future reference: > We changed the way we work with intents and used URIs, now it works > beautifully. > (dont forget your "<data android:schema... />" in your receivers > intent-filter !!) > > thanks Amitkeerti > > On Oct 7, 7:28 am, Amitkeerti <[email protected]> wrote: > > you might be facing a problem because of the pending intent. > > Inorder to differentiate the two intents, you set 2 different URLs in > > the intent. > > (i.e. when you create your intent instead of adding mAppWidgetId as > > putExtra, create an URL out of it and add it as intent1.setData(URI)) > > > > your extra data actually goes into a bundle in the Intent where as the > > URI gets stored in a different variable. So differentiating 2 intents > > based on getData do the trick (rather than differentiating based on > > putExtra(id, int)) > > > > On Oct 7, 1:38 am, Pablo <[email protected]> wrote: > > > > > > > > > A solution (or rather a workaround) was found. > > > I am posting this for future reference: > > > > > It was simpler than I thought, but it didn't occur to me or my friend > > > with whom I am developing this widget, until he recently came up with > > > this simple solution. > > > > > It consists in having the different flags selected by the users in the > > > configuration activity appended as strings to the intent action. > > > > > That way, if you want some instances of your widget to behave by > > > outputting sound and others not, setup different action strings > > > accordingly. > > > (for example, "action_button1_sound" if the button should output > > > sound, and "action_button1_nosound" for the opposite behavior. > > > > > If you have more than one flag you can set in your configuration > > > activity, as it is in our case, you'll have to manifest all possible > > > combinations in your intent-filters. You don't have to parse the > > > intent action string, though, as that is only needed so the intents do > > > not overwrite each other. > > > Therefore, you can now read the arguments passed through the extras > > > and make the buttons behave accordingly. > > > > > If someone finds a nicer solution I will be happy to hear about it! > > > > > thanks! > > > > > On Oct 5, 10:08 pm, Pablo <[email protected]> wrote: > > > > > > I am developing a simple widget which has a couple of buttons in its > > > > layout. > > > > > > Before the widget gets added, the configuration activity is > displayed, > > > > where the user can choose if the widget makes any sounds when the > > > > buttons get pressed or not. > > > > > > Thus, a user can put two instances of the widget, one where he chose > > > > sound to be activated and another where he chose the opposite. > > > > However, I can not seem to be able to reproduce the expected behavior > > > > (that one reproduces sound and the other doesn't). > > > > > > The buttons' behavior varies according to the flags specified to the > > > > PendingIntent: > > > > > > - FLAG_UPDATE_CURRENT seems to override the previous intent/setting > > > > - no flags (0x00) seems to ignore any intent/setting after the first > > > > instance of the widget is put. > > > > > > What I want to do: I want to be able to configure different instances > > > > of the same widget to behave in a different way, according to what > the > > > > user specified in the configuration activity. I am attempting to do > > > > this with the help of the appWidgetId of each instance: > > > > > > I have tried the following when assigning an action to the click of > > > > the button: > > > > > > int mAppWidgetId=appWidgetIds[i]; > > > > Intent intent1=new Intent(); > > > > > intent1.setAction("com.spartancoders.intenttest.TEST"); > > > > Log.d("TEST ONUPDATE",""+mAppWidgetId); > > > > intent1.putExtra("id", mAppWidgetId); > > > > PendingIntent pi1 = > PendingIntent.getBroadcast(context, > > > > 0,intent1,PendingIntent.FLAG_UPDATE_CURRENT); > > > > > > And in the onReceive() method: > > > > > > Bundle extras = arg1.getExtras(); > > > > if (arg1!=null){ > > > > Log.d("TEST > ONRECEIVE",""+extras.getInt("id")); > > > > } > > > > > > This results in the first widget acting properly (The IDs printed in > > > > logcat are as expected) > > > > When adding a second widget, however, the first widget starts > > > > reporting the second widget's appWidgetId in its onReceive(), when it > > > > previously did no such thing. > > > > (because of the FLAG_UPDATE_CURRENT, I guess) > > > > > > How can one make different instances behave in a different way? > > > > Is there a way to do this with the help of the appWidgetId? > > > > > > I have elaborated a widget application for the purpose of debugging > > > > this problem which tries to be minimal, while reproducing the (un) > > > > desired behavior: > > > > > >http://www.2shared.com/file/8243059/b6519584/IntentTesttar.html > > > > > > Any help is appreciated, thanks! > > > -- 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 -~----------~----~----~----~------~----~------~--~---
