1. 程式人生 > >返璞歸真,運用Android廣播機制來通知介面重新整理

返璞歸真,運用Android廣播機制來通知介面重新整理

大家在進行業務開發的時候,A介面跳轉到B介面,B介面進行操作後,反過來通知A介面重寫重新整理介面,這個邏輯是非常非常常見的

常用的手段

  • 通過Activity的一些回撥方法(這裡假設activity)
  • 獲取Activity例項來強制呼叫方法(前提是方法名暴露出來)
  • EventBus或者RxBus這類通訊工具去post一個訊息
  • 通過Handler等等….

就拿我自己來說,我之前是使用EventBus

我之前為什麼使用EventBus?

  • 因為他簡單
  • 並且是直接將一個複雜物件傳遞出去,省去了序列化的步驟
  • 框架也比較成熟
  • 耦合度不高

為什麼放棄它?

  • 需要建立大量的不同的訊息型別來加以區分(否則所有已註冊且未銷燬的介面都會收到相同的訊息)
  • 業務一旦複雜了以後,也正是因為其解耦的關係,使得訊息傳送和接收對於開發者自身後期維護和追蹤問題較為困難

其實就我個人而言,我的目的很簡單

  • 我這個訊息要一對一發送(或者一對多傳送)
  • 我不想建大量的訊息型別(即使這個型別是個空屬性)

說來也慚愧,Android開發這麼久了,在此之前幾乎沒怎麼用過廣播,不過也正是基於上面我放棄的原因和目的需求,在大概瞭解了一下Android的廣播後,驚人的發現似乎我可以用廣播去代替EventBus(不過網上更多的是EventBus/RxBus去代替廣播)

什麼是廣播?
那麼在瞭解了廣播以後,再回過頭來,梳理一下需求

  • 我要發訊息,不想讓不需要這個訊息的介面收到(假定是一對一發送)

    廣播正好可以設定action和Filter來過濾,如果說EventBus是通過不同的訊息型別來”過濾”,那麼廣播就是通過字串來過濾,符合我的要求,直接省去了訊息型別的建立

  • 業務變得稍微複雜以後,訊息傳送和接收不致於太亂

    這個還是見具體程式碼吧

Show Code!

/**
 * Created by GuoSS 2017/8/24.
 */
public class ActionBroadcast extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
        if
(listener != null) listener.receive(context, intent); } private ActionListener listener; public void setListener(ActionListener l) { listener = l; } public interface ActionListener { void receive(Context context, Intent intent); } }

可以看到自定義一個廣播接受者,定義一個簡單介面
(為了方便,下面的採用圖片來展示程式碼)
這裡寫圖片描述

  • 這裡的action字串定義為action+類名,如action.HomeActivity。
  • 並在基類註冊廣播和新增過濾,(除了這個action以外的其他任何訊息,都接收不能)
  • 在postAction方法中傳遞class物件,來發送訊息,送達該class的介面
  • 在receive方法中去接收事件,然後去做一些重新重新整理的操作,當然如果傳遞具體資料的話,如有可能的話,仍需要去序列化資料的物件型別
  • 在onDestroy裡去解註冊廣播,截圖裡未放出,意會即可
  • Fragment裡也同理,在onViewCreated註冊,在onDestroyView解除註冊即可,注意呼叫 getActivity().registerReceiver(),字首帶上getActivity()

雖然這種方法耦合程度較高,但是在簡單業務環境下省卻了開發者很多工作,至於耦合度的問題,我是這麼看的,耦合意味著查詢關係更簡單輕鬆,解耦雖然解除了強依賴關係,但是也使得相互之間的關係變得難以捉摸,非要解耦的話,對於action的命名個人覺得可以參考ARouter(阿里的一位Android開發者設計的路由框架)對於Route的管理,至於要不要使用這種廣播,見仁見智

最後來放出我的使用示例
這裡寫圖片描述
一段網路請求過後,刪除一個內容,通知某個頁面的資料需要重新整理
這裡寫圖片描述
該介面接收到訊息以後,霧草,一言不合直接重新整理給你看,當然如果需要的話,簡單資料無須序列化直接從intent裡取出來就好了

上面說的是一對一廣播,至於一對多廣播

我覺得是可以通過定義列舉來歸類這些不同的action,建立其他的廣播接收者,在有需要的介面,去註冊這些一對多的廣播即可,本質和一對一相同