想要追上最新的編程潮流嗎?想要導入最新的 Flux 編程方法嗎?這篇文章將手把手的帶你無痛進入 Flux 的領域。
這篇是 FluxJava: 給 Java 使用的 Flux 庫 的延續(xù),會透過建構一個演示的 Todo App 的過程來說明如何使用 FluxJava,所有演示的源代碼都可以在 Github 上找到。
Flux 簡介
為了方便不熟悉 Flux 的讀者,一開始會先簡短地說明這個架構。以下是借用 Facebook 在 Flux 官網上的原圖:
從圖上可以看到所有箭頭都是單向的,且形成一個封閉的循環(huán)。這一個循環(huán)代表的是數據在 Flux 架構中流動的過程,整個流程以 Dispatcher 為集散中心。
Action 大多是由與用戶互動的畫面控件所發(fā)起,在透過某種 Creator 的方法產生之后被送入 Dispatcher。此時,已經有跟 Dispatcher 注冊過的 Store 都會被調用,并且經由預先在 Store 上定義好的 Method 接收到 Action。Store 會在這個接收到 Action 的 Method 中,將數據的狀態(tài)依照 Action 的內容來進行調整。
前端的畫面控件或是負責控制畫面的控件,會收到由 Store 在處理完數據后所送出的異動事件,異動的事件就是用來代表在數據層的數據狀態(tài)已經不一樣了。這些前端控件在自行訂義的事件處理方法中聆聽、截收這些事件,并且在事件收到后由 Store 獲取最新的數據狀態(tài)。最后前端控件觸發(fā)自己內部的更新畫面程序,讓畫面上所有階層子控件都能夠反應新的數據狀態(tài),如此完成一個數據流動的循環(huán)。
以上是一個很簡單的說明,如果需要了解更進一步的內容,可以自行上網搜尋,現在網絡上應該已經有為數不少的文章可以參考。
以 BDD 來做為需求的開端
為了能夠更清楚的說明源代碼的細節(jié),所以文章中會依照 BDD 的概念來逐步解說源代碼。所以首先是要先列出需求:
- 顯示 Todo 清單
- 在不同用戶間切換 Todo 清單
- 新增 Todo
- 關閉/重啟 Todo
接著下來就要把需求轉更明確的敘述內容,因為只是演示,所列僅做出一個 Story 做為目標:
Story: Manage todo items
Narrative:
As a user
I want to manage todo items
So I can track something to be done
Scenario 1: Add a todo
When I tap the add menu on main activity
Then I see the add todo screen
When I input todo detail and press ADD button
Then I see a new entry in list
Scenario 2: Add a todo, but cancel the action
When I tap the add menu on main activity
And I press cancel button
Then Nothing happen
Scenario 3: Switch user
When I select a different user
Then I see the list changed
Scenario 4: Mark a todo as done
When I mark a todo as done
Then I see the todo has a check mark and strike through on title
也因為只是演示用,Story 的內容并沒有很嚴謹,而演示所使用的文字雖然是英文,但在實際的案例上用自己習慣的文字即可。
決定測試的方略
既然是采用 BDD 來做演示,當然在程序編寫的過程中會希望能夠有適切的工具的輔助,畢竟工欲善其事、必先利其器。所以在編寫測試源代碼時,不使用 Android 范本中的 JUnit,改為使用在“使用 Android Studio 開發(fā) Web 程序 - 測試”提到的 Spock Framework,并且全部以 Groovy 來編寫。因為 Spock Framework 內置了支援 BDD 的功能,把之前做好的 Story 轉成測試源代碼的工作也會簡化很多。
接下來要決定如何在 Android 項目中定位與分配測試源代碼。Espresso 是 Android 開發(fā)環(huán)境中內置的,使用 Espresso 來開發(fā)測試程序還是有一定的必要性。只不過 Espresso 必須要跑在實機或模擬的環(huán)境上,運行效率問題是無法被忽視的一個因素,而且 androidTest
下的源代碼其運行結果也沒有辦法在 Android Studio 中檢視 Code Coverage 的狀態(tài),所以用 Espresso 編寫的測試程序并不適合用來做為 Unit Test。
再加上新版的 Android Studio 提供了錄制測試步驟的功能,最后會被轉成 Espresso 的源代碼。所以看起來 Espresso 比較適合用來做為開發(fā)程流后段的一些測試工作,像是 UAT、壓力測試、穩(wěn)定度測試。依據這樣的定位,之前寫好的 Story 會在 Espresso 上轉成測試源代碼,來驗證程序的功能是否有達到 Story 描述的內容。
單元測試的部份沒有疑問地應該是寫在 Android 項目范本所提供的 test
的路徑之下,要解決的是 Android 控件如何在 JVM 的環(huán)境中運行測試。大部份人目前的選擇應該都會是 Robolectric,只不過測試源代碼要使用 Spock 來開發(fā),所以這二個包必須要做個整合。RoboSpock就是提供此一解決方案的包,可以讓 Robolectric 在基于 Spock 所開發(fā)的 Class 中能夠被直接使用。
使用 Robolectric 雖然能夠對 Android 組件在 JVM 中進行測試,但畢竟這類的組件相互之間的藕合性還是有點高,尤其是提供畫面的控件。所以這個部分在歸類上我定位成 Integration Test,但在數據的供給上,拜 Flux 架構之賜,可以依照情境來進行代換,只測試 Android 組件與組件之間的整合度,這個部份在接下來的內容會進行說明。附帶一提,有關測試上的一些想法我有寫成一篇文章,可以參考:“軟件測試雜談”。
以下列出本次使用的測試組件清單:
- Groovy
- Spock Framework
- RoboSpock
- Espresso
設定 Spock 與 Espresso、Robolectric 時會有一些細節(jié)需要注意,相關的說明請參考“配置 build.gradle 來用 Spock 對 Android 組件進行測試”。最后的 build.gradle
設定結果,可以在 Github 上的文件內容中看到。
建立畫面配置
在產生完 Android 項目空殼后,首先修改 MainActivity 的內容。在 MainActivity 畫面中加上 RecyclerView 及 Spinner 來顯示 Todo 清單以及提供切換用戶的功能。Layout 的配置顯示如下:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:id="@+id/activity_main"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:paddingBottom="@dimen/activity_vertical_margin"
android:paddingLeft="@dimen/activity_horizontal_margin"
android:paddingRight="@dimen/activity_horizontal_margin"
android:paddingTop="@dimen/activity_vertical_margin"
android:orientation="vertical"
tools:context="com.example.fluxjava.eventbus.MainActivity">
<Spinner
android:id="@+id/spinner"
android:layout_width="wrap_content"
android:layout_height="wrap_content" />
<android.support.v7.widget.RecyclerView
android:id="@+id/recyclerView"
android:layout_width="match_parent"
android:layout_height="match_parent"
app:layoutManager="LinearLayoutManager"
tools:listitem="@layout/item_todo" />
</LinearLayout>
開發(fā) UAT
原本范本中默認產生的 androidTest/java
的路徑可以刪除,另外要在 androidTest
之下增加一個 groovy
的文件夾,如果 build.gradle
有設定正確,在 groovy
文件夾上應該會出現代表測試源代碼的底色。因為目前只有一個 Story 所以在 groovy
路徑下配對的 Package 中增加一個 ManageTodoStory.groovy
的文件。
在這里就可以顯現 Spock 所帶來的優(yōu)勢,把之前的 Story 內容轉成以下的源代碼,與原本的 Story 比對并沒有太大的差距。
@Title("Manage todo items")
@Narrative("""
As a user
I want to manage todo items
So I can track something to be done
""")
class ManageTodoStory extends Specification {
def "Add a todo"() {
when: "I tap the add menu on main activity"
then: "I see the add todo screen"
when: "I input todo detail and press ADD button"
then: "I see a new entry in list"
}
def "Add a todo, but cancel the action"() {
when: "I tap the add menu on main activity"
and: "I press cancel button"
then: "Nothing happen"
}
def "Switch user"() {
when: "I select a different user"
then: "I see the list changed"
}
def "Mark a todo as done"() {
when: "I mark a todo as done"
then: "I see the todo has a check mark and strike through on title"
}
}
如果 Story 是用中文寫成的,以上的套用方式還是適用的。有關 Spock 的使用方式在這里就不詳細地說明,各位可以自行上網搜尋,或是參考我之前寫的這一篇及這一篇有關 Spock 的文章。接著就是把源代碼填入,完成后的內容如下所示:
@Title("Manage todo items")
@Narrative("""
As a user
I want to manage todo items
So I can track something to be done
""")
class ManageTodoStory extends Specification {
@Rule
public ActivityTestRule<MainActivity> mActivityRule = new ActivityTestRule<>(MainActivity.class)
private RecyclerView mRecyclerView
def "Add a todo"() {
when: "I tap the add menu on main activity"
this.mRecyclerView = (RecyclerView)this.mActivityRule.activity.findViewById(R.id.recyclerView)
onView(withId(R.id.add)).perform(click())
then: "I see the add todo screen"
onView(withText(R.string.dialog_title))
.inRoot(isDialog())
.check(matches(isDisplayed()))
onView(withText(R.string.title))
.inRoot(isDialog())
.check(matches(isDisplayed()))
onView(withId(R.id.title))
.inRoot(isDialog())
.check(matches(isDisplayed()))
onView(withText(R.string.memo))
.inRoot(isDialog())
.check(matches(isDisplayed()))
onView(withId(R.id.memo))
.inRoot(isDialog())
.check(matches(isDisplayed()))
onView(withText(R.string.due_date))
.inRoot(isDialog())
.check(matches(isDisplayed()))
onView(withId(R.id.dueText))
.inRoot(isDialog())
.check(matches(isDisplayed()))
onView(withId(android.R.id.button1))
.inRoot(isDialog())
.check(matches(withText(R.string.add)))
.check(matches(isDisplayed()))
onView(withId(android.R.id.button2))
.inRoot(isDialog())
.check(matches(withText(android.R.string.cancel)))
.check(matches(isDisplayed()))
when: "I input todo detail and press ADD button"
onView(withId(R.id.title))
.perform(typeText("Test title"))
onView(withId(R.id.memo))
.perform(typeText("Sample memo"))
onView(withId(R.id.dueText))
.perform(typeText("2016/1/1"), closeSoftKeyboard())
onView(withId(android.R.id.button1)).perform(click())
then: "I see a new entry in list"
onView(withText(R.string.dialog_title))
.check(doesNotExist())
this.mRecyclerView.getAdapter().itemCount == 5
onView(withId(R.id.recyclerView)).perform(scrollToPosition(4))
onView(withId(R.id.recyclerView))
.check(matches(hasDescendant(withText("Test title"))))
}
def "Add a todo, but cancel the action"() {
when: "I tap the add menu on main activity"
this.mRecyclerView = (RecyclerView)this.mActivityRule.activity.findViewById(R.id.recyclerView)
onView(withId(R.id.add)).perform(click())
and: "I press cancel button"
onView(withId(android.R.id.button2)).perform(click())
then: "Nothing happen"
this.mRecyclerView.getAdapter().itemCount == 4
}
def "Switch user"() {
when: "I select a different user"
this.mRecyclerView = (RecyclerView)this.mActivityRule.activity.findViewById(R.id.recyclerView)
onView(withId(R.id.spinner)).perform(click())
onView(allOf(withText("User2"), isDisplayed()))
.perform(click())
then: "I see the list changed"
this.mRecyclerView.getAdapter().itemCount == 5
}
def "Mark a todo as done"() {
when: "I mark a todo as done"
TextView target
this.mRecyclerView = (RecyclerView)this.mActivityRule.activity.findViewById(R.id.recyclerView)
onView(withRecyclerView(R.id.recyclerView).atPositionOnView(2, R.id.closed))
.perform(click())
target = (TextView)this.mRecyclerView
.findViewHolderForAdapterPosition(2)
.itemView
.findViewById(R.id.title)
then: "I see the todo has a check mark and strike through on title"
target.getText().toString().equals("Test title 2")
(target.getPaintFlags() & Paint.STRIKE_THRU_TEXT_FLAG) > 0
}
static RecyclerViewMatcher withRecyclerView(final int recyclerViewId) {
return new RecyclerViewMatcher(recyclerViewId)
}
}
以上源代碼中使用到的資源當然是要在編寫之前就事件準備好,否則出現錯誤的訊息。完成后先運行一次測試,當然結果都是失敗的,接下來就可以依照需求來逐項開發(fā)功能。
編寫 Bus
依照 Flux 架構,需要為整個數據循環(huán)建立 Dispatcher。但是在 FluxJava 中 Dispatcher 的功能是以 Bus 的方式實現,所以實際上是要先準備 Bus 的 Class。在這次的示范中使用 greenrobot 的 EventBus 來簡化開發(fā)工作,并且包裝在實現 IFluxBus
的 Interface 內,以便整合進 FluxJava 的 Framework 內。源代碼的內容如下:
public class Bus implements IFluxBus {
private EventBus mBus = EventBus.getDefault();
@Override
public void register(final Object inSubscriber) {
this.mBus.register(inSubscriber);
}
@Override
public void unregister(final Object inSubscriber) {
this.mBus.unregister(inSubscriber);
}
@Override
public void post(final Object inEvent) {
this.mBus.post(inEvent);
}
}
與 Bus 搭配的測試用 Class 的內容如下:
class BusSpec extends Specification {
public static class Subscriber {
Object actualEvent;
@Subscribe
public onEvent(String inEvent) {
this.actualEvent = inEvent;
}
}
def "Test register"() {
given:
def target = new Bus()
def expected = "Test"
def subscriber = new Subscriber()
def constants = new Constants()
target.register(subscriber)
when: "post an event with unexpected type"
target.post(0)
then: "will not get the event"
subscriber.actualEvent == null
constants != null
when: "post an event with expected type"
target.post(expected)
then: "get the event"
subscriber.actualEvent == expected
}
def "Test unregister"() {
given:
def target = new Bus()
def expected = "Test"
def subscriber = new Subscriber()
target.register(subscriber)
when: "post an event"
target.post(expected)
then: "get the event"
subscriber.actualEvent == expected
when: "unregister"
subscriber.actualEvent = null
target.unregister(subscriber)
target.post(expected)
then: "will not get any event"
subscriber.actualEvent == null
}
}
運行以上 Class 之后,確認測試通過并檢視 Code Coverage。如果測得到的源代碼都有被涵蓋,就可以確認目前完成的程序有一定的穩(wěn)定度,可以繼續(xù)往下進行接下來的工作。接下來的幾個小節(jié)都會采用這樣的工作節(jié)奏來逐步推進,以其望在程序完成時能夠有一定基礎的質量。
準備 Model
這里的 Model 是二個 POJO,分別用來代表一筆 User 和 Todo 的數據內容。因為這部分并不是示范的重點,所以文件的內容請自行參考 User.java
及 Todo.java
。
定義常量
常量主要的作用是以不同的數值來區(qū)分不同的數據種類,以及每一個數據種類因應需求所必須提供的功能。如同以下所展示的源代碼內容:
// constants for data type
public static final int DATA_USER = 10;
public static final int DATA_TODO = 20;
// constants for actions of user data
public static final int USER_LOAD = DATA_USER + 1;
// constants for actions of todo data
public static final int TODO_LOAD = DATA_TODO + 1;
public static final int TODO_ADD = DATA_TODO + 2;
public static final int TODO_CLOSE = DATA_TODO + 3;
在需求中提到需要處理二種類型的數據,所以就分別定義了 DATA_USER
及 DATA_TODO
來代表用戶及 Todo。以 User 的需求來看,在畫面上只會有載入數據的要求,以提供切換用戶的功能,所以 User 的動作只定義了 USER_LOAD。而 Todo 的需求就比較復雜,除了載入數據以外,還要可以新增、關閉 Todo。所以目前定義 TODO_LOAD
、TODO_ADD
、TODO_CLOSE
等三個常量。
這些常量接下來會被用在 StoreMap 的鍵值及 Action 的 Type。在 FluxJava 中并沒有限定只能使用數值型別來做為鍵值,可以根據每個項目的特性來設定,可以是字串、型別或是同一個型別不同的 Instance。
編寫 Action 及 Store
UserAction 和 TodoAction 都是很直接地繼承自 FluxAction。其中比較特別是:考量到一次可能會要處理多筆數據,所以在 Data 屬性的泛型上使用 List 來做為承載數據的基礎。這二個 Class 的內容請直接連上 Github 的 UserAction.java
及 TodoAction.java
二個文件查詢。
Store 可以繼承 FluxJava 內置的 FluxStore,或是自行實現 IFluxStore 的 Interface。在 IFluxStore 中 register
及 unregister
是提供給前端的畫面控件,做為向 Store 登記要接收到數據異動事件之用。
Tag 則是考量到同一個 Store 有可能要產生多個 Instance 來服務不同的畫面控件,所以仿照 Android 控件的方式,用 Tag 來識別不同的 Instance。像是在同一個畫面中,可能會因為需求的關系,要使用不同條件所產生的清單來呈現圖表。這時就有必要使用二個不同的 Instance 來提供數據,否則會造成畫面上數據的混亂。
至于 getItem
、findItem
、getCount
都是很基本在呈現數據內容時需要使用到的功能。其中 getItem
之所以限定一次只取得一筆數據,而不是以 List 的方式傳回,主要是為了符合 Flux 單向數據流的精神。如果 getItem
傳回的是 List,前端很有可能意外地異動了清單的內容,根據 Java 的特性,這樣的異動結果也會反應在 Store 所提供的信息上。也就等于數據的清單在 Store 以外,也有機會被異動,這就違反了 Flux 在設計上所想要達成的數據流動過程。
當然,就算是只提供一項數據,前端也許改不了整個清單,但還是可以修改所收到的這單一項目,其結果一樣會反應回 Store 的內部。所以在示范的源代碼中,在 getItem
所傳回的是一個全新的 Instance。
@Override
public User getItem(final int inIndex) {
return new User(this.mList.get(inIndex));
}
在 Store 中有一個關鍵的 Method 是 FluxStore 中沒有、要自行增加的,那就是用來接收前端所推送出來的 Action。由于目前使用的是 EventBus,以 UserStore 為例,會有以下的內容:
@Subscribe(threadMode = ThreadMode.BACKGROUND)
public void onAction(final UserAction inAction) {
// base on input action to process data
// in this sample only define one action
switch (inAction.getType()) {
case USER_LOAD:
this.mList.clear();
this.mList.addAll(inAction.getData());
super.emitChange(new ListChangeEvent());
break;
}
}
可以看到之前定義的常量在這里派上用場了,利用 Action 的 Type 可以區(qū)分出前端所接收到的指令。在這個 Demo 中,Store 的定位只是用來管理清單,清單的數據會由 ActionCreator 傳入,所以可以看到源代碼中只是做很簡單的載入工作,載入完即發(fā)出數據異動的事件。這個事件是定義在 Store 內部,每個 Store 都有定義自己的 Event,以便讓前端控件判別與過濾所想收到的 Event 種類。
在以上的 Method 源代碼中,使用了 EventBus 所提供的功能,在接收到 Action 的當下是以背景的 Thread 在運行,避免因為過長的數據處理時間導至前端畫面凍結。Method 的參數則是用以過濾 Action,讓指定的 Action 型別在 Bus 中被傳遞時才調用 Mehtod,減少源代碼判斷上的負擔。如果是同一個 Store 有多個 Instace 同時存在,在接收到的 Action 中可以加入 Tag 的信息,以便讓 Store 判別目前傳入的 Action 是否為針對自己所發(fā)出來的。
使用 EventBus 的 Annotation 規(guī)格聲明 Method 時,在 Android Studio 上會有一個即時語法檢查的警告出現,相關的處理細節(jié)可以參考這一篇文章。
而因為需求的關系,同樣的 Method 在 TodoStore 中就相對地復雜了一點:
@Subscribe(threadMode = ThreadMode.BACKGROUND)
public void onAction(final TodoAction inAction) {
// base on input action to process data
switch (inAction.getType()) {
case TODO_LOAD:
this.mList.clear();
this.mList.addAll(inAction.getData());
super.emitChange(new ListChangeEvent());
break;
case TODO_ADD:
this.mList.addAll(inAction.getData());
super.emitChange(new ListChangeEvent());
break;
case TODO_CLOSE:
for (int j = 0; j < inAction.getData().size(); j++) {
for (int i = 0; i < this.mList.size(); i++) {
if (this.mList.get(i).id == inAction.getData().get(j).id) {
this.mList.set(i, inAction.getData().get(j));
super.emitChange(new ItemChangeEvent(i));
break;
}
}
}
break;
}
}
主要是多了二種數據處理的要求:在新增時,前端會把新增的內容傳入,所以這里很簡單地把收到的項目加入清單之中,就可以通知前端刷新數據。至于在關閉 Todo 的部份,由于之前提到 Store 在 getItem
回傳的都是全新的 Instance,所以要先進行比對找出數據在清單中的位置,因為是示范的緣故,很單純地只寫了個循環(huán)來比對。找到了對應的位置后,直接以新的內容取代原本清單中的項目,再通知前端更新畫面。
如此,Action 與 Store 的編寫工作就算完成了。同樣地,在這個階段的最后,運行寫好的測試程序來確認目前為止的工作成果。
編寫 ActionHelper
FluxJava 已經內置了一個負責 ActionCreator 的 Class,這個 ActionCreator 使用 ActionHelper 來注入自定義的程序邏輯。可自定義的內容分為二個部份,第一個是決定如何建立 Action 的 Instance,第二個是協(xié)助處理數據格式的轉換。
以下是第一個部份的示范源代碼:
public Class<?> getActionClass(final Object inActionTypeId) {
Class<?> result = null;
if (inActionTypeId instanceof Integer) {
final int typeId = (int)inActionTypeId;
// return action type by pre-define id
switch (typeId) {
case USER_LOAD:
result = UserAction.class;
break;
case TODO_LOAD:
case TODO_ADD:
case TODO_CLOSE:
result = TodoAction.class;
break;
}
}
return result;
}
內容的重點就是依照先前定義好的常量來指定所屬的 Action 型別。
第二個部分就會有比較多的工作需要完成:
public Object wrapData(final Object inData) {
Object result = inData;
// base on data type to convert data into require form
if (inData instanceof Integer) {
result = this.getRemoteData((int)inData, -1);
}
if (inData instanceof String) {
final String[] command = ((String)inData).split(":");
final int action;
final int position;
action = Integer.valueOf(command[0]);
position = Integer.valueOf(command[1]);
result = this.getRemoteData(action, position);
}
if (inData instanceof Todo) {
final ArrayList<Todo> todoList = new ArrayList<>();
this.updateRemoteTodo();
todoList.add((Todo)inData);
result = todoList;
}
return result;
}
根據 Flux 文件的說明,ActionCreator 在建立 Action 的時候是調用外部 API 取得數據的切入點。所以 ActionHelper 提供了一個 wrapData
來讓使用 FluxJava 的程序有機會在此時取得外部的數據。在以上的程序中,還另外示范了另一種 wrapData
可能的用途。由于在前端會接收到的信息有可能有多種變化,像是在示范中,要求載入 User 時只需要一個數值、在載入 Todo 時則要額外告知此時選擇的 User、在新增或修改 Todo 時則是要把修改的結果傳入。這時 wrapData
就可以適時地把這些不同型式的信息轉成 Store 要的內容放在 Action 中,讓 Store 做后續(xù)的處理。
如果想要使用自定義的 ActionCreator,可以在初始化 FluxContext 時將自定義的 ActionCreator Instance 傳入,只是這個自定義的 ActionCreator 要繼承自內置的 ActionCreator,以覆寫原本的 Method 來達到自定義的效果。
組合控件
這次演示中,Flux 的架構橫跨整個 App 的生命周期。所以最合理的切入位置是自定義的 Application,這里增加了一個名為 AppConfig 的 Class 做為初始化 Flux 架構的進入點,同時修改 AndroidManifest.xml
讓 AppConfig 可以在 App 啟動時被調用。
在 AppConfig 內增加一個 setupFlux
的 Method,內容如下:
private void setupFlux() {
HashMap<Object, Class<?>> storeMap = new HashMap<>();
storeMap.put(DATA_USER, UserStore.class);
storeMap.put(DATA_TODO, TodoStore.class);
// setup relationship of components in framework
FluxContext.getBuilder()
.setBus(new Bus())
.setActionHelper(new ActionHelper())
.setStoreMap(storeMap)
.build();
}
重點工作是把之前步驟中準備好的 Bus、ActionHelper、StoreMap 傳入 FluxContext 的 Builder 之中,并且透過 Builder 建立 FluxContext 的 Instance。截至目前為止,后端準備的工作算是完成了,在文件夾的結構上各位應該可以看出來,我把以上的 Class 都歸類在 Domain 的范疇之中。
編寫 Adapter
Adapter 是用來供給 Spinner 及 RecyclerView 數據的 Class,同時在這次的演示中也是與 FluxJava 介接的關鍵角色,代表的是在 Flux 流程圖中的 View。在 MainActivity 中 Spinner 是用來顯示 User 清單,而 RecyclerView 是用來顯示 Todo 清單,所以各自對應的 Adapter 分別是 UserAdapter 及 TodoAdapter。
雖然這二個 Adapter 繼承自不同的 Base Class,但是都需要提供 Item 的 Layout 以便展示數據。所以先產生 item_user.xml
及 item_todo.xml
二個文件。
準備好了 Item 的 Layout 就可以進行 Adapter 的編寫工作,以下是 UserAdapter 的完整內容:
public class UserAdapter extends BaseAdapter {
private UserStore mStore;
public UserAdapter() {
// get the instance of store that will provide data
this.mStore = (UserStore)FluxContext.getInstance().getStore(DATA_USER, null, this);
}
@Override
public int getCount() {
return this.mStore.getCount();
}
@Override
public Object getItem(final int inPosition) {
return this.mStore.getItem(inPosition);
}
@Override
public long getItemId(final int inPosition) {
return inPosition;
}
@Override
public View getView(final int inPosition, final View inConvertView, final ViewGroup inParent) {
View itemView = inConvertView;
// bind data into item view of Spinner
if (itemView == null) {
itemView = LayoutInflater
.from(inParent.getContext())
.inflate(R.layout.item_user, inParent, false);
}
if (itemView instanceof TextView) {
((TextView)itemView).setText(this.mStore.getItem(inPosition).name);
}
return itemView;
}
@Subscribe(threadMode = ThreadMode.MAIN)
public void onEvent(final UserStore.ListChangeEvent inEvent) {
super.notifyDataSetChanged();
}
public void dispose() {
// Clear object reference to avoid memory leak issue
FluxContext.getInstance().unregisterStore(this.mStore, this);
}
}
在 UserAdapter 的 Constructor 中,使用 FluxContext 來取得 Store 的 Instance。使用的第一個參數就是之前在常量定義好的 USER_DATA
,第二參數的 Tag 因為本次示范沒有使用到所以傳入 Null。最后一個參數是把 Adapter 本身的 Instance 傳入,FluxContext 會把傳入的 Instance 注冊到 Store 中。當然,如果要在取回 Store 后再自行注冊也是可以的。
之后部份就是 Adapter 的基本應用,需要提供數據有關的信息時,則是透過 Store 來取得。
在 Adapter 的尾端可以看到有一個和 Store 類似的 Method,因為同樣是使用 EventBus 來傳送信息,所以使用相同的方式來接收數據異動的事件。同樣地,在 Method 的參數上以型別來限定要收到的事件種類,被調用后的工作也很簡單,就是轉通知 Spinner 重刷畫面。由于是要更新畫面上的信息,所以要回到 UI Thread 來運行,threadMode 被指定為 MainThread。如果同一個 Store 同時有多個 Instance 存在,和 Store 的 onAction
一樣,可以在 Event 中加入 Tag 的信息,以減少無用的重刷頻繁地出現。
最后則是一個用來釋放 Reference 的接口,主要之目的是避免 Memory Leak 的問題,大部份都是在 Activity 卸載時調用。
以下是另外一個 Adapter - TodoAdapter 的內容:
public class TodoAdapter extends RecyclerView.Adapter<TodoAdapter.ViewHolder> {
static class ViewHolder extends RecyclerView.ViewHolder {
TextView title;
TextView dueDate;
TextView memo;
CheckBox closed;
ViewHolder(final View inItemView) {
super(inItemView);
this.title = (TextView)inItemView.findViewById(R.id.title);
this.dueDate = (TextView)inItemView.findViewById(R.id.dueDate);
this.memo = (TextView)inItemView.findViewById(R.id.memo);
this.closed = (CheckBox)inItemView.findViewById(R.id.closed);
}
}
private TodoStore mStore;
public TodoAdapter() {
// get the instance of store that will provide data
this.mStore = (TodoStore)FluxContext.getInstance().getStore(DATA_TODO, null, this);
}
@Override
public ViewHolder onCreateViewHolder(final ViewGroup inParent, final int inViewType) {
final View itemView = LayoutInflater
.from(inParent.getContext()).inflate(R.layout.item_todo, inParent, false);
// use custom ViewHolder to display data
return new ViewHolder(itemView);
}
@Override
public void onBindViewHolder(final ViewHolder inViewHolder, final int inPosition) {
final Todo item = this.mStore.getItem(inPosition);
// bind data into item view of RecyclerView
inViewHolder.title.setText(item.title);
inViewHolder.dueDate.setText(item.dueDate);
inViewHolder.memo.setText(item.memo);
inViewHolder.closed.setOnCheckedChangeListener(null);
inViewHolder.closed.setChecked(item.closed);
}
@Override
public int getItemCount() {
return this.mStore.getCount();
}
@Subscribe(threadMode = ThreadMode.MAIN)
public void onEvent(final TodoStore.ListChangeEvent inEvent) {
super.notifyDataSetChanged();
}
@Subscribe(threadMode = ThreadMode.MAIN)
public void onEvent(final TodoStore.ItemChangeEvent inEvent) {
super.notifyItemChanged(inEvent.position);
}
public void dispose() {
// Clear object reference to avoid memory leak issue
FluxContext.getInstance().unregisterStore(this.mStore, this);
}
}
除了因為是繼承自不同 Base Class 所產生的寫法上之差異外,并沒有太大的不同。重點是在接收事件的 Method 多了一個,用來當數據異動的情境是修改時,只更新有異動的 Item,以增加程序運作的效率。
接下來的工作就是把 Adapter 整合到 MainActivity 的源代碼中:
public class MainActivity extends AppCompatActivity {
private UserAdapter mUserAdapter;
private TodoAdapter mTodoAdapter;
@Override
protected void onCreate(final Bundle inSavedInstanceState) {
super.onCreate(inSavedInstanceState);
super.setContentView(R.layout.activity_main);
this.setupRecyclerView();
this.setupSpinner();
}
@Override
protected void onStart() {
super.onStart();
// ask to get the list of user
FluxContext.getInstance().getActionCreator().sendRequestAsync(USER_LOAD, USER_LOAD);
}
@Override
protected void onStop() {
super.onStop();
// release resources
if (this.mUserAdapter != null) {
this.mUserAdapter.dispose();
}
if (this.mTodoAdapter != null) {
this.mTodoAdapter.dispose();
}
}
private void setupSpinner() {
final Spinner spinner = (Spinner)super.findViewById(R.id.spinner);
if (spinner != null) {
// configure spinner to show data
this.mUserAdapter = new UserAdapter();
spinner.setAdapter(this.mUserAdapter);
spinner.setOnItemSelectedListener(new AdapterView.OnItemSelectedListener() {
@Override
public void onItemSelected(final AdapterView<?> inParent, final View inView,
final int inPosition, final long inId) {
// when user change the selection of spinner, change the list of recyclerView
FluxContext.getInstance()
.getActionCreator()
.sendRequestAsync(TODO_LOAD, TODO_LOAD + ":" + inPosition);
}
@Override
public void onNothingSelected(final AdapterView<?> inParent) {
// Do nothing
}
});
}
}
private void setupRecyclerView() {
final RecyclerView recyclerView = (RecyclerView)super.findViewById(R.id.recyclerView);
if (recyclerView != null) {
// configure recyclerView to show data
this.mTodoAdapter = new TodoAdapter();
recyclerView.setAdapter(this.mTodoAdapter);
}
}
}
除了把 Adapter 傳入對應的畫面控件外,還有幾個重點。第一個是在 onStop
時要調用 Adapter 的 dispose
以避免之前提到的 Memory Leak 的問題。另外一個是在 onStart
時會以非同步的方式要求提供 User 的清單數據,在畫面持續(xù)在前景運作的同時,UserStore 完成數據載入就會觸發(fā) UserAdapter、UserAdapter 再觸發(fā) Spinner、Spinner 觸發(fā) TodoStore 的載入、TodoStore 觸發(fā) TodoAdapter、TodoAdapter 觸發(fā) RecyclerView 等一連串數據更新的動作。所以可以在 Spinner 的 OnItemSelectedListener
中看到要求送出 TODO_LOAD
的 Action。
會選在 onStart
都做一次數據載入的要求是考量到 Activity 被推入背景后,有可能會出現數據的異動,所以強制進行一次畫面的刷新。
寫到這里除了運行所有已完成的單元測試外,其實可以再回去運行一次 UAT,這時可以發(fā)現已經開始有測試結果轉為通過了。
編寫 Integration Test
在繼續(xù)完成需求之前,先插入一個有關測試上的說明,使用 Flux 的其中一個重要原因就是希望提高源代碼的可測試性。所以在這次的示范之中,選擇以 Integration Test 來展示 FluxJava 可以達到的效果。
就像一開始提到的,用 Robolectric 來測試 MainActivity 被定位成 Integration Test。主要的測試目標是要確認整合起來后 UI 的行為符合設計的內容,此時當然不希望使用真實的數據來測試,簡單的說就是要把 Store 給隔離開來。
要達到這個目的可以由 FluxContext 的初始化做為切入點,以 Robolectric 來說,他提供了一個方便的功能,就是可以在測試運行時以 Annotation 中設定的 Applicaton Class 取代原本的 Class。 就如同以下源代碼所示范:
@Config(constants = BuildConfig, sdk = 21, application = StubAppConfig)
class MainActivitySpec extends GradleRoboSpecification {
}
而在 StubAppConfig 中就可以對 FluxContext 注入測試用的 Class 來轉為提供測試用的數據:
public class StubAppConfig extends Application {
@Override
public void onCreate() {
super.onCreate();
this.setupFlux();
}
private void setupFlux() {
HashMap<Object, Class<?>> storeMap = new HashMap<>();
storeMap.put(DATA_USER, StubUserStore.class);
storeMap.put(DATA_TODO, StubTodoStore.class);
FluxContext.getBuilder()
.setBus(new Bus())
.setActionHelper(new StubActionHelper())
.setStoreMap(storeMap)
.build();
}
}
這里使用 StubAppConfig 做為切入點的演示并不是唯一的方法,在實際應用上還是應該選擇適合自己項目的方式。
如果在運行 UAT 希望也使用測試的數據來進行,以 FluxJava 來說當然也不會是問題,達成的方式在本次的示范中也可以看得到。原理同樣是和 Integration Test 相同,是使用取代原本 AppConfig 的方式。只是在 Espresso 里設定就會麻煩一點,首先要增加一個自定義的 JUnitRunner,接著 build.gradle
中 defaultConfig
改成以下的內容:
defaultConfig {
...
// replace "android.support.test.runner.AndroidJUnitRunner" with custom one
testInstrumentationRunner "com.example.fluxjava.eventbus.CustomJUnitRunner"
}
同時調整 Android Studio 的 Configuration 中指定的 Instrumentation Runner 內容如下:
所以在運行 UAT 與正常啟動的情況下,可以在畫面中看到截然不同的數據內容,即代表 Store 代換的工作確實地達成目標。
編寫新增 Todo 功能
在這次的演示中,達成新增 Todo 的功能就只是很簡單地在 MainActivity 加上 Add Menu,透過用戶按下 Add 后,顯示一個 AlertDialog 取回用戶新增的內容完成新增的程序。以下是 `menu_main.xml’ 的內容:
<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto">
<item
android:id="@+id/add"
android:title="@string/add"
app:showAsAction="always" />
</menu>
接著在 MainActivity.java
中加上以下的 Method:
@Override
public boolean onCreateOptionsMenu(final Menu inMenu) {
super.getMenuInflater().inflate(R.menu.menu_main, inMenu);
return true;
}
用來讓用戶輸入數據的 AlertDialog 是用 DialogFragment 來達成,以下是 Layout 的內容:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:padding="16dp">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/title" />
<EditText
android:id="@+id/title"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_weight="1"
android:layout_marginLeft="8dp"
android:layout_marginStart="8dp"
android:inputType="text" />
</LinearLayout>
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/memo" />
<EditText
android:id="@+id/memo"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_weight="1"
android:layout_marginLeft="8dp"
android:layout_marginStart="8dp"
android:inputType="text" />
</LinearLayout>
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@string/due_date" />
<EditText
android:id="@+id/dueText"
android:layout_width="0dp"
android:layout_height="wrap_content"
android:layout_weight="1"
android:layout_marginLeft="8dp"
android:layout_marginStart="8dp"
android:inputType="text" />
</LinearLayout>
</LinearLayout>
源代碼則是如下所示:
public class AddDialogFragment extends AppCompatDialogFragment {
@Nullable
@Override
public View onCreateView(final LayoutInflater inInflater,
@Nullable final ViewGroup inContainer,
@Nullable final Bundle inSavedInstanceState) {
return inInflater.inflate(R.layout.dialog_add, inContainer);
}
@NonNull
@Override
public Dialog onCreateDialog(final Bundle inSavedInstanceState) {
final AlertDialog.Builder builder = new AlertDialog.Builder(super.getActivity());
final LayoutInflater inflater = super.getActivity().getLayoutInflater();
final ViewGroup nullParent = null;
// display an alertDialog for input a new todo item
builder.setView(inflater.inflate(R.layout.dialog_add, nullParent))
.setTitle(R.string.dialog_title)
.setPositiveButton(R.string.add, new DialogInterface.OnClickListener() {
@Override
public void onClick(final DialogInterface inDialog, final int inId) {
final AlertDialog alertDialog = (AlertDialog)inDialog;
final Todo todo = new Todo();
final EditText title = (EditText)alertDialog.findViewById(R.id.title);
final EditText memo = (EditText)alertDialog.findViewById(R.id.memo);
final EditText dueDate = (EditText)alertDialog.findViewById(R.id.dueText);
if (title != null) {
todo.title = title.getText().toString();
}
if (memo != null) {
todo.memo = memo.getText().toString();
}
if (dueDate != null) {
todo.dueDate = dueDate.getText().toString();
}
// the input data will be sent to store by using bus
FluxContext.getInstance()
.getActionCreator()
.sendRequestAsync(TODO_ADD, todo);
}
})
.setNegativeButton(android.R.string.cancel, new DialogInterface.OnClickListener() {
public void onClick(final DialogInterface inDialog, final int inId) {
// Do nothing
}
});
return builder.create();
}
}
再來就是讓 MainActivity 可以在用戶按下 Menu 時彈出 AlertDialog,所以新增如下的 Method:
@Override
public boolean onOptionsItemSelected(MenuItem item) {
boolean result;
switch (item.getItemId()) {
case R.id.add:
AddDialogFragment addDialog = new AddDialogFragment();
// display an input dialog to get a new todo
addDialog.show(super.getSupportFragmentManager(), "Add");
result = true;
break;
default:
result = super.onOptionsItemSelected(item);
break;
}
return result;
}
運行所有的測試,看測試的結果沒有通過的不多了,距完成只剩一步之遙。
編寫關閉 Todo 的功能
從最后一次 UAT 運行的結果可以發(fā)現,仍未滿足需求的項目只剩下關閉 Todo 最后一項。要達成這一項功能要回到 TodoAdapter,將 onBindViewHolder
改成以下的內容:
@Override
public void onBindViewHolder(final ViewHolder inViewHolder, final int inPosition) {
final Todo item = this.mStore.getItem(inPosition);
// bind data into item view of RecyclerView
inViewHolder.title.setText(item.title);
if (item.closed) {
inViewHolder.title.setPaintFlags(
inViewHolder.title.getPaintFlags() | Paint.STRIKE_THRU_TEXT_FLAG);
} else {
inViewHolder.title.setPaintFlags(
inViewHolder.title.getPaintFlags() & (~ Paint.STRIKE_THRU_TEXT_FLAG));
}
inViewHolder.dueDate.setText(item.dueDate);
inViewHolder.memo.setText(item.memo);
inViewHolder.closed.setOnCheckedChangeListener(null);
inViewHolder.closed.setChecked(item.closed);
inViewHolder.closed.setOnCheckedChangeListener(new CompoundButton.OnCheckedChangeListener() {
@Override
public void onCheckedChanged(final CompoundButton inButtonView, final boolean inIsChecked) {
item.closed = inIsChecked;
FluxContext.getInstance()
.getActionCreator()
.sendRequestAsync(TODO_CLOSE, item);
}
});
}
最后,運行最開始寫好的 UAT,非常好,所有的需求都通過測試,打完收工!