Kotlinでの最新のAndroid開発。 パート2

こんにちは、Habr！ Mladen Rakonjacによる記事「 Kotlinによる最新のAndroid開発（パート2） 」の翻訳を紹介します。



ご注意 この記事は、 Mladen Rakonjacの一連の記事の翻訳です（記事日付： 2017年9月23日）。 Github SemperPeritusの最初の部分を読み始めたので、残りの部分が何らかの理由で翻訳されていないことを発見しました。 したがって、私はあなたの注意に第二部をもたらします。 記事は膨大であることが判明しました。







「Android Studio 3.0でAndroidの開発のすべてをカバーするプロジェクトを見つけるのは非常に難しいので、私はそれを書くことにしました。」



この記事では、以下を分析します。

1. Android Studio 3ベータ1 パート1
2. Kotlinプログラミング言語パート1
3. ビルドオプションパート1
4. ConstraintLayout パート1
5. データバインディングライブラリパート1
6. MVVMアーキテクチャ+リポジトリ+ Androidマネージャーラッパーパターン
7. RxJava2とそれがパート3アーキテクチャでどのように役立つか
8. Dagger 2.11、依存性注入とは何ですか、このパート4を使用する理由
9. レトロフィット（Rx Java2を使用）
10. ルーム（Rx Java2を使用）

MVVMアーキテクチャ+リポジトリ+ Androidマネージャーラッパーパターン

Androidの世界のアーキテクチャについて一言

かなり長い間、Android開発者はプロジェクトでアーキテクチャを使用していません。 過去3年間で、Android開発者のコ​​ミュニティで彼女の周りに多くの誇大宣伝が出てきました。 God Activityの時代は過ぎ去り、GoogleはAndroid Architecture Blueprintsリポジトリを公開しました。これには、さまざまなアーキテクチャアプローチに関する多くの例と指示が含まれています。 最後に、Google IO '17で、彼らはAndroid Architecture Componentsを導入しました。これは、よりクリーンなコードの作成とアプリケーションの改善を支援するために設計されたライブラリのコレクションです。 コンポーネントは、それらのすべてを使用することも、1つだけを使用することもできると言います。 しかし、それらはすべて非常に有用であることがわかりました。 さらに本文と以下の部分でそれらを使用します。 まず、コードの問題に取り組み、次にこれらのコンポーネントとライブラリを使用してリファクタリングし、解決すべき問題を確認します。



GUIコードを共有する2つの主要なアーキテクチャパターンがあります。

• MVP
• MVVM

どちらが良いかを言うのは難しいです。 両方を試して決定する必要があります。 ライフサイクル対応のコンポーネントを使用するMVVMを好み、それについて書きます。 MVPを使用したことがない場合は、Mediumでこれに関する多くの優れた記事があります。

MVVMパターンとは何ですか？

MVVMは、Model-View-ViewModelとして拡張されるアーキテクチャパターンです。 この名前は開発者を混乱させると思います。 私が彼の名前を思いついたのであれば、 ViewModelはViewとModelを接続しているため、 ViewModelを View-ViewModel-Modelと呼びます。



ビューは、 アクティビティ 、 フラグメント、またはその他のカスタムビュー（ Androidカスタムビュー ）の抽象化です。 このビューとAndroidビューを混同しないことが重要です。 ビューは馬鹿げているべきであり、それにロジックを書くべきではありません。 ビューにデータを含めることはできません。 ViewModelインスタンスへの参照と、 Viewが必要とするすべてのデータをそこから格納する必要があります。 さらに、 ビューはこのデータを監視する必要があり、 ViewModelのデータが変更されるとレイアウトが変更される必要があります。 要約すると、 Viewは次の役割を果たします。さまざまなデータと状態のレイアウトビュー。



