Comms和消息傳送

《Comms和消息傳送》由會員分享，可在線閱讀，更多相關《Comms和消息傳送（78頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、1 第十二章 Comms和消息傳送 2 完成本章內(nèi)容之后我們將能夠： 掌握 Symbian OS 的通訊架構 了解多媒體短信業(yè)務（ MMS） 本 章 目 標 3 本章概述了 Symbian OS提供的 comms工具 ， 并詳細研究了用于消息傳送 ， 特別是用于發(fā) 送和接收多媒體消息 (MMS)的 API。 4 概述 Symbian OS上的 comms開發(fā)可從 3個主要方面考 慮： 開發(fā)與通信硬件（比如串口或電話硬件）對話的 驅(qū)動程序。這一類型的開發(fā)在手機生產(chǎn)時由手機 開發(fā)商承擔。 Symbian提供與某些特定的基準硬 件（如 Intel Lubbock板）一起工作的驅(qū)動程序， 它可用于開發(fā)

2、其中的真正手機硬件和驅(qū)動程序。 開發(fā)協(xié)議實現(xiàn)，如用于訪問 Web的 HTTP實現(xiàn)，或 用于紅外線協(xié)議的紅外線。手機開發(fā)者和第三方 可以開發(fā)協(xié)議實現(xiàn)，并擴充到 Symbian OS已經(jīng)提 供的部分中。 5 概述 開發(fā)使用有效協(xié)議的應用程序：手機開發(fā)者提供 具有基本通信應用程序的手機，如電話和消息傳 送等應用程序。不過，很多領域中的應用程序可 以受益于與通信的集成，其中包括游戲 它可 以通過多玩家通過本地通信協(xié)議（如藍牙）或通 過 2.5G電話網(wǎng)絡上的包數(shù)據(jù)進行比賽，從而實現(xiàn) 交互。 企業(yè)應用 與專用應用程序服務器通信。 6 概述 通信組 目前可用的通信組件包括： 串行通信框架。 套接字框架。 電

3、話框架。 TCP/IP棧。 藍牙棧。 紅外線棧。 SMS和 EMS棧。 7 概述 WAP棧。 HTTP傳輸框架。 Telnet和 FTP引擎。 消息協(xié)議支持，包括 MMS、 SMTP、 POP3和 IMAP4。 這些組件提供了應用程序可訪問的 API。 8 概述 Comms及平臺 如同其他領域的 Symbian OS開發(fā)，在進行 comms 相關的工作時，需要了解什么是 Symbian OS提供 的，什么是 UI平臺增加的，比如 Series 60和 UIQ。 基本原則是： Symbian OS提供實現(xiàn)特定通信協(xié) 議的引擎組件，并向這些引擎公布 API； UI平臺 提供使用這些引擎的應用程序。

4、例如， Symbian OS提供了實現(xiàn)因特網(wǎng)電子郵件協(xié)議的組件，而 UIQ和 Series 60提供允許用戶發(fā)送和接收電子郵 件的消息傳送應用程序。 9 OS Comms架構 要理解 Symbian OS的 comms，需要理解所提供通用框 架和插入這些框架的特定協(xié)議的實現(xiàn)。本節(jié)首先 從框架著手。每種關鍵框架都使用了 Symbian OS 的客戶端服務器架構。在這種架構中，后臺運 行的程序（服務器）為其他多個程序（客戶）提 供服務。當手機上的多個客戶程序需要訪問一些 公共資源時，會選擇這種方案。服務器的任務是 控制對資源的訪問。對于底層的 comms服務器， 所討論的資源可能是一個硬件資源，比

5、如串口。 資源也可以是共享的數(shù)據(jù)，比如消息的存儲。 10 盡管框架通常具有服務器本身之外的其他要素， 如實用工具類的庫，但提到整個框架時，通常還 是簡稱為服務器。某些情況下， API使得客戶端 服務器架構的運用變得顯而易見。例如，使用 電話功能時，基本的任務就是創(chuàng)建一個 RTelServer對象，它提供與電話服務器的初始連接 （ Symbian OS約定就是和 RTelServer類似的 API 類，它用于訪問以 R 開頭的服務器）。如消 息等其他 API，提供廣泛的客戶端類，從客戶程 序中隱藏了客戶端服務器接口的直接使用。 OS Comms架構 11 核心服務器如下： 套接字：利用 TCP/

6、IP等協(xié)議，提供可尋址端點之 間的通信。自 Symbian OS的第一版起，即成為它 的一部分， 7.0增加了一個新的 API，用于創(chuàng)建和 管理連接。 串行 comms：提供簡單串行連接之上的通信，如 用于處理 RS232。 消息傳送：利用因特網(wǎng)電于郵件和 SMS這類協(xié)議， 提供消息的發(fā)送、檢索和存儲。 電話：提供電話呼叫及服務的控制，以及對電話 功能配置的控制。 OS Comms架構 12 套接字 套接字的概念首次出現(xiàn)于加州大學伯克利分校 的 Unix伯克利軟件發(fā)行中心 (BSD)，它是以 C語言 寫的一個 API。自此之后，套接字常見于很多操 作系統(tǒng)和語言中。 套接字代表一個通信“信 道”

