March 5th, 2017
Android Weekly Issue #248.
本期內(nèi)容包括: 為什么有時候應(yīng)該讓你的應(yīng)用崩潰(而不是一味保護(hù)); Trello離線模式實(shí)現(xiàn)中兩個id的問題; 如何讓Dagger的component按照scope保存, 在屏幕旋轉(zhuǎn)時不重建; 用Dagger構(gòu)建Realm的數(shù)據(jù)庫遷移邏輯;
利用各種mock工具寫單元測試; Map上markers的動畫實(shí)現(xiàn); JUnit5中@DisplayName的使用; RxJava中的Single和Completable使用; 舉例說明如何給FindBugs寫自定義的探測器; Android中靜態(tài)代碼分析工具的使用; Trello離線實(shí)現(xiàn)中sync失敗情況的處理.
ARTICLES & TUTORIALS
Why your app should crash
作者認(rèn)為有時候讓應(yīng)用崩潰反而是有好處的.
以NPE為例, 有時候我們會習(xí)慣性地加很多null判斷, 有的是多余的, 有的防御型的代碼反而會掩蓋了真實(shí)問題所在. 比如當(dāng)一個不合理的情況發(fā)生時, 讓用戶看到一個不可理解的頁面, 比如空白, 然后我們開發(fā)者根本不知道這種情況的發(fā)生.
與其這樣掩蓋錯誤, 不如讓應(yīng)用崩潰, 讓開發(fā)者立即知道問題的原因.
實(shí)用建議:
永遠(yuǎn)讓應(yīng)用對外來輸入(比如service的響應(yīng), UI的輸入, 進(jìn)來的intents)保持健壯性.
在程序的入口點(diǎn)保證數(shù)據(jù)的完整性. 這樣不合理的數(shù)據(jù)就不會到處都是, 所以你不用到處檢查.
如果你不確定某個錯誤是否會在某個地方發(fā)生, 先假裝它不會發(fā)生, 在測試階段再驗(yàn)證.
如果某個方法在產(chǎn)品環(huán)境不能被調(diào)用, 或者只能被調(diào)用一次等, 拋出
IllegalStateExce
