Add attachments setattachment and mmssetattachment to MMS
The specific implementation form of Composing and editingMMS In the Android Mms application, or the data structure is SlideshowModel. It is an ArrayList with each node as SlideModel, and SlideModel is a List of models, that is, it can receive sub-classes of any Model, including Audio, Video, Image, and Text, which can be placed on the SlideModel. SlideModel is mainly used to manage the various media above it, such as their layout and Their playback control, while SlideshowModel is mainly used to manage all attachments, for example, convert all attachments to the Data Type Pdu of the MMS protocol of Android, and convert from the Pdu to the SlideshowModel.
Pdu is the standard format of the MMS protocol. It can be directly sent to MMSC, and the data retrieved from MMSC is also in the Pdu format. The Application Layer Mms does not need to care about the specific implementation method of Pdu. In Android, an internal package com. google. android. mms. * is used to process MMS on the Android platform. It provides the ability to package data at the application layer, such as media files, into PDUS, and then decompose the PDUS into media files. The data structure of Pdu includes PduBody, which is used to store multimedia files. It contains a collection of pduparts, and each PduPart represents a file. PduPersister is used to operate on these data structures, including writing data to the database and reading data from the database.
SlideshowModel, also known as slide, is the implementation form of MMS at the application layer, or is a data structure used by the application layer MMS to create, edit, display, and manage multimedia. When creating and sending MMS, A SlideshowModel is created, MediaModel and TextModel are constructed, and added to the SlideshowModel. When sending a message, SlideshowModel retrieves the media files and converts them to PduPart and puts them in the PduBody. After receiving the information, retrieve the PduPart from the PduBody, restore it to a media file, generate MediaModel, and add it to the SlideshowModel, that is, restore it to a slide. After the application receives the slides, it can be displayed and played.
The attachment type. For the attachment type, all Mms in the MMS application has a slide containing all the attachment files. However, Mms performs some special processing. For an MMS information, its attachment types include IMAGE, AUDIO, VIDEO, and SLIDESHOW. These can be seen from the list in the Add attachment dialog box, the display methods are also different. But the actual implementation does not have so many types above, there is only one SlideshowModel, and all the attachments are in it. The rule is as follows. If only one media (image, audio, and video) is added, the media type is set to the corresponding media type, the attachment type is a slide only when multiple slides are explicitly selected in the attachment dialog box and added. This attachment type is only valid before adding an attachment to the MMS and before sending the MMS. It is mainly used to display the media file in the message list. If it is a specific media type, it is directly displayed, otherwise, it is displayed as a slide. This attachment type is used only for displaying the media in the application and does not have any trace in the PDUS that are sent out. After receiving the MMS, the attachment type is also determined based on the content in the converted SlideshowModel, and then displayed. Therefore, for an MMS, it always has a SlideshowModel. The attachment type that the user feels is only the processing above the attachment media display.
Unlike traditional mobile phones, creating and editing MMS does not require special methods. The difference between Mms and SMS is also very simple because the MMS application does not strictly distinguish between MMS and SMS, but is treated as a message in a unified conversation, check whether only the attachment (WorkingMessage) exists in a message. hasAttachment ()). Creating MMS is also very simple. You only need to click the Attach menu of Composer to add media. After selecting image, audio, and video in the list, there will be only one media file, and the file will be selected in other activities, and then its Uri will be returned to Composer. Composer will call WorkingMessage. setAttachment () is used for specific addition. You can use Uri to create MediaModel, add it to SlideshowModel, and set the type. In addition, if you select Attach slides, you can directly edit the slides. You can add and delete slide pages, add media files to the slides, and set the layout, after that, Composer will display the SlideshowModel, and the attachment type is also SLIDESHOW, all of which are through WorkingMessage. load.
After the WorkingMessage is added to the slides, an onAttachmentChanged () interface is called back. Composer implements this interface to notify Composer that the attachment has changed, refresh the UI to correctly display attachments. Composer will create AttachmentEditor to display the content of the attachment, because all the attachments are placed in Slideshow. This Slideshow is in WorkingMessage and can be obtained through WorkingMessage. getSlideshow. AttachmentEditor creates different views based on the content in Slideshow to display different attachments. If there is only one Video, Audio, or Image in Slideshow, The VideoAttachmentView, AudioAttachmentView, or ImageAttachmentView is directly created, slideshowAttachmentView is created when the number of pages in a slide is greater than 1. You can also use the corresponding buttons to edit, replace, or delete a media set. For a single media set, you can view the source image and play the audio and video. You can re-select an attachment for replacement, deleting an attachment will remove it. If Slideshow is edited or deleted, the editing will directly go to the slide editing page, where you can edit each slide in detail on one page, deleting will remove the attachment.
There are three ways to handle attachments after editing. One is to send information, the other is to save as draft, and the other is to discard information. Both sending information and saving the draft will package the slides, convert them to PDUS, and save them to the database. The subsequent slides will be loaded from the database and the Pdu will be decompressed into SlidehshowModel.
Packaging and unpackaging MMS must package the SlideshowModel to generate the Pdu format before sending information or saving the draft, and save it to the database. This is called Packaging of MMS, which is created by SlideshowModel. the makePduBody () method is used to obtain the content in the slide one by one, convert it into a PduPart, and then put it into the PduBody to generate a PduBody. A media corresponds to a PduPart, you can also set the attributes of PduPart to describe the media file, such as ContentType, which is a string used to identify the media MIME type; the Filename file name; and the path of the ContentLocation file. This information is used to describe the MetaData of the data in the PduPart, that is, what the data is, so that the data can be correctly processed during unpacking.
Then, PduPersister saves the PduBody to the database through its persist () method, and writes descriptive information in the PduPart as a database field, store the file in the TelephonyProvider folder (/data/android. providers. telephony/app_parts), and write the stored path to the database as the _ data field, so that all the MMS data is written to the database. After this, the MMS data is loaded from the database, so the database in the original SlideshowModel is no longer valid, for example, the Uri may point to a file or other databases in the original SlideshowModel, in PduPersister. persist () is no longer valid.
When PduPersister. after persist (), MMS attachments are loaded from the data, PduPersister. load () loads data from the database into a PduBody. The SlideshowModel method createFromPduBody () is used to convert the PduBody into a SlideshowModel, and retrieve the media information from the PduPart to obtain the correct media format, and related information. You can use Uri to obtain specific files (streams ).
The received MMS process is similar. When icationicationtransaction or RetrieveTransaction acquires MMS data from MMSC using HttpUtils, PduParser is used to parse the data and generate Pdu, and then PduPersister is used. persist () writes it to the database and then loads it from the database.
SMIL Language support also has an important data record for each MMS. SMIL is short for Synchronized Multimedia Integration Language (Synchronized Multimedia Integration Language), which is similar to HTML documents, it is a standard multimedia control language stipulated by W3C (World Wide Web Consortium. MMS also uses it to manage and play multimedia. Let's look at a specific SMIL language example:
When playing multimedia in SMIL language, a page is usually displayed, which is similar to playing in phantom, because many SMIL players make slides. Because MMS uses SMIL to transmit multimedia, the Mms terminal applications use slides to play MMS. This is why SlideshowModel is displayed in the Mms application. Slide display MMS is a common method. Even if some terminal applications do not display MMs in the form of Slide display, there is a page number for the MMS sent by the carrier or the MMS platform, in addition, some other mobile phones, such as non-smart phones, view MMS on a one-page slide.
It mainly records the layout information used for slides. This SMIL language is used for slide layout. That is to say, SMIL will describe how to layout slides like HTML document layout pages. It has these tags: head, layout, body, par, the head is the header information. The TAG layout is used to describe how this slide is laid out. Specifically, it uses sub-tags such as root-layout, region and so on. The TAG body lists all the media elements and details of the slides, such as image, audio, and text. Each par is one page, its Sub-TAG describes the content on this page. Of course, the SMIL language also has a lot of content to refer to the Wikipedia explanation.
When the slide is packaged and the SlideshowModel is converted to a Pdu, an SMIL language is generated based on the content of the SlideshowModel. getDocument () is used to generate the SMIL document and add it to the PduBody as the first PduPart. Its ContentType (MIME) is application/smil, and its content is SMIL document. Note that the SMIL document will always be the first Part in the PduBody, and it directly writes the document content to the PduPart, instead of the file format.
When unpacking, The SMIL document is taken out, parsed, and generated as a slide.
Because SMIL is a standard document, W3C has its own specifications and corresponding libraries for parsing and generation. In the Mms application, we can see two packages: org. w3c. dom. * And com. android. mms. dom. *; org. w3c. dom is a standard library of the SMIL language, while com. android. mms. dom. *; is for org. w3c. the implementation of some standard dom interfaces, or some adaptation for Mms applications. So in com. android. mms. model. * Some classes are also written according to the SMIL standard. For example, SmilHelper is used to parse SMIL Documents and generate SMIL Documents. Of course, it will use the two packages mentioned above. For example, ImageModel, TextModel, and RegionModel are also based on the SMIL standard. For example, they correspond to the labels img, text, and region in the SMIL document respectively.
Of course, this is the implementation of specific terminal applications. Different applications may have different methods, but the standard Pdu should be sent and received, the SMIL document is only one of the pduparts.