Android MMS之草稿管理

当编辑完一条信息后，如果在没有发送的情况下退出编辑页面，那么信息会自动保存为草稿。也就是在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，一次对话，只应该有一个没“说完”的话，所以这种设计也是合常理的。

Composing and editing

MMS在Android Mms应用里面的具体实现形式，或数据结构是SlideshowModel，它是一个每个节点为SlideModel的ArrayList，SlideModel是一个Model的List，也就是它可以接收任何Model的子类，Audio，Video，Image和Text都可以放到SlideModel上面。SlideModel主要用于管理其上面的各个媒体，比如它们的布局，它们的播放控制，而SlideshowModel主要用于管理所有的附件，比如把所有的附件转化成为Android的MMS协议的数据类型Pdu，以及从Pdu转化成为SlideshowModel。
Pdu是实现了MMS协议的标准格式，它可以直接的发送给MMSC，从MMSC取回来的也是一个Pdu格式的数据。应用层Mms不需要关心Pdu的具体实现方式，Android中有一个内部的包com google.android.mms.*下面的类都是专门用于处理Android平台上的MMS。里面提供了工作可以把应用层的数据，比如媒体文件等，进行包装成Pdu，再把Pdu分解成为媒体文件。Pdu的数据结构包括PduBody，这个是用于存放多媒体文件的地方，其里面是PduPart的集合，每个PduPart代表一个文件。PduPersister用于操作这些数据结构，包括写入数据库，从数据库中读取等。
SlideshowModel或俗称幻灯片是应用层的MMS的实现形式，或者它是应用层MMS用来创建，编辑，显示和管理多媒体的一个数据结构。创建和发送MMS的时候，就是创建一个SlideshowModel，构建MediaModel，TextModel等加入到SlideshowModel中。在发送时，SlideshowModel会把其内的媒体文件取出来，转化为PduPart放入PduBody中。收到信息后从PduBody中取出PduPart，还原成媒体文件，生成MediaModel，加入到SlideshowModel中，也就是还原为幻灯片。应用拿到幻灯片后可以做显示和播放。

附件类型

关于附件类型，Mms应用中所有的MMS都有一个幻灯片，其内含有所有的附件文件。但是Mms做了一些特殊的处理，对于一个MMS信息，它的附件类型分为IMAGE, AUDIO, VIDEO,和SLIDESHOW，这些从添加附件对话框的列表中可以看出，而且展现方式也有所不同。但是实际的实现上面并没有这么多的类型，只有一个SlideshowModel，所有的附件都在里面。它处理的规则是这样的，如果只添加了一个媒体(image, audio和video)时，会把类型设置为相应的媒体类型，而只有在附件对话框中明确选择添加幻灯片时并且添加了多张幻灯片后，附件类型才会是幻灯片。这个附件类型只在给MMS添加附件时和发送MMS前有效，主要用于在消息列表中如何展示媒体文件，如果是具体媒体类型，就直接显示，否则显示为幻灯片，这个附件类型仅存在于应用中显示媒体所用，并不会在发送出去的Pdu中有痕迹。当收到MMS后，也是根据转化后的SlideshowModel里面的内容来推测出附件类型，然后再做显示。所以，对于一个MMS来说它始终都有一个SlideshowModel，用户所感受到的附件类型仅是附件媒体显示上面的一个处理而已。

创建和编辑MMS

与传统手机不同，创建MMS并不需要特殊的方式。因为Mms应用对MMS和SMS并不做严格的区分，而是以统一的对话中的一个消息来对待，所以MMS与SMS的区别也很简单，就看一个消息中只否有附件(WorkingMessage.hasAttachment())。创建MMS也十分简单，只需点击Composer而的Attach菜单添加媒体即可。在列表中选择image, audio和video后就只有一个媒体文件，都会跑到其他的Activity去选择文件，然后会返回其Uri给Composer，Composer会调用WorkingMessage.setAttachment()来做具体的添加，用Uri创建MediaModel然后加入到SlideshowModel中，并设置类型。另外，如果选择了Attach幻灯片，就会直接进入编辑幻灯片的而面，可以添加删除幻灯片页，给幻灯片页加媒体文件，设置布局等，之后Composer会把SlideshowModel显示出来，此时的附件类型也是SLIDESHOW，这些都是通过WorkingMessage.load()来完成的。
WorkingMessage在把媒体加到幻灯片里以后，就会回调一个接口 onAttachmentChanged()，Composer实现了此接口，这个接口主要用于通知Composer附件已发生变化，刷新UI以正确显示附件。Composer会创建AttachmentEditor来显示附件的内容，因为所有的附件都放在Slideshow里面这个Slideshow在WorkingMessage中，可以通过WorkingMessage.getSlideshow()来获取。AttachmentEditor会根据Slideshow里面的内容来创建不同的View以展示不同的附件，如果Slideshow中只有一个Video，Audio或Image，就直接创建VideoAttachmentView，AudioAttachmentView或ImageAttachmentView，而对于幻灯片中页数大于1时就会创建SlideshowAttachmentView。还有相应的按扭可以用来编辑，替换或删除，对于单个媒体有查看/播放，选择后可以查看原图和播放音频视频，替换可以重新重选择一个附件，删除会移除掉附件；对于Slideshow有编辑和删除，编辑会直接进入幻灯片的编辑页面，那里可以一页一页的对每页幻灯片进行详细的编辑，删除会移除掉附件。
编辑完附件后有三种处理方式，一个是发送信息，一个是保存为草稿另一个就是放弃信息。发送信息和保存草稿都会对幻灯片进行打包，转成Pdu，并保存到数据库，之后的幻灯片都需要从数据库加载并把Pdu解包成为SlidehshowModel。

Packaging and unpackaging MMS

要发送信息前，或是保存草稿时，都需要把SlideshowModel进行打包生成Pdu格式，并保存至数据库。这个称为MMS的打包（Packaging），是由SlideshowModel.makePduBody()方法来完成，它会把幻灯片里面的内容一个一个的取出来，转成一个PduPart，再 放入PduBody中，以生成PduBody，一个媒体对应一个PduPart，同时还可以设置PduPart的属性以描述媒体的文件，比如ContentType，这是一个用于标识媒体MIME类型的字串；Filename文件的名字； ContentLocation文件的路径。这些信息都用于描述PduPart中数据的元信息（MetaData），也就是数据具体是什么，以便让解包的时候对数据进行正确的处理。
之后PduPersister会通过其persist()方法把PduBody存入到数据库中，它会把PduPart中的描述性信息作数据库字段写入，把文件存储在TelephonyProvider文件夹下面(/data/data/android.providers.telephony/app_parts)，并把存储后的路径作为_data字段写入数据库，这样一条MMS的数据就都写入了数据库中。这以后，MMS的数据都是从数据库中加载，所以原SlideshowModel中的数据库不再有效，如Uri在原SlideshowModel中可能指向一个文件，或是其他数据库，在PduPersister.persist()之后就不再有效了。
当PduPersister.persist()之后，MMS的附件就都从数据中加载，PduPersister.load()会从数据库把数据加载成为一个PduBody，SlideshowModel的方法createFromPduBody()就是用于把PduBody转化成为一个SlideshowModel，从PduPart取出媒体信息以得到正确的媒体格式，和相关信息，可以通过Uri来获取具体文件（流）。
接收到的MMS过程也差不多当NotificationTransaction或RetrieveTransaction用HttpUtils从MMSC获取到MMS数据后会用PduParser来解析数据生成Pdu，再用PduPersister.persist()把其写入数据库，之后会再从数据库中加载。