Androidアプリを段階的に構築する、パート1

この記事では、RxJavaとRetrofitを使用して、MVPパターンに基づいたアーキテクチャ設計とモバイルアプリケーションの作成について説明します。 トピックは非常に大きいことが判明したため、別々の部分で提供されます：最初はアプリケーションを設計および作成し、2番目はDagger 2でDIを実行して単体テストを作成し、3番目では統合および機能テストを追加し、Android開発の現実のTDDについても検討します。



内容：

• はじめに
• ステップ1.シンプルなアーキテクチャ
  
  
  • 階層化、MVP
  • モデル
    
    
    • 後付け
    • ポジョ
  • 発表者
  • 表示する
• ステップ2.複雑なアーキテクチャ
  • レトロラムダ
  • レイヤーごとに異なるデータモデル
  • モデル
  • 発表者
  • 表示する
• 結論または継続する

はじめに

コードの理解を深め、順次複雑にするために、設計を2つの段階に分割します。プリミティブ（最小限実行可能）と従来のアーキテクチャです。 プリミティブでは、最小限のコードとファイルを管理してから、このコードを改善します。

すべてのソースコードはgithubにあります。 リポジトリのブランチは、記事のステップに対応しています。 ステップ1単純なアーキテクチャ -最初のステップ、 ステップ2複雑なアーキテクチャ-2番目のステップ。

たとえば、Github APIを使用して、特定のユーザーのリポジトリのリストを取得してみましょう。



このアプリケーションでは、Rxを使用しているため、この記事を理解するには、このテクノロジーの一般的な考え方が必要です。GrokaiRxJavaの一連の出版物を読むことをお勧めします。

ステップ1.シンプルなアーキテクチャ

階層化、MVP

アーキテクチャを設計するときは、MVPパターンを順守します。 詳細はこちらをご覧ください：

https://ru.wikipedia.org/wiki/Model-View-Presenter

http://habrahabr.ru/post/131446/



プログラム全体を3つの主要な層に分割します。

モデル -ここでデータを取得して保存します。 出力は観測可能です。

プレゼンター -このレイヤーには、すべてのアプリケーションロジックが格納されます。 Observableを取得し、サブスクライブし、結果をビューに渡します。

ビュー -表示レイヤー。すべてのビュー要素、アクティベーション、フラグメントなどが含まれます。

モデル

データレイヤーは、Observable <List <Repo >>を提供する必要があります。インターフェイスを作成しましょう。

public interface Model { Observable<List<Repo>> getRepoList(String name); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

後付け

ネットワークでの作業を簡素化するために、Retrofitを使用します。 RetrofitはREST APIを操作するためのライブラリです。ネットワークでのすべての作業を処理します。インターフェイスと注釈を使用してリクエストを記述することしかできません。





リポジトリデータを取得するためのインターフェイス：

 public interface ApiInterface { @GET("users/{user}/repos") Observable<List<Repo>> getRepositories(@Path("user") String user); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データの操作、POJO

レトロフィット（およびその中のGSON）は、POJO（Plain Old Java Object）で動作します。 これは、次の形式のJSONからオブジェクトを取得することを意味します。

