3

许多 Android 应用程序都包含自己的 BaseActivity 类，应用程序中的所有活动都扩展了该类。这很有用，因为它为放置大多数/所有活动共有的功能提供了一个中心位置。拥有 BaseActivity 的主要缺点是您无法使用任何 Activity 子类（ListActivity 等）。

一种替代方法是使用 ActivityDelegate。这为功能提供了一个中心位置，同时仍然允许您使用 Activity 子类。它也可以说更具可测试性，因为它使用组合而不是继承。

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

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

  • 重复数据删除代码 - 所有常见功能都放入其中一个委托中
  • 允许使用 Activity 子类
  • 所有活动中的简单代码 - 所有 on* 方法仅转发给一个类
  • 易于测试 - 轻松模拟 Delegates 和 Delegate Manager 周围的所有内容以进行单元测试

有没有人尝试过使用这种模式？如果是这样，它是如何进行的？

4

1 回答 1

2

据我了解，您说的是整个应用程序的一个 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 生命周期方法。

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

  • 仅当您实际需要重复行为时，解耦才可用，这对于以 Activity 工作方式捆绑在一起的控制器 + 视图逻辑来说很少见。
  • 如果您有可能重用的活动，则删除继承很好 - 但我以前从未这样做过。但我想一个很好的用例是您在家中处理设置的活动或需要应用程序范围的 L&F 和行为的类似活动。

在我的脑海中，我可以想到这些缺点：

  • 在各处使用侦听器会模糊应用程序活动/调用层次结构的路径，并使代码难以理解。这适用于所有侦听器/调度程序类型的编程。这是一个强大的工具，但要小心处理。
  • 如果您所做的只是传递给生命周期侦听器/委托，它可以引入很多（正如您提到的）样板/意大利面条代码。
  • 您有责任从应用程序中注销自己的注册Application.unregisterActivityLifecycleCallbacks。我觉得没有什么好办法

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

  • ApplicationLifecycleLogger：每次您创建/恢复/暂停...一个活动时，您都会使用 logcat 或其他东西使调试生命周期变得更容易一些。
  • 例如，如果某人由于某种模型状态（例如响铃警报-> 无法进入 AlarmEditActivity）而进入他/她不允许进入的活动，您可以在此处执行 finish()。
  • 在没有 Parcelable:s 和屏幕旋转更改的情况下跨活动边界传递对象状态。通常这是通过应用程序中的地图或某处的某个静态字段来实现的。你可以通过让委托人保持状态来做到这一点。

另外，请看一下：在 Android 中对活动进行子类化时，是否有一种设计模式可以减少代码重复？

我希望这会有所帮助 =)

于 2013-11-18T16:50:53.323 回答