此模式类似于用于开发Web应用程序的主Servlet(前端控制器)模式.
这种模式的主要思想是:我们有一个Activity来管理多个视图,这个活动负责表示当前内容.并非所有观点都需要活动功能(例如生命周期方法),因此主要问题是:如果我没有活动,为什么我必须使用它?
我发现使用这种模式有以下缺点:
官方消息来源不建议重载单个活动屏幕, 但他们不解释原因.
我们不能用TabActivity,ListActivity,MapActivity.但是有一些技巧可以没有它们.
我发现使用这种模式有以下优点:
您如何看待这种模式?你能提供任何其他优点/缺点吗?
Com*_*are 59
我们不能使用TabActivity,ListAcivity,MapActivity.但是有一些技巧可以没有它们.
如果要使用,MapActivity则必须使用MapView.你必须使用PreferenceActivity,如果你想使用偏好XML.
我们有必要保持自己的历史.但是开发并不困难.
管理自己历史的困难将在很大程度上取决于历史需要.实现简单向导的历史记录相当容易.但是,这是一个特别简单的场景.在Android中有相当数量的历史管理代码,您必须为任意其他情况重写.
你也忘记了:
#5.您将容易泄漏内存,因为您将忘记清理内容,Android将不会清理内容(因为它假定您将使用许多小型活动,他们推荐的方式).
#6.配置更改(轮换,停靠,SIM更改,区域设置更改,多个显示,字体比例)的状态管理将更加复杂,因为现在您还必须弄清楚需要成为州的一部分的额外内容(例如,历史) ,你可以同时处理所有这些问题,而不是一次性处理活动.
#7.为您的应用程序设置多个入口点变得更具挑战性(例如,启动器中的多个图标,应用程序窗口小部件链接到除主要活动之外的某些活动,响应等).
更改当前活动的内容比启动另一个活动更快
对于大多数现代Android设备,速度差异对大多数用户来说并不重要,恕我直言.
如果我们只有一个活动上下文,那么查找和解决内存泄漏问题就更容易了
除了你还有超过"一个活动上下文".请记住:您的活动(无论大小)仍然会在配置更改时被销毁并重新创建.
您如何看待这种模式?
科斯的"公司性质"理论认为,企业扩张,直到内部做事的交易成本高于其他公司做同样事情的交易成本.
墨菲的"活动性质"理论认为,活动扩大,直到内部处事的交易成本高于其他活动做同样事情的交易成本.Android开发人员倾向于用于活动的"用户事务"模型 - 紧密耦合的事物(例如,向导中的步骤)将倾向于在单个活动中处理,以及具有很少关系的事物(例如,浏览与搜索与设置vs.帮助与约会相比,往往会在不同的活动中处理.
| 归档时间: |
|
| 查看次数: |
9493 次 |
| 最近记录: |