Android.App.PendingIntent Class
A description of an Intent and target action to perform with it.

See Also: PendingIntent Members

Syntax

[Android.Runtime.Register("android/app/PendingIntent", DoNotGenerateAcw=true)]
public sealed class PendingIntent : Java.Lang.Object, Android.OS.IParcelable, IDisposable

Remarks

A description of an Intent and target action to perform with it. Instances of this class are created with PendingIntent.GetActivity(Android.Content.Context, System.Int32, System.Int32, System.Int32), PendingIntent.GetActivities(Android.Content.Context, System.Int32, System.Int32, System.Int32), PendingIntent.GetBroadcast(Android.Content.Context, System.Int32, System.Int32, System.Int32), and PendingIntent.GetService(Android.Content.Context, System.Int32, System.Int32, System.Int32); the returned object can be handed to other applications so that they can perform the action you described on your behalf at a later time.

By giving a PendingIntent to another application, you are granting it the right to perform the operation you have specified as if the other application was yourself (with the same permissions and identity). As such, you should be careful about how you build the PendingIntent: almost always, for example, the base Intent you supply should have the component name explicitly set to one of your own components, to ensure it is ultimately sent there and nowhere else.

A PendingIntent itself is simply a reference to a token maintained by the system describing the original data used to retrieve it. This means that, even if its owning application's process is killed, the PendingIntent itself will remain usable from other processes that have been given it. If the creating application later re-retrieves the same kind of PendingIntent (same operation, same Intent action, data, categories, and components, and same flags), it will receive a PendingIntent representing the same token if that is still valid, and can thus call PendingIntent.Cancel to remove it.

Because of this behavior, it is important to know when two Intents are considered to be the same for purposes of retrieving a PendingIntent. A common mistake people make is to create multiple PendingIntent objects with Intents that only vary in their "extra" contents, expecting to get a different PendingIntent each time. This does not happen. The parts of the Intent that are used for matching are the same ones defined by Android.Content.Intent.FilterEquals(Android.Content.Intent). If you use two Intent objects that are equivalent as per Android.Content.Intent.FilterEquals(Android.Content.Intent), then you will get the same PendingIntent for both of them.

There are two typical ways to deal with this.

If you truly need multiple distinct PendingIntent objects active at the same time (such as to use as two notifications that are both shown at the same time), then you will need to ensure there is something that is different about them to associate them with different PendingIntents. This may be any of the Intent attributes considered by Android.Content.Intent.FilterEquals(Android.Content.Intent), or different request code integers supplied to PendingIntent.GetActivity(Android.Content.Context, System.Int32, System.Int32, System.Int32), PendingIntent.GetActivities(Android.Content.Context, System.Int32, System.Int32, System.Int32), PendingIntent.GetBroadcast(Android.Content.Context, System.Int32, System.Int32, System.Int32), or PendingIntent.GetService(Android.Content.Context, System.Int32, System.Int32, System.Int32).

If you only need one PendingIntent active at a time for any of the Intents you will use, then you can alternatively use the flags PendingIntent.FLAG_CANCEL_CURRENT or PendingIntent.FLAG_UPDATE_CURRENT to either cancel or modify whatever current PendingIntent is associated with the Intent you are supplying.

[Android Documentation]

Requirements

Namespace: Android.App
Assembly: Mono.Android (in Mono.Android.dll)
Assembly Versions: 0.0.0.0
Since: Added in API level 1