マルチライブラリ Android プロジェクトをマスターする:ローカルおよびリモート開発のベスト プラクティス

この記事では、Android のマルチライブラリ プロジェクトについて説明します。それは普通のことではありませんが、特別なことでもありません。

業務上、複数のライブラリを使用するプロジェクトに遭遇したことがあるかもしれません。あるいは、構造と構成を改善するためにライブラリをサブモジュールに変換することを検討しているかもしれません。いずれの場合でも、飛び込む前に、目の前に何が横たわっているのかをよく理解しておく必要があります。

Android で独自のライブラリを作成するのは簡単です。他の開発者 (または自分自身) を助けることができるコードを書くチャンスが得られます。

ライブラリは単独でスタンドアロン プロジェクトになることができないため、通常はプロジェクト内で常にアプリケーションとペアになります。これにより、機能を追加したりバグを修正したりするだけの単純なプロセスでライブラリを開発し、プロジェクト内のアプリケーションで直接テストできるようになります。したがって、開発者がライブラリをどのように統合するかを (ローカルな方法で) シミュレートします。

しかし、あなたのライブラリが開発中の別のライブラリに依存している場合はどうなるでしょうか?

ご存じない方は、ライブラリ (aar と読みます) 内に別のローカル ライブラリを含めることはできないことを知っておく必要があります。 (依存関係を介して) リモートでライブラリに依存することはできますが、ローカルなものには依存できません。

これは Android ではサポートされておらず、長年の間にいくつかの解決策 (FatAar) が登場しましたが、これらは必ずしも問題を解決するとは限らず、最新のものでもありません。この機能を要求する Google Issue Tracker もかなり前からオープンされており、コミュニティから多くの注目を集めています。ただし、どの壁を壊すことができ、どの壁を壊すことができないかを特定しましょう。

プロジェクト階層が次のようになっていると想像してください:

-- App
|
 -- OuterLib
 |
 --- InnerLib

それでは、InnerLib は元のプロジェクトの一部にはできないので、どこに配置できるのでしょうか?また、InnerLib 内で機能を開発しながらローカルで作業するにはどうすればよいでしょうか?

この記事では、これらの質問に答えていきます。

Git サブモジュール

ほとんどの技術的な問題には、解決策が常に 1 つだけあるとは限りません。通常はさらに多くの解決策がありますが、それぞれの解決策には欠点があります。結局のところ、どの欠点を抱えながら生活するのがより快適かということがすべての問題です。

InnerLib をどこに置くことができるかという最初の質問に答えるには、いくつかの選択肢があります。

<オル>

InnerLib を元のプロジェクトのサブモジュールにする

InnerLib を独自のリモート依存関係にする

Git のサブモジュールについてよく知らない場合は、Git のドキュメントを参照してよく理解してください。そこからの引用 (最初の段落):

1 つのプロジェクトで作業しているときに、そのプロジェクト内から別のプロジェクトを使用する必要があることがよくあります。 👉 おそらく、サードパーティが開発したライブラリ、または個別に開発して複数の親プロジェクトで使用しているライブラリである可能性があります。 👈 これらのシナリオでは、共通の問題が発生します。それは、2 つのプロジェクトを別個のものとして扱いながら、一方のプロジェクトを他方のプロジェクト内から使用できるようにする必要があるということです。

この段落は、これがまさに私たちのユースケースであることを示しています。サブモジュールを使用すると利点があります。すべてのコードは 1 か所にまとめられており、管理が簡単で、ローカルでの開発も簡単です。

しかし、サブモジュールにはいくつかの弱点があります。 1 つは、サブモジュールがどのブランチを指しているのかを常に意識しておく必要があるということです。メイン リポジトリのリリース ブランチにいて、サブモジュールがフィーチャー ブランチにあるシナリオを想像してください。気づかないと、本番環境に向けて準備ができていないバージョンのコードをリリースしてしまうことになります。おっと。

