有一个代表经理是一个好的设计理念吗？

Question

许多安卓应用程序都有自己的BaseActivity类，应用程序中的所有活动都是这样扩展的。这很有用，因为它提供了一个中心位置来放置大多数/所有活动中常见的功能。拥有BaseActivity的主要缺点是您无法使用任何活动子类(ListActivity等)。

一种选择是拥有一个ActivityDelegate。这为功能提供了一个中心位置，同时仍然允许您使用活动子类。它也可以说更易于测试，因为它使用组合而不是继承。

当BaseActivity/ActivityDelegate变得过于庞大和复杂时，这两种解决方案都可能导致大量的意大利面代码。一个可能的解决方案是使用委托模式，但将功能拆分为许多不同的代理。这减少了代表中的意大利面代码，但是活动变得更加复杂--他们现在正试图将他们的on*方法转发给许多不同的代表，而不仅仅是一个。

解决所有这些问题的一个可能的解决方案是使用代理管理器。代理管理器跟踪应用程序中所有较小的代表。活动将其on*方法转发给代理管理器，后者将其转发给所有单独的代表。这完成了以下所有工作：

• Dedupes代码-所有公共功能都被放置在一个代理程序中。
• 允许使用活动子类
• 所有活动中的简单代码-所有on*方法仅被转发到一个类
• 易于测试--很容易模拟出代表和代理管理器周围的所有单元测试

以前有人试过使用这种模式吗？如果是的话，进展如何？

Answer 1

据我所知，您谈论的是整个应用程序的一个DelegateManager对象。如果是这样的话，您可以使用registerActivityLifecycleCallbacks，(请参阅http://developer.android.com/reference/android/app/Application.html#registerActivityLifecycleCallbacks%28android.app.Application.ActivityLifecycleCallbacks%29 )

如果您所处的是< API级别14，则需要查看：https://github.com/BoD/android-activitylifecyclecallbacks-compat。

registerActivityLifecycleCallbacks允许您连接到活动onXXX生命周期方法。

这样做当然有您所描述的所有好处：

• 解耦只有在实际需要重复行为时才可用，对于controller+view逻辑来说，这种行为很少出现在活动的工作方式中。
• 如果您有可能重用的活动，那么删除继承是很好的--但是我以前从来没有这样做过。但是我想一个很好的用例应该是你在家做的处理设置的活动，或者类似的东西，它需要应用程序范围的L&F & behavior。

在我的头顶上，我能想到下面的缺点：

• 在各地使用监听器可能会模糊应用程序活动/调用层次结构的路径，并使代码难以理解。对于所有侦听器/dispatcher类型的编程来说，这都是正确的。这是一个强大的工具，但小心处理。
• 如果您所做的只是传递给生命周期监听器/委托，那么它可以引入大量的样板/意大利面代码。
• 用Application.unregisterActivityLifecycleCallbacks从应用程序中注销注册是您的责任。我不认为有什么好办法可以绕过它，

就我个人而言，我并没有在生命周期()中大量使用这种设计模式，但对于某些用例来说，它可能是值得的。例如：

• ApplicationLifecycleLogger:每次你创建/恢复/暂停.一个活动，您的logcat或其他东西，使调试生命周期稍微容易一点。
• 例如，如果某人由于某种类型的模型状态(例如，振铃警报->不能进入AlarmEditActivity)而不允许进入某个活动，则可以在那里执行finish()。
• 在不改变Parcelable:s和屏幕旋转的情况下跨活动边界传递对象状态。通常，这是通过应用程序中的Map或某个静态字段实现的。你可以通过让委派者保持状态来做到这一点。

另外，看一看：Is there a design pattern to cut down on code duplication when subclassing Activities in Android?

我希望这是有帮助的