Android MMS topic: information sending Process

For MMS applications, an information record is created and maintained in the information database. The real sending process is handled by the underlying function (frameworks Layer.

Generally, after the information is created, there are three places for the information. One is to give up the information, that is, the user does not want the information, information will not be saved; the second place is saved as a draft; the last place is to send this information.

After you click send, the UI Layer does not change. The UI Layer listens to the callback information of each class sent and the change information of the database to update the UI. The first stop of sending information is workingmessage. It will first process the information, for example, refresh the recipient (Sync recipients) to ensure that they are all legal recipients, and put the attachment (slideshow) convert to sendreq and makesendreq. Different Processing classes are called for different types of information (SMS and MMS. The processing process is similar. messages are first put into a queue, and then the corresponding service is started for processing. The Service maintains the information queue and processes each information. SMS is sent by smsmanager in frameworks, while MMS is sent through HTTP.

SMS sending

After workingmessage receives a message to be sent, it performs simple processing (refresh the recipient) and then uses different processing procedures for text messages and lottery. For short messages, workingmessage does not refresh contacts, but creates smessagesender and calls its sendmessage () method to send messages, the recipient address of the relevant parameter (a string separated by semicolons). The information content and the ID of the conversation (thread ID) are passed in to construct the smessagesender object. After the construction is complete, call the sendmessage () method directly. Then, smsmessagesender will handle all the tasks.

Before being processed by smessagesender, workingmessage calls back the UI once to refresh the recipient's edit box and information text input box.

The main task of SmsMessageSender is to split the information by recipient. That is to say, a text message is sent to each recipient. Although you may only edit one text message, when there are more than one recipient, as a result, multiple text messages are sent, and one text message is sent to each recipient. Therefore, the first task of SmsMessageSender is to analyze the recipient address to obtain the number of recipients, and then put the information into the queue to be sent according to each recipient. In this way, an SMS sending queue is obtained. The number of SMS messages is the number of recipients. In fact, the work of SmsMessageSender is nothing more than that. When all the information is put into the sending queue, that is, it is written into the database, and the information is in the sending status, it sends Intent calls SmsReceiverService to process the queue, and its work is complete, and sendMessage () also returns this. After SmsMessageSender sendMessage () is returned, WorkingMessage calls back the UI interface again. Because the SMS has been written to the database, the UI refreshes the information list and displays the text message, at this time, the status should be sending, because it is obtained from the waiting queue. After that, the sending process class will no longer directly communicate with the UI. The sending service SmsReceiverService will directly update the status of text messages in the database, and the UI will listen to changes in the database, once the information data changes, the UI will refresh the messages in the list and update the status, for example, changing the status of sending to sent, or indicating that sending fails. These statuses are all updated by the sending service.

SmsReceiverService. It is not only responsible for receiving information, but also for sending and receiving SMS messages, after receiving the short message instruction (ACTION_SEND_MESSAGE), the first short message will be read from the queue, and then the SmsSingleRecipientSender object will be created to pass in the recipient address, message content, the threadid and the Uri of the short message, and call its sendMessage () to send this text message.

Smssinglerecipientsender calls the smsmanager method dividemessage () to divide the short message into several suitable parts. Because the message may be too long to be sent at a time, it is necessary to divide the content into several parts for sending at a time. The message is also moved to the Outbox. Then, two pendingintents will be created for each part of the split. These two pendingintents are used for the underlying layer, and one is used to broadcast messages when they are sent, the other is broadcast when the text message has been received by the recipient. Therefore, one Broadcast can be used to identify that the text message has been sent, and the other can be used as a delivery notification. Finally, smsmanager. sendmultiparttextmessage is called and sent to the underlying layer for text messages.

Smsreceiverservice does not listen to send_message_action and message_sent_action on its own. Instead, smsreceiver listens to these two broadcast events, and then transmits these two events to smsreceiverservice for processing through startservice.

Message sent broadcast and message delivered broadcast are monitored by smsreceiverservice and messagestatusreceiver respectively. After receiving the broadcast, they obtain the detailed sending and delivery status from the intent, and then update the status of the information in the database. The UI updates the UI when the database changes.

At this point, a text message is sent completely.

MMS sending

The MMS sending process is not exactly the same as that of the SMS. workingmessage refresh the recipient and generate the PDU-sendreq that can be sent to the mms. Then, the MMS is written to the database, and the sendreq to be sent is also written to the database, later, sendreq will be read from the database and identified as a draft. Then, mmsmessagesender will be constructed, and the receiver and the mms uri will be input for sending. During this period, the UI is also called back to initialize the recipient's edit box and information edit box.

Mmsmessagesender first reads the PDU-sendreq sent by MMS from the database, and Google's built-in package COM. google. android. MMS. *; it encapsulates all PDU operations, including writing PDU to the database (pdupersister. persist (), read the generated PDU (pdupersister. load ()). Then, update sendreq based on the current MMS configuration and other information, such as setting expiration, priority, date, and size, move the MMS to outbox, and then start transactionservice to process the MMS. Sendmessage () is returned. Workingmessage calls back the UI interface again. Because the MMS is already in the database, the UI refreshes the information list and displays the MMS Message. The status of the message is sending.

Transactionservice, similar to the smsreceiverservice of short messages, is a service responsible for processing MMS and sending and receiving messages. For transactionservice, all the processes to be processed, whether sent or received, are transactions. It has two internal Queues: one is the transaction currently being processed (processing), and the other is the transaction to be processed (pending. It maintains the two queues, checks the network connection, opens the MMS network connection, prepares and checks the environment, extracts the first one from the queue to be processed, and puts it in the queue being processed, and process this transaction, that is, call transaction. process ().

Sending MMS is a sendtransaction. Its Process () method is used to send mms. It creates an independent thread and does not block transactionservice. The processing service can process other transactions. It first retrieves the multimedia PDU, M-Send.req, (sendreq) from the database, updates some fields, such as date, and then calls its parent class transaction. in Java, sendpdu is used to send sendreq. sendpdu () returns the sent result (send
Confirmation ). Transaction. sendpdu () first sets the network, then directly calls the httpconnection () method in httputils, sends the MMS via HTTP, and obtains the Response Message to sendtransaction. Sendtransaction checks the sending result, returns the result (send confirmation), analyzes the status, and updates it to the database (for example, sending failed or sending successful ). The UI monitors status changes and updates the information list.

At this point, a MMS message is sent completely.

Transactionsettings is the configuration information related to a processing process, which contains mmsc (Multimedia Message Service Center), proxy, and proxyport. This information is especially important for sending and receiving. Because the mobile phone information is not sent directly to the recipient's mobile phone, but directly to the service center, the service center then sends the information to the recipient's mobile phone. The same is true for mms. httputils sends the MMS to mmsc over HTTP, which is a URL address. Then, the MMS is sent to the sender, And the MMS Service Center (mmsc) the next sending process will be processed. The service center is related to mobile phone operations and is provided by the carrier. Transactionsettings is not specifically specified for MMS sending. That is to say, mmsc and proxy are not specified, transactionservice uses the default mmsc and proxy as transcationsetting and mmsc, proxy and proxyport need to be queried from the Telephony database. They are related to the APN settings of a specific mobile phone and the specific carrier. Therefore, if you want to change the configuration of the MMS, you can only change the configuration of the APN system.

SMS sending does not involve SMSC (SMS Service Center), because the tool in frameworks has encapsulated smsmanager to provide several methods for sending SMS messages. It may process SMSC-related items.

In summary, we can see that the database plays an important role in the process of sending information. When the information leaves the editor, it is immediately written into the database, each class in the sending process loads information from the database first, then processes the information, writes it back to the database or updates the status, and then submits it to the next process for processing. The so-called pending Message Queue actually does not have the corresponding data structure. They are all information in the database and the status is waiting for sending. Therefore, the information is written into the database after it leaves the editor, but the status is constantly changing, from sending to being sent, or sending fails, or if the Telephony Service is unavailable, it is still waiting for sending, but for the UI page, there may not be so many States, it may only display the sending, sent, and failed status.