7、的邏輯端點。它是物理機器的網(wǎng)絡地址和邏 輯端口號的組合，另一個套接字可以給它傳輸數(shù) 據(jù)。 因為套接字由機器地址和端口號確定， 所以在一個特定的計算機網(wǎng)絡中，每個套接字是 惟一標識的。這就允許應用程序惟一地識別網(wǎng)絡 中與其通信的另一位置。 OS Comms架構 13 套接字通常用于在運行因特網(wǎng)協(xié)議 (IP)的網(wǎng)絡 上進行通信。這時機器地址就是一個 IP地址，端 口將指定一些因特網(wǎng)應用程序，如 Web或 FTP。 與其他操作系統(tǒng)的套接字相比， Symbian OS實 現(xiàn)的套接字有兩個主要不同： 套接字可用于訪問多種協(xié)議，而不僅訪問 TCP/IP。 其中包括藍牙協(xié)議 L2CAP和 RFCOMM，以及

8、紅 外線協(xié)議 IrDA、 IrTinyTP和 IrMUX。 API用 C+編寫，與傳統(tǒng)的 BSD C API不同。如果 考慮必須使用 C API，例如向其他操作系統(tǒng)移植 代碼時，可以考慮 Symbian OS的 C標準庫 (STDLIB) 實現(xiàn)中可使用的 C API。 OS Comms架構 14 用于套接字的 Symbian OS C+ API是套接字客 戶 API，發(fā)布在頭文件 es_sock.h和庫文件 esock.dll中。與套接字服務器的客戶接口由 RSocketServ提供，套接字本身由 RSocket封 裝。套接字的客戶 API異步調(diào)用套接字服務器， 它協(xié)調(diào)客戶端訪問套接字服務，并

9、管理與協(xié)議模 塊的通信，這些協(xié)議模塊提供了對特定網(wǎng)絡協(xié)議 的支持。協(xié)議模塊是插件 DLL，服務器根據(jù)需要 進行加載和卸載。 OS Comms架構 15 除與套接字連接，并讀寫數(shù)據(jù)外， API還提供了 對其他工具的訪問： 主機名解析 (RHostResolver)：一些網(wǎng)絡類型能 夠在適合于給最終用戶顯示的符號主機地址與協(xié) 議內(nèi)部使用的數(shù)字地址之間轉(zhuǎn)換。在 TCP/IP中， 主機名解析服務就是域名服務 (DNS)。對于藍牙 和紅外線，解析接口可用于發(fā)現(xiàn)其他哪些設備在 范圍內(nèi)，并可使用這些協(xié)議進行通信。通過 RHostResolver對象產(chǎn)生的查詢打包在 TNameEntry描述符中，它保存了包含

10、主機名和地 址的 TNameRecord對象。 OS Comms架構 16 協(xié)議信息 (TProtocolDesc)：可以查詢手機上支 持哪些套接字協(xié)議，并可以得到每個協(xié)議的信息， 比如協(xié)議名稱和用于表明其性能的標志。 套接字 API還提供了下述功能，它們可能用得比 較少： 網(wǎng)絡數(shù)據(jù)庫訪問 (RNetDatabase)：用于訪問關于 設備的數(shù)據(jù)庫。對于紅外線，存在 IrDA信息訪問 服務 (IAS)這種服務。它與 TCP/IP或藍牙沒有關 聯(lián)。 服務解析 (RServiceResolver)：用于查詢遠程設 備的性能，也就是說，該設備在相應的協(xié)議上可 以提供什么服務。它不是為了 TCP/IP、

11、藍牙或紅 外線而實現(xiàn)的。藍牙標準中有 種服務，即藍牙 業(yè)務搜尋協(xié)議 (SDP)，但是 Symbian OS藍牙設備 沒有為此使用套接字 API，因為它有自己專門的 SDP API。 OS Comms架構 17 在 Symbian OS V7.0s以前的版本中，如何構 建網(wǎng)絡連接以實現(xiàn)套接字請求，套接字客戶 API的調(diào)用者不必關心。 連接是隱式建立的，舉例如下。 例如，應用程序請求與某個遠程地址的 TCP套 接字。與管理網(wǎng)絡接口 (NIFMAN)相關的 Symbian OS組件檢查沒有已存在的網(wǎng)絡連接。 它就讀取通信設置項數(shù)據(jù)庫 (CommDb)， 了解怎樣建立連接。例如，設置項可以指定撥 號連

12、接到某個服務提供商 (ISP)。調(diào)用能夠完 成撥號的其他組件，并利用適當?shù)膮f(xié)議（如 PPP）連接到 ISP。建立連接的所需設置，如 ISP的電話號碼和登錄信息，也保存在通信數(shù) 據(jù)庫中。 OS Comms架構 18 諸如 W-CDMA和最新版本的 GPRS等技術都可以 在一個連接中建立多個子連接。這在 v7.0s中 是由連接管理接口 RConnection來支持的。它 向客戶提供創(chuàng)建、配置和監(jiān)視連接與子連接的 功能。 OS Comms架構 19 串行通信 串行通信比套接字要簡單一些。數(shù)據(jù)從手機的 一個端口簡單地寫入和讀取，而不需要連接許多 可能的設備及其服務。習慣上，當 Symbian OS設

