🛒 🖐🏾 ✊🏾 Android向けレシピ：GradleスタイルのIoC ⚰️ 💆🏾 Ⓜ️

Androidプロジェクトは素晴らしいです。時々本当に大きい。私たちのプロジェクトの1つは、AndroidとFireOS（Amazon製）の2つの代替プラットフォーム用に同時に開発されているニュースアプリケーションです。これにより、Kindle Fireの読者は読むのが大好きなので、ニュースの読者の輪を広げることができます。ただし、これには各プラットフォームの機能を考慮する義務もあります。たとえば、AndroidでプッシュメッセージにGCMを使用する場合、FireOSではこれにAmazon AWSを使用する必要があります。アプリ内ショッピングシステムでも同様：Googleアプリ内課金とアプリ内購入。しかし、大きなプロジェクトサイズ！=大きなアプリケーションサイズ！

この記事では、代替ビルドを使用してアプリケーションを最適化し、開発プロセスに害を与えずにそれらを維持する方法を示します。

私たちは何を料理していますか？

マルチプラットフォームアプリケーションを開発する場合、開発者はプラットフォームの1つでのみ実行されるコードを処理できますが、他のプラットフォームで起動した場合は重荷となります。その存在に加えて、そのようなコードは確かにプロジェクトに同じ負担とそのすべての依存関係をもたらします。これ自体はあまり良いことではありませんが、Androidの開発の詳細：「65kの問題」を考えると、ダウンロード可能なファイルサイズをできる限り小さくすることがベストプラクティスです。このコードでは、必ず何かをする必要があります。そして、もしあなたがifAndroid（）またはifAmazon（）を何度もチェックすることはありません。

あなたが経験豊富なAndroid開発者であれば、おそらくProductFlavorのようなAndroid Gradleプラグインのオプションに出くわしたことでしょう。

フレーバー（英語）-味、香り

このオプションを使用すると、収集するフレーバーの名前に応じて、ビルド内の異なるディレクトリのファイルを含む、同じプロジェクトの代替アセンブリを作成できます。多くの場合、ProductFlavorはあらゆる種類の「ブランディング」アプリケーションに使用され、リソース（画像、テキスト、リンク）を置き換えます。別の一般的なケースは、収集されたフレーバーの名前がBuildConfig.FLAVORクラスのフィールドに自動的に分類されるため、アプリケーションをデモバージョンと完全バージョンに分割することです。その値は後でランタイムで確認でき、デモ版ではアクションを実行できません。

リソースだけでなく、コードにもフレーバーに分けることができます。ただし、flavor1で使用されるコードは、flavor2のコードとは対話できないことを理解する必要があります。そして、メインモジュールにあるコードは、常に一度に1つのflavor'ovからのみ見ることができます。これは、たとえば、あるフレーバーでユーティリティメソッドのセットを記述し、別のフレーバーで使用できないことを意味します。代替ビルドの切り替えがメインモジュールによって認識されないように、コードをできる限り分離して、賢明かつ非常に慎重に分離する必要があります。依存性注入パターンは非常に役立ちます。それに続いて、メインモジュールには一般的なインターフェイスのみを残し、特定の実装をフレーバーに分解します。 GitHubでリポジトリを検索するための簡単なアプリケーションを作成して、プロセス全体を見ていきます。

成分

必要なのは：

入力フィールド、ボタン、および結果のリストを含む画面（1個）。
Github Web APIを操作するためのクラス：そのモックとその実際の実装（合計2個）。
検索結果をキャッシュするためのクラス：実際の実装と模擬実装（合計2個）。
アイコン、テキスト、プログレスバー-味に。

アプリケーションをレイヤーに分割するアプローチを取り、プレゼンテーション用の.view、ビジネスロジックモデル用の.models、コンテンツプロバイダークラス用の.dataの3つのパッケージをすぐに作成します。データパッケージには、サービスとストレージの2つのパッケージが必要です。その結果、構造全体は次のようになります。

私たちにとって唯一のモデルは「リポジトリ」です。必要なものは何でも保存できますが、説明、名前、およびhtmlUrlが必要です。

