Androidクライアントサーバーアプリケーションのアーキテクチャ

クライアントサーバーアプリケーションは最も一般的であり、同時に開発が最も困難です。 クエリを実行する手段の選択から結果をキャッシュする方法まで、あらゆる段階で問題が発生します。 アプリケーションの安定した動作を保証する複雑なアーキテクチャを適切に編成する方法を知りたい場合は、猫をお願いします。







もちろん、今は2010年ではありません。開発者は有名なA / B / Cパターンを使用したり、AsyncTask を実行したり、タンバリンを激しく叩いたりする必要がありました 。 非同期を含め、クエリを簡単に実行できるさまざまなライブラリが多数登場しています。 これらのライブラリは非常に興味深いものであり、適切なライブラリを選択することから始めることも必要です。 しかし、最初に、すでに持っているものを少し思い出しましょう。



以前は、Androidでネットワークリクエストを実行するために使用できる唯一のツールはApacheクライアントでした。これは実際には理想からはほど遠いもので、Googleが新しいアプリケーションでそれを取り除くために一生懸命努力していることは無駄ではありません。 後に、HttpUrlConnectionクラスは、Google開発者の努力の結果となりました。 彼は状況をあまり修正しませんでした。 非同期リクエストを実行するための十分な能力はまだありませんでしたが、HttpUrlConnection + Loadersモデルはすでに多かれ少なかれ機能しています。



2013年はこの点で非常に効果的になりました。 素晴らしいボレーとレトロフィットのライブラリが登場しました。 Volleyはネットワークで動作するように設計されたより一般的なライブラリであり、RetrofitはREST Apiで動作するように特に設計されています。 そして、クライアント/サーバーアプリケーションの開発で広く認められた標準となった最後のライブラリでした。



レトロフィットは、他の手段と比較して、いくつかの主な利点を区別できます。

1）あらゆる要求を満たすための完全な機能を提供する非常に便利でシンプルなインターフェイス。

2）柔軟な構成-任意のクライアントを使用してリクエストを実行したり、jsonを解析するためのライブラリなどを使用したりできます。

3）jarを個別に解析する必要はありません-Gsonライブラリ（およびGsonのみ ） がこの機能を実行します。

4）結果とエラーの便利な処理。

5）Rxサポート。これも今日の重要な要素です。



Retrofitライブラリに慣れていない場合は、今すぐ学習してください 。 しかし、いずれにせよ、私は簡単な紹介を行うと同時に、バージョン2.0.0の新機能を見ていきます（ Retrofit 2.0.0のプレゼンテーションもご覧ください）。



例として、最大のシンプルさのために空港用のAPIを選択しました。 そして、最も一般的な問題を解決します-最寄りの空港のリストを取得します。



まず、選択したすべてのライブラリと、Retrofitに必要な依存関係を接続する必要があります。

compile 'com.squareup.retrofit:retrofit:2.0.0-beta1' compile 'com.squareup.retrofit:converter-gson:2.0.0-beta1' compile 'com.squareup.okhttp:okhttp:2.0.0'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特定のクラスのオブジェクトのリストの形式で空港を受け取ります。

