我正在使用片段创建我的应用。我有类似主要活动的东西,它有FrameLayout
作为根布局来保存碎片
经过深思熟虑后,我决定将我的应用程序逻辑分成几个部分,例如:MainActivity
负责app基本导航(MainPageFragment, CategoryListFragment, ProductListFragment, ProductDescriptionFragment
),AuthActivity
负责autherization,registration({ {1}})。
关于我的应用程序。如果您有推荐或不同意应用程序结构,我将非常感谢任何批评者。
问题是什么,因为您可以看到我的MainActivity有很多责任。现在有四个片段,但未来可能更多 让我们考虑下一个情况。在我的MainActivity中,我有MainPageFragment,当然这个片段也有一些视图。在click事件中,我需要更改片段,例如从MainPageFragment更改为CategoryListFragment。在这种情况下,我有几种方法来处理来自framgents的点击或其他事件。
最常见的方法是让活动实现片段类中定义的回调接口作为嵌套类接口。这种方法非常好并且易于使用。但是如果我的主机活动必须处理来自片段的多个回调,比如说,单个片段可以有多个回调,类(活动)声明开始增长,类体也是如此。解决此问题的另一种可能方法是什么?
你可以处理所有点击,直接在片段内的事件(开始活动,替换framgent ......)你可以做到这一点无痛,但对我个人回调的方法看起来更好,但也许没什么不好的,我可以使用这种方法。
使用一个或多个接口从片段中获取信息。例如,创建类SignInFragment, RegistrationFragment, RecoverPasswordFragment
来保存CallbackEvent
这样的信息....使用这种方法我们可以减少接口和方法,但是Activity类体在第一种方法中可以变得更大。
使用类似EventBus模式的东西通过第三方服务在应用程序组件之间进行通信。
当然还有其他一些方法可以做到这一点,但我描述的最受欢迎。
请建议,或者只是解释一下如何在应用中解决这个问题,哪种方法更好,如何建立这种易于维护的通信。
我很感激任何建议,提前批评。
答案 0 :(得分:1)
答案 1 :(得分:1)
我有两个片段规则 - 活动分离。
一个是逻辑。任何处理View(布局扩展,显示,监听器等)的东西都应该放在Fragment中。重要的后台进程(http请求,文件读取,图像处理等)应该在Activity内部。我的第二点解释了部分原因:
生命周期。活动的生命周期比片段更长。片段也很脆弱,甚至不保留其观点。这就是Fragment应该与Activity分离的原因。监听器和回调是紧密耦合,当某些进程尝试更新已调用其onDestroyView
的片段视图时,它们是无数空指针异常的原因。话虽如此,我建议发布者 - 订阅者模式,如事件总线,您可以计划一个消息传递,只有当发布者(在这种情况下对应于片段的视图)可用时才会消化它。
您拥有的众多点击监听器与您设计UI的方式有关。除非你减少布局,否则移动代码并没有多大帮助。