Android Mms 의:문자 발송 절차(그림 설명)

정보의 전송 은 Mms 응용 프로그램 에 있어 주로 정보 데이터 베이스 에서 정보 기록 을 만 들 고 유지 하 는 것 이다.진정한 전송 과정 은 바 텀(Frameworks 층)함수 에 의 해 처리 된다.
전체적으로 보면 정보 생 성 이 완 료 된 후에 정보 에 대해 세 가지 장소 가 있다.하 나 는 이 정 보 를 포기 하 는 것 이다.즉,사용자 가 이 정 보 를 원 하지 않 고 선택 하면 정 보 는 저장 되 지 않 는 다.두 번 째 장 소 는 초고 로 저장 하 는 것 이다.마지막 으로 가 는 곳 은 이 메 시 지 를 보 내 는 것 이다.
발송 을 클릭 하면 UI 층 에 변화 가 없 으 며,UI 층 은 발송 을 담당 하 는 각 종류의 리 셋 정보 와 데이터베이스 의 변화 정 보 를 감청 하여 UI 를 업데이트 해 야 합 니 다.메 시 지 를 보 내 는 첫 번 째 역 은 WorkingMessage 입 니 다.먼저 메시지 와 관련 된 내용 을 처리 합 니 다.예 를 들 어 수신 자(Sync Recipients)를 새로 고침 하여 합 법 적 인 수신 자 임 을 보증 합 니 다.첨부 파일(Slideshow)을 보 낼 수 있 는 컬러 편지 첨부 파일 Pdu(SendReq),MakeSendReq 로 전환 합 니 다.그 다음 에 서로 다른 정보 유형(문자,채 신)에 대해 서로 다른 처리 류 를 호출 하여 처리한다.처리 절차 도 비슷 하 다.먼저 메 시 지 를 한 대기 열 에 넣 고 해당 하 는 서 비 스 를 시작 하 는 것 이다.Service 는 정보 대기 열 을 유지 하고 모든 정 보 를 처리 합 니 다.문자 메 시 지 는 Frameworks 의 SmsManager 가 보 내 고 컬러 메 시 지 는 Http 프로 토 콜 을 통 해 보 냅 니 다문자 메 시 지 는 WorkingMessage 에서 보 낼 메 시 지 를 받 은 후에 간단하게 처리 한 다음 에 문자 와 컬러 메 시 지 를 서로 다른 처리 절 차 를 취한 다.문자 메시지 에 대해 WorkingMessage 는 연락 처 를 새로 고 치 는 것 외 에 다른 일 을 하지 않 습 니 다.Smsmessage Sender 를 만 들 고 sendmessage()방법 으로 메 시 지 를 보 냅 니 다.관련 매개 변수 수신 자 주소(분점 으로 구 분 된 문자),정보 내용 과 해당 대화 하 는 ID(thread id)는 Smsmessage Sender 대상 을 구성 하여 전 송 됩 니 다.구조 가 완 료 된 후에...sendmessage()방법 을 직접 호출 하면 됩 니 다.다음은 Smsmessage Sender 가 모든 일 을 처리 할 것 입 니 다.
Smsmessage Sender 에 의 해 처리 되 기 전에 WorkingMessage 는 UI 가 수신 자 편집 상자 와 정보 텍스트 입력 상 자 를 새로 고 칠 수 있 도록 UI 를 한 번 바 꿉 니 다.
Smsmessage Sender 의 주요 임 무 는 메 시 지 를 수신 자 에 따라 나 누 는 것 이다.즉,문 자 는 모든 수신 자 에 게 한 통 씩 보 내 는 것 이다.문자 한 통 만 편집 할 수 있 지만 수신 자가 한 통 이 아니 라 여러 개의 문자 가 되면 여러 개의 문 자 를 보 내 고 모든 수신 자 에 게 문 자 를 보 내야 한다.따라서 Smsmessage Sender 의 첫 번 째 임 무 는 수신 자의 주 소 를 분석 하고 수신 자의 개 수 를 얻 은 다음 에 모든 수신 자 에 따라 보 낼 대기 열 에 정 보 를 넣 는 것 이다.이렇게 해서 문자 발송 대기 열 을 얻 었 는데 문자 의 수 는 수신 자의 개수 이다.사실,Smsmessage Sender 의 작업 은 이것 뿐 입 니 다.메 시 지 를 모두 전송 대기 열 에 넣 으 면 데이터 베 이 스 를 기록 합 니 다.그리고 메 시 지 를 보 내 는 상 태 는 전송 중 입 니 다.Intent 를 보 내 SmsReceiver Service 를 불 러 대기 열 을 처리 합 니 다.작업 이 완료 되 고 sendmessage()도 돌아 갑 니 다.Smsmessage Sender 의 sendmessage()가 돌아 오 면 WorkingMessage 는 UI 의 인 터 페 이 스 를 다시 조정 합 니 다.이때 문자 가 데이터베이스 에 기록 되 어 있 기 때문에 UI 는 정보 목록 을 새로 고치 고 방금 문자 메 시 지 를 표시 합 니 다.이 상 태 는 발송 대기 열 에서 받 은 것 입 니 다.이후 발송 절차 의 종 류 는 UI 와 직접 통신 하지 않 고 발송 서비스 인 SmReceiverService 등 은 데이터베이스 에 있 는 문자 의 상 태 를 직접 업데이트 하 며,UI 는 데이터베이스 의 변 화 를 감청 하 며,정보 데이터 가 바 뀌 면 UI 는 목록 에 있 는 메시지,업데이트 상 태 를 새로 고 칩 니 다.예 를 들 어 발송 중 이미 발송 되 었 거나 발송 실패 등 을 표시 합 니 다.이 상태 들 은 모두 발송 서비스 가 업데이트 되 고 있다.
Sms ReceiverService,그 이름 에 얽 매 이지 마 세 요.정 보 를 받 는 것 만 책임 지 는 것 이 아니 라 문자(SMS)로 처리 하 는 Service 입 니 다.문자 의 발송 과 수신 을 책임 지고 짧 은 정보 명령(ACTION)을 받 습 니 다.SEND_MESSAGE)이후 대기 열 에서 첫 번 째 문자 메 시 지 를 읽 은 후 SmssSingle RecipientSender 대상 을 만 들 고 수신 자 주소,메시지 내용,소속 threadid 와 문자 메시지 의 Uri 를 전송 하 며 sendmessage()를 호출 하여 이 문 자 를 보 냅 니 다.
SmssSingle RecipientSender 는 SmsManager 의 방법 인 divideMessage()를 사용 하여 문 자 를 보 내기 좋 은 몇 부분 으로 나 눌 것 입 니 다.메시지 가 너무 길 어서 한 번 에 보 낼 수 없 기 때문에 몇 부분 으로 나 누 어 보 내야 합 니 다.동시에 메 시 지 를 Outbox 로 이동 합 니 다.그 다음 에 분 단 된 모든 부분 에 대해 두 개의 PendingIntent 를 만 들 것 이다.이 두 개의 PendingIntent 는 모두 바 텀 에 사용 되 는데 하 나 는 문자 가 보 낼 때 방송 되 고 다른 하 나 는 문자 가 받 은 사람 이 받 을 때 방송 되 는 것 이다.그래서 두 방송의 역할 은 하 나 는 문자 메시지 가 발송 되 었 음 을 표시 할 수 있 고 다른 하 나 는 전달 하 는 통지 로 사용 할 수 있다 는 것 이다.마지막 으로 SmsManager.send Multipart TextMessage 를 호출 하여 밑바닥 에서 문 자 를 보 냅 니 다.
Sms ReceiverService 는 SEND 를 직접 감청 하 는 것 이 아 닙 니 다.MESSAGE_ACTION 과 MESSAGESENT_ACTION 은 두 라디오 사건 을 SmReceiver 가 감청 한 다음 StartService 를 통 해 두 사건 을 SmReceiver Service 에 전송 하여 처리 합 니 다.
정 보 는 방송 과 정 보 를 보 냈 습 니 다.방송 은 각각 Sms Receiver Service 감청 과 Message Status Receiver 입 니 다.이들 은 라디오 를 받 으 면 Intent 에서 상세 한 전송 과 전송 상 태 를 얻 은 후 데이터베이스 에 있 는 정보의 상태(status)를 업데이트 하고,UI 는 데이터베이스 변 화 를 발견 하면 UI 를 업데이트 한다.
이로써 문자 한 통 발송 이 완료 됐다.
컬러 편지 발송 절 차 는 문자 메시지 와 완전히 일치 하지 않 습 니 다.WorkingMessage 는 수신 자 를 새로 고치 고 컬러 편 지 를 보 낼 수 있 는 Pdu-SendReq 를 생 성 합 니 다.이 어 컬러 편 지 를 데이터베이스 에 기록 하고 보 낼 SendReq 도 데이터베이스 에 기록 합 니 다.그 다음 에 데이터베이스 에서 SendReq 를 읽 고 초고 로 표 시 됩 니 다.그리고 MmsMessage Sender 를 구축 하여 수신 자 와 컬러 메 시 지 를 보 내 는 Uri 를 구축 합 니 다.수신 자 편집 상자 와 정보 편집 상 자 를 초기 화하 기 위해 UI 를 한 번 씩 되 돌려 줍 니 다.
MmsMessageSender 는 먼저 데이터베이스 에서 컬러 편지 가 보 낸 Pdu-SendReq,구 글 의 내장 패키지 com.google.android.mms.*를 읽 습 니 다.Pdu 를 데이터베이스(Pdu Persister.persist()에 기록 하고 데이터베이스 에서 Pdu(Pdu Persister.load)생 성 을 읽 는 등 Pdu 를 조작 하 는 모든 방법 을 봉 인 했 습 니 다.그 다음 에 현재 컬러 편지 의 설정 과 다른 정보 에 따라 SendReq 를 업데이트 합 니 다.예 를 들 어 Expiration,Priority,Date 와 Size 등 을 설정 하고 컬러 편 지 를 Outbox 로 옮 긴 다음 에 Transaction Service 를 시작 하여 컬러 편 지 를 처리 합 니 다.sendmessage()를 되 돌려 줍 니 다.WorkingMessage 는 UI 의 인 터 페 이 스 를 다시 조정 합 니 다.이때 컬러 메 시 지 는 데이터베이스 에 있 기 때문에 UI 는 정보 목록 을 새로 고치 고 방금 컬러 메 시 지 를 표시 합 니 다.이 상 태 는 발송 중 일 것 입 니 다.
트 랜 잭 션 서 비 스 는 문자 메시지 의 SmReceiverService 와 유사 하 게 컬러 메 시 지 를 처리 하 는 서비스 로 발송,수신 등 이 가능 하 다.TransactionService 에 있어 서 처리 해 야 할 모든 절 차 는 발송 이 든 수신 이 든 모두 Transaction 입 니 다.내부 에 두 개의 대기 열 이 있 습 니 다.하 나 는 현재 처리 되 고 있 는 Transaction 이 고 하 나 는 처리 되 어야 할 Transaction 입 니 다.이 두 대기 열 을 유지 하고 네트워크 연결 을 검사 하 며 컬러 메시지 네트워크 연결 을 열 고 환경 을 준비 하고 검사 한 다음 처리 할 대기 열 에서 첫 번 째 를 꺼 내 처리 중인 대기 열 에 넣 고 이 Transaction 을 처리 합 니 다.즉,Transaction.process()를 호출 합 니 다.
컬러 편 지 를 보 내 는 것 은 SendTransaction 입 니 다.프로 세 스()방법 은 컬러 편 지 를 보 내 는 것 을 책임 집 니 다.독립 된 스 레 드 를 만 들 기 때문에 Transaction Service 를 막 지 않 고 서 비 스 를 처리 하면 다른 Transaction 을 처리 할 수 있 습 니 다.데이터베이스 에서 컬러 편지 Pdu,M-Send.req,(SendReq)를 꺼 내 날짜 와 같은 필드 를 업데이트 한 다음 부모 클래스 Transaction.java 의 방법 sendPdu 를 호출 하여 SendReq 를 보 내 고 sendPdu()는 보 낸 결과(send confirmation)를 되 돌려 줍 니 다.Transaction.sendpdu()는 먼저 네트워크 를 설정 한 다음 HttpUtils 의 httpConnection()방법 을 직접 호출 하여 HTTP 로 컬러 편 지 를 보 내 고 SendTransaction 에 되 돌아 오 는 메시지(Response)를 가 져 옵 니 다.SendTransaction 은 발송 결 과 를 검사 하고 결 과 를 되 돌려 줍 니 다(Send Confirmation).상 태 를 분석 하고 데이터베이스 에 업데이트 합 니 다(예 를 들 어 발송 실패 나 발송 성공).UI 는 상태 변 화 를 감청 하고 정보 목록 을 업데이트 합 니 다.
여기에 컬러 편지 하나 가 완성 되 었 습 니 다.
앞에서 언급 한 TransactionSettings 는 하나의 처리 절차 에 대한 설정 정보 로 MMSC(Multimedia Message Service Center),Proxy 와 ProxyPort 가 포함 되 어 있 습 니 다.이런 정 보 는 특히 발송 과 수신 에 있어 서 매우 중요 하 다.휴대 전화 에 대한 메 시 지 는 휴대 전화 가 수신 자의 휴대 전화 로 메 시 지 를 직접 보 내 는 것 이 아니 라 서비스 센터 에 직접 보 내 는 것 이 고,그 뒤 에는 서비스 센터 에서 해당 수신 자의 휴대 전화 로 메 시 지 를 보 내 는 것 이기 때문이다.컬러 편지 에 대해 서도 HttpUtils 는 HTTP 프로 토 콜 을 통 해 MMSC 에 컬러 편 지 를 보 냅 니 다.이것 은 URL 주소 입 니 다.그 후에 발송 자 에 게 컬러 편 지 는 보 냈 습 니 다.컬러 편지 서비스 센터(MMSC)는 다음 발송 과정 을 처리 할 것 입 니 다.서비스 센터 는 핸드폰 운영 과 관련 되 고 운영 자가 제공 합 니 다.Mms 가 컬러 편 지 를 보 내 는 것 에 대해 서 는 특별히 TransactionSettings 를 지정 하지 않 는 다.즉,MMSC 와 Proxy 를 지정 하지 않 는 다 는 것 이다.그러면 TransactionService 는 시스템 의 기본 MMSC,Proxy 를 TransactionSetting,MMSC,Proxy 와 Proxy Port 로 서 Telephony 데이터베이스 에서 조회 해 야 한다.이들 은 구체 적 인 휴대 전화의 APN 설정 과 구체 적 인 운영 업 체 와 관련 이 있다.따라서 여기 서 컬러 편지 의 설정 정 보 를 변경 하려 면 APN 시스템 설정 을 변경 해서 만 완성 할 수 있 습 니 다.
문자 메 시 지 를 보 내 는 것 은 SMSC(문자 서비스 센터)와 관련 이 없다.Frameworks 의 도 구 는 SmsManager 가 문자 메 시 지 를 보 내 는 몇 가지 방법 을 제 공 했 기 때문에 SMSC 와 관련 된 것 을 처리 할 수 있 을 것 이다.

요약 하면 데이터 베 이 스 는 정 보 를 보 내 는 과정 에서 중요 한 역할 을 한 것 을 알 수 있다.정보 가 편집 기 를 떠 난 후에 바로 데이터 베 이 스 를 기록 했다.보 내 는 과정 에서 각 유형 은 데이터 베이스 에서 정 보 를 불 러 온 다음 에 해당 하 는 처 리 를 한 다음 에 데이터 베 이 스 를 쓰 거나 업데이트 상 태 를 기록 한 다음 에 다음 절차 에 맡 긴 다.한편,이른바 Pending Message Queue 는 해당 하 는 데이터 구조 가 없 는데 모두 데이터 베이스 에 있 는 정보 이 고 상 태 는 전송 을 기다 리 는 것 일 뿐이다.그래서 정 보 는 편집 기 를 떠 난 후에 데이터베이스 에 기록 되 었 습 니 다.상태 가 계속 바 뀌 었 을 뿐 입 니 다.보 내 는 중 에 보 내 거나 보 내 는 데 실 패 했 거나 텔 레 포 니 서비스 가 사용 되 지 않 으 면 보 내 려 고 하지만 UI 페이지 에 서 는 그렇게 많은 상태 가 없 을 수 있 습 니 다.보 내 는 중 에 만 보 내 고 보 내 는 데 실 패 했 을 수도 있 습 니 다.