Windows 程式開發-雲端與移動式手機整合（下）
Mobile Service與GCM

在Android的架構下，Activity必須要是處在Active才能有作用，而如果想要接收一些非同步的訊息，特別是在應用程式沒有執行時，此時就需要其它的元件配合。例如SMS簡訊的接收，或者像是skype, facebook的訊息，甚至是現在的line，whatsapp等等，由於它們的用途都是在程式不在執行時能夠接收並顯示訊息，所以必須要使用Activity之外的元件。

在Android主要的元件中有一個Broadcast Receiver，就是可以處理這種簡訊類的應用，它可以類似常註程式，當有訊息以Intent的形式廣播時，就可以啟動並且執行對應的程式片斷。此時再搭配Android的訊息告知，就可以順利的將這類訊息的告知顯示在畫面上。

除了Android端的處理之外，Google在伺服器端也運用了優勢，在Android2.2/2.3時推出了C2DM，也就是Cloud to Device Message，使用雲端的裝置，將訊息從伺服器推送至客戶端。同時這個解決方案正如同一般的簡訊般靈活，是可以作到任何端點的推播。而也由於這類的應用日益普及，Google在去年將C2DM進化成GCM，讓訊息推播的內容變成4K的大小之外 ，並且也增加了一些使用JSON的格式支援。除此之外，Google更推出了Google Cloud Messaging for Android Library的函式庫，讓使用者在開發Android的這類推播時，能夠更便利的達成。因此Windows Azure mobile service也同樣的使用這個技術。因此如果你要使用GCM的推播，請先使用Android的SDK Manager，下載Google Cloud Message for Android Library的函式庫如圖9。



▲ 圖9 下載Google Cloud Messaging for Android Library



因此如果你是在自己的專案中要使用GCM的支援，請先下載這個套件，並且在etras下的google的gcm目錄中找到gcm.jar，將它複製進libs目錄中，則可以在Android的應用程式中實作GCM相關的功能。

GCM的設定與Windows Mobile Service

GCM的元件由幾個部份所組成，除了在Android的客戶端實作之外，其實還是需要一個中央的應用程式伺服器，來負責和GCM的伺服器溝通。你可以將GCM想像成是郵局的郵差，它們知道如何遞送貨物到正確的地址，但是要送給誰，要送什麼內容，都不是 郵差來決定，而是必須要讓這個應用程式來決定。因此，這個任務如果是自己規畫是必須要讓自己實作，而如果是使用了Azure Mobile Service，則這個任務就可以交給Azure雲端的機器。

因此首先為了要讓 Azure和GCM溝通，必須先登入code.google.com/apis/console，新增一個專案。首先這個專案會有一個ID，必須作為到時候客戶端能夠和GCM建立協定的依據，因此建立專案後，可以在Overview中看到這個專案的Project Number如圖10。



▲ 圖10 在Google API console中建立專案並取得Project Number



而建立好專案之後，請你切換到Services的標籤，找到Google Cloud Messaging for Android的標籤，在確認過版權和 說明之後，將開關打開成ON如圖11。



▲ 圖 11 開啟GCM for Android



再來在API Access的畫面，請按下Create new Server Key…的標籤建立一個伺服器的驗証碼 ，將API Key複製下來，並且回到Azure的管理畫面，在該應用服務中Push標籤，可以看到google cloud messaging setting 的標籤，在API Key中請填入剛才取得的值如圖12。



▲ 圖12 取得API Key並填入Azure的畫面<


Android端實作的注意事項

當你在Azure的平台上輸入了API Key，也就代表著你的這個azure專案和 Google Cloud已經有了一個正式的認証，但是這個訊息能夠送到哪裡，哪些應用程式能夠接收到這一類的訊息，是另外的一件事情。因此，你必須先指定這個接收推送程式的客戶端，也就是在圖10中的SENDER_ID。

取得之後，可以將它送進com.google.android.gcm.GCMRegister的這個類別中。這個類別如果你有自己手寫過Android的C2DM或GCM就可以理解，它會起動一個 GCM註冊的intent，並且啟動這個intent的service，之後傳回的訊息就可以經由broadcast reciver接收並且傳回這個裝置的註冊碼。

這個註冊碼和一般的機碼類似，它是由你的Google帳號登入後和裝置運算後產生出的一長串碼。因此在產生機碼前，第一個請你先確認你的裝置是使用Google的API而非Android的API如圖13。



▲ 圖13確認產生的是Google API而非Android的API



同時，如果是Google的API，則你在設定的帳號登入畫面，看到的會有Google的帳號登入形式如圖14。此時你必須要使用一組合法的Google/Gmail的帳號密碼登入。你並不需要使用之前登入伸請GCM的gmail帳號作登入，此處的帳號其實就像是未來使用你的服務的使用者一樣，是任意的，直接在Google PLAY上下載的這些帳號密碼。



▲ 圖 14 Google API的登入畫面



而取得了裝置的機碼之後，在傳送新增的這些ToDoItem時，這個裝置的機碼就會變成channel的形式儲存在雲端，因此如果你在Azure平台要傳送訊息時，Azure就會幫你對這個機碼作訊息傳送的動作。

因此，你可以看到在Azure這一端其實幫你處理了裝置的機碼，和 伺服器的API Key，因此它提供的一個很基本的機制，就是 對在伺服器端提供了腳本，讓你在碰到某個情況，例如雲端的資料表格被新增，刪除或者有任何的異動時，進行這些push的訊息告知。

因此，在接收端你可以實作一個GCMBaseIntentService的子類別，在建構子時呼叫GCMBaseIntentService的建構子，並將SENDER_ID傳入，而在onRegistered時設定這個裝置的機碼。最後在onMessage()，也就是訊息已經傳遞到時，將Notification的builder，產生一個訊息的告知，並且產生在畫面上。

Azure mobile service的其它功能

既然Azure mobile service是一個專門為了mobile開發的雲端平台，所以其實很多實作的細節都以移動式設備為考量，例如在輸入資料時，你可以在伺服器端作一些資料驗証的動作，這樣在伺服器端腳本的設定可以減少很多客戶端使用Objective C/C#/Java所作驗証的時間。同時也由於mobile機架的資料存取記憶體有限，網路頻寬有限，在雲端可以作到輕易的資料分頁和分節，所以只要搭配前端的一份簡單的前一頁和上一頁，就可以從伺服器中將不同區塊的資料分段的顯示出來，一方面讓下載的時間不致過長，一方面讓顯示的速度更快。

結語
隨著iOS和 Android勢力的均衡，再加上其它新的OS的興起如Windows Phone和其它Linux based的作業系統，你可以發現專注於某一個平台的意思就是勢必要放下另外其它平台的商機。而雖然有一些利用HTML達成跨平台的solution，但是這樣又會造成效能或者功能上的妥協。

因此，如果要兼顧到效能和功能，原生的應用程式開發顯然有其必要性，而這時像Windows Azure for mobile service的重要性就更加顯露了。藉著上一回和這一回，你可以發現其實Mobile Service是將許多在裝置端需要實作的內容，例如驗証，授權和存取的機制都放置在伺服器上，這樣除了可以減少在不同的平台依照同樣功能實作同樣的內容之外，還可以藉著統一一個實作的方式，而達成便於管理的效果。至於Windwos Azure平台中mobile service與其它的功能，例如如何在伺服器端定時作一些工作項目，例如定時去遠端執行一些資料的存取或計算，或者是對於多媒體影音的一些處理這些更特化的功能，我們將在後面的文章中再和大家介紹。