次に、開発者のチーム内でこれについて考えてみましょう。一つの不注意なミスが大きな損害をもたらす可能性があります。

最初のオプションが問題があると思われる場合は、別のリポジトリでライブラリをホストすることが 2 番目の選択肢です。リポジトリのセットアップは非常に簡単ですが、現在ローカルでどのように作業していますか?

ローカルで働く

プロジェクトを適切に設定したので、OuterLib build.gradle ファイルに次のような行が含まれるはずです。

dependencies {
 implementation 'url_to_remote_inner_lib_repository'
}

開発サイクルを効率的かつ容易に行うにはどうすればよいでしょうか? InnerLib で何らかの機能を開発する場合、OuterLib でどのようにテストすればよいでしょうか?それともアプリケーション内でしょうか?

考えられる解決策の 1 つは、OuterLib プロジェクト内で InnerLib .gitignored を保持しながら、InnerLib をローカルでOuterLib プロジェクトにインポートすることです。これは、Android Studio の左側のメニューでプロジェクト名を右クリックし、[新規] → [モジュール] に移動することで簡単に行うことができます。

モジュールをインポートする方法 (ステップ 1)

次に、開いたウィンドウで、左下の [インポート] オプションを選択できます。

モジュールをインポートする方法 (ステップ 2)

ここまでは簡単でシンプルに思えますが、落とし穴は何でしょうか?

InnerLib に属するファイルを変更するたびに、その変更は無視されるため、InnerLib 内に反映されません。したがって、加えたい各変更は InnerLib 内で行う必要があり、変更を確認するには、OuterLib 内に再度インポートする必要があります。

これは正しくないようです。これを行うには、もっと良い方法があるはずです。

settings.gradle にわずか数行を追加するだけです。 ファイルを使用すると、InnerLib で変更を加えたときにファイルの同期を確実に保つことができます。

InnerLib をプロジェクトにインポートすると、Android Studio は InnerLib のコピーを作成し、キャッシュしました。そのため、ライブラリ内に変更を加えるたびにライブラリを再インポートする必要がありました。 projectDir を使用して、Android Studio にファイルを参照する場所を指示できます。 属性。

settings.gradle は次のようになります:

include ':outerLib', ':innerLib', ':app'

InnerLib をローカルで参照するには、settings.gradle を次のように変更する必要があります。

include ':outerLib', ':innerLib', ':app'
project('innerLib').projectDir = new File('PATH_TO_INNER_LIB')

このアプローチを使用すると、InnerLib ファイルが作業ディレクトリにリンクされるため、加えたすべての変更がすぐに反映されます。

ただし、InnerLib のリモート バージョンを使用して、OuterLib をローカルで作業する場合には柔軟性が必要です。上で settings.gradle ファイル内に記述した内容は、ローカルでの作業のみを許可するものであり、そのままではコミットしたくありません。

Maven ローカル

上記のアプローチが自分に合わない場合は、別のアプローチを取ることができます。 Maven を使用してライブラリをパブリックに公開するのと同じように、Maven local を使用して同じことをローカルで実行できます。 Maven ローカルは、マシン上にローカルに配置されるリポジトリのセットです。

以下は、マシンのオペレーティング システムに応じた mavenLocal のパスです。

• Mac → /Users/YOUR_USERNAME/.m2
• Linux → /home/YOUR_USERNAME/.m2
• Windows → C:\Users\YOUR_USERNAME.m2

基本的に、ライブラリをローカルに公開して、プロジェクト内でそのライブラリにリンクできます。このようにして、プロジェクトを InnerLib にリンクできます。

プロジェクトでこの構成を許可するには、次のことを行う必要があります。

<オル>

mavenLocal() を追加します。 リポジトリ条項内のリポジトリとして。これは、プロジェクトがローカルでリポジトリを検索できるようにするためです

buildscript {
 repositories {
 mavenLocal()
 }
}
...
allprojects { 
 repositories { 
 mavenLocal() 
 }
}

