JBoss 的推播方案 - Unified Push Server(現在叫 AeroGearPush)

前言

2016年獨立開發者最慘痛的第一個消息，大概就是臉書併購的 Parse 要收起來不玩了，我手上的專案用到 Parse 的推播功能也中鏢了，想到要自己把 GCM 接起來真的是一個頭兩個大。

簡單說明一下 Parse 是一個 BaaS(Back end as Service) 服務，可以想成臉書幫你養了一台提供資料庫/會員註冊/排程工作/推播的雲端主機，對開發者來說省去了架設/部署的工作，能夠專注於開發。

Parse 預計明年一月要收掉，整個 Parse 也已經開源出來，如果你本身也熟悉 Node.js 的開發生態，基本上可以整包拿下來架站。我最終選擇是改用 JBoss 提供的推播方案，下文大概介紹一下架構、功能，詳細實作的程式碼因為會隨著改版而失效，這邊就不會寫上程式碼。

JBoss Unified Push 架構

JBoss 的推播方案一開始叫做 Unified Push，現在就整進 AeroGearPush 裡頭(算是其中一個子專案)，整個程式碼也有開源出來，其實是一個跑在 JAVA EE Server 上的 war 檔。

因為我只有實作 Android Push 這一塊，以下就用 GCM 為例說明。Push Server 封裝了 GCM，如果沒有 Push Server，我們就必須自己去管理手機從 GCM 取得的註冊資訊。當有跨手機平台的推播需求的話，我們也只需與 Push Server 介接，Push Server 負責實作推播至不同手機平台的功能。

以下說明上圖每個元件的作用：

• Push Server：收集所有手機傳回的註冊資訊。發送訊息給各平台的推播系統，再推播至手機上。
• Application Backend Server：實作 APP 的後台邏輯，當有推播需求(ex：商品上架、有新事件)時透過 SDK 將訊息傳給 Push Server。
• Push Networks：就是指 Android / iOS 原生的推播系統。
• 手機：除了接收訊息外，最重要的將從原生推播系統取得註冊資訊傳給 Push Server。以 Android 來說，透過 SDK 將從 GCM 取得的 token 傳給 Push Server。

環境架設

除了把 Push Server 架起來外，上面可以看到手機 APP 和後台 Server 還會需要用到以下 SDK：

• aerogear-android-push (用來跟 PushServer 註冊裝置)
• unifiedpush-java-client (包裹 Web API 用來將要傳送的訊息交給 PushServer 推播)。

很多程式碼，名字變來變去，版號很多，這就代表有很多雷可以踩，建議先裝好 Push Server，裝好以後在 Web GUI 把推播相關的參數設定好，在 Web GUI 上有自動產生樣本程式碼的功能，這時候再來去抓最新 SDK，如果找不到類別或錯誤就降一版 SDK 試看看。我也是花了一點時間才找出來可以動的組合。

建議的步驟如下：

1. 安裝 Push Server。
2. 在 Push Server 上建立 Application。
3. Application 下設定 variant，variant 主要用來介接 iOS/Android 推播系統，介接的資料欄位需要從 iOS/Android 推播系統後台得到。
4. 此時，你 Push Server 上應該有一個 Application，一個以上的 variant。
5. 利用 Push Server > Application > variant 產生回傳註冊資訊至 Push Server 的範例程式碼，整合至手機 APP 程式碼，看看與下載的 aerogear-android-push 相不相容，不相容就找別的版本。
1. 開啟手機 APP，利用 Push Server 的 WEB GUI 觀察手機有無註冊成功。
2. 利用 Push Server 的 WEB GUI 發送訊息，驗證 Push Server 可以將訊息推到手機上。
6. 利用 Push Server > Application 產生推播訊息至 Push Server 的範例程式碼，整合 APP 後台程式碼，看看與下載的 unifiedpush-java-client 相不相容，不相容就找別的版本。
1. APP 後台發訊息給 Push Server，驗證可以透過 Push Server 將訊息推到手機上。

其他

關於 Push Server 的註冊部分，看到的寫法是每次打開 APP 或是某個頁面就重新註冊，這部分觀察資料庫，除非重新安裝 APP 否則上傳的註冊資料(GCM token)都是一樣的。解除註冊部分，看到的寫法可能寫在使用者勾選的開關上(讓使用者決定要不要收到推播)，或是離開某個頁面就解除註冊。以 GCM 來說，唯一知道這裝置已經解除 GCM 註冊的時機點是在推播的時候，然後如果是自己寫的 Push Server 就可以將這些裝置清掉，但 JBoss (我用的版本是1.0.0 beta 2)的做法是沒寫這塊邏輯，所以必須自己處理，我自己的做法是定時下 SQL 去清除一個月以上沒有向 Push Server 回傳註冊資訊的裝置。

最後還是想唸一下，紅帽的文件不是寫不好寫不夠多，是整理的很沒系統，這次找文件找 SDK 的時間大概比寫扣的時間還要多，只能說免費的最貴。