PendingIntent使用填坑记
PendingIntent作用
其实和Intent作用差不多,可以理解为是一种特殊的Intent。和Intent区别在于执行的时机不一样。Intent是立刻执行,PendingIntent是等待条件满足在执行。常用于通知、短信、闹钟等应用情景。
PendingIntent Flag介绍
FLAG_ONE_SHOT:获取的PendingIntent只能使用一次。
FLAG_NO_CREATE:利用FLAG_NO_CREAT获取的PendingIntent,若描述的Intent不存在则返回NULL值
FLAG_CANCEL_CURRENT:如果描述的PendingIntent已经存在,则在产生新的Intent之前会先取消掉当前的。
FLAG_UPDATE_CURRENT:能够新new一个 Intent
问题
在使用PendingIntent.getBroadcast()往里面传带extra的Intent的时候(下面伪代码)
Intent intent = new Intent("com.test.action");
intent.putExtra("key", value);
PendingIntent pi = PendingIntent.getBroadcast(this, 0, in, null, PendingIntent.FLAG_UPDATE_CURRENT);
上面为常见的使用方式。但是上面代码你连续出发2+次你就会发现你在接收的地方可能通过key拿到的value值是一样的。
产生问题的原因?
- Intent对象
- PengdingIntent Flag
- RequestCode
Flag我们这里使用的是FLAG_UPDATE_CURRENT,查阅文档发现问题不在Flag上.
查看Intent。在API描述里面有这么一段话翻译过来意思大概是
对于上文中的字面意思,如果判断为新Intent,则会更新对应的extra data,但是系统是如何判定新Intent的?Object.equals?Intent.filterEquals!但是从源码分析,filrerEquals 比较拥有同样的Action,不一样的data的 Intent 必定是返回false的.
那问题还会出在哪呢?只剩下RequestCode了。是因为RequestCode一样导致的?修改代码验证猜想
Intent intent = new Intent("com.test.action");
intent.putExtra("key", value);
PendingIntent pi = PendingIntent.getBroadcast(this,UUID.randomUUID.hashCode(), in, null, PendingIntent.FLAG_UPDATE_CURRENT);
发现接收结果却是改变了。
总结
归根结底这个问题出在了RequestCode上。所以只要在使用的时刻使用不同的RequestCode就好了。常见使用场景有通知、短信群发等需要添加一个附加值以供在响应结果处做处理的地方。