碼農的華爾滋-廣播(Broadcast)與服務(Service)篇

嘿~帥哥美女們！你們有使用過廣播與服務的功能？

等等~等等！先別用鄙視的眼神看著我。我指的不是那種在車上或網路上隨處都能收聽到的廣播節目。

 

咱們這裡是什麼地方？技術分享大平台啊。

容我重新在問一次。請問你們有在Android系統上使用過廣播(Broadcast)與服務(Service)的功能嗎？

 

嗚喔~我再次從螢幕前感受到部分的看倌投來一股不屑的眼神。

晚了！網路上分享者都把Android的基本技巧給分享到民國112年了。

也就是西曆2023年了。現在看倌們都成精了！沒有新貨可以蹭了。

 

兄弟。那我把廣播與服務再加上APP 硬體的版本兼容，你說能不能蹭？

 

 

讓我們先把時光倒轉到數個月前...

 

你遭遇到了物流廠商前來挑戰！

 

物流廠商對自己使用了舊案需求更新提升了大量的攻擊力。

工程師使用了專業系統分析，內心安定指數提了些許。

 

物流廠商使用了軟硬體同步更換連帶專案功能需要大幅度修改的特殊攻擊對工程師進行了致命的打擊！

 

效果十分卓越！工程師受到了嚴重的打擊。

 

工程師開啟應對技能選單

Ａ：我們把APP打掉重做吧！以下是價目表。承惠！

Ｂ：使用改版技能。基於舊的版本下去修改。

Ｃ：躺平（跳過本回合）

 

好！就此打住！在瞎搞下去估計這文章過不了審。

 

這次的案子是需要幫之前經手的物流公司，對PDA上的物流系統進行改版。

此案幾年前也是由我參與開發協力完成的Case。可以說算是我的老朋友了。

 

PDA(personal digital assistant):個人數位助理 即是這台機器。

這是一種裝載Android系統的條碼掃瞄器，也可以乾脆將他視為一隻具有掃碼功能的手機。

普遍物流公司、倉儲系統、拍賣場進出點貨..等需要盤點的業務。都有機會接觸到。

 

該專案需求很單純，僅需要依據廠商需求，建制對應的驗收、移庫、入庫、檢貨檢核等.....相關的功能，細節部分恕我無法透露過多，但整體來說是一個以資料流向為主導的APP，PDA端的工作項目主要是做資料收集與庫存驗證，貨源單位的轉換，透過API傳導給Server。進行倉儲與物流整合處理。

 

你問我這些跟廣播與服務有什麼關係!?別急嘛～

 

我們先把目光關注在廣播這個部分。以下是官方資料整理的重點

Android Broadcast Receivers 廣播接受器：

這是一個很實用的功能。當你的程式需要將某些資料推送給其他功能單位甚至是手機內其他APP使用時，這是一個相當棒的選擇。

 

在Android內部要接收廣播方式有兩種。

 

 

Manifest-Declared Receivers （清單註冊接收器）:

專案的設定文件AndroidManifest.xml內部設定<receive>標籤

 

 

Intent內文即是指定接受器的訂閱的廣播

 

 

宣告BroadcastReceiver,並且實作onReceive事件，Receive將實作接受廣播後續處理。

 

此方法在app安裝後就會自動註冊該Receciver。資料生命週期僅存在於onReceive運作期間。

 

Context-Declared Receivers （內文註冊接收器）：

一樣需要在功能程式內部宣告BroadcastReceiver，並且實作onReceive。

 

 

宣告IntentFilter，並設定接收廣播的action。並且調用registerReceiver註冊該接受器。

 

這方法僅只有Activity生命週期存續時才能夠接受廣播。

當Activity消滅時將停止接收並且在onDestory時務必要執行unregisterReceiver()。避免程式發生不可預期的錯誤。

 

那定好接收廣播了接下來就是發送廣播了

 

是的，就是這麼樸實無華。我們只需要定好接收的Action名稱。包入intent就可以執行SendBroadcast進行廣播

 

看到這邊我相信不少看倌們心中在點頭稱是的同時應該都有一個疑問吧？

 