次に、AppServiceリポジトリを検索するサービスクラスのインターフェイスを定義しましょう。

public interface AppService { List<Repository> searchRepositories(String query); }

RepositoryStorage検索の結果をキャッシュするクラスのインターフェイスをすぐに作成します。

 public interface RepositoryStorage { void saveRepositories(String query, List<Repository> repositoryList); List<Repository> getRepositories(String query); }

Applicationクラス内にサービスとリポジトリを作成して保存します。

 public class App extends Application { private AppService appService; private RepositoryStorage repositoryStorage; public AppService getAppService() { return appService; } public RepositoryStorage getRepositoryStorage() { return repositoryStorage; } }

準備段階では、画面自体を作成し、結果の受信と表示を書き込むだけです。デモアプリケーションの一部として、AsyncTaskはバックグラウンドの作業を行うのに十分ですが、お好みのアプローチをいつでも使用できます。

 public class MainActivity extends AppCompatActivity { @Bind(R.id.actionSearchView) Button actionSearchView; @Bind(R.id.recyclerView) RecyclerView recyclerView; @Bind(R.id.searchQueryView) EditText searchQueryView; @Bind(R.id.progressView) View progressView; private SearchResultsAdapter adapter; private AppService appService; private SearchTask searchTask; private RepositoryStorage repositoryStorage; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); ButterKnife.bind(this); appService = ((App) getApplication()).getAppService(); repositoryStorage = ((App) getApplication()).getRepositoryStorage(); recyclerView.setLayoutManager(new LinearLayoutManager(this)); adapter = new SearchResultsAdapter(); recyclerView.setAdapter(adapter); searchQueryView.setOnEditorActionListener(new TextView.OnEditorActionListener() { @Override public boolean onEditorAction(TextView v, int actionId, KeyEvent event) { querySearch(searchQueryView.getText().toString()); return true; } }); } @OnClick(R.id.actionSearchView) void onActionSearchClicked() { querySearch(searchQueryView.getText().toString()); } private void querySearch(String query) { if (TextUtils.isEmpty(query)) { return; } if (searchTask != null) { return; } InputMethodManager imm = (InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE); imm.hideSoftInputFromWindow(searchQueryView.getWindowToken(), 0); searchTask = new SearchTask(); searchTask.execute(query); showProgress(true); } private void showData(List<Repository> repositories) { searchTask = null; adapter.setData(repositories); } private void showProgress(boolean inProgress) { progressView.setVisibility(inProgress ? View.VISIBLE : View.GONE); actionSearchView.setEnabled(!inProgress); } private void showError(@Nullable ApiException exception) { searchTask = null; new AlertDialog.Builder(this) .setMessage(exception != null ? exception.getMessage() : getString(R.string.unknown_error)) .setTitle(R.string.error_title) .show(); } private class SearchTask extends AsyncTask<String, Void, SearchTaskResult> { @Override protected SearchTaskResult doInBackground(String... params) { String q = params[0]; SearchTaskResult result = new SearchTaskResult(); try { result.repositories = appService.searchRepositories(q); repositoryStorage.saveRepositories(q, result.repositories); } catch (ApiException e) { result.exception = e; //try to show some cached results result.repositories = repositoryStorage.getRepositories(q); } return result; } @Override protected void onPostExecute(SearchTaskResult result) { if (result.exception != null) { showError(result.exception); } showData(result.repositories); showProgress(false); } } private class SearchTaskResult { List<Repository> repositories; ApiException exception; } }

アダプタの実装とデモプロジェクト全体は、 GitHubで表示できます。

この段階では、プロジェクトはすでにコンパイルおよび起動できますが、これは意味がありません。AppServiceおよびRepositoryStorageインターフェースの実装を何も書いていないので、それを実行する時です。

味を追加

まず、プロジェクトのメインモジュールでbuild.gradleを開き、それにフレーバーを追加する必要があります。たとえば、 「mock」や「prod」と呼びましょう

 productFlavors { mock {} prod {} }

buildTypes {...}と同じレベルで、 Androidセクション{...}に 追加する必要があります。

その後、必ず[プロジェクトをGradleファイルと同期]ボタンをクリックしてください。

同期が完了するとすぐに、[バリアントのビルド]ウィンドウに新しいフレーバーが表示されます。

mockDebugを選択します。

プロジェクトで製品フレーバーを定義したら、 mainと同じレベルで同じ名前のディレクトリを作成できます。一部のフレーバーのアセンブリ中に、これらのディレクトリからファイルが取得されます。

モックフォルダーを追加し、その中のサービスとストレージパッケージの構造を繰り返します。

最後に、インターフェイスのモックを開始できます。

 public class AppServiceImpl implements AppService { @Override public List<Repository> searchRepositories(String query) { if (query.equals("error")) { throw new ApiException("Manual exception"); } List<Repository> results = new ArrayList<>(); for (int i = 1; i <= 10; i++) { results.add(new Repository("Mock description " + i, "Mock Repository " + i, "http://mock-repo-url")); } return results; } } public class MockRepositoryStorage implements RepositoryStorage { @Override public void saveRepositories(String q, List<Repository> repositoryList) {} @Override public List<Repository> getRepositories(String q) { return null; } }

ご覧のとおり、モックサービスは非常に有益な10のリポジトリモデルを提供し、モックストレージはまったく何もしません。 Appクラスでそれらを初期化します。

 @Override public void onCreate() { super.onCreate(); appService = new AppServiceImpl(); repositoryStorage = new MockRepositoryStorage(); }

これで、アプリケーションを作成して起動する準備が整いました。これで、UIの動作をテストおよび調整できます。これで、インターフェイスの真の実装に進むことができます。

[バリアントのビルド]ウィンドウでprodDebugオプションを選択し、 モックフォルダーと同様に、同じパッケージとクラスでprodフォルダーを作成します。

ネットワークリクエストにはretrofit2を使用します。AppServiceImplの実装内で機能します。

 public class AppServiceImpl implements AppService { private final RetroGithubService service; public AppServiceImpl() { service = new Retrofit.Builder() .baseUrl("https://api.github.com/") .addConverterFactory(GsonConverterFactory.create()) .build().create(RetroGithubService.class); } @Override public List<Repository> searchRepositories(String query) { Call<ApiRepositorySearchEntity> call = service.searchRepositories(query); try { Response<ApiRepositorySearchEntity> response = call.execute(); if (response.isSuccess()) { ApiRepositorySearchEntity body = response.body(); List<Repository> results = new ArrayList<>(); RepositoryMapper mapper = new RepositoryMapper(); for (RepositoryEntity entity : body.items) { results.add(mapper.map(entity)); } return results; } else { throw new ApiException(response.message()); } } catch (Exception e) { throw new ApiException(e); } } } public interface RetroGithubService { @GET("search/repositories") Call<ApiRepositorySearchEntity> searchRepositories(@Query("q") String query); }

コードからわかるように、ヘルパークラスをさらに作成しました。 *応答を解析するためのエンティティと、応答をリポジトリモデルにマッピングするためのRepositoryMapper 。

RepositoryEntity、RepositoryMapper、RetroGithubServiceなど、サーバーとの実際の作業に関連するすべてのクラスは、「prod」フレーバーフォルダーにあることに注意してください。 つまり、モックなどの他のフレーバーを構築する場合、これらのクラスは結果のapkファイルに入れられません 。

注意深い読者は、サーバーで実際の作業を実装するクラスの名前とそれに対応する模擬の名前が同じであるAppServiceImpl.javaに気付くかもしれません 。これは意図的に行われたもので、これにより、メインフォルダーにあるメインプロジェクトコードのフレーバーを変更する際に変更する必要はありません。 モックフレーバーを選択すると、アプリケーションはモックフォルダーにあるAppServiceImplクラスを表示し、 prodフォルダーにあるクラスを表示しません。同様に、選択されたフレーバーprodを使用します。

同様に注意深い読者は、キャッシュ実装クラスMockRepositoryStorageを呼び出し 、それを封印した可能性があることに気付くかもしれません。しかし、いや、実装クラスの異なる名前とそれらのそれぞれに異なるコンストラクターを持つことができる方法のオプションの1つを示すことを意図的にしました。

トリックは基本的に簡単です。異なるフレーバーに対して同じ名前のRepositoryStorageBuilderクラスを作成します。これにより、フレーバーに応じて、目的の実装が提供されます。

productFlavor = prod

 public class RepositoryStorageBuilder { private int maxSize; public RepositoryStorageBuilder setMaxSize(int maxSize) { this.maxSize = maxSize; return this; } public RepositoryStorage build() { return new InMemoryRepositoryStorage(maxSize); } }

productFlavor =モック

 public class RepositoryStorageBuilder { public RepositoryStorageBuilder setMaxSize(int maxSize) { return this; } public RepositoryStorage build() { return new MockRepositoryStorage(); } }

そして、アプリケーションの両方の初期化に共通：

 @Override public void onCreate() { super.onCreate(); ... repositoryStorage = new RepositoryStorageBuilder() .setMaxSize(5) .build(); }

これで、作業の「正直な」実装は完了したと見なすことができますが、ここで停止すると、ProductFlavorの全機能を使用できなくなります。実際には、 依存関係セクションで宣言されている検索の正直な実装で使用されるライブラリは、選択されたフレーバーに関係なく、アセンブリに分類されます。幸いなことに、コンパイル時に単語の前に目的のフレーバー名を追加することで、依存関係ごとにビルドでそれを表示するかどうかを個別に指定できます。

 dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) testCompile 'junit:junit:4.12' prodCompile 'com.squareup.retrofit:retrofit:2.0.0-beta2' prodCompile 'com.squareup.retrofit:converter-gson:2.0.0-beta2' prodCompile 'com.google.code.gson:gson:2.5' compile 'com.android.support:appcompat-v7:23.1.1' compile 'com.android.support:recyclerview-v7:23.1.1' compile 'com.jakewharton:butterknife:7.0.1' }

これにより、アプリケーションのサイズが小さくなるだけでなく、依存関係が非常に大きい場合は、アセンブリの速度が向上します。

なんで？

Dagger2、Roboguiceがあり、手動で記述できる場合でも、このアプローチを依存性注入に使用するのはなぜですか？

もちろん、このアプローチの主な違いは、実装の定義がコンパイル段階で行われ、実際に使用される依存関係のみがビルドに組み込まれ、その後のすべての結果が生じることです。同時に、お気に入りのDIフレームワークを引き続き使用して、実行時の依存関係を判断できます。

実話

冒頭で述べたように、AndroidとAmazon FireOSの2つのプラットフォーム用のプロジェクトの1つをすぐに開発しています。これらのオペレーティングシステムはほとんど互いに似ています（もちろん、誰と誰が似ているかを理解しています:)）が、プッシュ通知の独自の実装とアプリ内購入のための独自のメカニズムがあります。これらおよびその他のプラットフォームの違いについては、デモプロジェクトと同様に、メインモジュールには共通のインターフェイスのみを残しました：プッシュメッセージサーバーでの同じデバイス登録、同じサブスクリプション購入プロセス、および特定のプラットフォーム依存の実装を対応するフレーバーに格納します。

私たちは長い間このアプローチを使用しており、次のような使用感を共有する準備ができています。

長所

プラットフォームで使用されることのない、すべてのコードとその依存関係の結果のアセンブリの例外。
プロジェクトのビルド時間を短縮します、なぜなら選択された（アクティブな）フレーバーのみが収集されます。
IoCを使用することのすべての利点、インターフェイスを実装から分離し、if isAndroid（）のスタイルで見苦しい分岐がない

短所

Android Studioは、選択されたフレーバーとそのディレクトリのみを同時に表示します。このため、自動リファクタリング、Javaクラスでの検索、およびリソースでの検索は完全には機能しません。非アクティブなフレーバーには適用されないという意味では機能しません。リファクタリング後、フレーバーを切り替えて、フレーバーごとに個別にリファクタリングを繰り返す必要がある場合があります。

あなたが見ることができるように、私たちは3倍以上のプラスがあると信じています:)お食事をお楽しみください！

Android向けレシピ：GradleスタイルのIoC

私たちは何を料理していますか？

成分

味を追加

なんで？

実話

More articles: