模式"一个活动,多个视图":优点和缺点

Fla*_*vio 26 android

此模式类似于用于开发Web应用程序的主Servlet(前端控制器)模式.

这种模式的主要思想是:我们有一个Activity来管理多个视图,这个活动负责表示当前内容.并非所有观点都需要活动功能(例如生命周期方法),因此主要问题是:如果我没有活动,为什么我必须使用它?


我发现使用这种模式有以下缺点:

  1. 官方消息来源不建议重载单个活动屏幕, 但他们不解释原因.

  2. 我们不能用TabActivity,ListActivity,MapActivity.但是有一些技巧可以没有它们.

  3. 如果不同的屏幕具有不同的菜单,那么在没有活动的情况下进行该操作是个问
  4. 我们有必要保持自己的历史.但是开发并不困难.

我发现使用这种模式有以下优点:

  1. 更改当前活动的内容比启动另一个活动更快
  2. 我们可以随心所欲地管理历史
  3. 如果我们只有一个活动上下文,那么查找和解决内存泄漏问题就更容易了

您如何看待这种模式?你能提供任何其他优点/缺点吗?

Com*_*are 59

我们不能使用TabActivity,ListAcivity,MapActivity.但是有一些技巧可以没有它们.

如果要使用,MapActivity则必须使用MapView.你必须使用PreferenceActivity,如果你想使用偏好XML.

我们有必要保持自己的历史.但是开发并不困难.

管理自己历史的困难将在很大程度上取决于历史需要.实现简单向导的历史记录相当容易.但是,这是一个特别简单的场景.在Android中有相当数量的历史管理代码,您必须为任意其他情况重写.

你也忘记了:

#5.您将容易泄漏内存,因为您将忘记清理内容,Android将不会清理内容(因为它假定您将使用许多小型活动,他们推荐的方式).

#6.配置更改(轮换,停靠,SIM更改,区域设置更改,多个显示,字体比例)的状态管理将更加复杂,因为现在您还必须弄清楚需要成为州的一部分的额外内容(例如,历史) ,你可以同时处理所有这些问题,而不是一次性处理活动.

#7.为您的应用程序设置多个入口点变得更具挑战性(例如,启动器中的多个图标,应用程序窗口小部件链接到除主要活动之外的某些活动,响应等).

更改当前活动的内容比启动另一个活动更快

对于大多数现代Android设备,速度差异对大多数用户来说并不重要,恕我直言.

如果我们只有一个活动上下文,那么查找和解决内存泄漏问题就更容易了

除了你还有超过"一个活动上下文".请记住:您的活动(无论大小)仍然会在配置更改时被销毁并重新创建.

您如何看待这种模式?

科斯的"公司性质"理论认为,企业扩张,直到内部做事的交易成本高于其他公司做同样事情的交易成本.

墨菲的"活动性质"理论认为,活动扩大,直到内部处事的交易成本高于其他活动做同样事情的交易成本.Android开发人员倾向于用于活动的"用户事务"模型 - 紧密耦合的事物(例如,向导中的步骤)将倾向于在单个活动中处理,以及具有很少关系的事物(例如,浏览与搜索与设置vs.帮助与约会相比,往往会在不同的活动中处理.