ano*_*nim 7 android design-patterns
我不是Android专家,虽然我开发了一个包含50多个活动的应用程序,这使得应用程序非常庞大.经过8周的开发,现在存在导致应用程序难以维护和升级的问题.我正在处理的主要是
我无法将对象引用传递给活动的构造函数.事实上,我发现了startActivityForResult- 的机制Intent- onActivityResult真正限制并导致每个活动的动作的许多常量的脏代码,并且很多switch case这很难跟随应用程序的流程.
另一个问题是我不知道如何管理整个应用程序的生命周期,因为每个活动都有自己的生命周期.
我有一些LWUIT和J2ME的成功经验- 抛光忽略了J2ME MIDlets(类似于android活动)并实现了他们自己的架构和窗口系统,只有一个MIDlet作为应用程序的入口.我为android提出了同样的想法.
为了澄清,我正在考虑一个应用程序只有一个主要Activity和其他活动实现为扩展View对象的对象,这些视图可以动态添加到主活动FrameLayout和堆叠在一起.活动的逻辑可以在这些类中实现,我甚至找到了以这种方式实现对话框的方法.业务和状态对象可以传递给它们的构造函数,听起来很好,忽略了编写更多代码的副作用.这种方式也可以将侦听器传递给视图的构造函数,从而使应用程序UI切换和流程管理更加容易.
但问题是:
我也知道
这些都没有明确地用合理的证据或文件参考来解决有关表现或实践的问题
请有人帮我这个
市场上有流行的应用只有一个或几个活动.他们使用片段并切换它们.我更喜欢你的方法片段.虽然我认为片段对于许多目的而言过于复杂,但对于您的用例来说,这将是一个很好的解决方案.您的UI行为应该是片段,您的活动是控制器部分在片段之间传输数据.碎片也有自己的生命周期.
我也不喜欢startActivityForResult.如果我有一组活动 - 都提供数据 - 我不知道它们将被调用的顺序,我更喜欢使用单例类,然后使用意图在活动之间进行数据传输.但是你必须分析你的问题以获得一个好的解决方案.
| 归档时间: |
|
| 查看次数: |
8123 次 |
| 最近记录: |