App開發架構指南（谷歌官方文檔譯文）

時間 2019-11-11

原文原文鏈接

這篇文章面向的是已經掌握app開發基本知識，想知道如何開發健壯app的讀者。html

注：本指南假設讀者對 Android Framework 已經很熟悉。若是你仍是app開發的新手，請查看 Getting Started 系列教程，該教程涵蓋了本指南的預備知識。java

app開發者面臨的常見問題

跟傳統的桌面應用開發不一樣，Android app的架構要複雜得多。一個典型的Android app是由多個app組件構成的，包括activity,Fragment,service,content provider以及broadcast receiver。而傳統的桌面應用每每在一個龐大的單一的進程中就完成了。react

大多數的app組件都聲明在app manifest中，Android OS用它來決定如何將你的app與設備整合造成統一的用戶體驗。雖然就如剛說的，桌面app只運行一個進程，可是一個優秀的Android app卻須要更加靈活，由於用戶操做在不一樣app之間，不斷的切換流程和任務。android

好比，當你要在本身最喜歡的社交網絡app中分享一張照片的時候，你能夠想象一下會發生什麼。app觸發一個camera intent，而後Android OS啓動一個camera app來處理這一動做。此時用戶已經離開了社交網絡的app，可是用戶的操做體驗倒是無縫對接的。而 camera app反過來也可能觸發另外一個intent，好比啓動一個文件選擇器，這可能會再次打開另外一個app。最後用戶回到社交網絡app並分享照片。在這期間的任意時刻用戶均可被電話打斷，打完電話以後繼續回來分享照片。git

在Android中，這種app並行操做的行爲是很常見的，所以你的app必須正確處理這些流程。還要記住移動設備的資源是有限的，所以任什麼時候候操做系統都有可能殺死某些app，爲新運行的app騰出空間。github

總的來講就是，你的app組件多是單獨啓動而且是無序的，並且在任什麼時候候都有可能被系統或者用戶銷燬。由於app組件生命的短暫性以及生命週期的不可控制性，任何數據都不該該把存放在app組件中，同時app組件之間也不該該相互依賴。web

通用的架構準則

若是app組件不能存放數據和狀態，那麼app仍是可架構的嗎？數據庫

最重要的一個原則就是儘可能在app中作到separation of concerns（關注點分離）。常見的錯誤就是把全部代碼都寫在Activity或者Fragment中。任何跟UI和系統交互無關的事情都不該該放在這些類當中。儘量讓它們保持簡單輕量能夠避免不少生命週期方面的問題。別忘了能並不擁有這些類，它們只是鏈接app和操做系統的橋樑。根據用戶的操做和其它因素，好比低內存，Android OS可能在任什麼時候候銷燬它們。爲了提供可靠的用戶體驗，最好把對它們的依賴最小化。編程

第二個很重要的準則是用。之因此要持久化是基於兩個緣由：若是OS銷燬app釋放資源，用戶數據不會丟失；當網絡不好或者斷網的時候app能夠繼續工做。Model是負責app數據處理的組件。它們不依賴於View或者app 組件（Activity，Fragment等），所以它們不會受那些組件的生命週期的影響。保持UI代碼的簡單，於業務邏輯分離可讓它更易管理。後端

app架構推薦

在這一小節中，咱們將經過一個用例演示如何使用Architecture Component構建一個app。

注：沒有一種適合全部場景的app編寫方式。也就是說，這裏推薦的架構適合做爲大多數用戶案例的開端。可是若是你已經有了一種好的架構，沒有必要再去修改。

假設咱們在建立一個顯示用戶簡介的UI。用戶信息取自咱們本身的私有的後端REST API。

建立用戶界面

UI由UserProfileFragment.java以及相應的佈局文件user_profile_layout.xml組成。

要驅動UI，咱們的data model須要持有兩個數據元素。

User ID: 用戶的身份識別。最好使用fragment argument來傳遞這個數據。若是OS殺死了你的進程，這個數據能夠被保存下來，因此app再次啓動的時候id還是可用的。

User object: 一個持有用戶信息數據的POJO對象。

咱們將建立一個繼承ViewModel類的UserProfileViewModel來保存這一信息。

一個ViewModel爲特定的UI組件提供數據，好比fragment 或者 activity，並負責和數據處理的業務邏輯部分通訊，好比調用其它組件加載數據或者轉發用戶的修改。ViewModel並不知道View的存在，也不會被configuration change影響。

