Reputation: 42768
Android example ( https://developer.android.com/develop/ui/views/notifications/navigation#java ) is using FLAG_UPDATE_CURRENT for notification.
Intent notifyIntent = new Intent(this, ResultActivity.class);
// Set the Activity to start in a new, empty task
notifyIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK
| Intent.FLAG_ACTIVITY_CLEAR_TASK);
// Create the PendingIntent
PendingIntent notifyPendingIntent = PendingIntent.getActivity(
this, 0, notifyIntent,
PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE
);
May I know what is the exact different, if we are using FLAG_CANCEL_CURRENT
?
Intent notifyIntent = new Intent(this, ResultActivity.class);
// Set the Activity to start in a new, empty task
notifyIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK
| Intent.FLAG_ACTIVITY_CLEAR_TASK);
// Create the PendingIntent
PendingIntent notifyPendingIntent = PendingIntent.getActivity(
this, 0, notifyIntent,
PendingIntent.FLAG_CANCEL_UPDATE | PendingIntent.FLAG_IMMUTABLE
);
I know I can find their definition
https://developer.android.com/reference/android/app/PendingIntent#FLAG_UPDATE_CURRENT
Flag indicating that if the described PendingIntent already exists, then keep it but replace its extra data with what is in this new Intent. For use with getActivity(Context, int, Intent, int), getBroadcast(Context, int, Intent, int), and getService(Context, int, Intent, int).
This can be used if you are creating intents where only the extras change, and don't care that any entities that received your previous PendingIntent will be able to launch it with your new extras even if they are not explicitly given to it.
FLAG_UPDATE_CURRENT still works even if FLAG_IMMUTABLE is set - the creator of the PendingIntent can always update the PendingIntent itself. The IMMUTABLE flag only limits the ability to alter the semantics of the intent that is sent by send() by the invoker of send().
https://developer.android.com/reference/android/app/PendingIntent#FLAG_CANCEL_CURRENT
Flag indicating that if the described PendingIntent already exists, the current one should be canceled before generating a new one. For use with getActivity(Context, int, Intent, int), getBroadcast(Context, int, Intent, int), and getService(Context, int, Intent, int).
You can use this to retrieve a new PendingIntent when you are only changing the extra data in the Intent; by canceling the previous pending intent, this ensures that only entities given the new data will be able to launch it. If this assurance is not an issue, consider FLAG_UPDATE_CURRENT.
However, it is still not entirely clear. How we can understand their differences, as far as launching activity from drop down notification, by using PendingIntent.getActivity
is concerned?
How can we decide which one to use?
Upvotes: 0
Views: 176
Reputation: 93678
The first one can be used if you're just changing some configuration data of the Intent- some of the parameters in the extras. The second needs to be used if you're changing the activity/broadcast/service it's being sent to.
The first also allows apps that were sent the old pending intent to still use it. The second only allows apps sent the new one to use it. For a notification this isn't applicable, but could be with other uses of a PendingIntent.
Upvotes: 0