當編輯完一條資訊後,如果在沒有發送的情況下退出編輯頁面,那麼資訊會自動儲存為草稿。也就是在ComposeMessageActivity的onStop()時,如果還沒有發送,那麼就會調用WorkingMessage.saveDraft()來把資訊儲存為草稿。期間也會檢查一些條件,比如訊息是否已被標識為放棄,或是是否為空白(isWorthSaving),如果一切正常會saveDraft()並會用Toast來告知資訊已儲存為草稿。
草稿的儲存也是針對不同的資訊而不同,簡訊和多媒體訊息的流程有所不同。
儲存簡訊為草稿
WorkingMessage會先取出簡訊內容,然後開啟一個新的線程去做接下來的事,WorkingMessage.saveDraft()也會就此返回。線上程中,會先確保ThreadId的正確,如果沒有正確的ThreadId,就不會儲存。接著把信寫進資料庫,把Type標識為Draft。最後會刪除這個Thread所擁有的多媒體訊息草稿,因為一個Thread中只能有一個草稿,所以如果有了新的簡訊草稿那麼就要刪除舊的多媒體訊息草稿,同理,後面儲存多媒體訊息草稿的時候也會刪除簡訊草稿的。
儲存多媒體訊息為草稿
與儲存簡訊類似,ComposeMessageActivity在onStop時調用WorkingMessage.saveDraft();WorkingMessage.saveDraft()先會重新整理收信人資訊,然後會建立一個多媒體訊息的資料結構SendReq,然後啟動線程做其他的事,saveDraft()也就此返回。線上程中,先是保證是一個合法的Thread,也就是threadid要正確。同時也要把這個Thread標誌為有草稿,這個是由一個DraftCache在管理,它是一個HashMap,來標識哪些Thread含有Draft。如果這個Thread以前沒有附件,那麼就為它建立附件,也就是把SendReq寫入資料庫;相反,如果已有了附件,那麼就更新資料庫,把SendReq和Slideshow,日期更新成為當前資訊的內容。最後刪除掉已有簡訊草稿。
這裡要注意的對於多媒體訊息的操作都由Frameworks中的com.google.android.mms.*包裡面提供的類和工具來完成的,它裡面會提供Android所支援的多媒體訊息的資料結構SendReq,把資料(Text,Medias,Files)放入SendReq的方法PduPart,PduBody,把SendReq寫入資料庫和從資料中讀取SendReq—通過PduPersister。用戶端的應用程式,只是建立SendReq,用提供的方法把資料寫入SendReq中,用PduPersister來寫入資料庫和從資料庫中提取,最後用HTTP協議把SendReq發送出去。
同時還有一個專門的類DraftCache用來管理哪些Thread含有草稿,它的內部是一個HashMap,可以標識哪些Therad含有草稿。所以,在對草稿操作的地方都會用到DraftCache,如果一個Thread含有草稿,就需要把它的ThreadId標識為有草稿;如果一個Thread的資訊已發送出去,就要把它標識為不含有草稿。
傳統的以檔案夾方式管理資訊都會有一個專門用於存放草稿的檔案夾叫草稿箱。每次編輯資訊,無論是發給哪個人,都可以放入這草稿箱。但是這裡也可以發現,與傳統的以檔案夾方式不同,Android中的Mms的草稿是每個Thread一個,而且只有一個,換句話說,不可能儲存太多的草稿。因為Android中的Mms是以對話Thread方式來管理資訊的,而一個Thread,一次對話,只應該有一個沒“說完”的話,所以這種設計也是合常理的。