Android官方架構組件介紹之LiveData(二)

標籤：override   roi   chm   .com   ted   tran   調用   transform   並且   

LiveData

LiveData是一個用於持有資料並支援資料可被監聽（觀察）。和傳統的觀察者模式中的被觀察者不一樣，LiveData是一個生命週期感知組件，因此觀察者可以指定某一個LifeCycle給LiveData，並對資料進行監聽。

如果觀察者指定LifeCycle處於Started或者RESUMED狀態，LiveData會將觀察者視為活動狀態，並通知其資料的變化。

我們看一段代碼：

public class LocationLiveData extends LiveData<Location> {    private LocationManager locationManager;    private SimpleLocationListener listener = new SimpleLocationListener() {        @Override        public void onLocationChanged(Location location) {            setValue(location);        }    };    public LocationLiveData(Context context) {        locationManager = (LocationManager) context.getSystemService(                Context.LOCATION_SERVICE);    }    @Override    protected void onActive() {        locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, listener);    }    @Override    protected void onInactive() {        locationManager.removeUpdates(listener);    }}

上面有三個值得注意的地方：

• onActive()

當這個方法被調用時，表示LiveData的觀察者數量從0變為了1，這時就我們的位置監聽來說，就應該註冊我們的時間監聽了。

• onInactive()

這個方法被調用時，表示LiveData的觀察者數量變為了0，既然沒有了觀察者，也就沒有理由再做監聽，此時我們就應該將位置監聽移除。

• setValue()

通過調用這個方法來更新LiveData的資料，並通知處於活動狀態的觀察者。

接著我們就能像下面這樣使用LocationLiveData了。

