android mvc框架原理,Android开发中的设计模式原理是什么？

chubbsondubs..

53

Android的架构一开始让我恼火,但我开始看到一种疯狂的方法.Android文档很难解释它.我最大的抱怨一直是,很难拥有一个集中数据模型,其中包含您的活动共享的对象,就像普通的应用程序一样.Android似乎希望我成为一名游牧民族,因为我只能在我的活动之间分享原语.并且在数据库中丢弃垃圾不是模型,因为它不包含任何行为.因此,大多数人的业务逻辑都在我的活动中结束,这使得很难在其他活动中共享业务逻辑.

我来找出我错过了一些关键的拼图.Android是MVC.但是,它与View相当重要.

活动==控制器

Model ==申请子类

任何继承View == View的东西

有趣的是,你可以创建一个Application的子类并在你的Manifest文件中声明它,Android将创建这个对象的单个实例,无论Activity被销毁或创建什么,它都会占用应用程序的长度.这意味着您可以在那里构建一个所有活动都可以访问的集中数据模型.

我看到这种方式就像一个原始的Spring容器,你可以初始化对象并解决它们之间的依赖关系.这样,您可以将应用程序的模型部分与活动本身分开.只需让Activity对模型进行调用,然后手动回调即可接收结果,以便更新UI.

Android的问题在于它混合了控制器和视图.例如,像TabActivity,ListActivity这样的子类意味着使用了某个视图.因此,交换视图非常复杂.即使您使用Activity,Controller也会对视图的内容做出非常具体的假设.他包含对TextView等UI对象的直接引用.它还注册了低级事件,如点击,键盘等.

如果活动可以注册更多高级别的活动,例如"登录","更新帐户余额"等,视图会响应一系列点击,键盘,触摸事件而调度,这样会更好.这样,控制器就可以在您可能描述的功能级别而不是设计功能上工作.

我认为我们最终会达到这种类型的设计,因为我们更好地理解了更好的工具和技术.似乎Android可能具有实现这一目标的可扩展性,但是由社区来制定它.

模型对活动"本地"的想法是UI设计的副产品.如果通过添加功能或改进设计进行更改,您可以非常轻松地在视图之间共享数据.因此,将诸如付款和发票之类的数据模型绑定到活动并不是一种灵活的设计方式,因为它会将您锁定在UI设计中.那么如何将这些内容分开,以便您可以更轻松地修改UI而无需重写大量管道？使用模型,控制器和视图之间的适当分离,这是使用应用程序的子类可以帮助您做到这一点. (2认同)