如今咱們有了三個文件。

user_profile.xml: 定義頁面的UI

UserProfileViewModel.java: 爲UI準備數據的類

UserProfileFragment.java: 顯示ViewModel中的數據與響應用戶交互的控制器

下面咱們開始實現（爲簡單起見，省略了佈局文件）：

public class UserProfileViewModel extends ViewModel {
private String userId;
private User user;
public void init(String userId) {
this.userId = userId;
}
public User getUser() {
return user;
}
}

public class UserProfileFragment extends LifecycleFragment {
private static final String UID_KEY = "uid";
private UserProfileViewModel viewModel;
@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
String userId = getArguments().getString(UID_KEY);
viewModel = ViewModelProviders.of(this).get(UserProfileViewModel.class);
viewModel.init(userId);
}
@Override
public View onCreateView(LayoutInflater inflater,
@Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
return inflater.inflate(R.layout.user_profile, container, false);
}
}

注：上面的例子中繼承的是LifecycleFragment而不是Fragment類。等Architecture Component中的lifecycles API穩定以後，Android Support Library中的Fragment類也將實現LifecycleOwner。

如今咱們有了這些代碼模塊，如何鏈接它們呢？畢竟當ViewModel的user成員設置以後，咱們還須要把它顯示到界面上。這就要用到LiveData了。

LiveData是一個可觀察的數據持有者。無需明確在它與app組件之間建立依賴就能夠觀察LiveData對象的變化。LiveData還考慮了app組件(activities, fragments, services)的生命週期狀態，作了防止對象泄漏的事情。

注：若是你已經在使用RxJava或者Agera這樣的庫，你能夠繼續使用它們，而不使用LiveData。可是使用它們的時候要確保正確的處理生命週期的問題，與之相關的LifecycleOwner stopped的時候數據流要中止，LifecycleOwner destroyed的時候數據流也要銷燬。你也可使用android.arch.lifecycle:reactivestreams讓LiveData和其它的響應式數據流庫一塊兒使用(好比, RxJava2)。

如今咱們把UserProfileViewModel中的User成員替換成LiveData，這樣當數據發生變化的時候fragment就會接到通知。LiveData的妙處在於它是有生命週期意識的，當它再也不被須要的時候會自動清理引用。

public class UserProfileViewModel extends ViewModel {
...
private User user;
private LiveData<User> user;
public LiveData<User> getUser() {
return user;
}
}

如今咱們修改UserProfileFragment，讓它觀察數據並更新UI。

@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
viewModel.getUser().observe(this, user -> {
// update UI
});
}

每當User數據更新的時候 onChanged 回調將被觸發，而後刷新UI。

若是你熟悉其它library的observable callback的用法，你會意識到咱們不須要重寫fragment的onStop()方法中止對數據的觀察。由於LiveData是有生命週期意識的，也就是說除非fragment處於活動狀態，不然callback不會觸發。LiveData還能夠在fragmentonDestroy()的時候自動移除observer。

對咱們也沒有作任何特殊的操做來處理 configuration changes（好比旋轉屏幕）。ViewModel能夠在configuration change的時候自動保存下來，一旦新的fragment進入生命週期，它將收到相同的ViewModel實例，而且攜帶當前數據的callback將當即被調用。這就是爲何ViewModel不該該直接引用任何View，它們遊離在View的生命週期以外。參見ViewModel的生命週期。

獲取數據

如今咱們把ViewModel和fragment聯繫了起來，可是ViewModel該如何獲取數據呢？在咱們的例子中，假設後端提供一個REST API，咱們使用Retrofit從後端提取數據。你也可使用任何其它的library來達到相同的目的。

下面是和後端交互的retrofit Webservice：

public interface Webservice {
/**
* @GET declares an HTTP GET request
* @Path("user") annotation on the userId parameter marks it as a
* replacement for the {user} placeholder in the @GET path
*/
@GET("/users/{user}")
Call<User> getUser(@Path("user") String userId);
}

ViewModel的一個簡單的實現方式是直接調用Webservice獲取數據，而後把它賦值給User對象。雖然這樣可行，可是隨着app的增大會變得難以維護。ViewModel的職責過多也違背了前面提到的關注點分離（separation of concerns）原則。另外，ViewModel的有效時間是和Activity和Fragment的生命週期綁定的，所以當它的生命週期結束便丟失全部數據是一種很差的用戶體驗。相反，咱們的ViewModel將把這個工做代理給Repository模塊。

Repository模塊負責處理數據方面的操做。它們爲app提供一個簡潔的API。它們知道從哪裏獲得數據以及數據更新的時候調用什麼API。你能夠把它們當作是不一樣數據源（persistent model, web service, cache, 等等）之間的媒介。

下面的UserRepository類使用了WebService來獲取用戶數據。

public class UserRepository {
private Webservice webservice;
// ...
public LiveData<User> getUser(int userId) {
// This is not an optimal implementation, we'll fix it below
final MutableLiveData<User> data = new MutableLiveData<>();
webservice.getUser(userId).enqueue(new Callback<User>() {
@Override
public void onResponse(Call<User> call, Response<User> response) {
// error case is left out for brevity
data.setValue(response.body());
}
});
return data;
}
}

雖然repository模塊看起來沒什麼必要，但它其實演扮演着重要的角色；它把數據源從app中抽象出來。如今咱們的ViewModel並不知道數據是由Webservice提供的，意味着有必要的話能夠替換成其它的實現方式。

注：爲簡單起見咱們省略了網絡錯誤出現的狀況。實現了暴露網絡錯誤和加載狀態的版本見下面的Addendum: exposing network status。

管理不一樣組件間的依賴：

前面的UserRepository類須要Webservice的實例才能完成它的工做。能夠直接建立它就是了，可是爲此咱們還須要知道Webservice所依賴的東西才能構建它。這顯著的增減了代碼的複雜度和偶合度（好比，每一個須要Webservice實例的類都須要知道如何用它的依賴去構建它）。另外，UserRepository極可能不是惟一須要Webservice的類。若是每一個類都建立一個新的WebService，就變得很重了。

有兩種模式能夠解決這個問題：

依賴注入: 依賴注入容許類在無需構造依賴的狀況下定義本身的依賴對象。在運行時由另外一個類來負責提供這些依賴。在Android app中咱們推薦使用谷歌的Dagger 2來實現依賴注入。Dagger 2 經過遍歷依賴樹自動構建對象，並提供編譯時的依賴。

Service Locator：Service Locator 提供一個registry，類能夠從這裏獲得它們的依賴而不是構建它們。相對依賴注入來講要簡單些，因此若是你對依賴注入不熟悉，可使用 Service Locator 。

這些模式容許你擴展本身的代碼，由於它們提供了清晰的模式來管理依賴，而不是不斷的重複代碼。二者均支持替換成mock依賴來測試，這也是使用它們主要優點之一。

在這個例子中，咱們將使用 Dagger 2 來管理依賴。

鏈接ViewModel和repository

如今咱們修改UserProfileViewModel以使用repository。

public class UserProfileViewModel extends ViewModel {
private LiveData<User> user;
private UserRepository userRepo;
@Inject // UserRepository parameter is provided by Dagger 2
public UserProfileViewModel(UserRepository userRepo) {
this.userRepo = userRepo;
}
public void init(String userId) {
if (this.user != null) {
// ViewModel is created per Fragment so
// we know the userId won't change
return;
}
user = userRepo.getUser(userId);
}
public LiveData<User> getUser() {
return this.user;
}
}

緩存數據

上面的repository對抽象web service調用是很好的，可是由於它只依賴於一個數據源，並非很是實用。

UserRepository的問題在於當獲取完數據以後，它並無把數據保存下來。若是用戶離開UserProfileFragment而後在回來，app會從新獲取數據。這是很很差的，緣由有二：1.浪費了帶寬資源，2.用戶被迫等待新的查詢完成。爲了解決這個問題，咱們向UserRepository中添加了一個新的數據源，它將把User對象緩存到內存中。

@Singleton // informs Dagger that this class should be constructed once
public class UserRepository {
private Webservice webservice;
// simple in memory cache, details omitted for brevity
private UserCache userCache;
public LiveData<User> getUser(String userId) {
LiveData<User> cached = userCache.get(userId);
if (cached != null) {
return cached;
}
final MutableLiveData<User> data = new MutableLiveData<>();
userCache.put(userId, data);
// this is still suboptimal but better than before.
// a complete implementation must also handle the error cases.
webservice.getUser(userId).enqueue(new Callback<User>() {
@Override
public void onResponse(Call<User> call, Response<User> response) {
data.setValue(response.body());
}
});
return data;
}
}

