具有活动的NavigationDrawer与带碎片的NavigationDrawer

以我目前正在使用的应用为例: – 它有一个包含多个项目的navigationDrawer; 有两个东西我现在感兴趣,我会叫他们X和Y.

片段方法正在工作,但是我花了一段时间来pipe理片段之间的导航。 另外,我可能不得不在抽屉里添加一些类似于X和Y的新项目。我的抽屉和我做碎片切换的主要活动已经很密集了,这让我想到了:应该我从碎片切换到活动? 我正在考虑select抽屉项目时开始一个新的活动,并处理与该活动中选定项目相关的列表/视图/编辑片段,而不是处理单个活动中所有项目的所有片段。

这是个好主意吗? 这是不好的devise?

Solutions Collecting From Web of "具有活动的NavigationDrawer与带碎片的NavigationDrawer"

我在类似的船,我使用的活动方法,这种方式,我有每个活动与特定的导航视图点击组的片段。 显然,我使用NavigationView,但只用一个MainActivity来pipe理所有这些片段实际上是一个痛苦的任务。

当我们点击一​​个导航项目时,宁愿使用EachActivitypipe理自己的片段。 这给了我一个更好的性能,因为我不需要担心很多碎片的生命周期,它是backStack和添加/删除/显示/隐藏地狱。

我使用下面的SO问题来巧妙地使用实现NavigationDrawer的BaseActivity,并与所有其他活动共享它。 真正的魔力是它不重复代码,或者它不仅仅是普通的旧式inheritance技术。

这里的链接,检查出来

我在我的两个项目中使用了这种方法,运行得非常好,而且我从一开始就不必处理片段pipe理。

我有以下几点提交:

  1. 碎片方法好得多。 您应该使用片段为用户提供更好的UI体验

  2. 像这样想,把你的屏幕想象成一篮子的信息,如果你有另一个篮子(我是另一个屏幕), 有很多数据需要来回转移,那么根据我的观点,在容器活动中使用两个篮子的碎片。 当然,可以有两个以上的篮子/屏幕。

  3. 没有硬性和快速的规则,你应该只使用片段或活动,但谷歌说,它是好得多的碎片,如果有可能的话

  4. 一般来说,开发人员使用片段将关联的逻辑组合在一起,这样做更好,因为它可以提供您正在尝试执行的任何操作的逻辑分组

  5. 通过容器活动和接口的帮助,在分片之间传递java数据对象也是很容易的。 这也被认为是一个非常模块化的方法。

rest取决于你想如何定义你的应用程序的stream程。 我认为在你的情况下使用片段是一个更好的方法。 无论您认为相关逻辑发生了什么变化,都可以使用容器活动。

首先,pipe理片段之间的导航并不困难。 你可以检查谷歌的教程 。 如果您发布代码,我可以build议您进行一些修改

我认为这是不好的devise,有两个原因

  • 很多代码返工
  • 如果你想改变你的导航模式来说标签,这是不容易的。