Androidの開発者に必要なスキルは、あなたでしょうか？MVVM最新の学習体験！

序文

前の年の上昇MVVM建築デザインパターン、フレームの最も代表的であるDataBinding私は、この時間の短い期間があまりにも人気のデザインアーキテクチャではないかもしれないと思ったので、このアーキテクチャのデザインは非常に革新的ではあるが、まだ使用中、多くの痛みのポイントがあります。

最近、新しいプロジェクトを引き継いで使用されるMVVMだけの努力の1つまたは2つの年を見つけるために、MVVMたとえそうであっても、すぐに開発を、それはすでにAndroidの開発者のために必要なスキルの一つです。

テキスト

DataBinding最初の段階では、私が最も厄介では、データ処理の問題でありました、多くの場合、データを表示するためには、私がしたいXMLに結合しN、複数のフィールド、それはプロジェクトの平均を上回っている場合など、さらに多くの退屈な問題が、あります。

あなたは、XML緊急の必要があるかもしれませんifかswitch、そのような判断を。
予期しないNULLポインタ

2018年には、Googleの打ち上げJetPack図書館、ViewModel+LIveData最終的にはMVVM新たな高みにプッシュ。

ViewModelに

使用ViewModeに頼るリットルの必要性lifecycleライブラリ：

  implementation "android.arch.lifecycle:viewmodel:x.x.x"
  implementation "android.arch.lifecycle:extensions:x.x.x"

ViewModel創造主に2つの方法があります。

  // 获取FragmentActivity共享的ViewModel
  ViewModelProviders.of(FragmentActivity).get(ViewModel::class.java)

  // 获取FragmentActivity共享的ViewModel
  ViewModelProviders.of(Fragment).get(ViewModel::class.java)

ViewModel共有範囲は主に二つある。一つはあるFragmentActivity1がある、Fragmentあなたが自分のニーズに応じて範囲を共有することを選択することができます。必要に応じてApplicationレベルをViewModel、現在サポートされていません、あなたがカスタマイズすることができますApplication保持するためにViewModel、またはシングルトンパターンを使用します。

ViewModelに問題

1、データ共有シナリオの拡張。

一般的なデータ共有でデータ転送、伝統的なアプローチが使用され、この方法は、次のような欠点があります。ActivityFragmentsetArguments(Bundle)

これは、予測できないことができsetArguments意志Fragmentサイクルが異常の判断であることを、完了しました。
setArguments場合、データの変更は、見ることができるActivity直接設定Fragmentデータは、高い結合します。
より多くのデータは、Fragment可読性や保守性に影響を与える多くの変数が存在します。

使用してViewModel、より多くの恥ずかしい事態を避けるために、どのようなデータがあなたから必要とされているViewModelに取ります：

新しい追加のデータ転送、変更することなくコード方式を、受信したデータを書き込みません。ActivitysetArgumentsFragment
関係なく、あなたは、一時的に未使用のコードを削除するかどうかの、データ転送を削減。
データをフェッチする場合、あなたが判断を行うことができ、データの妥当性を注意してください。

また、カスタムはView得ることができますViewModelので、いくつかの機能的結合は非常に強力なカスタムでView容易に開発。しかし、そのノートコンテキストがあるタイプ（されません）、あなただけ使用することができるデータ共有のレベルを。ViewcontextActivityFragmentActivity

ビュー表示をデータバインディングの問題を解決するには2、。

ビューは、大量のデータが必要な場合は、XMLそれはますます肥大化となり、緊急の必要性は、以下のようないくつかの単純な判断を、追加します：

Aが空である場合、Cが空である場合、Bは、最初のCに空である場合に表示されるBは、であり、...

が、DataBinding三項演算子のサポートは判決であればニーズを満たすために、それは明らかであるXMLメンテナンスよりもロジックJavaまたはKotlinはるかに困難（無スペルエラー、など）。だから我々は非常にいくつかのコードを配置する必要がありXML、隔離ViewModelこの役割のために非常に有資格。

改正前：

  <?xml version="1.0" encoding="utf-8"?>
  <layout>
    
      <data>
        
          <variable
                  name="A"
                  type="String" />

          <variable
                  name="B"
                  type="String" />

          <variable
                  name="C"
                  type="String" />
        
        
      </data>

       <TextView
                  android:layout_width="match_parent"
                  android:layout_height="wrap_content"
                  android:maxLines="4"
                  android:ellipsize="middle"
                  android:text="A != null ? A : B != null ? B : C" />
    ...
    
  </layout>

更新：

  <?xml version="1.0" encoding="utf-8"?>
  <layout>

      <data>

          <variable
                  name="viewModel"
                  type="ViewModel" />

      </data>

      <TextView
                  android:layout_width="match_parent"
                  android:layout_height="wrap_content"
                  android:maxLines="4"
                  android:ellipsize="middle"
                  android:text="@{viewModel.getShowContent()}" />
  ...

  </layout>

LiveData

ちょうど今、我々が議論してきたViewModel使用方法の最善の方法を、しかしそこには、問題が解決されないされ、それがデータ更新の問題であり、この問題を解決するには、観察者モードにですが、観察者の登録和解タイに対処しなかった場合は、メモリを起こしやすいですオーバーフロー。LiveDataこれは、この問題の完璧な解決策になることができます。

私たちは、追加する必要がLiveData依存関係を：

  implementation "androidx.lifecycle:lifecycle-livedata:2.1.0"

以下は簡単な例です：

  // 名为openDrawer的Boolean类型的LiveData
  public final MutableLiveData<Boolean> openDrawer = new MutableLiveData<>();

  // 更新openDrawer
  openDrawer.setValue(true)

  // 观察openDrawer 的值的变化
  openDrawer.observe(this, aBoolean -> {
               Toast.makeText(this, "${aBoolean}", Toast.LENGTH_SHORT).show();
          });

LiveDataサブクラスがありMutableLiveData、内部valueプロパティが最新の値、サブスクリプションを保持LiveData変更、直接電話をLiveData.observe()：

公共観察無効（@NonNull LifecycleOwner所有者、@NonNullオブザーバーはオブザーバー<スーパーT？>）
所有者：登録期間は、時に所有者、アンバンドリングオブザーバー破壊されます。
オブザーバー：コールバック関数の観測値が変更されました

owner直接使用するActivityか、Fragmentすることができます。あなたが理解していない場合はLifecycle使用を、あなたは、関連する情報を見ることができます。

概要

最後に、私は何を最新にまとめ、図アーキテクチャを描いたMVVMアーキテクチャを使用します：

Activity：との契約UI問題は、しかし、そうするために可能な限り一貫して使用として避けるべきですDataBinding。
ViewModel：保存ページでは、複雑な機能は、複数の単語に分割することができ、データを必要とします。
DataBinding：処理UIビュー、保留ViewModelデータ表示のために。ページの機能は、より複雑な場合、それができるViewModelとDataBinding再び細分化。