最近公司開發(fā)一個項(xiàng)目，要求app能夠發(fā)送短信并獲取送達(dá)報告。這本不是一個什么難題，實(shí)現(xiàn)這一功能的代碼一搜一大把，那么這么簡單的一個問題，為什么我要在這里提出來呢？那是因?yàn)槲以趯懘a的時候掉入了一個坑，而且這很可能發(fā)生在很多和我一樣粗心的朋友身上。先給大家分享一下當(dāng)初讓我掉進(jìn)坑里的代碼：

咋一看，好像這段代碼并沒有什么問題，但是在測試的時候發(fā)現(xiàn)無論發(fā)送多少條短信，每次都只能獲取第一條短息的送達(dá)報告??！這個問題當(dāng)時困擾了我很久，感覺自己明明沒有寫錯啊，為什么會出現(xiàn)這樣莫名其妙的問題呢？思索無果之后，我決定查看Android的api,這一看，果然發(fā)現(xiàn)了問題的所在。

PendingIntent.getBroadcast(Context context, int requestCode,Intent intent, int flags)這個方法中有四個參數(shù)，在官方api中給這四個參數(shù)的定義如下：

官方文檔告訴我們，第一個參數(shù)context表示廣播運(yùn)行的環(huán)境，這個很好理解，在Android中activity、service、application等都是context的繼承類；第二個參數(shù)requestCode表示發(fā)送者自定義的一個請求碼；第三個參數(shù)intent用來定義廣播接收者；第四個參數(shù)flag用于控制未指明的意圖，并提供實(shí)際的發(fā)送情況。官方給出了5個值：FLAG_ONE_SHOT表示這個PendingIntent只能被執(zhí)行一次，在調(diào)用PendingIntent的send()方法后將會自動取消，之后再通過它發(fā)送的消息都將失敗，F(xiàn)LAG_NO_CREATE表示當(dāng)這個PendingIntent不存在時返回結(jié)果為null，F(xiàn)LAG_CANCEL_CURRENT表示當(dāng)有新的PendingIntent被創(chuàng)建時，當(dāng)前的PendingIntent將被取消，只需要intent中攜帶的參數(shù)發(fā)生改變，將會檢索一個新的PendingIntent，通過取消之前等待的pengdingIntent確保只有新的數(shù)據(jù)能夠啟動它。FLAG_UPDATE_CURRENT表示當(dāng)pengdingIntent存在時，將會保留它只是將他的intent中的參數(shù)替換。FLAG_IMMUTABLE表示這是一個不可變的PendingItent。當(dāng)然第四個參數(shù)flag也可以自定義。

這下就很容易理解，為什么我每次收到的都是第一條短信的送達(dá)報告了。在我的代碼中，PendingIntent.getBroadcast(Context context, int requestCode,Intent intent, int flags)第二個參數(shù)requestCode給了一個固定值，第四個參數(shù)flag給了一個自定義的值，導(dǎo)致了smsManager以為每次的PendingIntent是同一個，所以每次都返回第一條短信的送達(dá)報告。解決這個問題的方法就是：

1.如果flag自定義且保持不變，則每次請求的requestcode需要改變

2.如果requestCode保持不變且flag非自定義，則flag的值不能是FLAG_IMMUTABLE,FLAG_NO_CREATE

3.如果requestCode保持不變且flag自定義，則flag的值需要作出改變

以上所述是小編給大家介紹的關(guān)于Android發(fā)送短信獲取送達(dá)報告的問題，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！

最新評論