public class MyFragment extends LifecycleFragment {    public void onActivityCreated (Bundle savedInstanceState) {        LiveData<Location> myLocationListener = ...;        Util.checkUserStatus(result -> {            if (result) {                myLocationListener.addObserver(this, location -> {                    // update UI                });            }        });    }}

注意上面的addObserver方法，我們將LifeCycleOwner作為第一個參數傳遞了進去，這表示我們的LocationLiveData將遵照這個Fragment所持有的LifeCycle辦事。

• 如果LifeCycle不在Started或者RESUMED這兩個狀態，那麼觀察者將無法接受到資料更新的回調，即使資料發生了變化。
• 如果LifeCycle銷毀了，即生命週期結束，觀察者將被自動從LiveData中移除。

既然LocationLiveData是生命週期感知的，那麼我們就可以稍微改動一下它的代碼，讓它可以被多個Activity或者Fragment公用：

public class LocationLiveData extends LiveData<Location> {    private static LocationLiveData sInstance;    private LocationManager locationManager;    @MainThread    public static LocationLiveData get(Context context) {        if (sInstance == null) {            sInstance = new LocationLiveData(context.getApplicationContext());        }        return sInstance;    }    private SimpleLocationListener listener = new SimpleLocationListener() {        @Override        public void onLocationChanged(Location location) {            setValue(location);        }    };    private LocationLiveData(Context context) {        locationManager = (LocationManager) context.getSystemService(                Context.LOCATION_SERVICE);    }    @Override    protected void onActive() {        locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, listener);    }    @Override    protected void onInactive() {        locationManager.removeUpdates(listener);    }}

這裡使用單例的原因就是讓多個Activity或者Fragment共用一個LocationLiveData執行個體。
然後我們可以這麼使用：

public class MyFragment extends LifecycleFragment {    public void onActivityCreated (Bundle savedInstanceState) {        Util.checkUserStatus(result -> {            if (result) {                MyLocationListener.get(getActivity()).addObserver(this, location -> {                   // update UI                });            }        });  }}

通過這麼一改，現在即使有多個Activity或者Fragment在使用LocationLiveData，它也能對其進行優雅的管理。不必理會頁面銷毀帶來的諸多麻煩。

總結幾點LiveData的有點：

• 沒有記憶體溢出

當觀察者被綁定他們對應的LifeCycle以後，當頁面銷毀時他們會自動被溢出，不會導致記憶體溢出。

• 不會因為Activity的不可見導致Crash

當Activity不可見時，即使有資料變化，LiveData也不會通知觀察者。因為此時觀察者的LifeCyele並不處於Started或者RESUMED狀態。

• 配置的改變

噹噹前Activity配置改變（如螢幕方向），導致重新從onCreate走一遍，這是觀察者們會立刻收到配置變化前的最新資料。

• 資源共用

我們只需要一個LocationLivaData,串連系統服務一次，就能支援所有的觀察者。

• 不再有人為生命週期處理

通過上面的代碼可以知道，我們的Activity或者Fragment只要在需要觀察資料的時候觀察資料即可，不需要理會生命週期變化了。這一切都交給LiveData來自動管理。

LiveData的轉換

有時候有這樣的需求，需要在LiveData將變化的資料通知給觀察者前，改變資料的類型；或者是返回一個不一樣的LiveData。

這裡介紹一個類Transformations,它可以協助完成上面的這些操作。

• Transformations.map()

在LiveData資料的改變傳遞到觀察者之前，在資料上應用一個方法：

LiveData<User> userLiveData = ...;LiveData<String> userName = Transformations.map(userLiveData, user -> {    user.name + " " + user.lastName});

這裡我們如果只需要知道變化使用者的名字，那麼只要觀察userName這個LiveData對象即可。它會從userLiveData資料中提取使用者名稱並傳遞給它自己的觀察者。

• Transformations.switchMap()

與Transformations.map()類似，只不過這裡傳遞個switchMap()的方法必須返回一個LiveData對象。

private LiveData<User> getUser(String id) {  ...;}LiveData<String> userId = ...;LiveData<User> user = Transformations.switchMap(userId, id -> getUser(id) );

當你考慮在ViewModel中使用LifeCycle對象時，這種轉換就是一個可選的解決方案。
假如有一下需求，使用者輸入一個地址，我們在螢幕上更新這個地址對應的郵編，簡單的寫法如下：

class MyViewModel extends ViewModel {    private final PostalCodeRepository repository;    public MyViewModel(PostalCodeRepository repository) {       this.repository = repository;    }    private LiveData<String> getPostalCode(String address) {       // DON‘T DO THIS       return repository.getPostCode(address);    }}

這樣寫問題顯然很嚴重，當每次調用getPostalCode方法後，UI代碼中都需要對getPostalCode的傳回值做註冊觀察者操作，並且還要移除上一個觀察者，這樣顯然是低效率的。此外，如果這時UI因為配置的變化（旋轉螢幕）重建了，那麼它會觸發再次調用getPostalCode，而不是使用之前的調用結果。

因此我們可以做如下轉換：

class MyViewModel extends ViewModel {    private final PostalCodeRepository repository;    private final MutableLiveData<String> addressInput = new MutableLiveData();    public final LiveData<String> postalCode =            Transformations.switchMap(addressInput, (address) -> {                return repository.getPostCode(address);             });  public MyViewModel(PostalCodeRepository repository) {      this.repository = repository  }  private void setInput(String address) {      addressInput.setValue(address);  }}

注意，這裡我們將postalCode訪問限制符寫成public final，因為它將始終不變，UI只要在需要用的時候將觀察者註冊到postalCode中就行。這是當使用者調用setInput後，如果postalCode上有可活動的觀察者，那麼repository.getPostCode(address)就會被調用，如果此時沒有可活動的觀察者，則repository.getPostCode(address)不會被調用。

自訂轉換

在你的應用中可能需要除了上面兩種以外更多的LiveData的轉換，為了實現這些轉換，你可以使用MediatorLiveData類，它可以用來正確的處理其他多個LiveData的事件變化，並處理這些事件。MediatorLiveData會將自身的active/inactive狀態變化正確的傳遞給它所處理的LiveData，例如MediatorLiveData沒有觀察者的話

 

本文轉自https://www.cnblogs.com/zqlxtt/p/6887940.htm

 

Android官方架構組件介紹之LiveData(二)