13、備通過一根電纜或紅外線連接到 PC進行同步，或 連接到外部調(diào)制解調(diào)器，此時使用這種方式。 與套接字類似， Symbian OS串行 comms的實現(xiàn)使 用了一個服務器，它可以加載插件模塊來處理特 定的通信協(xié)議。這些插件模塊稱做 CSY模塊，它 們被串行通信服務器加載，客戶應用程序不能直 接訪問。 OS Comms架構 20 Symbian OS手機可能包括許多 CSY模塊作為標 準配置，比如用于處理 RS232和紅外線串口通 信的模塊。串口協(xié)議模塊 API允許開發(fā)新的 CSY 模塊。 通過服務器會話類 RCommServ，可 以找到手機上可用的串口以及它們的協(xié)議。一 旦選定了要用的端口，就可以

14、通過串口接口 RComm訪問它。該類用于讀、寫、配置、設置 中斷條件和得到端口狀態(tài)信息。 OS Comms架構 21 通常，使用端口前，要先設置其配置。這包 括設置數(shù)據(jù)速率、奇偶類型和握手控制等。這 些設置保存在一個 TCommConfigV01類型的串口 配置塊中。在配置串口前，可以先檢查它的性 能，以保證所需配置是可行的。該串口的性能 由一個 TCommCapsV01類型的對象進行封裝。 OS Comms架構 22 消息傳送 Symbian OS的消息傳送組件為多協(xié)議消息傳送 提供了一個框架，并且支持特定的消息傳送協(xié)議。 消息傳送為建立高性能消息客戶應用程序以及 創(chuàng)建用于支持個別消息傳送協(xié)

15、議的插件模塊提供 了可能。建立這種插件模塊的組件集合叫做消息 類型模塊 (MTM)。與底層通信協(xié)議（如 TCP/IP） 的所有交互均由 MTM完成。 OS Comms架構 23 消息傳送架構提供了一些基類，這些基類定 義了用于 MTM實現(xiàn)的組件接口。利用基類按口， 允許客戶應用程序發(fā)現(xiàn)并動態(tài)使用可用的消息 傳送協(xié)議。 協(xié)議提供者為他們的 MTM實現(xiàn) 開發(fā)新庫。這些實現(xiàn)在協(xié)議需要時訪問底層通 信庫。 OS Comms架構 24 消息服務器 消息服務器控制對消息數(shù)據(jù)的訪問，并將協(xié) 議相關的請求委托給服務器端 MTM。由服務器 保存的每條消息部有一個 TMsvId類型的整型 標識符。一條消息的狀態(tài)（

16、例如是否可讀或不 可讀）和一些常規(guī)屬性對大多數(shù)消息是公用的， 如日期和主題保存在頭部數(shù)據(jù)對象中，需要通 過 TMsvEntry類訪問。消息還可以具有： 一個文件存儲：保存消息正文文本、協(xié)議相關 的數(shù)據(jù)：它由 CMsvStore類封裝。 一個目錄：可存放相關文件（如消息附件） OS Comms架構 25 總體上，消息從 ID、頭部、存儲和文件目錄， 都可以訪問和操作，并由 CMsvEntry封裝。 除消息本身之外，服務器還保存代表服務和文 件夾的記錄。一個服務就是一個收集設置信息 的有用抽象。例如 SMTP，服務將為郵件帳戶指定設置。文件夾保存 記錄組（消息和其他文件夾）。其中某些文件 夾，如收

17、件箱和草稿箱，總是存在并且在消息 服務器首次啟動時創(chuàng)建。用戶也可以創(chuàng)建自己 的文件夾。 消息以樹形結構保存，與文件系統(tǒng)的目錄樹 形式類似。樹中的每條記錄代表一個服務、消 息文件夾或消息部分。圖 8-1給出了一個實例。 OS Comms架構 26 OS Comms架構 根 郵 件 服 務 S M S 服 務 本 地 服 務 發(fā) 件 箱 發(fā) 件 箱 發(fā) 件 箱 發(fā) 件 箱 1 2 3 圖 8-1 消息存儲 27 樹可以分解為三級： 根記錄：只是用來表示將樹結構捆綁在一起。 服務記錄：有一個本地服務，在它下面保存文件 夾和消息，還有零或多個遠程服務。遠程服務代 表消息賬號。 消息和文件夾記錄：本地服

18、務下的消息和文件夾 代表存儲在設備上的消息。遠程服務下的消息和 文件夾代表遠程服務器上存在的消息在本地的副 本。例如，在 POP3電子郵件服務下面，會有 POP3 電子郵件服務器上存在的所有消息的副本；而在 SMS服務下面，可以找到 SIM上保存的 SMS消息。 OS Comms架構 28 MTM基類 MTM基類是提供消息傳送協(xié)議支持的子類，可以 認為有四個類。用戶接口 MTM(CBaseMtmUi)提供 用戶接口操作，其中包括： 創(chuàng)建：運行消息編輯器并打開一條新消息。 編輯：如果記錄是一條消息，則裝入編輯器；如 果記錄是一個服務，則編輯設置。 瀏覽：為消息運行瀏覽器。 顯示操作的進度。 OS

