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

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

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

上一篇:mysql数据恢复 insert\update\delete 工具MyFlash


下一篇:【斜率DP】BZOJ 3675:[Apio2014]序列分割