{"id":1928,"date":"2014-12-05T13:12:31","date_gmt":"2014-12-05T07:42:31","guid":{"rendered":"http:\/\/codetheory.in\/?p=1928"},"modified":"2016-05-12T12:59:00","modified_gmt":"2016-05-12T07:29:00","slug":"android-pending-intents","status":"publish","type":"post","link":"https:\/\/codetheory.in\/android-pending-intents\/","title":{"rendered":"Understanding Android Pending Intents"},"content":{"rendered":"

PendingIntent<\/a> is basically an object that wraps another Intent<\/a> object. Then it can be passed to a foreign application where you’re granting that app the right to perform the operation, i.e., execute the intent as if it were executed from your own app’s process (same permission and identity). For security reasons you should always pass explicit intents to a PendingIntent rather than being implicit.<\/p>\n

<\/p>\n

It can be used for various purposes like declaring an Intent which is executed at some point of time in future via the AlarmManager<\/code><\/a> class or one which is executed when the user performs some action with your app Notification.<\/p>\n

A PendingIntent itself is a token referencing the original data (Intent action, data, categories, etc.) maintained by the system. Hence if the owning app’s (creator) process is killed, the PendingIntent will still remain usable from other app proesses that had received it. The owning app can later re-retrieve<\/a> the PendingIntent token if that’s still valid by specifying the same set of data and then even cancel()<\/code><\/a> it.<\/p>\n

Each explicit intent is supposed to be handled by a specific app component like Activity, BroadcastReceiver or a Service. Hence PendingIntent has different methods to handle different types of Intents that it wraps:<\/p>\n