 { "id":3, "name":"Andrey", "phone":"511 55 55" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GSONが値を書き込むUserクラスが必要になります。

 public class User { private int id; private String name; private String phone; public int getId() { return id; } public void setId(int id) { this.id = id; } // etc }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのようなクラスを自分の手で生成する必要は当然ありません;これには、例えばwww.jsonschema2pojo.orgのような特別なジェネレーターがあります。



JSONをフィードし、選択します：



ソースタイプ：JSON

注釈スタイル：Gson

ゲッターとセッターを含める



ファイルのコードを取得します。 zipまたはjarとしてダウンロードして、プロジェクトに入れることができます。 リポジトリーについては、所有者、許可、リポジトリーの3つのオブジェクトが取得されました。

発表者

プレゼンターは、ダウンロードする内容、エラーが発生した場合の対処方法などを知っています。 つまり、ロジックをプレゼンテーションから分離します。 この場合の表示は、可能な限り簡単であることがわかりました。 プレゼンターは、検索ボタンのクリックを処理し、ダウンロードを初期化し、データを送信し、アクティビティが停止した場合に登録を解除できる必要があります。



プレゼンターインターフェイス：

 public interface Presenter { void onSearchClick(); void onStop(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

表示する

Viewは、受信したデータの表示、エラーの表示、空のリストの通知、プレゼンターからのリクエストに応じたユーザー名の表示が可能なアクティビティとしてViewを実装します。 インターフェース：

 public interface IView { void showList(List<Repo> RepoList); void showError(String error); void showEmptyList(); String getUserName(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、レイヤーに分割されたシンプルなアプリケーションができました。



スキーム：







改善が必要なものもありますが、一般的な考え方は明確です。 次に、新しい機能を追加してタスクを複雑にします。

パート2.複雑なアーキテクチャ

アプリケーションに新しい機能を追加し、リポジトリに関する情報を表示します。 ブランチと貢献者のリストを表示します。これらはAPIからのさまざまなリクエストによって取得されます。

レトロラムダ

ラムダなしでRxを使用するのは苦痛で、すぐに疲れるたびに匿名クラスを書く必要があります。 AndroidはJava 8とラムダをサポートしていませんが、Retrolambda（ https://github.com/evant/gradle-retrolambda ）が助けになります。 ラムダ式の詳細： http : //habrahabr.ru/post/224593/

レイヤーごとに異なるデータモデル。

ご覧のとおり、3つのレイヤーすべてで同じRepoデータオブジェクトを使用しています。 このアプローチは単純なアプリケーションには適していますが、実際には、APIの変更、オブジェクトを変更する必要性、または何か他のものに出くわすことがあります。 複数の人がプロジェクトに取り組んでいる場合、別のレイヤーの利益のためにクラスを変更するリスクがあります。



そのため、多くの場合、1つのレイヤー= 1つのデータ形式というアプローチが適用されます。 モデルの一部のフィールドが変更されても、これはビューレイヤーに影響しません。 Presenterレイヤーに変更を加えることはできますが、Viewでは厳密に定義されたオブジェクト（クラス）を提供します。 このため、データモデルからのレイヤーの独立性が達成され、各レイヤーには独自のモデルがあります。 モデルを変更するときは、マッパーを書き換えて、レイヤー自体には触れないようにする必要があります。 これはコントラクトプログラミングに似ています。どのオブジェクトがレイヤーに到達し、どのオブジェクトをさらに提供する必要があるかを正確に把握しているため、予測不可能な結果から自分自身と同僚を保護します。



この例では、DTO-データ転送オブジェクト（JSONオブジェクトを完全にコピー）とビューオブジェクト（表示用に調整されたオブジェクト）の2種類のデータで十分です。 より複雑なアプリケーションがある場合、ビジネスオブジェクト（ビジネスプロセス用）またはデータベースオブジェクト（データベースに複雑なオブジェクトを保存するため）が必要になる場合があります





リポジトリの名前をRepositoryDTOに変更し、新しいリポジトリクラスを作成し、インターフェイスFunc1 <List <RepositoryDTO >>、List <Repository >>を実装するマッパーを記述します。

（リスト<RepositoryDTO>からリスト<Repository>への翻訳）

モデル

レイヤーごとに異なるデータモデルを導入しました。ModelインターフェイスはDTOオブジェクトを提供するようになりました。それ以外はすべて同じです。

 public interface Model { Observable<List<RepositoryDTO>> getRepoList(String name); Observable<List<BranchDTO>> getRepoBranches(String owner, String name); Observable<List<ContributorDTO>> getRepoContributors(String owner, String name); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

発表者

Presenterレイヤーでは、共通のクラスが必要です。 プレゼンターは、さまざまな機能を実行できます。ダウンロードショーの簡単なプレゼンター、アイテムをロードする必要があるリスト、サイト上のオブジェクトをリクエストするマップ、および他の多くのエンティティがあります。 しかし、それらはすべて、メモリリークを回避するためにObservableからサブスクライブを解除する必要性によって統一されています。 残りは発表者のタイプによって異なります。



複数のObservableを使用する場合、onStopで一度にすべてのサブスクリプションを解除する必要があります。 これを行うには、CompositeSubscriptionを使用できます。すべてのサブスクリプションをそこに追加し、コマンドでサブスクライブを解除します。



また、プレゼンターに状態の保存を追加します。 これを行うには、onCreate（BundledInstanceState）およびonSaveInstanceState（Bundle outState）メソッドを作成して実装します。 DTOをVOに変換するには、マッパーを使用します。

表示する

アクティビティを使用してフラグメントを管理します。 各エンティティには独自のフラグメントがあり、ベースフラグメントから継承されます。 ベースプレゼンターインターフェイスを使用するベースフラグメントは、onStop（）でサブスクライブ解除されます。



また、状態の復元にも注意してください。すべてのロジックがプレゼンターに移動しました。ビューはできるだけシンプルにする必要があります。











2番目のステップでのアプリケーションの一般的なスキーム（ クリック可能 ）：

結論または継続...

その結果、抽象化の必要なすべてのレベルとコンポーネント（ ソース ）による責任の明確な分割に準拠した実用的なアプリケーションを手に入れました。 このようなコードは保守と補完が容易であり、開発者のチームがそれに取り組むことができます。 しかし、主な利点の1つは非常に簡単なテストです。 次の記事では、Dagger 2の導入を検討し、TDDの原則に従って、既存のコードをテストでカバーし、新しい機能を作成します。



更新

Androidアプリを段階的に構築する、パート2

Androidアプリを段階的に構築する、パート3