持久化數據

目前的實現中，若是用戶旋轉屏幕或者是離開以後再次回到app，UI將當即可見，由於repository是從常駐內存的緩存中獲取的數據。可是若是用戶離開了app，幾個小時以後再回來時進程已經被殺死了怎麼辦呢？

以目前的實現來看，咱們須要再次從網絡獲取數據。這不只僅是糟糕的用戶體驗，仍是一種浪費，由於它須要花費移動流量獲取相同的數據。你能夠直接緩存web請求，可是這又產生了新的問題。若是一樣的user數據來自於另外一個類型的請求呢（好比獲取一個朋友的列表）？那樣的話你的app極可能會顯示不一致的數據，這是一種困惑的用戶體驗。例如，由於朋友列表請求與用戶請求可能在不一樣的時間執行，同一用戶的數據可能會不一致。你的app須要融合它們以免數據出現不一致。

處理這個問題的正確方式是使用持久化的model。持久化庫Room就是爲此而生。

Room是一個對象關係映射庫，以最少的代碼提供本地數據持久化功能。它在編譯時驗證每一個查詢，因此損壞的SQL查詢只會致使編譯時錯誤而不是運行時崩潰。Room抽象了部分SQL查詢與表的相關操做的底層細節。它還可讓你經過一個LiveData對象監聽到數據庫數據的變化。另外，它還明肯定義了線程約束，解決了諸如從主線程獲取存儲這樣的常見的問題。

注：若是熟悉其它的持久化方案好比SQLite ORM或者是一個不一樣的數據庫，如Realm，你不須要把它替換成Room，除非Room的特性對你的用例而言更加劇要。

要使用Room，咱們須要定義本地的schema。首先使用@Entity註解User類，將它標記爲數據庫中的一張表。

@Entity
class User {
@PrimaryKey
private int id;
private String name;
private String lastName;
// getters and setters for fields
}

而後經過繼承RoomDatabase建立一個database類：

@Database(entities = {User.class}, version = 1)
public abstract class MyDatabase extends RoomDatabase {
}

注意MyDatabase是抽象類。Room根據它自動提供一個實現。詳細狀況參見Room文檔。

如今咱們須要一個向數據庫插入數據的方法。爲此建立一個data access object (DAO)。

@Dao
public interface UserDao {
@Insert(onConflict = REPLACE)
void save(User user);
@Query("SELECT * FROM user WHERE id = :userId")
LiveData<User> load(String userId);
}

而後，在database類中引用DAO。

@Database(entities = {User.class}, version = 1)
public abstract class MyDatabase extends RoomDatabase {
public abstract UserDao userDao();
}

注意load方法返回的是LiveData。Room知道database何時被修改過，當數據變化的時候，它將自動通知全部處於活動狀態的observer。

注：對於alpha 1 版本，Room是根據表的修改檢查驗證，所以可能會發送錯誤的信號。

如今咱們能夠修改UserRepository以和Room協同工做。

@Singleton
public class UserRepository {
private final Webservice webservice;
private final UserDao userDao;
private final Executor executor;
@Inject
public UserRepository(Webservice webservice, UserDao userDao, Executor executor) {
this.webservice = webservice;
this.userDao = userDao;
this.executor = executor;
}
public LiveData<User> getUser(String userId) {
refreshUser(userId);
// return a LiveData directly from the database.
return userDao.load(userId);
}
private void refreshUser(final String userId) {
executor.execute(() -> {
// running in a background thread
// check if user was fetched recently
boolean userExists = userDao.hasUser(FRESH_TIMEOUT);
if (!userExists) {
// refresh the data
Response response = webservice.getUser(userId).execute();
// TODO check for error etc.
// Update the database.The LiveData will automatically refresh so
// we don't need to do anything else here besides updating the database
userDao.save(response.body());
}
});
}
}

雖然咱們在UserRepository中改變了數據來源，可是咱們不須要修改UserProfileViewModel或者UserProfileFragment。這就是抽象帶來的靈活性。這對測試一樣有好處，由於你能夠提供一個假的UserRepository來測試UserProfileViewModel。

