Android 设计随便说说之简单实践（模块划分）
上篇随笔随（Android 设计随便说说）便说了一下什么是设计以及设计的原则，这里举一个简单的例子来进一步的说Android设计。我们以应用商店的设计来举例。
在设计之前，需要把握两部分内容，才能使得设计更加的合理，恰当。
第一部分是应用本身包含的业务都有哪些。应用商店的业务大体上有一下几个：
1 给用户展示apk信息
2 提供用户下载apk
当然了已上还可以继续细分。但是对于我们的例子来说已经足够了。
第二部分本地sdk，也就是手机能够提供哪些接口。对于上面的分析我们需要了解一下API。
第一，界面展示的API能否支持。
第二，网络是否支持socket，
假设我们已经熟悉了应用商店的基本业务和需要的API，现在就开始我们的设计之旅。
在上一篇我提到了两个较为关键着手点。一是模块划分，二是合理组合。
说模块划分之前需要说明的是什么是依赖，什么是接口。
所谓的依赖，就是模块对外界类的调用的方法。所谓的依赖倒置是原来模块对外界的依赖是实现，现在模块对外界的依赖是虚接口。如果外界实体可以实现需实现虚接口，才可以和模块实现依赖。
所谓的接口，就是模块对外界提供的调用的方法。有两种，一种是直接的一个public方法。一种是以接口的形式，告诉外界。
我们先说应用商店的模块划分。
首先需要UI部分，UI的作用是什么？UI的作用有两个，一是给使用者展现信息，二是提供给使用者一个操作的平台。因此UI部分需要数据，而这些数据的来源需要其他模块的支撑，除非是一个helloworld程序。当然了在UI进程中不能做耗时操作，否则出现ANR。因此不允许在UI中网络请求。
例举一个页面RecommendActivity，apk推荐页面。
RecommendActivity（实体类，用户用户操作）对外的接口是
- apk详情查看gotoAppDetailsInfo(id);调用这个方法实现apk详情的展现。
- apk下载请求gotoDownLoadApp(id);调用这个方法实现apk的下载。
和接口类RecommendInterface（Interface，底层数据改变更新到界面）
- onPageViewDataComplate() 页面你数据的回调
- onAppInfoDataComplate() appinfo数据的回调
- onImageComplate(uil)页面图片数据的回调
..............
RecommendActivity依赖是RecommendBase（Interface或虚基类，用于实现类的继承）
- getPageViewData()获取页面的要显示的模板信息。
- getAppInfosData()获取要显示页面的app信息。
- getImages(appid)根据appid获取页面图片信息
- setCommondInterface(RecommendInterface) 设置回调
..............
第二部分，网络请求模块。负责从服务端获取APK数据。
NetTaskManager（实体类）网络任务管理，这一模块的接口类。它依赖于HttpGet，HttpConnect等网络接口实现业务，已经是底层，依赖API即可。那么他提供的接口有哪些。
- downLoadImageByUrl()图片加载接口
- downLoadTemplatesById(id)根据页面编号请求模板
- downLoadAppsByTemplates()根据模板编号请求app数据。
- downLoadAppsInfo(id)根据id获取app详情
................
上面都是正向接口，但是它还需要将请求结果上报，由因为该模块的实现是异步完成的，因此还需要定义一个回调NetTaskResultListener（接口）提供以下接口
- netTaskImageDownLoadCommplate(url),对外回报图片已经下载完成。
- netTaskTemplatesDownLoadCommplate(id),对外回报模板数据已经下载完成
- netTaskAppsDownLoadComplate(id)对外回报app数据已经下载完成。
- netTaskAppsInfoComplate(id)对外回报app详情数据
............
以上笼统的说了一下提供的接口。当然了还有一些细节这里不再计较。
第三部分，数据解析模块，从网络中来的数据流毕竟不能够直接使用，需要一个转换，这个模块就负责这个任务。
举例DataWorkManager（实体类） 负责数据的解析和组装。
它依赖的接口，实际上他需要对数据解析，是json或是xml都是依赖于API，因此它的依赖是API。
它提供的接口如下：
- setData(temp, apps)负责将temp数据和apps数据解析和整合。（看起来好复杂啊，但是一般都是模板和apps数据对应的，所以无法分割出去）
- setIamge(url)当图片下载完成，负责将图片和界面关联。
- setAppInfo(appinfos)负责appinfo数据的解析和模板整合。
......
此外，这些数据的处理要看数据量是否大，耗时是否会长。如果，数据量不大，而且耗时不长，则同步即可，不需要提供回调。
- getViewDataByTempId(); 获取界面上要显示的viewData。
- getIamgeByUrl(url);根据图的url获取图。
- getAppsInfoData(id)根据appid获取app详情页面数据
.......
如果运算量较大，耗时长，则需要异步处理，需要提供一个回调接口。这里不再细说。
第四部分，下载模块，负责应用的下载。有人会问，下载也是从网络中请求数据，为什么不在网络请求模块中。原因是这两个模块功能完全不同，网络请求模块的职责是负责页面数据展示，随着页面的向下滑动，它需要同时不停的请求，如果页面跳转，则需要暂停原来的请求，进行新的请求。不确定性比较大。但是下载模块，职责是负责apk的下载。他需要区分网络是那种网络，而且下载是按照顺序的，除非人为改动。
例举DownLoadAppManager（实体接口类）对于外界的依赖，实际上还是网络接口的API。
对于外界的接口：
- startDownLoad();
- setDownLoadApps(appinfo);
............
此外对外还有一个回调接口类DownLoadListener
- downLaodProgress(id, progress);
.............
第五部分，调度模块，为了上面的四个模块有条不紊的实现业务，需要这个模块进行调度。这个模块是负责用户交互和业务实现的中间模块，对上层，负责接收用户的响应和提供UI界面数据。对下层，负责调度各个业务单元实现整体业务。
以Controller来命名该模块。
它需要提供的接口如下：
- getViewByTemp(id)用户到不同的页面启动不同页面上的数据请求。
- downLoad(id),stopDownload(id).....用户下载的指令接口
- getAppInfo()用户查看app详情界面，启动app详情数据请求。
它还需要提供回调接口如下：
ControllerUIInterface
- onViewComplate(viewData);页面数据组合完毕回调
- onDownloadProgress(id,progress) 下载进度回调
- onAppInfos(viewData) app详情页面数据准备完毕回调
ControllerDownLoadInterface
- downLoadIamgeComplate(url) 图片下载完成回调
- doanloadTemplateComplate(id) 模板下载完成回调
- downloadAppsByTempComplate(id) 模板数据下载完成回调
ControllerDownLoadAppInfo
- downLoadAppStart(id) 开始下载app回调
- downLoadAppProgress(id, progress) app下载中进度回调
它需要依赖的接口ControllerDependInterface（虚类，或接口）。
1 针对网络请求
- downloadImage(url) 添加下载图片
- downloadTemplateById(id) 下载模板
- downloadAppsByTemp(id) 下载模板对应的app信息
2 针对网络请求的数据处理
- setData(temp, apps) 进行模板和app数据组合
- setAppInfo(appinfos) 进行模板和app详情组合
- getViewDataByTempId() 获取组合后的viewData
- getIamgeByUrl(url) 获取图片
- getAppsInfoData(id) 获取组合后的app详情数据
3 针对app下载
- startDownLoad() 开始下载
- setDownLoadApps(appinfo); 添加下载项
我们好好分析一下调度模块，它有二个功能，第一通过调度各个业务单元，从而实现整个业务。接受到界面指令之后，对指令进行拆分，综合结果并且上报。这样做的好处是业务统一处理。第二，它分割UI和各个业务单元紧密关联，通过添加一个层来隔离UI和各个业务，使得UI层和各个业务单元各自为政，互不干系。这样做的好处是业务单元不直接影响UI，结构扁平，增加稳定性。
但是这也有不好处，如果业务庞大的话，这样的调度模块就显得臃肿。当然了，另一个方法就是数据处理模块依赖网络模块，而调度模块不再依赖网络模块。这样由扁平成了垂直设计，无论怎么样，只要模块划分差不多，就容易在进行下去了。
模块划分就说明在这里。明天说合理组合部分。