19、 Comms架構 29 客戶端 MTM(CBaseMtm)提供一個通用接口來操作 消息數(shù) 據(jù)。該類定義的函數(shù)可以用于： 創(chuàng)建消息。 回復消息。 轉(zhuǎn)發(fā)消息。 增加刪除地址。 增加刪除正文文本。 增加刪除主題。 增加刪除附件。 OS Comms架構 30 UI數(shù)據(jù) MTM(CBaseMtmUiData)提供對特定 UI MTM 相關資源 的訪問。它包括： 用于消息服務器記錄的 MTM相關圖標。 用于 MTM相關操作的用戶界面文字，例如菜單。 信息函數(shù)，用于檢查 MTM函數(shù)是否適用于某條記 錄。 OS Comms架構 31 最后，服務器端 MTM(CBaseServerMtm)提供了通 過相關通信協(xié)

20、議對遠程服務的消息傳輸，它的功 能包括： 移動或拷貝當前處于遠程服務下的記錄。 從本地服務移動或拷貝到遠程服務下的一個目的 地。 創(chuàng)建、刪除或修改遠程記錄（如果協(xié)議允許操作 遠程服務器上的消息）。 實現(xiàn) MTM相關命令。例如，同步化記錄與遠程服 務器上消息的命令。 OS Comms架構 32 注冊 MTM必須用消息服務器注冊。這就允許客戶查 詢當前是什么類型的 MTM，服務器可以知道哪些 DLL要加載，以創(chuàng)建一個給定的 MTM組件。通過 為每個 MTM提供一個資源文件來完成注冊。 注冊類允許標識和實例化 MTM組件。關鍵的類是 CClientMtmRegistry和 CmtmUiDataReg

21、istry。 OS Comms架構 33 SendAs 該接口的使用很簡單，它允許應用程序創(chuàng)建發(fā) 出的消息。注意，并不是像接口的名字的含義那 樣， SendAs提供的 API只能創(chuàng)建而不能發(fā)送消息。 使用 SendAs時，它首先向調(diào)用者提供一個所有 支持發(fā)送消息的已注冊 MTM列表。然后，應用程 序可以對 MTM列表增加更多的限制：例如，可以 要求 MTM支持附件或確定的消息大小。 SendAs按 這些附加的條件查詢每一個 MTM，并從列表中移 除那些與條件不匹配的 MTM。應用程序完成條件 的增加之后，選擇留在列表中的一個 MTM，并用 它構建消息、添加地址、標題、正文文本和附件。 OS C

22、omms架構 34 基本接口由 CSendAs和 MSendAsObserver提供。但 是，還存在“引擎” API，它們不為創(chuàng)建和發(fā)送 消息提供可以簡單添加到應用程序中的用戶接口。 不過，用戶接口平臺確實提供了包裝器類來達到 這一目的，它們是： UIQ API:CqikSendAsDialog。 Series 60 API:CsendAppUi。 OS Comms架構 35 規(guī)劃發(fā)送 規(guī)劃發(fā)送功能為客戶提供了能夠?qū)⑾l(fā)送安 排在稍后某一時刻，而不是立即發(fā)送。它允許為 規(guī)劃消息、刪除規(guī)劃、重新規(guī)劃和核對規(guī)劃。它 還提供針對性的狀態(tài)信息，如消息目前是否已規(guī) 劃、正在發(fā)送或失敗等。 MTM可以選

23、擇是否為規(guī)劃提供支持。要支持規(guī)劃， 服務器 MTM必須派生于 CscheduleBase ServerMtm。 服務器 MTM使用另一個叫做任務規(guī)劃器的 Symbian OS組件，它可以負責在指定時刻啟動指定的動作。 與任務規(guī)劃器的接口由 CMsvScheduleSend封裝。 OS Comms架構 36 電話 移動電話是一個包含很多用于手機服務、網(wǎng) 絡和硬件標準的復雜領域。 Symbian OS提供的 電話 API及其框架希望通過提供與手機功能的 公共接口來減少這種復雜性，而不必關心下層 硬件或網(wǎng)絡。 電話 API使用 Symbian OS客戶端朋艮務器框架， 并提供向電話服務器發(fā)送請求的

24、R類。服務器 反過來將請求傳遞給管理物理設備的適當電話 驅(qū)動器插件。 OS Comms架構 37 手機制造商利用電話 API提供手機上的電話 應用程序，使用戶能夠撥打電話及設置服務 選項。除了這個用途，電話 API可認為是低層 次的，主要用于其他更高級的 comms組件。例 如，套接字一節(jié)講述了要求連接套接字的 應用程序請求如何最終撥號連接到 ISP。 如果確實需要從應用程序中直接使用電話， 你會發(fā)現(xiàn)一個難題：授權商通常選擇在他們 的 SDK中不暴露過多的高級電話 API。所以， 除非你是授權商或 Symbian的合作伙伴，否則 應用程序有可能不能訪問所有的手機電話功 能。 OS Comms架

25、構 38 然而， SDK確實暴露了兩個應用程序編程者通常 感興趣的 API： ETel Core和 Third PartyTelephony。 ETel Core定義了一組幾乎所有電話設備和服務 都支持的核心函數(shù)。應用程序可以直接使用它來 訪問通用電話設備。該 API可細分為四個主要的 類，它們分別封裝了與電話服務器、手機、線路 和呼叫的會話。 會話類 RTelServer：提供了對系統(tǒng)電話信息的訪 問，特別是可用的手機和 TSY。 手機類 RPhone：對特定的電話設備進行抽象化。 它允許客戶訪問設備的狀態(tài)和功能，并在它們改 變時得到通知。 OS Comms架構 39 線路類 RLine：代

