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

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

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

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

  • Android:每次点击导航抽屉项目时创build一个新的片段,或者加载之前创build的片段,会更好吗?
  • 导航抽屉的应用程序的Robotium UItesting
  • 如何select导航抽屉中的第一个项目并在应用程序启动时打开一个片段
  • 如何使用Fragments在NavigationDrawer上隐藏OptionsMenu?
  • 我在类似的船,我使用的活动方法,这种方式,我有每个活动与特定的导航视图点击组的片段。 显然,我使用NavigationView,但只用一个MainActivity来pipe理所有这些片段实际上是一个痛苦的任务。

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

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

    这里的链接,检查出来

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

    我有以下几点提交:

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

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

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

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

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

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

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

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

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