一款基於Kotlin+MVP+元件化的麻雀App

Cysion1989發表於2019-01-08

為什麼叫麻雀

麻雀雖小,五臟俱全。

其實本app並不叫做麻雀,只是本人認為它比較符合麻雀的特點:小而全。

小,即輕量級,一是指app只專注於實現常見app基礎的邏輯業務功能,並沒有在某個功能點或者UI上做更為細節的實現;二是指app使用了簡潔的的Kotlin語言作為實現語言,使用了相對簡單的一種MVP實現方式,使用了一種比較輕量級的元件化方案。

全,當然是相對的,一是指app的後端也是本人開發,這能讓整個業務邏輯更為全面,也能讓感興趣讀者能更為全面的瞭解此app;二是指app涉及了當前技術趨勢下安卓開發的多個技術點,包括kotlin,mvp,元件化,rxjava,retrofit等;三是指本app實際上可以作為一個快速開發框架,這主要得益於元件化的實現,具體怎麼使用,後續會提到。

此app名字不叫麻雀,而是叫做KtDevBox。

倉庫地址:

App實現-KtDevBox

後端實現-KtDevBox-backend

為什麼要寫這個app

誠然,網上關於Kotlin,MVP,元件化的研究、分享已經有很多,但是多數部落格僅僅是泛泛而談,程式碼庫沒有提供不說,部落格中的程式碼甚至都有問題,有些更是抄來抄去。雖然有些好資源的確有挺好的借鑑意義,比如KotlinMvpReading等【本文僅著眼於專案級別實現,一些好的library並不在此討論中】,但以下幾點還是讓我覺得有些不足:

  • 這些專案的介面,基本都是爬來的,大多數都是get方式實現,很難形成比較完整的一個功能邏輯,也很難從更全的角度去來展示某些技術點的實現;
  • Kotlin的使用,Java的味道較重,特別是網路請求的封裝部分;
  • 元件化幾乎沒有涉及,專案是個app,並不能方便的轉為另一專案的實現框架;
  • 文件等介紹略少

KtDevBox當然也存在的一些不足,但該專案的初衷,也僅做學習交流之用,以期對該方面技術的發展,起到一點點幫助。

為什麼用Kotlin

僅說自己體會,至少有這幾個原因吧:

  • 語言切換,對老手真不是問題,況且kotlin與java的相容性很好,所以學習成本不應作為不使用kotlin的理由;
  • 真正擺脫了控制元件從佈局到使用的查詢問題,簡潔明瞭;
  • 函式地位的提升,帶來的程式設計思想的改變,對開發者開發思維是有提升的,當然,程式碼的靈活、更好的擴充套件是可視的效果;
  • 閉包、擴充套件函式、命名引數等語法糖帶來的諸多便利。

為什麼用MVP

有關MVP的討論真是太多了,不過正如本人之前的部落格提到,MVX不管怎麼叫,核心在於分層,至於是C、P或是VM,要看專案自身情況來,甚至可以在同一專案中出現。本專案使用的是MVP的一種簡化些的實現方式,至於好不好用,仁者見仁,這裡只談使用,不談優劣,手動滑稽。再簡略叨叨下MVP的發展吧,以表原因。

  • MVC中C重,於是功能轉移,出現來了xxModel、xxLogic黨,主要分擔資料獲取的職責;
  • C和xxModel的強依賴、空指標問題和記憶體洩露問題,促進了Presenter的出現,其主要處理業務邏輯,並繫結View的生命週期,面向介面,更為鬆耦合;此時C轉為P。
  • 完全面向介面之後,難以避免的V和P介面爆炸,也過於分散,出現了Contract,人工約束,首見於github上谷歌的MVP官方示例。

個人認為,M結構相對很穩定,View並無太大必要通過持有P的介面引用去使用P,再者通過Contract的維護並不能真正降低介面太多造成的注意力分散問題。本專案app的MVP實現較為簡單些,也是一種比較常見的方式,具體可閱讀專案程式碼。

為什麼用元件化

元件化是近兩年才較為突出的一種專案管理實現方案,本人認為其符合基本的分而治之的思想,是同MVX一樣,應該出現在任何一個打算長期維護的專案中的技術方案。其實,不僅在安卓端,在ios端、前端(Vue)、後端(Java、Python)都有元件化的使用。至於什麼是元件化,元件化有什麼好處以及如何實現,我想網上有太多優秀部落格和開源庫提及,這裡就不再贅述。

本app雖然小,但也涉及了元件化,選擇的是一種很輕量級、侵入性小的方案–Appjoint,方案雖然輕量級,但是本人認為:元件化思維,入侵性小、能在最初的時候將業務進行元件化管理是元件化的核心,而這個庫很好的符合了要求。

主要功能點

  • 使用者註冊、登入以及資料管理功能;
  • 部落格建立、更新、刪除和檢視等功能;
  • 部落格的收藏、評論、點贊功能;
  • 爬了網易新聞和一些電臺的介面以展示,主要做元件化演示。

專案架構

專案核心架構如圖所示:

在這裡插入圖片描述

專案中的shell只含有MyApplication這一個類檔案,目前app涉及的業務也僅usercenter和media這兩個module,其中usercenter和module並無依賴關係。因此,此專案完全可以作為一個快速開發框架。簡單做法:新建幾個module編寫自身的業務,僅需要被shell依賴,它們並不會受到原業務usercenter和module的影響。然後更改入口Activity之後,就是一個新專案,也不會被打包進apk中。更多元件化的使用可見Appjoint的介紹。

目錄結構

每個元件和一般app的目錄結構基本一致,主要多出了一個package,用來盛放與其它元件通訊用到的類,專案中media元件有例項展示。

在這裡插入圖片描述

router庫的結構如下圖,其中每個元件都單獨擁有一個package,裡面分別盛放元件間通訊的服務介面和共享的資料(元件通訊資料實體類,或者面向json程式設計,手動哈哈,另一個話題)。

在這裡插入圖片描述

主要使用的第三方庫

感謝:

本專案僅做學習交流之用。

倉庫地址:

App實現-KtDevBox

後端實現-KtDevBox-backend

喜歡請記得Star一下。

後續還有更為詳細的專案介紹。

最後,可能有些童鞋還對下面這張圖感興趣。不過,本文只談技術,不談“風月”,微笑。

在這裡插入圖片描述

來源:https://juejin.im/post/5c34088ee51d4551cc6de40b

相關文章