26、表屬于手機的一條線路?？蛻?可以訪問線路的狀態(tài)和功能，并在它們改變時得 到通知。 最后，線路可以有零或多個激活的呼叫，呼叫由 RCall類進行封裝。呼叫具有撥號、等待呼入以 及掛機等功能。前面一樣，客戶可以取得狀態(tài)和 功能的信息，并在它們改變時得到通知。 OS Comms架構 40 可見， ETel Core具有相當直接和合理的結 構，而它的功能封裝卻比較簡單。 Third Party Telephony API也 是如此，它為電話數(shù)據(jù)呼叫提供了一個高級接口。 它允許此 API用戶發(fā)出電話呼叫、等待呼入或 檢查線路狀態(tài)。 此 API有單獨一個類 CTelephony。調(diào)用者將一個 RComm（

27、串口）對 象傳遞給 CTelephony對象，當呼叫建立后， 它利用該對象讀寫連接上的數(shù)據(jù)。 OS Comms架構 41 高級 API 現(xiàn)代移動電話標準提供的功能遠不止接打電 話。 Symbian OS對基本 ETel Core API提供了 擴展，以支持對這些高級性能的使用。不過， 如前所述，這些擴展在 SDK中可能不提供。 主要的高級 API是 ETel Multimode，它擴展了 ETel Core API，以提供對用于多種空中接口 蜂窩標準（或模式）的公共移動電話服務的訪 問。在 v7.0s版本中，模式有 GSM、 GPRS、 EDGE、 CDMA(IS-95)、 3GPP2 cdm

28、a2000 1x （版本 A）和 3GPP W-CDMA。該 API還為用于特 定標準的專用服務（如 GSM）提供訪問。 OS Comms架構 42 其他高級電話 API有： ETel Multimode Packet Data：提供用于電話包 數(shù)據(jù)標準的公用 API，如 GPRS、 CDMAOne和 CDMA2000中的包數(shù)據(jù)。 SIM應用程序工具箱：提供一個 API，用于訪問由 手機 SIM卡提供的功能。 完成電話 API的綜述前，還要提到幾個不太重要 的 API： 撥號：提供撥號相關的實用工具，如處理電話號 碼。 電話簿同步器：同步化 Symbian OS手機上的兩種 地址信息存儲，即手

29、機 ICC（在 GSM手機上稱為 SIM卡）上的電話簿和聯(lián)系人數(shù)據(jù)庫。 OS Comms架構 43 最后，對傳真的支持也和電話 API緊密相關： ETel傳真客戶用于運用 Symbian OS傳真存儲文件 收發(fā)傳真。 Faxio API為傳真編碼和壓縮提供庫。 Fax存儲 API用于 訪問存儲的傳真。 隨著電話框架的介紹，結束了對 Symbian OS comms架構中最重要組件的綜述?，F(xiàn)在可以進一 步介紹該架構所開發(fā)的很多具體 comms協(xié)議。 OS Comms架構 44 多媒體消息傳送業(yè)務是開放移動聯(lián)盟 (最 初由 WAP論壇 )定義的 個標準，用于發(fā)送 和接收具有豐富內(nèi)容的消息，通過移動

30、電 話網(wǎng)絡，從用戶發(fā)送到服務器，再發(fā)送到 用戶。 MMS操作通過撥號 (CSD)或 GPRS連接，并 使用 WAP或 HTTP進行消息的傳輸和通知。 MMS消息本身與 MIME電子郵件消息類似， 它們包含定義消息屬性的頭部，還包含理 論上可以是任何媒體類型的 MIME正文。實 際上，希望的 MMS消息格式是 MIME內(nèi)容類 型：多部分關聯(lián)。 MMS 45 例如，消息包含一些多媒體對象，如圖 片、聲音和文字。第一個對象應該是一個 同步多媒體語言 (SMIL)文件， 個向客戶 提供關于如何呈現(xiàn)消息中其他媒體對象的 XML文檔。 如前所見， Symbian OS設備之間存在兼 容性問題的不僅僅是 c

31、omms， MMS的實現(xiàn)在 一般性 Symbian OS、 UIQ中的使用和 Series60之間也不同。這里所描述的 API 都是 Symbian版本。對于 Nokia版本，參見 Series 60 SDK文檔的“ Desigming MMS Client Applications for the Series 60Plateform(為 Series 60平臺設計 MMS客 戶應用程序 )” 。 MMS 46 MTM及 API MMS：實現(xiàn)是通過消息傳送框架的插件來提供 的，其中有些支持實用工具庫 : MMS客戶 MTM為 MMS消早的創(chuàng)建、檢索、發(fā) 送、轉(zhuǎn)發(fā)和回復等操作提供接口。 MMS

