NavigationDrawer活动与片段回调和应用程序业务逻辑混杂

包含NavigationDrawer的Activity应该与其片段混杂在一起。我的问题是抽屉必须在应用程序的所有可能的屏幕上可用，这使得我唯一的活动MainActivity非常混乱的片段回调代码和不同种类的导航/业务逻辑。NavigationDrawer活动与片段回调和应用程序业务逻辑混杂

随着应用程序的增长，它变得更难以浏览整个活动，我开始考虑可能的替代方法。新方法必须保持与原始相同的视觉行为并消除混乱。

除了导航抽屉事件之外，还有多个片段也包含导航/业务逻辑，这也是由MainActivity处理的。例如，一个片段可能包含3个或更多按钮，这些按钮可以启动其他片段或执行一些交叉关注的业务逻辑。

因此，由MainActivity实现的监听器接口的最终数量增长，并且截至此刻为止。您可能会认为它看起来不舒服或感觉不舒服。

我想我可能会将事情分解为多个NavigationDrawer活动以简化维护。它表明较大的资源消耗和轻微的视觉效果偏差，因为新的活动只有在抽屉关闭后才会启动，与原来的方法立即改变碎片相反。

你认为这是一个坏主意吗？如何改进？或者有更好的解决方案？

谢谢。

UPD细化描述。

来源

2013-10-18 midnight

我被困在这样的问题和发布问题在这里> http://stackoverflow.com/questions/17779915/open-android-navigation-drawer-from-an-activity-class 。没有尝试解决方案，但你可以尝试，如果它的工作，我不知道它是否工作。我最终只从几块碎片打开抽屉。 –

公平点。视觉效果怎么样 - 我应该在抽屉关闭后才显示新的活动吗？ – midnight

您将在抽屉上选择点击并可能启动新活动或显示其中一个片段，这不会成为问题，它会在选择时自动关闭。 –

你说，你只有一个活动。所以，我认为所有屏幕都是应用程序中的碎片。因此，NavDrawer在默认情况下随时可以在您的应用程序中使用。

不需要多个具有不同NavDrawer实现的活动。您可以使用一个BaseActivity来处理NavDrawer的实现，如果您希望在未来实现更多功能，那么您可以在每个您喜欢的活动中使用它。这将遵循OOP原则并导致更清晰的代码。此外，NavDrawer的外观和行为在每个活动中都相同。这是它的目的，为您的应用程序有一个导航菜单。

扩展BaseActivity的Activity的工作是处理碎片的事务以及通过回调与它们进行通信。

有了这个你的应用程序的导航清晰的结构，并明确的路要走。

你可以按照这个非常好的完成tutorial这样做。第一眼看起来有些压倒，但你可以得到基本的想法。

来源

2013-10-20 17:04:43

这是OP试图避免/寻求建议的原因。 “这暗示着......轻微的视觉效果偏差，因为新的活动只有在抽屉关闭之后才会启动，与原先的方法相反，这会立即改变碎片。 – Vikram

@ user2558882我的回答不是关于抽屉里的选择，它可能会同时启动活动和片段。无论如何，这是为了避免。这是抽屉的视觉效果或行为会改变的唯一情况。我只是说如果代码更多地在不同的类中结构化，代码将更清晰。 –

我会建议只需要一个NavigationDrawerDelegate类，它负责处理所有的导航逻辑并将其添加到您的活动中，并将其委托给它。一个很好的例子here

来源

2013-10-22 21:51:15

NavigationDrawer活动与片段回调和应用程序业务逻辑混杂

回答

相关问题