ViewModelは、データとロジックを含むクラスの抽象名です。このデータを受信するタイミングと表示するタイミングです。 ViewModelは現在の状態を保存します 。 ViewModelは、1つ以上のModelへのリンクも保存し、それらからすべてのデータを受け取ります。 たとえば、データがどこから来たのか、データベースから来たのか、サーバーから来たのかを知るべきではありません。 さらに、 ViewModelはViewについて何も知る必要がありません。 さらに、 ViewModelはAndroidフレームワークについて何も知らないはずです。



Modelは、 ViewModelのデータを準備するレイヤーの抽象名です。 これは、サーバーからデータを受信して​​キャッシュするか、ローカルデータベースに保存するクラスです。 これらは、User、Car、Square、単純にデータを保存する他のモデルクラスと同じクラスではないことに注意してください。 原則として、これはリポジトリテンプレートの実装であり、後で検討します。 モデルはViewModelについて何も知らないはずです。



MVVMは 、正しく実装されていれば、コードを破壊してテストしやすくする優れた方法です。 これにより、 SOLID原則に従うことができるため、コードの保守が容易になります。

コード例

次に、これがどのように機能するかを示す簡単な例を作成します。



始めるために、行を返す簡単なモデルを作成しましょう：





通常、データ取得は非同期呼び出しであるため、待機する必要があります。 これをシミュレートするために、クラスを次のように変更しました。





onDataReady



メソッドでOnDataReadyCallback



インターフェイスを作成しました。 そして今、 refreshData



メソッドはrefreshData



を実装（実装）していOnDataReadyCallback



。 待機をシミュレートするには、 Handler



を使用します。 2秒に1 onDataReady



、 OnDataReadyCallback



インターフェイスを実装するクラスでonDataReady



メソッドが呼び出されます。



ViewModelを作成しましょう：





ご覧のRepoModel



、 text



されるRepoModel



、 text



インスタンス、および現在の状態を格納する変数isLoading



があります。 データを取得するrefresh



メソッドを作成しましょう。





refresh



メソッドは、引数にOnDataReadyCallback



実装をとるRepoModel



でrefreshData



を呼び出します。 わかりましたが、 object



とは何ですか？ インターフェイスを実装するか、サブクラス化せずに拡張クラスを継承する場合は常に、 オブジェクト宣言を使用します 。 そして、これを匿名クラスとして使用したい場合は？ この場合、 オブジェクト式を使用しています ：





refresh



を呼び出すときは、ビューを読み込み状態に変更し、データが到着しisLoading



をfalse



に設定するisLoading



がありfalse



。



また、 text



を

 ObservableField<String>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

、およびisLoading



on

 ObservableField<Boolean>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

。 ObservableField



は、Observableオブジェクトを作成する代わりに使用できるデータバインディングライブラリのクラスであり、監視するオブジェクトをラップします。





varの代わりにvalを使用していることに注意してください。フィールドの値のみを変更し、フィールド自体は変更しないためです。 また、初期化する場合は、次を使用します。







テキストとisLoadingを監視できるようにレイアウトを変更しましょう。 開始するには、 RepositoryではなくMainViewModelをバインドします 。





次に：

• TextViewを変更して、MainViewModelからのテキストを監視します
• isLoading trueの場合にのみ表示されるProgressBarを追加します
• [追加]ボタン。クリックすると、 MainViewModelからrefreshメソッドが呼び出され、 isLoading falseの場合にのみクリック可能になります。

ここで実行すると、 View.VISIBLE and View.GONE cannot be used if View is not imported



、 View.VISIBLE and View.GONE cannot be used if View is not imported



。 さて、インポートしましょう：





OK、レイアウトの完成です。 バインディングを終了します。 前にも言ったように、 View



はViewModel



インスタンスが必要です。







古いデータが 新しいデータに置き換えられていることがわかります 。



これは単純なMVVMの例です。





古いデータが新しい データを置き換えました 。 これはどのように可能ですか？ アクティビティのライフサイクルを見てください。





電話をオンにすると、アクティビティの新しいインスタンスが作成され、 onCreate()



メソッドが呼び出されました。 私たちの活動を見てください：