32、服務器 MTM調(diào)用低層 comms組件來發(fā)送 和接收 MMS消息。它不具有客戶接口。 MMS。實用工具庫提供了封裝 MMS消息及消 息頭部和媒體對象等部分的類。 MMS 47 這些庫不提供任何可供顯示和編輯 MMS消 息的功能，也不提供其他任何用戶接口操 作。不過，有一個庫可以用來解析 SMIL文 檔。實際上，如果將問題復雜化，可以說 有兩個這樣的庫。一個原始庫，稱做 SMIL 解析器和設計器， (smiltranslator.lib)， 它是為 v7.0s制作的。 v7.0s實際上對此方 法進行了改進，使其更加靈活，具有處理 各種特定 DTD的 XML，文檔的能力。此 API 稱為消息傳送

33、XML支持 API。 v7.0API仍然 可用，但如果編碼新代碼，則最好使用新 API。 MMS 48 現(xiàn)在將完成一些涉及使用消息傳送框架 和 MMS API來發(fā)送和接收 MMS消息的任務。 這些任務是： 連接消息服務器。 獲取客戶 MTM。 創(chuàng)建消息。 設置消息內(nèi)容和屬性。 發(fā)送消息。 接收消息。 MMS 49 服務器會話 消息傳送框架圍繞一個服務器程序為基 礎，在執(zhí)行消息傳送之前，必須建立與它 的連接 (會話 )。會話類叫做 CMsvSession， 消息客戶應用程序在啟動時通常創(chuàng)建該類 的一個實例?？蛻舳?MTM實例、用戶接口 MTM和高層客戶庫類維護對消息客戶應用 程序的會話對象的引用

34、，以便在需要時， 它們可以向服務器發(fā)出請求。 MMS 50 /創(chuàng)建消息服務器會話 iMsvSession=CMsvSession:OpenSyncL(*thi s)； OpenSyncL()方法接受一個 MMsvSessionObserver類型的參數(shù)，所以， 為使該代碼工作，包含的類必須實現(xiàn)這個 觀察器接口。它使服務器能夠呼叫客戶， 向它通知重要事件，如注冊 個新 MTM。 MMS 51 客戶 MTM 應用程序不能直接為它希望使用的 MTM創(chuàng)建對象， 它必須請求消息服務器為它創(chuàng)建該對象。所有安 裝在機器上的 MTM組件的記錄保存在一個由消息 服務器管理的專用注冊文件中。注冊類利用此注 冊數(shù)據(jù)

35、標識和實例化 MTM組件。例如， CClientMtmRegistry類有一個成員函數(shù)可用于創(chuàng) 建客戶端 MTM對象： 消息客戶應用程序調(diào)用該函數(shù)，傳遞它需要的 MTM組件的 UID。 CClientMtmRegistry搜索所需 MTM組件的記錄注 冊，并從中獲得庫名和可刨建 MTM對象的庫導出 工廠函數(shù)的序數(shù)。 CClientMtmRegistry加載 DLL，并調(diào)用工廠函數(shù)， 將新對象傳回調(diào)用者。 MMS 52 類似的處理用于用戶接口和 UI數(shù)據(jù) MTM。 這樣的 MTM對象由創(chuàng)建它們的客戶擁有。 客戶還負責刪除這些對象。 在當前示例中，需要 MMS客戶 MTM，因此 要利用 CClie

36、ntMtmRegistry： /創(chuàng)建客戶注冊對象 iClientMtmRegistry = CClientMtmRegistry:NewL(*iMsvSession)； MMS 53 /請求 MMS客戶 MTM對象 iMmsClientMtm = (CMmsClientMtm*)iClientMtmRegistry- NewMtmL(KUidMsgTypeMMS)； 注冊 NewMtmL()函數(shù)返回一個指向客戶 MTM基類 CBaseMtm的指針，將它轉(zhuǎn)換成 MMS 客戶類 CMmsClientMtm。 MMS 54 消息創(chuàng)建和刪除 在創(chuàng)建新消息前，需要決定在哪里存儲 它。通常創(chuàng)建新記錄的地方

37、是草稿文件夾。 客戶端 MTM具有當前項或上下文的概念， 在此進行操作，因此需要將當前項設置為 草稿文件夾。也許你還記得前面討論的消 息結構，每個項均有一個標識符用以查閱。 草稿文件夾的標識符是 KMsvDraftEntryld， 在 API中公開。下 面的調(diào)用將當前項設置為該文件夾： MMS 55 /設置草稿文件夾的上下文 iMmsClientMtm- SwitchCurrentEntryL(KMsvDraftEntryI d)； 在創(chuàng)建消息前，還需要設置它屬于什么 服務。可以通過編程方式發(fā)現(xiàn)哪些服務是 可用的。下面的代碼使用了消息項 ChildrenWithMtmL()函數(shù)來請求消息根項

