iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 8
1
Software Development

0 -> Android -> Kotlin 開發筆記系列 第 8

[Day08] Android 四大元件介紹 II


今天介紹四大元件中的另外兩個,直接開始:
BroadcastReceiver:官方解釋網址

這個元件的用途是Android 預設的溝通模式,溝通的方式就好像以前的無線電,Broadcast透過Intent 廣播到某個彼此溝通好的 Action頻道上,Receiver則是向收音機一樣,將對應的資訊從頻道上擷取下來,再去執行自己需要的動作,Android所有的開放的服務如打電話、連絡人、檔案總管等等,都是可以透過Broadcast 與Intent去呼叫對應的行為。
筆者認為這個元件的優點是實作方便,但缺點就是沒有AIDL 的IBinder穩定跟效率,所以如果有跨App或Process(之後的多執行緒篇章再解釋)且穩定及效率上的考量,可以考慮直接實作AIDL,筆者選了幾篇值得一看的文章如下:

ContentProvider:官方解釋網址

寫到這個原件,筆者覺得很值得一提的一個回憶,大約筆者在第一年(4.x)開發的時候就知道了這個元件,但當時使用這個元件的人極少,為甚麼?舉例:

那個時候的軟硬整合的Source code,大多都是一些直接從Linux層去讀對應位置的值,
然後直接實作功能的程式碼,這也不能怪開發者,因為有一些這樣實作的功能,
還比透過Android官方建議的ContentProvider還穩定
(因為做手機的廠商根本沒照規定實作,就好比Nexus 5x的鏡頭是反的….)

時過境遷,現在Android因為使用的人多了,資安跟權限的考量提升,
因此Android 6以後的版本幾乎都要求需要透過官方文件上所示的方式去讀值,
因此這個元件的使用率就大幅提升了xD(教學文件大多是2017年出現的),
可以說是鹹魚翻身的一個元件?

此元件的用途大多是給予不同的App或是使用者讀取自身App產生的檔案的讀寫權限,
因此這個才是比較正式的檔案資訊傳遞管道,當然開發者圖方便或是為了解決某些限制,
筆者自己的認知,多是直接用讀取外部資料這個權限…

p.s. 現在很多以前版本的Source Code、Simple Code其實都Build不起來或是Build起來會直接噴Crash了…


最後介紹筆者認為值得一提的Context:官方解釋網址
先列出拜讀過的文章:

依筆者的說法來說,Context就是一個Application的靈魂!

一個App不會有兩個靈魂,所有的功能接口都是透過這個Context去跟別的App溝通,
當然你需要的功能也可以從Context上去取得,在App Context上宣的變數,
也可以視為這個App scope裡的全域變數,Activity跟Service都是繼承他實作出來的。

筆者也遇過開發者使用過Activity、Service,也常用到Context,
但就是沒有特別去了解Context是什麼,也因此會有很多不太正確的用法。

因此介紹四大元件的最後,呼籲大家一定要順便了解Context是什麼~


希望讀者看完這兩天的文章後,對於Android可以更熟悉一些!
本文同步刊登在Medium上,連結在此


上一篇
[Day07] Android 四大元件介紹 I
下一篇
[Day09] Android 開發常用名稱介紹
系列文
0 -> Android -> Kotlin 開發筆記30

尚未有邦友留言

立即登入留言