所以....李嚴，那個醬汁呢？

 

 

……………

 

……

 

…

 

.

 

PDA掃描BarCode功能在軟體面的實做，就是透過廣播功能實踐的。（拇指）

當然PDA Scan 所引用的SDK內部實作不會只有單純的廣播，我稍微透視了一下SDK內部結構。

資料解碼後最終傳導的方式就是以廣播方式傳遞取值。

 

還記得剛剛對戰中廠商使用的需求打擊嗎？

這次專案我面對的問題不只是系統上的改動，這次作業項目是連硬體都被置換掉了，

但是並不是單純將舊有的機器給代換掉。而是存在了新舊並行的狀況，未來也需要再考量新的機種加入的情形。

所以APP必須存在兼用的相容性需求。

 

 

這時候該請出這次第二個主角Service了

 

先簡介一下官方Service的重點

 

Service：服務是一種可以長期在專案背景執行，並且無須提供程式介面的元件。

應用範疇大部分都是需要長期執行並且不需要與使用者有互動的任務。

我們可以從官方定義生命週期看出Service生命週期是凌駕於Activity的，
因此通常只要不註銷Service，Service是可以在背景中長期存續的。

 

 

Service 也可以大略分成3種模式

 

 

Foreground Service（前景服務）：前景服務主要的目標是完成用戶能注意到的服務，比方說手機音樂的播放，前台服務都必須顯示通知（Notification），該服務在APP關閉之後也將失效。

 

Background Service（背景服務)：背景服務通常執行不須通知用戶的操作，比方說壓縮空間，當APP關閉後該服務還是會繼續存在。

 

 

Bound Service（綁定服務）：當你使用bindService來啟用Service時。Client就會與此Server進行綁定（Client 可以是 Activity）發送請求，接受響應。並能透過ICP協定通信。服務會與綁定Client生命同週期。

 

服務的應用，單篇幅度文章我難以全面講完有興趣看倌可以參閱一下官網。

(https://developer.android.com/guide/components/services?hl=zh-cn)

這邊我是使用了前景服務來做解決方案。

前景與背景服務在專案中實作僅差異在你是否需要啟動Notification來通知使用者，並且啟用的函示略有不同而已。

 

我們把注意力拉回到PDA來。上面我們已經知道了PDA的Scan最終傳導的方式是透過廣播方式拿回。

而且各家廠牌的Scaner 幾乎都以自己規格方式進行廣播。

 

那我們只要將各廠牌的Scaner，各自做成一個Service，

我只需要透過Android 內部 getDevice 判斷出目前使用的機器為哪種機型，

讓APP啟動對應的Service取值，不就解決了這問題了嗎。

 

 

 

我不宜透過多的專案程式碼。所以這邊只好使用官方圖片借花獻佛一下並大略說明一下我在其中做了什麼來解決專案相容性問題。

 

 

onCreate：此處Service 初始化，在此處宣告Notification，安著版本10以上後強製版定需要宣告，否則將會出錯。

 

 

onStartCommand：Service啟動初完成後會執行此函式。在此處我會註冊一個廣播接受器，用來接收sdk廣播給我的PDA Scan 解碼後的值。並且在接收訊息後再次使用”統一規格標籤“進行全域廣播。

 

onDestroy：此處為Service 結束會執行函示，在這邊為Service註銷時我同步將廣播接收器給註銷。

 

上述作業目標其實就是將Scaner從我APP中剝離出去。

讓Service負起PDA溝通的職責，如此我們程式只要單純的負責各工項的作業即可。

未來如果PDA的機種增加了那我只需要再添加新的Service就能並行程式。

 

 

好拉！到此終於迎來分享的結尾了。

碼農華爾滋有可能會是一篇系列作品。

當每完成一個專案有空閒時，我就將專案有趣的點或實用的技能抽出來整理整理在跟大家分享一下。

也當成是我在公司活動過的軌跡做個紀念回憶一下。

 

末尾付幾張實作的圖片，證明這個案子真的有實作喔。

而且現在還在線上使用中。