38、下 MMS類型項的列表。由于服務都存儲在 根下，這樣將得到一個 MMS服務的列表。 MMS 56 /獲取消息服務器根項 CMsvEntry* root=CMsvEntry: NewL ( *iMsvSession， KMsvRoot IndexEntryId， TMsvSelectionOrdering ( KMsvNoGrouping， EMsvSortByOescriPtlon)； CleanupStack:PushL (root)； /獲取根的所有 MMS類型的子項 ID cmsvEntrySelection* Services = root- ChildrenWithMtmL (KUi

39、dMsgTypeNMS)； CleanupStack:PushL(Services)； MMS 57 /如果無 MMs服務則退出 if (services - Count() = 0) User:Leave(KErrNotFound)； 該代碼得到 MMS服務的 ID列表，如果沒有 可用的 MMS，服務將退出。 消息傳送還具有默認服務的概念，除非 用戶指定了其他服務，否則將使用默認服 務。默認服務設置可通過類 CMsvDefaultServices找到。它們存儲在 與根項關聯(lián)的消息存儲器中。下面的代碼 從這個存儲器中讀取默認服務設置，并獲 得 serviceld中默認 MMS服務的 ID。 M

40、MS 58 CMsvDefaultServices* services = new(ELeave)CMsvDefaultServices; CleanupStack:PushL(services)； TMsvId serviceId; if(root-HasStoreL() /如果根具有存儲器，則恢復默認的服務 CMsvStore*store = root-ReadStoreL()； CleanupStack:PushL(store)； services-RestoreL(*store)； CteanupStack:PopAndDestroy()； /存 儲器 MMS 59 TInt erro

41、r = services- DefaultService(KUidMsgTypeMMS， serviceId)； CleanupStack:PopAndDestroy()； /服務 經(jīng)過這些準備之后，就可以直接創(chuàng)建消 息了： /創(chuàng)建新消息項 iMmsClientMtm- CreateMessageL(serviceId)； 還可以分別用 CMmsClientMtm:ForwardL()和 CMmsClientMtm:ReplyL()通過轉(zhuǎn)發(fā)或回 復已存在的 MMS消息來創(chuàng)建新消息。在這 些情形下，新消息創(chuàng)建時，從原始消息中 拷入適當?shù)膬?nèi)容和頭。 MMS 60 設置消息內(nèi)容 下一項任務是設置消息

42、的內(nèi)容和頭?？?戶 MTM基 類 CBaseMtm定義了一些函數(shù)，大部分 MTM均可 以使用 它們來完成這項任務： SetSubjectL()：設置消息主題。 Body()：讀取和設置正文文本。 AddAddresseeL()：設置收件人。 CreateAttachmentL()：添加附件。 MMS 61 然而， MMS消息的屬性和內(nèi)容比使用上述 通用函數(shù)所定義的要復雜得多。因此， API在它的類 CMmsClientMessage和基類 CMmsMessage中提供了 MMS消息的完整封裝。 該消息類擁有個對象，該對象封裝了消息 頭 CMmsHeaders和一個 CMmsMediaObjec

43、t對 象列表，每個對象均描述了一種多媒體對 象，如 SMIL或圖像文件。 MMS 62 為了獲取剛創(chuàng)建消息的 CMmsClientMessge對象， 使用如下調(diào)用： /將新項設置為一條 MMS消息 iMmsClientMessage = CMmsClientMessage:NewL(*iMsvSession， iMmsClientMtm-Entry() EntryId()； 這里， NewL()的第二個參數(shù)是 MMS消息的 ID。序列 iMmsClientMtm- Entry() Entryld()要求客戶 MTM返回當 前項的 ID:因為 CreateMessageL()函數(shù)設 置當前項為新

44、消息，返回新消息的 1D。 MMS 63 CMmsClientMessage對象承擔舶第一項任 務是設置消息頭。， MMS規(guī)范定義了很多 可以在 MMS消息頭中設置的字段。其中一 些是強制性的，如消息類型、事務 ID、 MMS版本號、發(fā)件人地址、內(nèi)容類型和至 少一個收件人地址字段 (To， Cc或 Bcc)。 除客戶必須自行指定收件人外， MMS服務 器 MTM為所有強制字段給出了適當?shù)闹怠?這一過程相當直接，下例是為消息設置了 一個 To收件人 (anewRecipient是一個指定 地址的描述符 )。 MMS 64 iMmsClientMessage- Headers().AddRecip

45、ientL(CMmsHeaders :ETo， aNewRecipient)； 還可以設置可選字段。設置消息的主題： iMmsClientMessage- Headers().SetSubjectL(aSubject)； MMS 65 媒體對象 消息的媒體內(nèi)容通過添加一個或多個媒 體對象來定義。媒體對象可以通過 CMmsMessage:CreateMediaObjectL()添加。 CreateMediaObjectL()返回另一個 MMS實 用工具類 CMmsMediaObject對象。該對象 指定了拷貝媒體數(shù)據(jù) (如圖像或 SMIL文件 ) 的目標文件名。當添加媒體對象后，調(diào)用 者就可以指

46、定該對象為消息的“根”對象： 通常是包含了其他對象表達的 SMIL文件。 下述代碼添加一個根 SMIL文件，其文件名 在 smilFile中指定。 MMS 66 /要求創(chuàng)建 MO，傳遞根選項 MIME類型和文件 擴展名 /文件的 MIME類型 _LIT(KSMILMIME， application/smil)； /文件的擴展名 _LIT(KSMILExt， .smil) ； CMmsMediaObject MMS 68 發(fā)送消息 也許令人驚訝，客戶 MTM基類 CBaseMtm并 不提供發(fā)送消息的方法。然而，它為 MTM 提供了一種標準手段使 MTM特有的功能可 用。為此， MTM實現(xiàn)了兩個虛

