編輯:Android資訊
嘿!經過一段時間收集了大量反饋意見後,我認為應該來說說這個話題了。我會在這裡給出我認為構建現代移動應用(Android)的好方法,這會是另一番體味。
開始之前,假設你已經閱讀過我之前撰寫的文章“ Architecting Android…The clean way ?”。如果還沒有閱讀過,為了更好地理解這篇文章,應借此機會讀一讀:
演變意味著一個循序漸進的過程,由某些狀態改變到另一種不同的狀態,且新狀態通常更好或更復雜。
照這麼一說,軟件是隨著時間發展和改變的,是架構上的發展和改變。實際上,好的軟件設計必須能夠幫助我們發展和擴充解決方案,保持其健壯性,而不 必每件事都重寫代碼(雖然在某些情況下重寫的方法更好,但是那是另一篇文章的話題,所以相信我,讓我們聚焦在前面所討論的話題上)。
在這篇文章中,我將講解我認為是必需的和重要的要點,為了保持基本代碼條理清晰,要記住下面這張圖片,我們開始吧!
因為已經 有很多這方面的文章 ,還有這方面 做得很好、令人景仰的人 ,所以我不打算在這裡討論RxJava的好處( 我假設您已經對它有所體驗了 )。但是,我將指出在Android應用程序開發方面的有趣之處,以及如何幫助我形成第一個清晰的架構的方法。
首先,我選擇了一種響應式的模式通過轉換usecase(在這個清晰的架構命名規則中,其被稱為interactor)返回Observables<T>,表示所有底層都遵循這一鏈條,也返回Observables<T> 。
正如你所看到的,所有用例繼承這個抽象類,並實現抽象方法buildUseCaseObservable()。該方法將建立一個Observables<T>,它承擔了繁重的工作,還要返回所需的數據。
需要強調是,在execute()方法中,要確保Observables<T> 是在獨立線程執行,因此,要盡可能減輕阻止android主線程的程度。其結果就是會通過android主線程調度程序將主線程壓入線程隊列的尾部(push back)。
到目前為止,我們的Observables<T>啟動並且運行了。但是,正如你所知,必須要觀察它所發出的數據序列。要做到這一點, 我改進了presenters(MVP模式表現層的一部分),把它變成了觀察者(Subscribers),它通過用例對發出的項目做出“react”, 以便更新用戶界面。
觀察者是這樣的:
每個觀察者都是每個presenter的內部類,並實現了一個Defaultsubscriber<T>接口,創建了基本的默認錯誤處理。
將所有的片段放在一起後,通過下面的圖,你可以獲得完整的概念:
讓我們列舉一些擺脫基於RxJava方法的好處:
在觀察者(Subscribers)與被觀察者(Observables)之間去耦合:更加易於維護和測試。
從我的角度看有一點不足,甚至要為此需要付出代價,那些還不熟悉概念的開發人員還是要遵循學習曲線。但你從中得到了極有價值的東西。為了成功而reactive起來吧!
關於依賴注入, 因為我已經寫了一篇完整的文章 ,我不想說太多。強烈建議你閱讀它,這樣我們就可以接著說下面的內容了。
值得一提的是,通過實現一個像Dagger 2那樣的依賴注入框架我們能夠獲得:
沒有人會抱怨在代碼中使用Java 8的lambada表達式,甚至在簡化並擺脫了很多樣板代碼以後,使用得更多,如你看到這段代碼:
然而,我百感交集,為什麼呢?我們曾在 @SoundCloud 討論 Retrolambada ,主要是是否使用它,結果是:
1. 贊成的理由:
2. 反對的理由:
最後,我們認定它不能為我們解決任何問題:你的代碼看起來很好且具有可讀性,但這不是我們與之共存的東西,由於現在所有功能最強大的IDE都包含代碼折疊式選項,這就涵蓋這一需求了,至少是一個可接受的方式。
說實話,盡管我可能會在業余時間的項目中使用它,但在這裡使用它的主要原因是嘗試和體驗Android中Lambda表達式。是否使用它由你自己決定。在這裡我只是展示我的視野。當然,對於這樣一個了不起的工作,這個 庫 的作者值得我的稱贊。
在測試方面,與示例的第一個版本相關的部分變化不大:
幸運的是,這都是過去的一部分,而現在所有都是即刻可用,這樣我可以把它們重新放到數據模塊內,專門為其默認的測試路徑:src/test/java。
我認為一個好的架構關鍵因素之一是代碼/包的組織:程序員浏覽源代碼遇到的第一件事情就是包結構。一切從它流出,一切依賴於它。
我們能夠辨別出將應用程序封裝進入包(package)的2個路徑:
我的建議是去掉按特性分包,會帶來的好處有以下主要幾點:
如果與功能特性團隊一起工作(就像我們在@SoundCloud的所作所為),也會是非常有趣的事情。代碼的所有權會更容易組織,也更容易被模塊化。在許多開發人員共用一個代碼庫的成長型組織當中,這是一種成功。
如你所見,我的方法看起來就像按層分包:這裡我可能會犯錯(例如,在“users”下組織一切),但在這種情況下我會原諒自己,因為這是個以學習為目的的例子,而且我想顯示的是清晰架構方法的主要概念。領會其意,切勿盲目模仿:-)。
我們都知道,房子是從地基上建立起來的。軟件開發也是這樣,我想說的是,從我的角度來看,構建系統(及其組織)是軟件架構的重要部分。
在Android平台上,我們采用Gradle,它事實上是一種與平台無關的構建系統,功能非常強大。這裡的想法是通過一些提示和技巧,讓你組織構建應用程序時能夠得到簡化。
因此,你可以用“apply from: ‘buildsystem/ci.gradle’”插入到任何Gradle建立的文件中進行配置。不要把所有都放置在一個build.gradle文件中,否則就是去創建一個怪物,這是教訓。
如果想在項目的不同模塊間重用相同的組件版本,這很好;否則就要在不同的模塊間使用不同的版本的組件依賴。另外一點,你是在同一個地方控制依賴關系,像組件版本發生沖突這樣的事情一眼就能看出來。
到目前為止講了那麼多,一句話,要記住沒有靈丹妙藥。但好的軟件架構會幫助代碼保持清晰和健壯,還可以保持代碼的可擴展性,易於維護。
我想指出一些事情。面對軟件存在的問題,要報以本應當解決的態度:
Android編程中一個共同的困難就是協調Activity的生命周期和長時間運行的任務(task),並且要避免可能的內存洩露。思考下面Activity的代碼,在它
本文由碼農網 – 小峰原創翻譯,轉載請看清文末的轉載要求,歡迎參與我們的付費投稿計劃! 移動開發變得越來越受歡迎,但移動開發者正面臨著一系列挑戰。本文將介
Android在執行一些後台操作的時候,比如加載游戲,播放歌曲時,用戶根本不知道程序執行的進度情況,這時候,可以使用進度條來顯示這些進度。 Andorid系統提供
本文由碼農網 – 小峰原創翻譯,轉載請看清文末的轉載要求,歡迎參與我們的付費投稿計劃! 今天,幾乎所有的web和移動app都自帶谷歌和Facebook登錄