如今咱們的代碼就完成了。若是用戶稍後回到相同的界面，將當即看到用戶信息，由於這些信息作了持久化。同時，若是數據過於陳舊，repository將在後臺更新數據。固然，這取決於你的案例，你可能會喜歡在數據太老的狀況下不顯示持久化的數據。

在某些狀況下，好比下拉刷新，在界面上顯示當前是否正在進行網絡操做是很重要的。把UI操做和和實際數據分離是一種很好的實踐，由於它可能由於各類緣由而更新（好比，若是咱們獲取一個朋友的列表，同一用戶可能被再次獲取，從而觸發一個 LiveData<User> update）。

這個問題有兩種經常使用的解決辦法：

把getUser修改爲返回包含了網絡操做狀態的LiveData。附: 暴露網絡狀態小節中提供了一個實現了的例子。
在repository類中另外提供一個能夠返回User刷新狀態的公共的函數。若是隻是爲了明確的響應用戶操做而在界面上顯示網絡狀態（(好比 pull-to-refresh).），這種方式更好些。

單一數據源（Single source of truth）

不一樣的後端REST API返回相同的數據是很常見的事情。好比，若是有一個另外的後端地址返回一個朋友的列表，那麼相同的User對象就有可能來自兩個不一樣的API地址，也許連內容詳細程度都不同。若是UserRepository直接返回 Webservice 請求的響應，咱們的UI就有可能顯示不一致，由於服務端的兩個請求之間數據是有區別的。這就是爲何在UserRepository的實現中，web service 的回調只是把數據保存在數據庫中。而後數據庫中的變化將觸發LiveData對象的callback。

在這個模型中，database就是這裏的單一數據源（Single source of truth），其它部分都是經過repository獲取它。無論你是不是使用磁盤緩存，咱們都推薦你的repository指明一個能夠做爲single source of truth數據源供app其它部分使用。

最終架構

下面的圖標顯示了咱們所推薦的架構的全部模塊以及它們之間是如何交互的：

指導原則

編程是一種創造性的勞動，開發Android app也不例外。同一問題有許多種解決辦法，無論是activity或者fragment之間的數據交互，仍是獲取遠程數據並緩存到本地，仍是一個有必定規模的app可能遇到的其它常見問題。
雖然下面的建議不是強制性的，但根據咱們以往的經驗，從長遠來看，遵照它們可讓你的代碼更加健壯，更加易於測試和維護。
manifest定義的入口－activity, service, broadcast receiver..等等，都不是數據源，它們只應該和與該入口相關的數據協做。由於每一個app組件的生命都很是短暫，取決於用戶的行爲以及設備運行時的情況，你確定不會但願把它們做爲數據源。
app不一樣模塊之間要有明確的責任邊界。好比，不要把加載網絡數據的代碼分散到不一樣的類或者包中。一樣，也不要把不相關的職責－好比數據緩存和數據綁定－放在一個類中。
每一個模塊暴露的細節越少越好。不要圖一時爽快把模塊的內部實現暴露出來。你可能當時節省了一點時間，但隨着代碼的演變，你可能會付出不知翻了多少倍的技術債。
在定義模塊之間的交互時，思考如何作到各個模塊的獨立和可測試。好比，一個設計良好的網絡數據請求API可讓緩存數據到本地數據庫模塊的測試更加簡單。而若是把這兩個模塊的邏輯混到一塊兒，或者把網絡請求的代碼分散到代碼的各處，都會使測試變得很難。
app的核心應該可讓app脫穎而出的那些東西，不要把時間花在重複造輪子和反覆寫相同代碼的事情上。相反，你應該把本身的精力集中到如何使app獨一無二上。重複的工做就交給Android Architecture Components以及推薦的庫來處理吧。
儘量的持久化重要的，新生的數據，以便讓你的app在離線狀態下均可用。雖然你可能享受着高速的網絡，但你的用戶也許不是。
repository應該指派一個能夠用做single source of truth的數據源。每當app須要獲取一塊數據的時候，它老是來自這個single source of truth。更多的信息參見上面的Single source of truth。

附：暴露網絡狀態

在前面app架構推薦一節中，爲了保持例子的簡單，咱們有意省略了網絡錯誤以及加載狀態。這一節咱們將演示一種暴露網絡狀態的方法，使用一個Resource類來封裝數據以及數據的狀態。

下面是一個實現的例子：

