QDaily - Android MVP改造

演进式框架设计。使得工程未来更有设计感和易于维护。
上个月事情多,周末好多时间都周转于河北天津,而且有点懈怠,以后博客继续更新。

整个改造思路来源于google的Android Architecture Blueprints,google这个框架名字就非常霸气,Android架构蓝图,有了这个做参考,给了架构设计一个非常指导性的建议。

比较MVC和MVP。 MVP到底是什么

MVC来源于J2EE(web开发)的一个概念,Model就是一个数据实体,controller在逻辑处理完成后,通知View该更新了,view取model的最新值进行更新。MVC三个对象互相持有依赖。

主要来源于微软的软件开发(MPF客户端开发)概念。MVP中的M其实是model层的意思,例如我们的getlist、xxxDao类,是一个获取数据的user case。MVC中的model其实属于Presenter的一部分。


一般需要定义的结构。MVP之间的所有依赖都是基于interface。

说下当前的问题

  • 举两个例子

    InformationFlowFragment
    LauncherActivity
    
  • 最大问题:上帝类

优劣(改造目标)

可测试(TDD)

可维护(代码复用)

容易Review

信息隐蔽

冗余的,尤其是小型App开发

(有可能)额外的学习曲线

开始编写代码之前需要时间成本

改造的要求

初级目标:VP分离,M可以适当延后。

  • 层级结构

  • Activity用于装配各个MVP组件

可见实现,只有装配功能,没有任何具体的业务实现和UI实现。

  • Presenter用于实现逻辑。
    禁止持有任何Context、Application、View、Dialog的UI层信息。与UI渲染所有的联系都来源于view层的抽象。

头文件、成员变量都不能有UI和Android组件。

  • View层用于展示
    头文件不能有任何逻辑的、网络请求的引用。基本都是UI层和Android组件

成员变量不能有model数据。

关于Model层:

  • QDaily在网络层(请求,CGI,缓存,prefetcher,download)基本稳定,上层还需要一些小的封装。在现有设计风格上,改造有限。

  • 在本地存储方面(sql、xml),因为比较轻,也没有太多值得进行调整和优化的。

  • 图片相关的下载和缓存,完全基于glide,在不修改第三方组件的情况下,能做的有限。

Model层调整主要在接口封装上。核心还是表现层架构的架构。

参考

参考:Android Architecture Blueprints

比较MVC和MVP。 MVP到底是什么

MVC来源于J2EE(web开发)的一个概念,Model就是一个数据实体,controller在逻辑处理完成后,通知View该更新了,view取model的最新值进行更新。MVC三个对象互相持有依赖。

主要来源于微软的软件开发(MPF客户端开发)概念。MVP中的M其实是model层的意思,例如我们的getlist、xxxDao类,是一个获取数据的user case。MVC中的model其实属于Presenter的一部分。


一般需要定义的结构。MVP之间的所有依赖都是基于interface。

说下当前的问题

  • 举两个例子

    InformationFlowFragment
    LauncherActivity
    
  • 最大问题:上帝类

优劣(改造目标)

可测试(TDD)

可维护(代码复用)

容易Review

信息隐蔽

冗余的,尤其是小型App开发

(有可能)额外的学习曲线

开始编写代码之前需要时间成本

改造的要求

初级目标:VP分离,M可以适当延后。

  • 层级结构

  • Activity用于装配各个MVP组件

可见实现,只有装配功能,没有任何具体的业务实现和UI实现。

  • Presenter用于实现逻辑。
    禁止持有任何Context、Application、View、Dialog的UI层信息。与UI渲染所有的联系都来源于view层的抽象。

头文件、成员变量都不能有UI和Android组件。

  • View层用于展示
    头文件不能有任何逻辑的、网络请求的引用。基本都是UI层和Android组件

成员变量不能有model数据。

关于Model层:

  • QDaily在网络层(请求,CGI,缓存,prefetcher,download)基本稳定,上层还需要一些小的封装。在现有设计风格上,改造有限。

  • 在本地存储方面(sql、xml),因为比较轻,也没有太多值得进行调整和优化的。

  • 图片相关的下载和缓存,完全基于glide,在不修改第三方组件的情况下,能做的有限。

Model层调整主要在接口封装上。核心还是表现层架构的架构。

参考

参考:Android Architecture Blueprints

这对于一直困惑于到底该用何种架构的Android开发者来说是好事,开发者只要根据自己项目的情况,在不同的实现中进行选择(app规模、团队状况、维护工作量的大小、平板是否支持、代码简洁程度偏好等等,这些都会影响你的选择),重点是代码结构,整体架构、可测试性和可维护性。

理想状况

真实案例