mms slidemodel

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()把其写入数据库，之后会再从数据库中加载。