47、方法 InvokeAsyncFunctionL()(用于異步操作 ) 和 InvokeSyncFunctionL()(，用于同步操 作 )，或只實現(xiàn)其中一個方法。許多 MTM利 用這些函數(shù)提供了發(fā)送消息的命令， MMS 通過 InvokeAsyncFunctionL()來完成。 MMS 69 函數(shù)的參數(shù)包括： 指定執(zhí)行命令的參數(shù)。枚舉 TMmsMtmCmds 定義了 MMS MTM特有操作的 ID： KMmsMtmSendMessage是發(fā)送命令的 ID。 要執(zhí)行命令的消息 ID。 可擁有可選參數(shù)的緩沖 (這里不用 )。 異步操作的常用請求狀態(tài)參數(shù)。 MMS 70 下述代碼開始發(fā)送數(shù)組 ild

48、ToSend中列出 的消息，數(shù)組的類型是 CMsvEntrySelection。 TBuf8param； /未使用 /異步發(fā)送消息 CMsvOperation* msvOperation = iMmsClientMtm-InvokeAsyncFunctionL( KMmsMtmSendMessage， *iIdToSend， param, aCompletionStatus)； MMS 71 消息 API的一個特性是，像這樣完成異步 操作的函數(shù)，返回一個 CMsvOperation對 象。這就允許調(diào)用者得到操作的進度信息 (例如，發(fā)送了四條消息中的兩條 )，并可 取消該操作。 發(fā)送消息的另一種

49、方式是利用 CMsvEntry:CopyL()，將消息從本地文件 夾拷貝到遠程服務項中。 結束關于 MMS的討論前，再看看應用程序 怎樣處理到達的消息。 MMS 72 到達的消息 消息傳送架構聲明了一對抽象接口，定 義了會話觀察器和數(shù)據(jù)項觀察器。會話觀 察器必須實現(xiàn)接口 MMsvSesionObserver，它得到新消息到達、 新 MTM注冊等事件通知。數(shù)據(jù)項觀察器實 現(xiàn)了接口 MMsvEntryObserver，當更改或 訪問各個數(shù)據(jù)項時，它得到事件通知。 為了處理到達的消息，需要一個會話觀 察器類。接口只需實現(xiàn)一個函數(shù)： void HandleSessionEventL(TMsvSessi

50、onEvent aEvent， TAny* aArgl， TAny* aArg2， TAny* aArg3) = 0； MMS 73 TMsvSessionEvent參數(shù)說明發(fā)生了什么 類型的事件：其他參數(shù)根據(jù)事件類型，可 以提供與該事件有關的數(shù)據(jù)。對于到達的 MMS消息，兩種事件類型需要處理： EMsvEntriesCreated 當通知新 MMS消 息到達手機時發(fā)生。 aArgl是包含新數(shù)據(jù) 頂?shù)?CMsvEntrySelection，而 aArg2是父 數(shù)據(jù)項的 TMsvld。 EMsvEntriesChanged 當取得消息正文 并可運行或可顯示時發(fā)生。該事件的參數(shù) 同 EMsvEnt

51、riesCreated。 MMS 74 由于 MMS消息不一定需要完全從服務器上 取得，所以有兩個事件。而遠程 MMS服務 器首先向手機發(fā)送一條通知，告知現(xiàn)有一 條新消息。此時， SymbianOS MMS實現(xiàn)在消息存儲器中創(chuàng)建一個新數(shù)據(jù)項， 并設置那些通知可用的頭字段 (其他字段 保持空值 )。隨后，手機可以選擇是否要 獲得消息正文 (它的媒體對象 )。 MMS 75 取得數(shù)據(jù)可以自動或按請求進行。 MMS服 務可以用方法 CMmsSettings:SetAutomatiFetch()設置 為自動取得完整的消息。未設置自動取得 數(shù)據(jù)的地方，應用程序可以通過 CMmsClientMtm:Inv

52、okeAsyncFunctionL()， 利用 KMmsMtmFetchMessage或 KMmsMtmBackgroundFetchMessage命令明確地 請求取得數(shù)據(jù)?？梢酝ㄟ^檢查 TMsvEntry:Complete()標志是否為真， 來檢查消息是否己完全取得。 MMS 76 另一個需小心的復雜之處是，觀察器將 接收所有類型消息的通知，而不僅僅是 MMS。所以，處理 MMS的代碼需保證首先檢 查與 MMS消息相關的事件。下列代碼可以 實現(xiàn)這一點，它假設 entries是包含新數(shù) 據(jù)項 ID的 CMsvEntrySelection。 MMS 77 TInt count = entries

53、-Count(); while (count- !=0) const TMsvId id=(*entries)count; CMsvEntry* msvEntry = iMsvSession- GetEntryL(id); CleanupStack:PushL(msvEntry); if(msvEntry-Entry() .iMtm = KUidMsgTypeMMS) ProcessMyMmsL(id); CleanupStack:PopAndDestroy (msvEntry); MMS 78 如果應用程序只想要處理 MMS消息，而不 是處理所有類型的消息，就需要讀取消息 并檢查一些特征，比如主題，檢查是否需 要處理它。這可以通過為該消息實例化一 個新的 CMmsClientMessage并訪問所需的 頭字段來完成。如果決定應用程序必須處理 該消息，可以阻止用戶從標準消息應用程 序的收件箱中看到它。為了做到這一點， 用 TMsvEntry:SetVisible()將消息項的 可見標志置為否。 MMS