//a generic class that describes a data with a status
public class Resource<T> {
@NonNull public final Status status;
@Nullable public final T data;
@Nullable public final String message;
private Resource(@NonNull Status status, @Nullable T data, @Nullable String message) {
this.status = status;
this.data = data;
this.message = message;
}
public static <T> Resource<T> success(@NonNull T data) {
return new Resource<>(SUCCESS, data, null);
}
public static <T> Resource<T> error(String msg, @Nullable T data) {
return new Resource<>(ERROR, data, msg);
}
public static <T> Resource<T> loading(@Nullable T data) {
return new Resource<>(LOADING, data, null);
}
}

由於從網絡加載數據而顯示從磁盤讀出的數據是一種常見的用例，咱們將建立一個能夠在多個地方重用的helper類：NetworkBoundResource。

下面是NetworkBoundResource的決策樹：

首先從監聽database獲取resource開始。當第一次從數據庫加載的時候，NetworkBoundResource檢查獲得的結果是否能夠分發或者須要從網絡獲取。注意這二者可能同時發生，由於當從網絡更新緩存數據的時候每每還須要顯示數據。

若是網絡調用成功完成，將響應結果保存到數據庫中，而後從新初始化數據流。若是請求失敗，咱們直接發出一個錯誤信號。

下面是NetworkBoundResource類爲其子類提供的公共API：

// ResultType: Type for the Resource data
// RequestType: Type for the API response
public abstract class NetworkBoundResource<ResultType, RequestType> {
// Called to save the result of the API response into the database
@WorkerThread
protected abstract void saveCallResult(@NonNull RequestType item);
// Called with the data in the database to decide whether it should be
// fetched from the network.
@MainThread
protected abstract boolean shouldFetch(@Nullable ResultType data);
// Called to get the cached data from the database
@NonNull @MainThread
protected abstract LiveData<ResultType> loadFromDb();
// Called to create the API call.
@NonNull @MainThread
protected abstract LiveData<ApiResponse<RequestType>> createCall();
// Called when the fetch fails. The child class may want to reset components
// like rate limiter.
@MainThread
protected void onFetchFailed() {
}
// returns a LiveData that represents the resource
public final LiveData<Resource<ResultType>> getAsLiveData() {
return result;
}
}

注意上面的類定義了兩個類型的參數(ResultType,RequestType)，由於API返回的數據類型可能和本地使用的數據類型不一致。

同時注意上面的代碼使用了 ApiResponse 做爲網絡請求， ApiResponse 是對Retrofit2.Call 類的簡單封裝，用於將其響應轉換爲LiveData。

下面是NetworkBoundResource類其他的實現：

public abstract class NetworkBoundResource<ResultType, RequestType> {
private final MediatorLiveData<Resource<ResultType>> result = new MediatorLiveData<>();
@MainThread
NetworkBoundResource() {
result.setValue(Resource.loading(null));
LiveData<ResultType> dbSource = loadFromDb();
result.addSource(dbSource, data -> {
result.removeSource(dbSource);
if (shouldFetch(data)) {
fetchFromNetwork(dbSource);
} else {
result.addSource(dbSource,
newData -> result.setValue(Resource.success(newData)));
}
});
}
private void fetchFromNetwork(final LiveData<ResultType> dbSource) {
LiveData<ApiResponse<RequestType>> apiResponse = createCall();
// we re-attach dbSource as a new source,
// it will dispatch its latest value quickly
result.addSource(dbSource,
newData -> result.setValue(Resource.loading(newData)));
result.addSource(apiResponse, response -> {
result.removeSource(apiResponse);
result.removeSource(dbSource);
//noinspection ConstantConditions
if (response.isSuccessful()) {
saveResultAndReInit(response);
} else {
onFetchFailed();
result.addSource(dbSource,
newData -> result.setValue(
Resource.error(response.errorMessage, newData)));
}
});
}
@MainThread
private void saveResultAndReInit(ApiResponse<RequestType> response) {
new AsyncTask<Void, Void, Void>() {
@Override
protected Void doInBackground(Void... voids) {
saveCallResult(response.body);
return null;
}
@Override
protected void onPostExecute(Void aVoid) {
// we specially request a new live data,
// otherwise we will get immediately last cached value,
// which may not be updated with latest results received from network.
result.addSource(loadFromDb(),
newData -> result.setValue(Resource.success(newData)));
}
}.execute();
}
}