Android MVP架构中的Presentation层应该怎么设计_android开发_ThinkSAAS
Android MVP架构中的Presentation层应该怎么设计
Android MVP架构中的Presentation层应该怎么设计
本文作者发现，当人们从遗留代码库迁移到MVP架构时，会面临部分代码不知道放到Presentation层还是UI层的问题，甚至作者之前的项目还有人评论说：他不知道某段代码是否属于业务代码。如果连这都不能分清的话，今后在分离代码职责的时候一定会犯错误。本文介绍作者对Presentation层的设计，来理清这些问题。
Android view vs View vs 界面
先区分一下Android View、View、界面的区别
Android View： 只是继承android.view.View的Android组件。
View：接口，用于由presenter向View实现类通信，你可以在Android组件中实现它。有时最好直接使用Activity，Fragment或自定义View。
界面：界面是面向用户的概念。比如要在手机上进行界面间切换时，我们在代码中可以通过多种方式实现，如Activity到Activity或一个Activity内部的Fragment/View进行切换。所以这个概念基于用户的视觉，包括了所有View中能看到的东西。
界面间的切换可以是两个Fragment、两个Activity、打开对话框、启动新Activity等等。当然切换的具体实现原理不属于这篇文章的内容，而进行切换操作则是Presentation层的职责。Presenter应该知道要做什么，而它的实现类要知道怎么完成。在这个例子中，要做的就是切换界面，完成方式就是启动新的Activity。
但这样会有一个问题。Presentation层是纯java代码，所以Presenter中不应该有任何与安卓相关的代码。那怎么完成界面的切换呢？通过抽象。这里可以写一个只有一个navigate()方法的接口NavigationCommand。在需要时我们在Presenter中调用这个接口的navigate()方法，然后在Activity中实现这个接口。假设要从Activity A切到Activity B，那么流程如下：
代码长这样：
ActivityA.java
public class ActivityA extends Activity {
@OnClick(R.id.someButton)
public void onSomeButtonClicked() {
presenter.onSomeButtonClicked();
ToActivityB.java
public class ToActivityB implements NavigationCommand {
private final Activity currentA
public ToActivityB(Activity activity) {
currentActivity =
public void navigate() {
currentActivity.startActivity();
Presentation层
NavigationCommand.interface
public interface NavigationCommand {
public void navigate();
PresenterA.java
public class PresenterA {
private final NavigationCommand toBN
public PresenterA(NavigationCommand toBNavigation) {
this.toBNavigation = toBN
public void onSomeButtonClicked() {
toBNavigation.navigate();
这样我们就可以将VP两层解耦。这里将切换到一个Activity的代码提取出来，可以复用，我们可以通过注入NavigationCommand方法来测试Presenter，而且就算要跳转的页面变了，Presenter的代码也不变。这也符合Open Close原则。
另一个问题就是当一个Presenter中出现多个NavigationCommand时，构造方法就开始变得诡异了。
public class PresenterA {
private final NavigationCommand toBN
private final NavigationCommand toCN
public PresenterA(NavigationCommand toBNavigation, NavigationCommand toCNavigation) {
this.toBNavigation = toBN
this.toCNavigation = toCN
在这里初始化Presenter的类很难搞清楚两个NavigationCommand之间的顺序，似乎只能通过名字来辨识，这里其实可以再写一个接口继承NavigationCommand来专门管理一类特定的切换，或者如果你使用依赖注入框架的话也可以指定参数的类型。
有时需要在切换界面时传递一些参数，这时就要改动一下NavigationCommand的代码：
public interface ToScreenBNavigationCommand extends NavigationCommand {
void setMyParameterToNavigate(String parameter);
这样只需要在Presenter中在调用navigate()方法之前调用设置参数的方法就行了。
这个idea归功于Pedro的项目EffectiveAndroidUI（）
一个界面中有多个View
Android中一个View可能由不同的组件实现，但这不影响Presenter。那一个界面中可以有多个View吗？当然可以！那如何在一个Activity中写多个View/Presenter呢？下面以Browse Spotify界面为例分析。
这个界面里有一个横向的滚动条显示不同的歌单，然后是一个有多重选项的菜单，在底部有一个正在播放的歌曲。当然每个人看一个界面会有不同的理解，但这不是关键，所以我们来考虑如何按上述三个组件分开View和Presenter。
黄色是歌单，红色是菜单，蓝色是正在播放。
不过为什么要分开呢？分开写View/Presenter与合在一起写一个有所有操作的Presenter有多大区别呢？这时要考虑到谁负责填充这些View，以及如何复用组件。这三个组件是完全不同的组件，有不同的功能、操作与逻辑代码，它们都会在其他界面被用到。
所以一个界面可以有多个View/Presenter，因为一个界面可能包括了许多组件而且可能负责许多操作，这个是设计师的事。要记住每一项责任就是一个潜在的发生改变的原因，而上述这三个View都很可能发生改变。
一个View可以有2个实现类吗？
当然！对同一个Presenter的View可以有多个实现类。再以Spotify举例，刚才的界面的下方有一个正在播放的栏，当你点击时出现下面这个界面：
是不是只是换了一种展示的方式呢？所以或许我们可以继续使用同样的Presenter并在另一个Android组件中实现View接口。不过这个界面似乎有更多的功能，那要不要把这些新功能加进这个Presenter呢？这个视情况而定，有多种方案：一是将Presenter整合负责不同操作，二是写两个Presenter分别负责操作和展示，三是写一个Presenter包含所有操作（在两个View相似时）。记住没有完美的解决方案，编程的过程就是让步的过程。
总结一下前面的内容：
一个View使用一个Presenter
一个界面可以有多个View/Presenter
一个View可以被多次实现以使用同一个Presenter
一个Android组件可以实现一个View。如果要同时实现两个View接口，或许这两个View最好一起来展示一个组件，或是你应该将View的实现分割，分别对应两个View接口。
下面来看一下其他的概念。
Presenter生命周期
下面这张截图来自Citymapper，当你点击“带我去那”按钮的时候就会打开一个让你选择开始结束位置的界面。
如何分解这个界面呢？我首先想到的事情就是：如果没有结束位置，那起始位置还有意义吗？应该没有。所以我可以写一个Presenter "PickLocation"来监听开始和结束位置是否填写。而后写一个Activity包含两个Fragment能在ViewPager中切换，这就组成了View层。两个Fragment都可以调用同一个Presenter的startLocationChanged()和endLocationChanged()方法。
如果此时设计改了，不再是两个tab了，而是一个分为两步的表单。这是需要将选择开始位置的Fragment替换为选择结束位置的Fragment。View层的代码改变了，但Presenter不变。设计可以千变万化，再比如分屏显示两个地图，但都不会改变Presenter的代码。
那么Presenter的生命周期如何呢？这取决于与Presenter对应的组件。
我们先看一下Selltag应用，这是一个二手交易应用。下面是旧版应用创建商品的截图：
这就是一个三步表单。除了西班牙词汇外还都挺清晰地。"Siguiente"是"下一步","Publicar"是“发布”。
在第一步中，先给商品添加一些图片。第二步中要填写标题、描述和价格。最后点击发布按钮，商品就进入交易市场了。
在我给这个表单建立的模型中只有一个Presenter：“PublishProductPresenter”。这个Presenter代表了整个“发布商品”的概念。而这个表单在平板上该如何显示呢？或许这三步可以整合在一个界面中，毕竟屏幕变大了。但不要看到界面变了就改架构，这里只是View层变了，因为Presentation层只需要处理用户事件，代码不变。
这里有一个问题是如果只用一个Presenter的话，在不同的界面间如何传递数据呢？是在后面界面的Presenter保留前面界面Presenter的引用吗？还是创建一个Presenter让三个Activity共享？这样出了bug很难调试啊。这里也可以将这三个界面写成Fragment放在一个Activity里。
Presenter状态
当屏幕方向改变的时候，Activity和Presenter都会被销毁，所以要不要给Presenter设置状态呢？其实添加Presenter状态还不如修改一下Model层的代码。为什么这么讲，请看这个例子：
这是F-Droid的Android版，一个只包含开源项目的开源市场。当Available栏目刷新时会发起一次网络请求。假如这时屏幕旋转，并且Presenter是没有状态的话，List就会被重新加载。如何解决这个问题呢？其实不难，可以把上次的response缓存进内存或disk中，并指定一个ttl(time to live有效期)。但不要将从网络获取的内容存进Presenter里，因为如果要重建Presenter的话，就需要重新发送一遍请求。综上，我不喜欢给我的Presenter添加状态。
回调地狱Callback Hell
Callback Hell是人们谈论Presentation层时经常讨论的问题。许多有关回调地狱的问题都是因为Presenter的任务太重。不要把Model层的任务放在Presenter里，Presentation层只应该调用Model层的方法，由Model层完成诸如同步等操作。在使用RxJava或Jdeferred等第三方库之前请思考是真的需要还是只是必须通过这些库把整个系统粘在一起。
为了描述上述问题我造了一个例子：想象一个系统，只在服务端返回true时加载并展示一个产品组成的列表。下面第一个图所展示的流程主要在错在两个地方：第一是Presenter不应该知道服务端返回的flag，这个是Model层的事。第二是presentation层因为要负责各种同步之类的事情导致代码变多。
改进之后的流程图：
这样一来两个问题就解决了，而且如果未来不再需要flag了就只需要修改action就行了。
设计Presentation层的架构很简单，但你需要知道什么代码归Presenter什么归Model。当你有一个巨型Presenter时，想想真的是界面需要响应的事件太多，还是你的Presenter干了Model的事。
关于阿里百川
阿里百川（)是阿里巴巴集团“云”+“端”的核心战略是阿里巴巴集团无线开放平台，基于世界级的后端服务和成熟的商业组件，通过“技术、商业及大数据”的开放，为移动创业者提供可快速搭建App、商业化APP并提升用户体验的解决方案；同时提供多元化的创业服务-物理空间、孵化运营、创业投资等，为移动创业者提供全面保障。内容来源：
PHP开发框架
开发工具/编程工具
服务器环境
ThinkSAAS商业授权：
ThinkSAAS为用户提供有偿个性定制开发服务
ThinkSAAS将为商业授权用户提供二次开发指导和技术支持
让ThinkSAAS更好，把建议拿来。
开发客服微信浅谈MVP架构及开发模式
浅谈MVP架构及开发模式
Model-View-Presenter(MVP)概述&&& MVC模式已经出现了几十年了，在GUI领域已经得到了广泛的应用，由于微软ASP.NET MVC Framework的出现，致使MVC一度成为.NET社区的热名话题。作为MVC的变种MVP模式，也已经出现好几年了，在微软模式与实践小组提供的Web Client Software Factory中，给出了实现MVP模式的应用程序最佳实践，本文将试着对这两种实现比较一二。MVC（Model-View-Controller，模型-视图-控制器）模式是80年代Smalltalk-80出现的一种软件设计模式，后来得到了广泛的应用，其主要目的在于促进应用中模型，视图，控制器间的关注的清晰分离。MVP（Model-View-Presenter，模型-视图-表示器）模式则是由IBM开发出来的一个针对C++和Java的编程模型，大概出现于2000年，是MVC模式的一个变种，主要用来隔离UI、UI逻辑和业务逻辑、数据。在下面的文字中，如无特别说明，MVC均指ASP.NET MVC Framework。
Model-View-Presenter(MVP)优缺点&&& 针对ASP.NET MVP Sample实例，在这个实例中MVP模式采用了Castle框架和底层数据映射NHibernate框架，在开发过程中要注意NHibernate的版本的不同，有的支持sql server 2000,有的支持sql server 2005数据库。IHttpModule接口的实现。其实在使用Castle框架时，IContainerAccessor接口已经封装了IoC模式。还有泛型编程。事务回滚操作。在编程过程中，你可以保留它现有的模式，也可以增加或改变其模式。&&& Model-view-presenter旨在应用程序分层和提高测试效率，它的主要目标是将显示逻辑与业务逻辑分离，正如我们设计面向对象程序中创建松散耦合并可重用的对象。&&& MVP的另一个目标是提高针对View的测试效率。编写依赖Session, ViewState, AJAX, HTML或web控件和业务实体的单元测试类较为复杂，因此我们将各视图的显示逻辑保留在ASPX/ASCX文件类中，并将业务逻辑从中分离出来放在相应的类中，在MVP中Presenter充当视图和业务逻辑的缓冲层。
MVP与MVC的区别&&& MVP——Model-View-Presenter 它是MVC模式的变种。UI是容易变化的，且是多样的，一样的数据会有N种显示方式；业务逻辑也是比较容易变化的。为了使得Application具有较大的弹性，我们期望将UI、逻辑（UI的逻辑和业务逻辑）和数据隔离开来，而MVP是一个很好的选择。&&& Presenter代替了Controller，它比Controller担当更多的任务，也更加复杂。Presenter处理事件，执行相应的逻辑，这些逻辑映射到Model的Command以操作Model。那些处理UI如何工作的代码基本上都位于Presenter。Presenter如同一个乐队的指挥家，表现和协调整个Application，它负责创建和协调其它对象。&&& Model和View使用Observer模式进行沟通；而Presenter和View则使用Mediator模式进行通信；Presenter操作Model则使用Command模式来进行。基本设计和MVC相同：Model存储数据，View表示Model的表现，Presenter协调两者之间的通信。在 MVP 中 View 接收到事件，然后会将它们传递到 Presenter, 如何具体处理这些事件，将由 Presenter 来完成。
图1：Model-View-Controller
图2：Model-View-Presenter处理流程方面，在MVC中，用户的请求首先会到达Controller,有Controller从Model获取数据，选择合适的View,把处理结果呈现到View上；在MVP中，用户的请求首先会到达View,View传递请求到特定的Presenter,Presenter从Model获取数据后，再把处理结果通过接口传递到View。使用MVP后，我们可以提高对Model和Presenter的复用，比如可以对Model和Presenter不做修改，而能提供ASP.NET Web Form和 Windows Form。在ASP.NET MVC Framework中，采用行内代码进行数据呈现，逻辑集中在Controller中，但是View无法完全交给UI设计人员完成。在MVP模式中，所有的业务逻辑交给Presenter去处理，这样View中代码就变得及其简洁，将可以轻易的把开发人员和UI设计人员分开，如下图所示：
MVP实例讲解& 下面看一个简单的例子：& 该方式将创建Presenter,传递View和model，调用“InitView”方法的功能交给ASCX用户控件（View）处理。View应用相应的Presenter，Presenter只知道View的接口。ASPX页只用于添加用户控件，因此只需要将用户控件拖拽到页面上可以很容易的重用。
public&class&Presenter{&&&&public&Presenter(IView&view,&IModel&model)&&&& {&&&&&&&&&&&&&&&&this.view&=&&&&&&&&&this.model&=&&&&&}&&&&public&void&InitView(bool&isPostBack)&&&& {&&&&&&&&if(!isPostBack)&&&&&&&& {&&&&&&&&&&&&view.SetProducts(model.GetProducts());&&&&&&&&}&&&&}&&&&&&&&public&void&SaveProducts(IList&IProduct&&products)&&&& {&&&&&&&&model.SaveProducts(products);&&&&}}
//页面或用户控件CS代码protected&override&void&OnInit(EventArgs&e){&&&&base.OnInit(e);&&&&presenter&=&new&Presenter(this,model);&&&&presenter.InitView(Page.IsPostBack);}public&void&SetProducts(IList&IProduct&&products){&&&&//bind&products&to&view}//视图接口public&interface&IView{&&&&void&SetProducts(IList&IProduct&&products);}
通过上面的代码就可以了解到MVP的结构是什么样的，可根据这种模式来开发你的项目。当然你也可以从codeplex网站上下载一个Demo，进一步理解。希望这篇文章能对大家有用。
企业级MVP架构的应用& 在企业级ASP.NET应用中使用MVP 1、使用用户控件封装Views：这个主题讨论用户控件作为MVP中的View。2、MVP的事件处理：这个主题讨论连同页面验证传递事件到Presenter，IsPostBack和将消息传递到View。3、MVP和PageMethods的页面重定向：这个主题讨论使用用户控件作为View，如何使用PageMethods处理页面重定向。4、MVP的Presentation安全控制：这个主题讨论如何根据基本的安全限制显示/掩藏View中的区段。5、使用MVP的应用的架构（高级）：这是个重点，这个主题展示一个使用Nhibernate作为数据访问层的MVP应用。
&Codeplex网站上的那个例子，含概的内容不少，大家可以下载下来分析。
MVP工作感言&&& 这次写这篇文章，主要是解读MVP框架，针对微软MVP的一个例子讲解所涉及到的一些应用模式。最近公司项目采用了MVP架构来开发，对我来说有颇多收获和感慨。对于MVP模式来开发，应当算是新的架构，因为之前只知道微软MVP(Microsoft Most Valuable Professional)，并不知道MVP(Model-View-Presenter)。自从来到博客园里不断学习，不断借鉴，丰富了自己的知识。在此要感谢drummery和ξ箫音ξ两位老师的文章，同时也借鉴了UML软件工程组织网站的文章。MVP模式开发项目，我想未来几年将会越来越被许多人使用开发项目。在这里的MVP，我想同样应该实用于开发Windows软件项目。这篇文章写的比较仓促，难免有误之处，同时我也在不断的挖掘MVP的更深层次的应用。在这里这是我个人的理解，希望高人点评指点，若您有其他的理解，可以与我共同探讨。希望大家一起学习，共同进步。
发表评论：
TA的最新馆藏[转]&[转]&[转]&[转]&[转]&[转]&更多公众号：gh_fd安卓开发干货分享最新文章相关推荐搜狗：感谢您阅读如何设计MVP中的Presentation层，本文可能来自网络，如果侵犯了您的相关权益，请联系管理员。QQ:Android上的MVP：如何组织显示层的内容 - 文章 - 伯乐在线
& Android上的MVP：如何组织显示层的内容
MVP（Model View Presenter）模式是著名的MVC（Model View Controller）模式的一个演化版本，目前它在Android应用开发中越来越重要了，大家也都在讨论关于MVP的理论，只是结构化的资料非常少。这就是我写这篇博客的原因，我想鼓励大家多参与讨论，然后把MVP模式运用在项目开发中。
什么是MVP？
MVP模式可以分离显示层和逻辑层，所以功能接口如何工作与功能的展示可以实现分离，MVP模式理想化地可以实现同一份逻辑代码搭配不同的显示界面。首先要澄清就是MVP不是一个结构化的模式，它只是负责显示层而已，任何时候都可以在自己的项目结构中使用MVP模式。
为什么要使用MVP？
我们知道在Android上逻辑接口和数据存取是紧耦合的，这个问题可以看看CursorAdapter这个例子，它既融合了适配器，同时也有显示的成分，而cursor很大程度上应该是数据数据存取层的。
对于一个可扩展、稳定的应用来说，我们需要定义各个分离层，毕竟，我们不知道以后还要加入什么逻辑，是从本地数据库检索数据？还是从远程的web Service中？
MVP模式可以让显示界面和数据分离，我们开发的应用可以分离至少三层，这样也可以进行独立测试。有了MVP我们就可以从Activity中分离大部分代码，而且不用单元测试可以对每个模块进行单独测试了。
怎么在Android上实现MVP？
说到这里，问题就有点复杂了。实现MVP的方式有很多种，每个人都可以根据自己的需求和自己喜欢的方式去修正MVP的实现方式，它可以随着Presenter的复杂程度变化。
在View中需不需要控制进度条？或者是在Presenter处理？还有，谁来决定Action Bar该显示什么操作？这是一个艰难的决定。这里我会展示我自己的做法，但是我希望本文成为一个讨论如何应用MVP的地方，因为目前为止还没有实现MVP的标准方式。
Presenter主要作为沟通View和Model的桥梁，它从Model层检索数据后，返回给View层，但是不想典型的MVC结构，因为它也可以决定与View层的交互操作。
View通常来说是由Activity实现的（也许是Fragment，VIew，取决于app的整体结构），它会包含一个Presenter的引用，最理想的是Presenter由一个依赖注入管理器提供，比如，不过如果不用注入器的话，就需要独立创建Presenter对象了。View要做的就只是在每次有接口调用的时候（比如按钮点击后）调用Presenter的方法。
对于一个结构化的APP来说，Model主要是通向主领域层或者逻辑层的通道，如果使用了的话，Model就可能是一个实现了用例场景的交互工具，这也是我将要在另一篇文章中讨论的一个主题。现在，只要把它看做是给View提供数据的容器就对了。
鉴于已经解释的太长了，本人写了一个例子，由一个登录界面组成，可以验证数据然后进入一个带有列表的主界面，数据来自Model，因为比较简单，所以本文就不讲代码了，但是如果读者觉得还是很难理解的话，我还可以再写一篇文章详细介绍。
在Android上要分离接口和逻辑不容易实现，但是Model-View-Presenter模式可以更简单的防止在Activity中掺杂太多代码在大的项目中，组织好代码结构是最基本的要求，不然，代码的稳定和扩展就很困难了。
关于作者：
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2016 伯乐在线Android 加强版（9）
本问出自：
MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。
MVC和MVP的区别？
作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter
(MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会直接从Model中读取数据而不是通过 Controller。
在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，即View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
二丶白话慨述
view（客户），presenter（产品狗），model（程序猿）。
有一天，客户找到了产品狗说：“我要开发一个像微信一样的App”
然后，产品狗原封不动地转达了给程序猿，程序猿默默地说了一句：“傻X，有病”。
当然产品狗也不会这么傻，它当然要在客户面前夸他，于是在电话里头说：“我们的工作人员，对此表示有挑战性，但是他们很乐意。”
于是新需求就来了，最终苦逼的还是程序猿。
终于，程序猿受不了了，辞职了，但是又来了一批新的，需求还是需求，并不会因为人不同了，就推掉这单生意（重构项目）。
view（客户），contorler（产品狗），model（程序猿）
有一天，客户找到了产品狗和程序猿说：“我要开发一个像微信一样的App”&
程序猿默默地说了一句：“傻X，有病”。&
嗯，打起来了，项目没了。
通过这么深刻的故事，我们看到了MVP的优点
1.view和model相互不认识（解耦），并不会因为model不一样了，而影响了view，反过来也一样。那么model什么时候会变呢？例如，老子原来用的是Volley网络框架，但是我现在要换成OKhttp。没关系，我只需改动model即可。
2.model是面向接口文档编程的，view是面向设计图编程的，而presenter是负责协调的，这样就可以并行开发了。
3.测试，因为是view和model不认识（解耦），那么就可以单独地对model进行测试，验证它的准确性。做好了view，真机调试，又可以发朋友圈了。最后用presenter连起来，如果测试得好，Bug也会少很多。
4.做不好不用背锅，还可以多踩一脚（O(∩_∩)O~）。我做model的，数据给你了，你显示那么丑......这是一个后台跟App的故事。
5.presenter（产品狗），可以同时面对多个view（客户），做更多的事情（累死更多的程序猿）。
1.presenter负责逻辑，代码会多。（产品狗确实挺累的）
2.写得很累，明明view跟model可以直接相连，非要跟presenter联系，可能在传递时出现Bug。（明明程序猿可以跟客户面对面沟通，但是经过了产品狗，回来的需求就不一样了）
三丶小案例参考
MVP开发攻略套路
model开发一条龙
这是我开发的套路，希望你们喜欢。正常情况下，3天就能完成所有的接口文档对应的model。而在做model的时候，面对的是接口文档，没有比这个东西更接近需求了，因此，你做完之后会更加明白这个项目。
用Rxjava+Retrofit是什么体验
直接生成Bean对象
view开发一条龙
简单但是暴力。我还有隆重地为大家推荐几款插件。
1.SelectorChapek for Android（自动生成Selector的XML文件），再也不要考虑那些乱七八糟的press，focus，normal
2.jimu Mirror（不需要写代码，就能在真机显示布局，包括列表），神器！加快了朕发朋友圈的速度。
3.butterknife（依赖注入库，自动注解布局中带@+id的控件），用完就更model的同学说，真慢！
4.Android studio自带的Get，Set生成器。
presenter层
根据model的所需参数创建外部调用接口（presenter的方法接口）
实现Sept1中的接口和model层提供的回调接口
根据业务逻辑，调用view层提供的方法。
四丶大神文章
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：41712次
积分：1411
积分：1411
排名：千里之外
原创：95篇
评论：24条
文章：13篇
阅读：2868
文章：43篇
阅读：9569
(12)(5)(8)(2)(15)(5)(21)(24)(6)