ご覧のとおり、Activityインスタンスが作成されると、 MainViewModelインスタンスも作成されます。 どういうわけか、再作成されたMainActivityごとにMainViewModelの同じインスタンスがあればいいですか？

ライフサイクル対応コンポーネントの概要

なぜなら 多くの開発者がこの問題に直面しているため、Android Frameworkチームの開発者は、この問題を解決するために設計されたライブラリを作成することにしました。 ViewModelクラスはその1つです。 これは、すべてのViewModelが継承するクラスです。



ライフサイクル対応コンポーネントのViewModelからMainViewModelを継承しましょう。 最初に、 ライフサイクル対応コンポーネントライブラリをbuild.gradleファイルに追加する必要があります。





MainViewModelをViewModel の継承者にします 。





MainActivityのonCreate（）メソッドは次のようになります。





MainViewModelの新しいインスタンスを作成しなかったことに注意してください。 ViewModelProvidersを使用して取得します。 ViewModelProvidersは、 ViewModelProviderを取得するメソッドを持つUtilityクラスです。 それはすべてscopeに関するものです。 アクティビティでViewModelProviders.of（this）を呼び出すと、 ViewModelは、このアクティビティが生きている限り（再作成せずに破棄されるまで）生き続けます。 したがって、これをフラグメントで呼び出すと、フラグメントが生きている間、 ViewModelは生き続けます。 図を見てください：





ViewModelProviderは、最初の呼び出しで新しいインスタンスを作成するか、アクティビティまたはフラグメントが再作成された場合に古いインスタンスを返します。



と混同しないでください

 MainViewModel::class.java
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コトリンでは、従うなら

 MainViewModel::class
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより 、JavaのClassとは異なるKClassが返されます。 .javaを記述すると、ドキュメントによると：

KClassのこのインスタンスに対応するJava クラスのインスタンスを返します

画面の回転前と同じデータがあります。



前回の記事で、アプリケーションがGithubリポジトリのリストを取得して表示すると述べました。 これを行うには、リポジトリの偽のリストを返すgetRepositories関数を追加する必要があります。





RepoModelからgetRepositoriesを呼び出すMainViewModelのメソッドも必要です 。





最後に、RecyclerViewでこれらのリポジトリを表示する必要があります。 これを行うには、以下を行う必要があります。

• レイアウトrv_item_repository.xmlを作成します
• レイアウトactivity_main.xmlにRecyclerViewを追加します
• RepositoryRecyclerViewAdapterを作成する
• recyclerviewでアダプターをインストールする

rv_item_repository.xmlを作成するには、CardViewライブラリを使用したため、build.gradle（アプリ）に追加する必要があります。

 implementation 'com.android.support:cardview-v7:26.0.1'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは次のようなものです。





次のステップは、RecyclerViewをactivity_main.xmlに追加することです。 これを行う前に、RecyclerViewライブラリを追加してください：

 implementation 'com.android.support:recyclerview-v7:26.0.1'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一部のTextView要素を削除し、ボタンがrefreshではなくloadRepositoriesを起動することに注意してください。





不要な場合は、 MainViewModelからrefreshメソッドを、 RepoModelからrefreshDataを削除しましょう。



次に、RecyclerViewのアダプターを作成する必要があります。





ViewHolderはViewではなくRvItemRepositoryBinding型のインスタンスを取るため、各要素のViewHolderにデータバインディングを実装できることに注意してください。 単一行機能（1行）に困らないでください。

 override fun onBindViewHolder(holder: ViewHolder, position: Int) = holder.bind(items[position], listener)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、以下の短いエントリーです。

 override fun onBindViewHolder(holder: ViewHolder, position: Int){ return holder.bind(items[position], listener) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、 items [position]はインデックス演算子の実装です。 items.get（position）に似ています。



あなたを混乱させるかもしれない別の行：

 binding.root.setOnClickListener({ _ -> listener.onItemClick(layoutPosition) })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

使用していない場合は、パラメーターを_に置き換えることができます。 いいですね



アダプタを作成しましたが、 MainActivityのrecyclerViewにはまだ適用していません。







これは変です。 どうしたの？

• アクティビティが作成されたため、事実上空のリポジトリで新しいアダプタも作成されました
• ボタンを押す
• loadRepositoriesを呼び出し、進行状況を表示
• 2秒後、リポジトリが取得され、進行状況は非表示になりますが、表示されません。 これは、 notifyDataSetChangedがアダプターで呼び出されないためです。
• 画面を回転させると、新しいアクティビティが作成されます。そのため、 repositoriesパラメーターとデータを含む新しいアダプターが作成されます

したがって、 MainViewModelはMainActivityに新しいアイテムを通知する必要があるため、 notifyDataSetChangedを呼び出すことができますか？



できません。



これは本当に重要です。MainViewModelはMainActivityをまったく知らないはずです。



MainActivityはMainViewModelのインスタンスを持っているため、変更をリッスンし、 アダプターに変更を通知する必要があります。



しかし、それを行う方法は？



リポジトリーを観察できるため、データを変更した後、アダプターを変更できます。



この決定の何が問題になっていますか？



次のケースを見てみましょう。

• MainActivityでは 、リポジトリを観察します。変更が発生すると、 notifyDataSetChangedを実行します
• ボタンを押す
• データの変更を待っている間に、 構成の変更によりMainActivityが再作成される場合があります。
• MainViewModelはまだ生きています
• 2秒後、 リポジトリフィールドは新しいアイテムを受け取り、データが変更されたことをオブザーバーに通知します
• オブザーバーは、もう存在しないアダプターでnotifyDataSetChangedを実行しようとします。 MainActivityが再作成されました

まあ、私たちの決定は十分ではありません。

LiveDataの概要

LiveDataは、 ライフサイクルを認識する別のコンポーネントであり 、Viewライフサイクルについて知っているオブザーバブルに基づいています。 そのため、構成の変更によりActivityが破棄された場合、 LiveDataはそれを認識しているため、破棄されたActivityからオブザーバーも削除します。



MainViewModelで実装します 。





MainActivityの監視を開始します。





それはどういう意味ですか？ 関数にパラメーターが1つしかない場合、このパラメーターへのアクセスは、itキーワードを使用して取得できます。 したがって、2を掛けるラムダ式があるとします。

 ((a) -> 2 * a)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のように置き換えることができます。

 (it * 2)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...

なぜMVPよりもMVVMを好むのですか？

• Viewには退屈なインターフェイスはありません。 ViewModelにはViewへの参照がありません
• Presenterには退屈なインターフェイスはありません。これは必要ありません
• 構成変更の処理がはるかに簡単
• MVVMを使用すると、アクティビティ、フラグメントなどのコードが少なくなります。

...

リポジトリパターン

先ほど言ったように、 Modelはデータを準備しているレイヤーの単なる抽象名です。 通常、リポジトリとデータクラスが含まれます。 各エンティティ（データ）クラスには、対応するリポジトリクラスがあります。 たとえば、 UserクラスとPostクラスがある場合、 UserRepositoryとPostRepositoryも必要です 。 すべてのデータはそこから取得されます。 ViewまたはViewModelからShared PreferencesまたはDBのインスタンスを呼び出さないでください。



そのため、RepoModelの名前をGitRepoRepositoryに変更できます。GitRepoはGithubリポジトリから取得し、Repositoryはリポジトリパターンから取得します。





わかりました。MainViewModelはGitRepoRepsitoriesからリポジトリのGithubリストを取得しますが、 GitRepoRepositoriesはどこから取得しますか？



インスタンスからリポジトリでクライアントまたはDBを直接呼び出すことができますが、これはまだベストプラクティスではありません。 アプリケーションはできるだけモジュール化する必要があります。 VolleyをRetrofitに置き換えるために別のクライアントを使用することにした場合はどうなりますか？ 内部に何らかのロジックがある場合、リファクタリングを行うのは困難です。 リポジトリは、リモートデータの取得に使用しているクライアントを知る必要はありません。

• リポジトリが知る必要があるのは、データがリモートまたはローカルに到着することだけです。 このリモートまたはローカルデータを取得する方法を知る必要はありません。
• 必要なビューモデルはデータのみです
• ビューが行うべきことは、このデータを表示することだけです。

Androidでの開発を始めたばかりの頃、アプリケーションがオフラインでどのように機能し、データ同期がどのように機能するのかと思っていました。 優れたアプリケーションアーキテクチャにより、これを簡単に行うことができます。 たとえば、インターネット接続がある場合にViewModelの loadRepositoriesが呼び出されると、 GitRepoRepositoriesはリモートデータソースからデータを受信し、ローカルデータソースに保存できます。 電話がオフラインのとき、 GitRepoRepositoryはローカルストレージからデータを受信できます。 そのため、 リポジトリにはRemoteDataSourceおよびLocalDataSourceのインスタンスと、このデータの取得元であるロジック処理が必要です。



ローカルデータソースを追加します 。





ここには2つの方法があります。1つ目は偽のローカルデータを返す方法で、2つ目は架空のデータストレージ用です。



リモートデータソースを追加します 。





偽のリモートデータを返すメソッドは1つだけです。



これで、リポジトリにいくつかのロジックを追加できます。





したがって、ソースを共有すると、データをローカルに簡単に保存できます。



ネットワークからのデータのみが必要な場合でも、リポジトリテンプレートを使用する必要がありますか？ はい これにより、コードのテストが容易になり、他の開発者がコードをよりよく理解できるようになり、より迅速にサポートできます！



...

Androidマネージャーラッパー

GitRepoRepositoryでインターネット接続を確認して、どこからデータをリクエストするかを知りたい場合はどうしますか？ViewModelとModelにAndroid関連のコードを配置するべきではないと既に述べたので、この問題にどのように対処しますか？



インターネット接続用のラッパーを作成しましょう。





このコードは、マニフェストにアクセス許可を追加した場合にのみ機能します。

 <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

我々は、コンテキスト（持っていない場合しかし、どのように、リポジトリ内のインスタンスを作成するコンテキストザ・を）？コンストラクタでリクエストできます：





ViewModelのGitRepoRepositoryの新しいインスタンスの前に作成しました。NetManagerのコンテキストが必要なときに、ViewModelにNetManagerを含めるにはどうすればよいですか？コンテキストを持つLifecycle対応コンポーネントライブラリのAndroidViewModelを使用できます。これはアプリケーションのコンテキストであり、アクティビティではありません。





この行で

 constructor(application: Application) : super(application)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MainViewModelのコンストラクターを定義しました。AndroidViewModelはコンストラクターでアプリケーションのインスタンスを要求するため、これが必要です。そのため、コンストラクターでは、スーパービューメソッドを呼び出します。このメソッドは、AndroidViewModelコンストラクターを呼び出し、そこから継承します。



注：次の場合、1行を削除できます。

 class MainViewModel(application: Application) : AndroidViewModel(application) { ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、GitRepoRepositoryに NetManagerインスタンスがあるので、インターネット接続を確認できます。





したがって、インターネットに接続している場合、削除されたデータを受信して​​ローカルに保存します。インターネットに接続していない場合は、ローカルデータを取得します。



Kotlinの注意：オペレータが聞かせてヌルのためのチェックをし、内の値を返すIT。



次のいずれかの記事で、依存性注入、ViewModelでリポジトリインスタンスを作成するのがいかに悪いか、AndroidViewModelの使用を避ける方法について説明します。また、現在コードにある多くの問題についても説明します。理由のためにそれらを残しました...



これらのライブラリがすべて人気がある理由とそれらを使用する理由を理解できるように、問題を表示しようとしています。



PS私は、マッパー（についての私の心を変えたマッパー）。これについては、次の記事で説明することにしました。