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，結構扁平，增加穩定性。

      但是這也有不好處，如果業務龐大的話，這樣的調度模組就顯得臃腫。當然了，另一個方法就是資料處理模組依賴網路模組，而調度模組不再依賴網路模組。這樣由扁平成了垂直設計，無論怎麼樣，只要模組劃分差不多，就容易在進行下去了。

模組劃分就說明在這裡。明天說合理組合部分。

Android 設計隨便說說之簡單實踐（模組劃分）