Android中的片段回調vs EventBus

我遇到了這個問題。我的Activity是片段容器，所以要在活動和片段之間進行通信，我使用普通的Callback方法。在這種情況下，我的活動必須根據片段數量實現大量的回調接口。
我不喜歡硬編碼和不可讀的代碼。在我的情況下，我的類聲明可能需要幾行來列出所有接口。
我想擺脫這一點。Android中的片段回調vs EventBus

還有一種方法是使用EventBus模式。
在活動

EventBus.getDefault().register(this);

在片段

EventBus.getDetault().post(new MyEvent(description));

而且在活動處理若干事件類型。

也許會有更好的使用EventBus在這裏，而不是默認的回調方法??
或者，也許有我的錯，我的活動是持有很多片段（上帝對象），最好是使用活動，而不是片段？

請提出哪種方法更好？

來源

2015-05-31 CROSP

你interface做法是真棒，正好趕上他們，也許嘗試和切片/讓你interface靜態的，所有的點點void S和return method s添加到該接口使你可以實現一個和調用的函數。

EventBus？怎麼樣LocalBroadcastReceiver？它是一個偏好的問題，你認爲哪一個更適合你，畢竟如果你處理了10,000個請求並且討厭擁有100個，你最終會使用1並嵌套99.

&只是忘了，持有Fragment而不是Activity，因爲在一天結束時Activity的生命週期很難維護，其次你不能真正控制Activity很好，與Fragment和Fragment相比是個好奴隸，更好地爲你服務

希望其有價值

來源

2015-05-31 05:05:29 Elltz

對於一個片段層次結構的簡單活動，回調是最簡單的決定。但考慮包含片段的活動，並且片段包含可滑動的ViewPager，並且ViewPager的每個選項卡都有片段A，B，C。

片段A，B，C會長時間將事件發送給母親活動，並且在crazy complex Android Activity-Fragment lifecycle dances期間它們恢復後，可能會失去活動與孩子之間的界面連接。在這種情況下，像otto這樣的事件總線可能是一個不錯的選擇。

事件總線方法的缺點是，很難保證事件發生的地方。所以，建議保留一些發件人。

來源

2015-05-31 05:15:18 Youngjae

MyEvenet中的「發件人」屬性不會提供誰提出該事件的想法？ OP有 'EventBus.getDetault（）。post（new MyEvent（description））;' – OmarBizreh

@OmarBizreh //是的。這有助於。但是我們必須記住，'sender'可能是_null_。 – Youngjae

我明白了，所以唯一的缺點是事件的來源，我要開始一個新的項目並使用EventBus，還有什麼我需要檢查？到目前爲止，我看到的所有SO鏈接都提到事件的來源是迄今爲止最糟糕的退步。 – OmarBizreh

Android中的片段回調vs EventBus

回答

相關問題