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，结构扁平，增加稳定性。

但是这也有不好处，如果业务庞大的话，这样的调度模块就显得臃肿。当然了，另一个方法就是数据处理模块依赖网络模块，而调度模块不再依赖网络模块。这样由扁平成了垂直设计，无论怎么样，只要模块划分差不多，就容易在进行下去了。

模块划分就说明在这里。明天说合理组合部分。