測試上遇到的困擾
測試一直是軟體開發中重要的一環，在「軟體測試經驗分享」中，提到了一些測試相關的概念。Android 的開發裡，AVD 則是測試不可或缺的一部份。透過 AVD 可以不用準備大量的實體設備，就可以讓所開發的 App 在不同的環境中檢視其運作的情況。
使用 Notebook 進行 Android 開發的人，通常都會遇到一個困擾是：Notebook 的磁碟空間大多不是很充裕。在開發 Android App 時，常常要使用多個...
使用遠端的 AVD 進行測試
2017/12/1
2017/11/14
FluxJava 新增 RxJava2 的支援功能
FluxJava 最初的設計就是以 Add-on 的方式來提供對於 RxJava 的支援，所以這次增加 RxJava2 的部份也依照相同的模式，在 Project 中加上了 fluxjava-rx2 的 Module。新的 Module 功能上與 fluxjava-rx 大致上相同，只是原本以 RxJava 規格運作的部份，改為使用 RxJava2。
由於 RxJava 與 RxJava2 不太有機會共存在同一個 Module 裡，所以 fluxjava-rx2 沿用了 fluxjava-rx 的 Package 名稱，在使用上這二個 Add-on 必須要擇一引用。不過也帶來了一個額外的好處，如果想要由...
2017/11/13
FluxJava 與 RxJava2 結合的使用示範
這篇是「FluxJava: 給 Java 使用的 Flux 函式庫」的延續，會透過建構一個示範的 Todo App 的過程來說明如何使用 FluxJava，所有示範的原始碼都可以在 Github 上找到。
大部份的內容其實都已經寫在另一篇中，但考量到有一些性急的朋友對於要開另外一篇文章，來看與想找的主題無關的內容會感到不耐，所以在這篇文章中還是會呈現完整的步驟及相關的內容。
Flux 簡介
為了方便不熟悉 Flux 的讀者，一開始會先簡短地說明這個架構。以下是借用...
2017/7/4
如何在 Android Studio 中引用不在專案目錄中的 jar 檔
Android Studio 使用 Gradle 做為建置的工具在 Dependency 的管理上，節省掉很多煩人的工作，讓引用 Library 變成極為單純的作業，也讓開發人員可以更專注在重要的事項。透過 Gradle 的功能，要引用 Project 以外的 Library，只要在 build.gradle 中提供 Library 的識別名稱及對應版本編號，即可透過預先設定好的 Repository 來自動取得 jar，不需要再由人工下載、更新。
以下是一個簡易的引用示範：
...
2017/6/12
Espresso 只做了半套的 Code Coverage
有在使用 Espresso 撰寫測試程式的人應該都知道，在 Android Studio 中 Android Test 類型的 Configuration 是不能使用 Code Coverage 的，最少在 Android Studio 2.2.2 仍然是如此。也就是說「Run 'xxx' with Coverage」的按鈕沒有辦法按，情況如下圖所示：
這點和 JUnit 的 Configuration 不同：
產出...
2017/6/5
解決 Spock 與 PowerMock 的整合問題
在前一篇文章中，提到了如何在 Spock 中測試 Static 的 Method，以彌補 Spock 在這個部份的不足。當時使用的是 PowerMock 1.6.2，只不過隨著時間的推移，最新的 Mockito 與 PowerMock 組合，在與 Spock 的整合上並不順利。
Mockito 目前已經發展到第二版，但是要在這個版本的 Mockito 上使用 PowerMock，依據官方的說明仍然還停留在試驗性質的版本，目前最新可取得的版本是 1.7.0RC4。
如果使用前一篇文章提到的，以 @Rule 的方式來啟動 PowerMock：
...
2017/5/30
善用 Android Studio 的異動管理功能
身為一個開發人員，每天的工作就是在不斷地異動 Source Code 中度過。增加新的、修改舊的、刪掉不要的，而每一個異動都會對應到特定的目的，像是為了新的需求、修改 Bug、重構程式等等。
很多時候，異動的目的在工作的過程中是混在一起的，例如開發新功能的同時，也有可能在修正之前的問題。在自己的工作環境中，這些異動混在一起通常都不會有什麼問題產生。只不過這些工作的成果終究是要交付出去的，而問題總在於這些目的卻不一定是在同一個時間點被交付。如果所有的異動都混在一起，要隔離出需要交付的部份，勢必要花費一番工夫才能辦得到。
而這樣的工作要靠人工來逐個...
2017/4/24
使用 MVP 時在設計上的考量
在「FluxJava: 給 Java 使用的 Flux 函式庫」這篇文章中提到，設計中使用 MVP 最大的問題，是會讓不同的畫面形成一組、一組的 Class，但各組之間是獨立的。MVP 最基本的設計概念中，只描述了同一組內 Class 如何互動，並沒有提到組內的 Class 如何跨組與其他的 Class 互動。當設計上出現要跨組的情況時，就得要仰賴設計者的功力與經驗了。
就 MVP 的精神，View 要負責的工作，只是把 Presenter 送來的 Model 內容呈現在畫面上。並且，與使用者互動，接收使用者的意圖、收集使用者輸入的資料，再交由 Presenter 處理。至於其他與 Business...
2017/3/31
MVC 與 MVP 的抉擇
古人有句話說「十年河東、十年河西」，前幾年在 Android 開發上，MVC 的設計一直是眾人談論的重點。但是隨著時間的更替，MVP 似乎開始熱了起來，連 Google 自家的範例中都提供了 MVP 的設計樣板，MVC 反而不在示範之列。
這讓很多人會興起一個疑問是：
MVC 和 MVP 我該選哪一個？我真的該棄 MVC 改投 MVP 的懷抱嗎？
面對這樣的一個問題，讓我想到了星爺電影中的一句台詞：
爭什麼爭，把兩樣摻在一起做瀨尿牛丸不就得了，笨蛋！
聽起戲謔，但卻不失為一個設計上可以思考的方向。MVC...
2017/2/8
如何做好專案結構規劃
在另一篇文章中說明了「規劃專案結構」的重要性，在這篇文章中則要來談談如何實踐。
決定結構的依據
在決定專案結構的分類方式時，不外乎是依 Feature 或是依 Layer 來設置所謂的 Package 或是 Namespace，一般都會與實體的目錄名稱做搭配，形成一個同步的樹狀結構。這二種分類的差別，其實說白了就是倒底是要依照 SA 還是 SD 的文件內容來做分類的基準。
在進行系統設計時，理所當然地會以 SA 文件為基礎來開展工作，因為系統分析本來就是做為設計之前的資訊分析與統整的工作。在這樣的前提之下，所設計出來的 Class 就注定會帶有 SA 文件分類的屬性。然而在 OOP 的原則之下，單一個...
2017/1/30
為什麼應該要做好專案結構的規畫
首先，先說明一下「規劃專案結構」具體的工作內容是什麼。以二個常見的程式開發平台來說，不管是用 Visual Studio 來開發 .NET 的程式，還是用各種 IDE 來開發 Java 的程式，都會有一組用來輔助 IDE 進行程式專案管理的檔案、甚至會伴隨著一到數個特定的目錄結構。只不過，這些都不是這篇文章要涉及的部份。而是除了這些內容以外，由開發人員自行產生的檔案該如何妥適的進行分門別類的工作，就是這篇文章所提到「規劃專案結構」要主要工作內容。
對很多的從業人員來說，「規劃專案結構」可能是個無足輕重的工作項目，心裡會想：不就是開幾個目錄把檔案往裡面丟就完事了嗎？能編能跑才是王道！會這樣想...