片段回调爆炸,如何处理?

时间:2015-06-03 17:29:31

标签: android design-patterns android-fragments android-activity callback

我正在使用片段创建我的应用。我有类似主要活动的东西,它有FrameLayout作为根布局来保存碎片 经过深思熟虑后,我决定将我的应用程序逻辑分成几个部分,例如:MainActivity负责app基本导航(MainPageFragment, CategoryListFragment, ProductListFragment, ProductDescriptionFragment),AuthActivity负责autherization,registration({ {1}})。
关于我的应用程序。如果您有推荐或不同意应用程序结构,我将非常感谢任何批评者。

问题是什么,因为您可以看到我的MainActivity有很多责任。现在有四个片段,但未来可能更多 让我们考虑下一个情况。在我的MainActivity中,我有MainPageFragment,当然这个片段也有一些视图。在click事件中,我需要更改片段,例如从MainPageFragment更改为CategoryListFragment。在这种情况下,我有几种方法来处理来自framgents的点击或其他事件。

  1. 最常见的方法是让活动实现片段类中定义的回调接口作为嵌套类接口。这种方法非常好并且易​​于使用。但是如果我的主机活动必须处理来自片段的多个回调,比如说,单个片段可以有多个回调,类(活动)声明开始增长,类体也是如此。解决此问题的另一种可能方法是什么?

  2. 你可以处理所有点击,直接在片段内的事件(开始活动,替换framgent ......)你可以做到这一点无痛,但对我个人回调的方法看起来更好,但也许没什么不好的,我可以使用这种方法。

  3. 使用一个或多个接口从片段中获取信息。例如,创建类SignInFragment, RegistrationFragment, RecoverPasswordFragment来保存CallbackEvent这样的信息....使用这种方法我们可以减少接口和方法,但是Activity类体在第一种方法中可以变得更大。

  4. 使用类似EventBus模式的东西通过第三方服务在应用程序组件之间进行通信。

  5. 当然还有其他一些方法可以做到这一点,但我描述的最受欢迎。

    请建议,或者只是解释一下如何在应用中解决这个问题,哪种方法更好,如何建立这种易于维护的通信。

    我很感激任何建议,提前批评。

2 个答案:

答案 0 :(得分:1)

  1. 如果您的应用程序变得更复杂,使用回调模式将变得混乱,特别是如果片段需要与片段通信。我只对低复杂度的应用程序(活动,一个或两个片段)使用该模式。
  2. 如果片段内发生任何事情,则应在片段内处理点击,事件等。不要在片段中替换片段,这是活动的责任。在片段中执行getActivity()。someMethod可能看起来更容易,但这会导致难以维护代码。你现在可能已经明白它在做什么,但会在半年内挣扎。
  3. 这种方法对我来说也很混乱(类似于1。)
  4. 那是我推荐的那个。我使用了EventBus(https://github.com/greenrobot/EventBus),但是有其他类似Otto(https://github.com/square/otto)的实现,而且我从未回顾过使用回调模式的时代。使用EventBus解耦不同组件之间的通信,您的代码变得更加简单和精简。但是,由于存在一些缺陷,因此您需要小心这种方法。一个是从任何组件到任何其他组件的通信变得更加容易,这可能导致甚至比监听器/观察者模式更脏的代码。另一个问题是,与同步侦听器调用相比,事件是异步的,因此您需要确保只接收"权利"组件生命周期中恰当的事件。 EventBus方法的主要优点是IMO:
    • 与更实用的侦听器方法调用相比,消息始终是强制开发人员编写面向对象的对象
    • 它解耦了不同的组件。出版商和订阅者不必彼此了解。解耦组件将使您的代码更精简,更易于阅读(和维护)。
    • 可以由任意组件使用。例如。我用EventBus消息替换了所有LocalBroadcastManager调用(EventBus比使用LocalBroadcastManager快得多)。如果组件不能直接相互访问(如对话框和首选项对象),则能够在任意组件之间进行通信是非常方便的。

答案 1 :(得分:1)

我有两个片段规则 - 活动分离。

一个是逻辑。任何处理View(布局扩展,显示,监听器等)的东西都应该放在Fragment中。重要的后台进程(http请求,文件读取,图像处理等)应该在Activity内部。我的第二点解释了部分原因:

生命周期。活动的生命周期比片段更长。片段也很脆弱,甚至不保留其观点。这就是Fragment应该与Activity分离的原因。监听器和回调是紧密耦合,当某些进程尝试更新已调用其onDestroyView的片段视图时,它们是无数空指针异常的原因。话虽如此,我建议发布者 - 订阅者模式,如事件总线,您可以计划一个消息传递,只有当发布者(在这种情况下对应于片段的视图)可用时才会消化它。

您拥有的众多点击监听器与您设计UI的方式有关。除非你减少布局,否则移动代码并没有多大帮助。