0

我希望使用Otto進行片段間通信。如果我可以提供幫助,我想用最佳做法來做到這一點。 Github上的Otto示例對Bus對象使用單例,但建議使用依賴注入。我對這兩個概念都很陌生,儘管前者似乎更容易實現。儘管四處閱讀,我仍然努力想看看後者如何付出相當大的努力。使用otto進行片段間通信 - 依賴注入混淆

有操作系統依賴注入器匕首,guice和其他一些,但他們似乎像他們會相當沉重的像我這樣的相對新手拿起。我想知道是否真的值得學習如何使用其中的一種方法,以達到效率/代碼慣例中看似微不足道的效果。更何況他們會膨脹我的項目。

使用DI來實現Otto真的很值得嗎,當時我只是想用它來替換一些接口和監聽器?我只會真的註冊Bus在幾個片段的活動

我不會單元測試,我可以與兩個或三個活動(十分之一)緊緊耦合到他們的片段。我看不到任何東西確實是這樣做不好,特別是如果它稍後切換到依賴注入相對容易。

最後,我需要單獨的Bus實例爲單獨的活動 - 片段組,其中溝通將只發生在所述組?從閱讀中我不清楚我是否需​​要爲最佳實踐/效率或安全而做到這一點?

回答

2

我想你可能會對此有不同的看法,但是我已經使用了Otto和Dagger自己,考慮到你提供的信息,我不認爲實施DI的成本/收益(包括匕首,guice或其他東西)將爲你值得。這不是一把匕首 - 我喜歡它,並且成功地使用它,但是有一條學習曲線,如果你沒有進行單元測試,我不知道它會爲你提供多少價值。

如果您稍後開始進行單元測試,那麼添加DI將是一個好的舉措。

關於單獨的活動 - 片段組的單獨Bus實例的問題,如果這些活動 - 片段組未發佈和訂閱相同種類的事件,則可能不需要。也就是說,如果活動片段組A只關心Foo事件,而活動片段組B只關心Bar事件,那麼我認爲單個應用程序範圍Bus可能會滿足您的需求。

+0

我同意,儘管我認爲在某些時候學習單元測試可能是一個想法,尤其是對於許多活動應用程序。拋開學習方面,似乎將來無論如何轉換到像Dagger這樣的相對容易。 – nme32