<オル>

依存関係句内の実装行を変更して、リモートで参照しているかのように InnerLib を参照するようにします。

InnerLib をローカルに公開するには、次の内容を含む PublishingLocally.gradle というファイルを作成します。

apply plugin: 'maven-publish' 
project.afterEvaluate {
 publishing { 
 publications {
 library(MavenPublication) { 
 setGroupId groupId //your library package
 setArtifactId artifactId 
 version versionName //I.E. 1.0
 artifact bundleDebugAar
 pom.withXml { 
 def dependenciesNode = asNode().appendNode('dependencies')
 def dependencyNode = dependenciesNode.appendNode('dependency')
 dependencyNode.appendNode('groupId', 'your_group_id')
 dependencyNode.appendNode('artifactId', 'your_artificat_id')
 dependencyNode.appendNode('version', 'your_version')
 } 
 }
 }
 }
}

<オル>

アプリケーション レベルの build.gradle ファイル内に、次の行を追加します。

apply from: '/.publishingLocally.gradle

この選択肢が真実であるには少し良すぎるように思えるかもしれませんが、それは真実です。 。一方で、リモート ライブラリを操作しているかのように、ローカルでシームレスに開発できます。一方、ローカルで作業中に InnerLib 内に変更を加えた場合は、ローカルで再度公開する必要があります。これはコストのかかるタスクではありませんが、退屈なタスクを何度も実行する必要があります。

ローカルおよびリモートで作業するためのソリューション

ローカルで変更を加えるたびに、InnerLib パッケージを再公開する必要が常に生じることを避けたいと考えています。プロジェクトにそれらの変更を認識させる方法を見つける必要があります。

「ローカルでの作業」セクションでその方法を確認しましたが、settings.gradle ファイルのコミットに問題がありました。この問題を解決して、InnerLib をローカルとリモートの両方で操作できるようにするには、gradle.properties で定義するパラメータを使用します。 ファイル。

gradle.properties ファイルは、開発環境を構成するプロジェクト レベルの設定を保存できる場所です。これにより、チーム内のすべての開発者が一貫した開発環境を確保できるようになります。

このファイル内にあるよく知られた設定には、AndroidX サポート (android.useAndroidX=true) や JVM 引数 (org.gradle.jvmargs=-Xmx1536m) などがあります。

この状況を解決するために、ローカルで作業するかどうかを示すパラメーターをここに追加できます。次のようなもの:

workingLocally = false

このパラメータにより、ローカルまたは実稼働コードでどの設定を使用しているかを区別できるようになります。まず、パラメータが true かどうかをチェックする条件でラップして、settings.gradle ファイルの内容を変更しましょう。

include ':outerLib', ':innerLib', ':app'
if (workingLocally.booleanValue()) {
 project('innerLib').projectDir = new File('PATH_TO_INNER_LIB')
}

このようにして、InnerLib のファイルをマシンからローカルに取得するようにプロジェクトに指示します。

ロジックを変更する必要があるもう 1 つの場所は、build.gradle ファイルです。ここでは、依存関係ブロックでコードをライブラリにリモートで取得する代わりに、ローカルで依存しているかどうかを示すことができます。

dependencies {
 if (workingLocally.booleanValue()) {
 implementation 'innerLib'
 } else {
 implementation 'url_to_remote_repository'
 }
}

⚠️ 警告:ローカルで作業する場合は、gradle.properties ファイルを決してコミットしないでください。

旅は長くて、かなり疲れたように思えたかもしれません。しかし今では、複数のライブラリ プロジェクトをローカルおよびリモートで作業するための完全なセットアップが用意されています。

問題が発生した場合、またはこれについてご意見がございましたら、お気軽にコメントを残してください。

無料でコーディングを学びましょう。 freeCodeCamp のオープンソース カリキュラムは、40,000 人以上の人々が開発者としての職に就くのに役立ちました。始めましょう