回顧昨天的進度,列出下方兩點要進行的方向
一般來說在嫁接網路層的時候,都希望能夠在應用層的雜訊越少越好,舉昨天的例子來說:
call.enqueue(object : Callback<ProfileList> {
override fun onResponse(call: Call<ProfileList>, response: Response<ProfileList>) {
response.body()?.let {
it.results.forEach {
Log.i("MainActivity", "$it")
}
}
}
override fun onFailure(call: Call<ProfileList>, t: Throwable) {
}
})
onResponse 函式當中,所回傳的 response 中的 body 才是網路層那邊帶回來的解析完的物件,也是畫面上需要呈現的部份,而 onFailure 也是希望以單純一點的形式,將錯誤訊息可以自訂我們需要內容而呈現,像特定的錯誤訊息。
因此建立一個實作 Retrofit 的 callback,將資訊整理一下。 callback 整理完之後,在 MainActivity 呼叫的地方,就會變成
call.enqueue(object : NetworkCallback<ProfileList>() {
override fun onSuccess(response: ProfileList) {
response.results.forEach {
Log.i("MainActivity", "$it")
}
}
override fun onFailure(
call: Call<ProfileList>,
statusCode: Int,
errorBody: ResponseBody?
) {
Log.e("MainActivity", "statusCode= $statusCode & errorBody= $errorBody")
}
})
看到昨天留下的這個 memo,後來想想只接 1 隻 API 需要還要再嫁接一層嗎? ?
在工作上接的 API 很多,所以會在網路層跟應用層(UI) 中間再加一層,以免某些狀況下,網路層丟上來的東西需要大幅度修改。
想了一下,將畫面及邏輯層的部份切開的架構,反而比架中間層更重要,所以這一個 TODO 就改成 MVP 架構了
View & Presenter 的部份請見 github 程式碼,這邊只列實做完之後的 MainActvitiy
長什麼樣子:
class MainActivity : AppCompatActivity(), MainContract.View {
private var presenter: MainContract.Presenter? = null
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
MainPresenter(this)
presenter?.fetchData()
}
override fun onStop() {
super.onStop()
presenter?.cancelAPIRequest()
}
override fun showProfileList(list: List<Profile>) {
list.forEach {
Log.i("MainActivity", "$it")
}
}
override fun showApiError(errorMessage: String) {
Log.e("MainActivity", errorMessage)
}
override fun setPresenter(presenter: MainContract.Presenter) {
this.presenter = presenter
}
}