Android MMS: SMS sending process (picture and text explanation)

For MMS applications, the sending of information is mainly to create and maintain an information record in the information database. The real sending process is handled by the underlying (frameworks layer) function.

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

After clicking send, the UI layer will not change temporarily. The UI layer should listen to the callback information of each class and the change information of the database to update the UI. The first stop of message sending is workingmessage. It will first process the relevant contents of the message, such as refreshing the sync recipients to ensure that they are legal recipients, converting the attachment (slideshow) into a multimedia message attachment PDU (sendreq) and makesendreq. Then, different processing classes are called for different information types (SMS, MMS). The processing process is also similar. First, put the message in a queue, and then start the corresponding service for processing. The service maintains the information queue and then processes each information. SMS is sent by smsmanager in frameworks, while MMS is sent through HTTP protocol.

Before handing it over to smsmessagesender for processing, workingmessage will call back the UI once to let the UI refresh the recipient edit box and the message text input box.

The main task of smsmessagesender is to split the message according to the recipient, that is, the message is to send one message to each recipient. Although you may only edit one message, when there is more than one recipient, it will become multiple messages. You need to send multiple messages and send one message to each recipient. Therefore, the first task of smsmessagesender is to analyze the recipient address, get the number of recipients, and then put the information into the queue to be sent according to each recipient. In this way, we get a short message sending queue. The number of short messages is the number of recipients. In fact, the work of smsmessagesender is nothing more. When the information is put into the sending queue, that is, it is written into the database. Then the information status is being sent. It will send an intent to arouse smsreceiverservice to process the queue. Its work is completed and sendmessage() will return. After smsmessagesender's sendmessage() returns, workingmessage will call back to the UI interface again. Because the message has been written to the database, the UI will refresh the message list and display the message just. At this time, the status should be sending, because it is obtained from the queue to be sent. From then on, the class of the sending process will no longer communicate directly with the UI. The sending service smsreceiverservice will directly update the status of SMS in the database, and the UI will monitor the changes in the database. Once the information data changes, the UI will refresh the messages in the list and update the status, such as changing the sending process to sent, or indicating the sending failure, These states are updated by the sending service.

Smsreceiverservice should not be fooled by its name. It is not only responsible for receiving messages. It is a service for short message (SMS) processing. It is responsible for sending and receiving short messages. After receiving the action_send_message, it will read the first short message from the queue, and then create a smsinglerecipientsender object to pass in the recipient address and message content, The ThreadID and the URI of the short message, and call its sendmessage() to send the short message.

Smssinglercipientsender will call the method dividemessage() of smsmanager to divide the short message into several parts suitable for sending. Because the message may be too long to be sent at one time, it needs to be sent in several parts. At the same time, the message will be moved to Out@R_ 228_ 2419@。 Then, two pendingintents will be created for each part of the split. These two pendingintents are used for the bottom layer. One is used to broadcast when the SMS is sent, and the other is broadcast when the SMS has been received by the recipient. Therefore, the function of the two broadcasts is that one can be used to identify that the SMS has been sent, and the other can be used as a delivery notice. Finally, SmsManager.sendMultipartTextMessage is sent to the bottom to send short messages.

Smsreceiverservice does not listen to send itself_ MESSAGE_ Action and message_ SENT_ Action, but smsreceiver listens to these two broadcast events, and then transmits these two events to smsreceiverservice for processing through startservice.

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

So far, a short message is sent.

Mmsmessagesender first reads the PDU sent by MMS from the database - sendreq, Google's built-in package com. Google. Android. MMS. *; It encapsulates all methods of operating PDU, including writing PDU to the database (pdupersister. Persist()), reading from the database and generating PDU (pdupersister. Load()). Then update sendreq according to the current MMS configuration and other information, such as setting expiration, priority, date and size, and move the MMS to Out@R_ 228_ 2419 @, and then start transactionservice to process multimedia messages. Sendmessage() returns here. Workingmessage will call back the UI interface again. Because the MMS has been in the database, the UI will refresh the message list and display the MMS just now. At this time, the status should be sending.

Transactionservice, similar to SMS smsreceiverservice, is a service responsible for processing multimedia messages. It can send, receive, etc. For transactionservice, all processes to be processed, whether sending or receiving, are a transaction. There are two queues inside it, one is the transaction currently being processed and the other is the pending transaction. It maintains the two queues, checks the network connection, opens the MMS network connection, prepares and checks the environment, then takes the first one from the queue to be processed, puts it into the queue being processed, and processes the transaction, that is, calls transaction. Process ().

Sending MMS is a sendtransaction. Its process () method is responsible for sending MMS. It will create an independent thread to do it. Therefore, the transactionservice will not be blocked, and the processing service can process other transactions. It will first extract the MMS Pdu, M-Send.req, (SendReq) from the database, update some fields, such as date, then call sendPdu in the parent class Transaction.java to send SendReq, sendPdu () will return the result sent (send confirmation). Transaction. Sendpdu() will first set up the network, then directly call the httpconnection() method in httputils, send the multimedia message over HTTP, and obtain the return message (response) to sendtransaction. Sendtransaction will check the sending result, return the result (send confirmation), analyze the status and update it to the database (such as sending failed or sending succeeded). The UI will listen to the status change and update the information list.

Here, a multimedia message is sent.

As mentioned earlier, transactionsettings is the configuration information related to a processing process, including MMSC (Multimedia Message Service Center), proxy and proxyport. This information is very important, especially for sending and receiving. Because the mobile phone does not directly send the information to the recipient's mobile phone, but directly to the service center. Later, the service center sends the information to the corresponding recipient's mobile phone. The same is true for MMS. Httputils sends MMS to MMSC through HTTP protocol. It is a URL address. For the sender, the MMS is sent. MMSC will process the next sending process. The service center is related to mobile phone operation, which is provided by the operator. For MMS sending MMS, transactionsettings will not be specified specifically, that is, MMSC and proxy will not be specified. Then transactionservice will use the system default MMSC and proxy as transactionsetting. MMSC, proxy and proxyport need to be queried from the telephone database. They are related to the APN settings of specific mobile phones and specific operators. Therefore, if you want to change the configuration information of MMS here, you can only change the APN system settings.

SMS sending does not involve SMSC (short message service center), because the tools in frameworks have been encapsulated. Smsmanager provides several methods to send SMS. It may deal with SMSC related things.

In summary, it can be seen that the database plays an important role in the sending process of information. When the information leaves the editor, it is written to the database immediately. All classes in the sending process first load the information from the database, then do corresponding processing, and then write it back to the database or update the status, and then hand it over to the next process for processing. The so-called pending message queue actually has no corresponding data structure. They are all information in the database and the status is to be sent. Therefore, after leaving the editor, the information is written to the database, but the status changes all the time, from being sent to being sent, or sending fails, or if the telephone service is unavailable, it will still be waiting to be sent, but there may not be so many statuses for the UI page. It may only display being sent, sent and sending failed.