當編輯完一條信息后，如果在沒有發(fā)送的情況下退出編輯頁面，那么信息會自動保存為草稿。也就是在ComposeMessageActivity的onStop()時，如果還沒有發(fā)送，那么就會調用WorkingMessage.saveDraft()來把信息保存為草稿。期間也會檢查一些條件，比如消息是否已被標識為放棄，或是是否為空（isWorthSaving），如果一切正常會saveDraft()并會用Toast來告知信息已保存為草稿。
草稿的保存也是針對不同的信息而不同，短信和彩信的流程有所不同。
保存短信為草稿
WorkingMessage會先取出短信內容，然后開啟一個新的線程去做接下來的事，WorkingMessage.saveDraft()也會就此返回。在線程中，會先確保ThreadId的正確，如果沒有正確的ThreadId，就不會保存。接著把信寫進數(shù)據(jù)庫，把Type標識為Draft。最后會刪除這個Thread所擁有的彩信草稿，因為一個Thread中只能有一個草稿，所以如果有了新的短信草稿那么就要刪除舊的彩信草稿，同理，后面保存彩信草稿的時候也會刪除短信草稿的。
保存彩信為草稿
與保存短信類似，ComposeMessageActivity在onStop時調用WorkingMessage.saveDraft()；WorkingMessage.saveDraft()先會刷新收信人信息，然后會創(chuàng)建一個彩信的數(shù)據(jù)結構SendReq，然后啟動線程做其他的事，saveDraft()也就此返回。在線程中，先是保證是一個合法的Thread，也就是threadid要正確。同時也要把這個Thread標志為有草稿，這個是由一個DraftCache在管理，它是一個HashMap，來標識哪些Thread含有Draft。如果這個Thread以前沒有附件，那么就為它創(chuàng)建附件，也就是把SendReq寫入數(shù)據(jù)庫；相反，如果已有了附件，那么就更新數(shù)據(jù)庫，把SendReq和Slideshow，日期更新成為當前信息的內容。最后刪除掉已有短信草稿。

這里要注意的對于彩信的操作都由Frameworks中的com.google.android.mms.*包里面提供的類和工具來完成的，它里面會提供Android所支持的彩信的數(shù)據(jù)結構SendReq，把數(shù)據(jù)（Text，Medias，F(xiàn)iles）放入SendReq的方法PduPart，PduBody，把SendReq寫入數(shù)據(jù)庫和從數(shù)據(jù)中讀取SendReq—通過PduPersister?？蛻舳说膽贸绦?，只是創(chuàng)建SendReq，用提供的方法把數(shù)據(jù)寫入SendReq中，用PduPersister來寫入數(shù)據(jù)庫和從數(shù)據(jù)庫中提取，最后用HTTP協(xié)議把SendReq發(fā)送出去。

同時還有一個專門的類DraftCache用來管理哪些Thread含有草稿，它的內部是一個HashMap，可以標識哪些Therad含有草稿。所以，在對草稿操作的地方都會用到DraftCache，如果一個Thread含有草稿，就需要把它的ThreadId標識為有草稿；如果一個Thread的信息已發(fā)送出去，就要把它標識為不含有草稿。

傳統(tǒng)的以文件夾方式管理信息都會有一個專門用于存放草稿的文件夾叫草稿箱。每次編輯信息，無論是發(fā)給哪個人，都可以放入這草稿箱。但是這里也可以發(fā)現(xiàn)，與傳統(tǒng)的以文件夾方式不同，Android中的Mms的草稿是每個Thread一個，而且只有一個，換句話說，不可能存儲太多的草稿。因為Android中的Mms是以對話Thread方式來管理信息的，而一個Thread，一次對話，只應該有一個沒“說完”的話，所以這種設計也是合常理的。

最新評論