リクエスト用のサービスを作成します。

 public interface AirportsService { @GET("/places/coords_to_places_ru.json") Call<List<Airport>> airports(@Query("coords") String gps); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Retrofit 2.0.0に関する注意

以前は、同期要求と非同期要求を実行するには、異なるメソッドを記述する必要がありました。 これで、voidメソッドを含むサービスを作成しようとすると、エラーが発生します。 Retrofit 2.0.0では、Callインターフェースはリクエストをカプセル化し、リクエストを同期的または非同期的に実行できるようにします。





ヘルパーメソッドを作成します。

 public class ApiFactory { private static final int CONNECT_TIMEOUT = 15; private static final int WRITE_TIMEOUT = 60; private static final int TIMEOUT = 60; private static final OkHttpClient CLIENT = new OkHttpClient(); static { CLIENT.setConnectTimeout(CONNECT_TIMEOUT, TimeUnit.SECONDS); CLIENT.setWriteTimeout(WRITE_TIMEOUT, TimeUnit.SECONDS); CLIENT.setReadTimeout(TIMEOUT, TimeUnit.SECONDS); } @NonNull public static AirportsService getAirportsService() { return getRetrofit().create(AirportsService.class); } @NonNull private static Retrofit getRetrofit() { return new Retrofit.Builder() .baseUrl(BuildConfig.API_ENDPOINT) .addConverterFactory(GsonConverterFactory.create()) .client(CLIENT) .build(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いいね！ 準備が完了し、要求を満たせるようになりました。

 public class MainActivity extends AppCompatActivity implements Callback<List<Airport>> { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); AirportsService service = ApiFactory.getAirportsService(); Call<List<Airport>> call = service.airports("55.749792,37.6324949"); call.enqueue(this); } @Override public void onResponse(Response<List<Airport>> response) { if (response.isSuccess()) { List<Airport> airports = response.body(); //do something here } } @Override public void onFailure(Throwable t) { } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが非常に簡単に思えます。 必要なクラスを簡単に作成しました。クエリを実行し、結果を取得し、エラーを処理することは、すべて文字通り10分で行えます。 他に何が必要ですか？



ただし、このアプローチは根本的に間違っています。 リクエストの実行中に、ユーザーがデバイスを回したり、アプリケーションを閉じたりするとどうなりますか？ 自信を持って言えば、望みどおりの結果が保証されているわけではなく、最初の問題からそれほど遠くないということだけです。 はい、アクティビティとフラグメントのリクエストはコードに美しさを追加しません。 したがって、最終的に記事のメイントピックであるクライアントサーバーアプリケーションのアーキテクチャの構築に戻るときが来ました。



この状況では、いくつかのオプションがあります。 マルチスレッドで有能な作業を提供するライブラリを使用できます。 特にRetrofitがサポートしているため、Rxフレームワークは完璧です。 ただし、Rxを使用してアーキテクチャを構築したり、機能的なリアクティブプログラミングを使用したりすることは簡単な作業ではありません。 より簡単な方法を取ります：Androidが提供するツールをそのまま使用します。 すなわち、ローダー。



ローダーはAPIバージョン11で登場しましたが、依然としてクエリの並列実行のための非常に強力なツールです。 もちろん、ローダーでは何でもできますが、通常はデータベースからデータを読み取るか、ネットワーク要求を実行するために使用されます。 そして、ローダーの最も重要な利点は、LoaderManagerクラスを介して、アクティビティとフラグメントのライフサイクルに関連付けられることです。 これにより、アプリケーションを閉じるとデータが失われたり、結果が間違ったコールバックに戻ったりすることを恐れずにそれらを使用できます。



通常、ローダーを操作するモデルには次の手順が含まれます。

1）要求を満たし、結果を取得します。

2）何らかの方法で結果をキャッシュします（ほとんどの場合、データベースに）。

3）結果をアクティビティまたはフラグメントで返します。



ご注意

ActivityやFragmentはデータの取得方法を考慮しないため、このようなモデルは優れています。 たとえば、サーバーからエラーが返される場合がありますが、同時にローダーはキャッシュされたデータを返します。



そのようなモデルを実装しましょう。 データベースの実装方法の詳細は省略しますが、必要に応じて、Githubで例を見ることができます（記事の最後のリンク）。 ここでも多くのバリエーションが可能であり、それらの利点と欠点を順番に検討し、最終的には最適と思われるモデルに到達します。



ご注意

すべてのローダーは、異なるタイプのロードされたデータの1つのアクティビティまたはフラグメントでLoaderCallbacksインターフェイスを使用できるように、ユニバーサルデータタイプで動作する必要があります。 最初に思い浮かぶのは、カーソルです。



もう一つの注意

ローダーに関連付けられているすべてのモデルには小さな欠点があります。リクエストごとに、個別のローダーが必要です。 これは、アーキテクチャを変更したり、たとえば別のデータベースに切り替えたりすると、多くのリファクタリングが発生することを意味しますが、これはあまり良くありません。 この問題を可能な限り回避するために、すべてのローダーに基本クラスを使用し、可能なすべての共通ロジックを格納します。

ローダー+ ContentProvider +非同期リクエスト

前提条件：ContentProviderを介してSQLiteデータベースを操作するためのクラスがあり、エンティティをこのデータベースに保存することができます。



このモデルのコンテキストでは、一般的なロジックを基本クラスにすることは非常に困難であるため、この場合、非同期要求を実行するために継承するのに便利なローダーにすぎません。 その内容は問題のアーキテクチャに直接適用されないため、ネタバレです。 ただし、アプリケーションで使用することもできます。



空港をロードするためのローダーは次のようになります。

 public class AirportsLoader extends BaseLoader { private final String mGps; private final AirportsService mAirportsService; public AirportsLoader(Context context, String gps) { super(context); mGps = gps; mAirportsService = ApiFactory.getAirportsService(); } @Override protected void onForceLoad() { Call<List<Airport>> call = mAirportsService.airports(mGps); call.enqueue(new RetrofitCallback<List<Airport>>() { @Override public void onResponse(Response<List<Airport>> response) { if (response.isSuccess()) { AirportsTable.clear(getContext()); AirportsTable.save(getContext(), response.body()); Cursor cursor = getContext().getContentResolver().query(AirportsTable.URI, null, null, null, null); deliverResult(cursor); } else { deliverResult(null); } } }); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ついにUIクラスで使用できるようになりました。

 public class MainActivity extends AppCompatActivity implements LoaderManager.LoaderCallbacks<Cursor> { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); getLoaderManager().initLoader(R.id.airports_loader, Bundle.EMPTY, this); } @Override public Loader<Cursor> onCreateLoader(int id, Bundle args) { switch (id) { case R.id.airports_loader: return new AirportsLoader(this, "55.749792,37.6324949"); default: return null; } } @Override public void onLoadFinished(Loader<Cursor> loader, Cursor data) { int id = loader.getId(); if (id == R.id.airports_loader) { if (data != null && data.moveToFirst()) { List<Airport> airports = AirportsTable.listFromCursor(data); //do something here } } getLoaderManager().destroyLoader(id); } @Override public void onLoaderReset(Loader<Cursor> loader) { } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

どうやら、複雑なことは何もない。 これは、ローダーの絶対的な標準作業です。 私の意見では、ローダーは理想的なレベルの抽象化を提供します。 必要なデータをロードしますが、ロード方法に関する不必要な知識はありません。



このモデルは安定しており、使用するのに十分便利ですが、まだ欠点があります：

1）新しいローダーにはそれぞれ、結果を処理するための独自のロジックが含まれています。 この欠陥は修正することができ、一部は次のモデルで、完全に後者で行います。

2）2番目の欠点ははるかに深刻です。すべてのデータベース操作はアプリケーションのメインスレッドで実行されるため、大量のデータが保存されてアプリケーションが停止する前であっても、さまざまなマイナスの結果を招く可能性があります。 最後に、ローダーを使用します。 非同期ですべてをやりましょう！

ローダー+ ContentProvider +同期リクエスト

問題は、ローダーがバックグラウンドで作業を許可しているのに、なぜレトロフィットを使用してリクエストを非同期に実行したのですか？ 修正してください。



このモデルは単純化されていますが、主な違いは、ローダーを介して要求の非同期性が達成され、データベースの操作がメインスレッドで行われないことです。 基本クラスの相続人は、Cursor型のオブジェクトのみを返す必要があります。 これで、基本クラスは次のようになります。

 public abstract class BaseLoader extends AsyncTaskLoader<Cursor> { public BaseLoader(Context context) { super(context); } @Override protected void onStartLoading() { super.onStartLoading(); forceLoad(); } @Override public Cursor loadInBackground() { try { return apiCall(); } catch (IOException e) { return null; } } protected abstract Cursor apiCall() throws IOException; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、抽象メソッドの実装は次のようになります。

 @Override protected Cursor apiCall() throws IOException { AirportsService service = ApiFactory.getAirportsService(); Call<List<Airport>> call = service.airports(mGps); List<Airport> airports = call.execute().body(); AirportsTable.save(getContext(), airports); return getContext().getContentResolver().query(AirportsTable.URI, null, null, null, null); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UIでのローダーの操作は変更されていません。



実際、このモデルは以前のモデルの修正版であり、欠点を部分的に排除しています。 しかし、私の意見では、これはまだ十分ではありません。 ここでも、欠点を強調することができます。

1）各ローダーには、データを保存するための個別のロジックがあります。

2）SQLiteデータベースでのみ機能します。



そして最後に、これらの欠点を完全に取り除き、普遍的でほぼ完璧なモデルを手に入れましょう！

ローダー+任意のデータストア+同期リクエスト

特定のモデルを検討する前に、ローダーでは単一のデータ型を使用する必要があるという事実について説明しました。 カーソル以外には、何も思い浮かびません。 それでは、このタイプを作成しましょう！ その中には何がありますか？ 当然、ジェネリック型であるべきではありません（そうしないと、1つのアクティビティ/フラグメントで異なるデータ型のローダーコールバックを使用できません）が、同時に任意の型のオブジェクトのコンテナーである必要があります。 そして、ここにこのモデルの唯一の弱点があります-オブジェクト型を使用し、未チェックの変換を実行する必要があります。 それでも、これは大きなマイナスではありません。 このタイプの最終バージョンは次のとおりです。

 public class Response { @Nullable private Object mAnswer; private RequestResult mRequestResult; public Response() { mRequestResult = RequestResult.ERROR; } @NonNull public RequestResult getRequestResult() { return mRequestResult; } public Response setRequestResult(RequestResult requestResult) { mRequestResult = requestResult; return this; } @Nullable public <T> T getTypedAnswer() { if (mAnswer == null) { return null; } //noinspection unchecked return (T) mAnswer; } public Response setAnswer(@Nullable Object answer) { mAnswer = answer; return this; } public void save(Context context) { } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このタイプは、クエリの結果を保存できます。 特定のリクエストに対して何かをしたい場合、このクラスから継承し、必要なメソッドをオーバーライド/追加する必要があります。 たとえば、次のように：

 public class AirportsResponse extends Response { @Override public void save(Context context) { List<Airport> airports = getTypedAnswer(); if (airports != null) { AirportsTable.save(context, airports); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いいね！ ローダーの基本クラスを作成しましょう。

 public abstract class BaseLoader extends AsyncTaskLoader<Response> { public BaseLoader(Context context) { super(context); } @Override protected void onStartLoading() { super.onStartLoading(); forceLoad(); } @Override public Response loadInBackground() { try { Response response = apiCall(); if (response.getRequestResult() == RequestResult.SUCCESS) { response.save(getContext()); onSuccess(); } else { onError(); } return response; } catch (IOException e) { onError(); return new Response(); } } protected void onSuccess() { } protected void onError() { } protected abstract Response apiCall() throws IOException; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このローダークラスは、この記事の最終的な目標であり、私の意見では、優れた、実行可能で拡張可能なモデルです。 たとえば、SQLiteからRealmにアップグレードしたいですか？ 問題ありません。 これを次の例と考えてください。 ローダーのクラスは変更されず、いずれの場合でも編集するモデルのみが変更されます。 リクエストを完了できませんでしたか？ 問題ではありませんが、相続人のapiCallメソッドを変更します。 エラー時にデータベースをクリアしたいですか？ onErrorとworkをオーバーライドします-このメソッドはバックグラウンドスレッドで実行されます。



また、特定のローダーは次のように表すことができます（ここでも、抽象メソッドの実装のみを示します）。

 @Override protected Response apiCall() throws IOException { AirportsService service = ApiFactory.getAirportsService(); Call<List<Airport>> call = service.airports(mGps); List<Airport> airports = call.execute().body(); return new AirportsResponse() .setRequestResult(RequestResult.SUCCESS) .setAnswer(airports); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご注意

リクエストが正常に実行されなかった場合、例外がスローされ、ベースローダーのcatchブランチに到達します。



その結果、次の結果が得られました。

1）各ローダーは、その要求（パラメーターと結果）のみに依存しますが、同時に、受信したデータをどう処理するかを知りません。 つまり、特定のリクエストのパラメータを変更する場合にのみ変更されます。

2）ベースローダーは、クエリ実行のロジック全体を制御し、結果を処理します。

3）さらに、モデルクラス自体にも、データベースなどの処理がどのように配置されているかについての手がかりがありません。 これらはすべて、個別のクラス/メソッドで実行されます。 これはどこにも明示的に示していませんが、Githubの例（記事の最後にあるリンク）で見ることができます。

結論の代わりに

もう少し上に、別の例を示すことを約束しました-SQLiteからRealmへの移行-そして、ローダーに実際に影響しないことを確認します。 やってみましょう。 実際、ここでのコードはほんの少しです。データベースの操作が1つの方法でのみ実行されるようになったためです（Realmの詳細に関連する変更は考慮していませんが、特に、フィールドの命名とGsonの操作に関するルールです。 Githubにあります）。



レルムの接続：

 compile 'io.realm:realm-android:0.82.1'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AirportsResponseの保存方法を変更します。

 public class AirportsResponse extends Response { @Override public void save(Context context) { List<Airport> airports = getTypedAnswer(); if (airports != null) { AirportsHelper.save(Realm.getInstance(context), airports); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以上です！ 基本的な方法で、異なるロジックを含むクラスに影響を与えることなく、データの保存方法を変更しました。

まだ結論

かなり重要な点を強調したいと思います。キャッシュされたデータの使用に関連する問題、つまりインターネットがない場合は考慮しませんでした。 ただし、各アプリケーションでキャッシュされたデータを使用する戦略は個々のものであり、特定のアプローチを課すことは適切とは考えていません。 そして記事は引き伸ばされました。



その結果、クライアントサーバーアプリケーションのアーキテクチャを整理する際の主な問題を調査しました。この記事が新しいことを学び、プロジェクトで上記のモデルのいずれかを使用することを願っています。 さらに、そのようなアーキテクチャの編成方法について独自のアイデアがあれば、書いてください。



最後まで読んでくれてありがとう。 良い開発を！



PS GitHubのコードへの約束されたリンク。