モジュラーAndroidアプリケーション開発

Androidアプリケーションを開発するとき、コードの特定の部分をライブラリの形でレンダリングして、異なるプロジェクトで再利用できるようにすることができます。

• 頻繁に見つかるプロジェクト内のモジュール。 たとえば、カスタムビュー
• 既存のAPIが不便だったり、意図したことを実行できない場合は、このAPIの拡張機能を作成します

ほとんどの場合、すべての問題は私たちよりずっと前に解決されましたが、私たちのケースでは、ビジネスロジックレイヤーの一部と、統合された企業Wheels Roof Marketの 3つの主要製品のデータを担当するレイヤー全体をレイアウトする必要がありました。 当社の製品はすべて、自動車、不動産、その他の商品に関する分類です。 そのため、開発者である私たちは、会社のすべての製品に対して1つのソリューションを作成することにしました。 さらに、それは私たちの仕事を促進しました。

gitサブモジュールを試しました

最も簡単な解決策は、gitサブモジュールを使用することです。 その動作を簡単に説明する場合、別のgitリポジトリへのリンクを添付します。これは自動的に親とともに複製されるはずです。 すべてがシンプルに思えます。すべてのモジュールライブラリが格納されているgitリポジトリがいくつかあり、gitサブモジュールで指定するだけです。

しかし、バージョンはどうですか？ git submodule updateコマンドで更新すると、サブモジュールへの変更は消去され、マージは発生しません。 別の開発者がこのサブモジュールに変更を加えた場合、常に更新する必要があります。 代わりに、jarファイルまたはAndroidアーカイブ（aar）を備えたライブラリーの形式でモジュールを開発する価値があります。 実際、これらのアーカイブにはgitサブモジュールにある可能性のある同じファイルが含まれていますが、現在はコミットまたはタグの履歴ではなく、より理解しやすいバージョン管理があります。

注意、すべてを公開できるわけではありません。

ライブラリを公開する場合、企業の機密データを含めないように注意してください。 さらに、ライブラリに特定の会社に関連するコードが含まれている場合、他の開発者にとっては便利ではありません。 したがって、ライブラリをプライベートアクセスで保存するためのプライベートアーティファクトが必要です。 多くのオープンソースソリューションがありますが、私たちはJFrog Artifactoryを使用しています。

また、公開できる場合はどうなりますか？ この場合、オープンソースプロジェクトの世界への明るい道が見つかります。 ホストされたjarファイルとaarファイルがプロジェクトの依存関係を介してプルされるように、単にgradleをサポートするオープンWebサーバーを見つけます。

それで、モジュールを作成し始めます

それはすべて単純に始まります- File > New > New Module…





このウィンドウで指定するライブラリの名前は、ライブラリのバイナリの名前になります。

モジュールを作成したら、コードの記述を開始できます。 添付コードにテストを書くと、チームの他のメンバーはモジュールの使用方法を理解できます。 さらに良いことに、実際のデバイスでのデモ用にモジュールと排他的に動作する新しいサンプルアプリモジュールを作成します。 アーティファクトに公開する前にコードを事前にテストする必要がある場合に便利です。 これを行うには、 build.gradleで依存関係を指定するだけです。 例では、モジュールの名前としてlibrarymoduleを示します。

 # {module project}/sample-app dependencies { implementation project(":librarymodule") }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

gradleをカスタマイズしてアーティファクトに公開する

Chris Banes： Gradleスクリプトからビルドスクリプトを取得して、アーティファクトをMavenリポジトリにアップロードします

具体的には、彼の場合、プロセスは公開出版のためにMavenリポジトリに記述されています。 主な設定はまったく同じです。公開する各モジュールで、モジュールのbuild.gradleファイルからgradleスクリプトファイルを呼び出し、gradle.propertiesを作成します。ここには、公開の構成情報が格納されます。 私たちは、私的なアーティファクトで公開する能力に興味があります

 # {project}/build.gradle RELEASE_REPOSITORY_URL={artifactory_url}/release-modules SNAPSHOT_REPOSITORY_URL={artifactory_url}/snapshot-modules
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アーティファクトの公開用に2つのフォルダーを追加する必要があります。1つは公式リリース用で、もう1つはモジュールのテストビルド用のスナップショットです。

最終的にgradle.properties構成ファイルを構成したら、アーティファクトでライブラリを最初に公開する準備ができました。 テストビルドで、SNAPSHOTをVERSION_NAMEに設定します。 次に、コマンドを実行します。

 ./gradlew clean build sdk:uploadArchives
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CI環境の設定

私たちはプライベートのアーティファクトでモジュールを手動で公開することができました。 結論として、開発プロセスにパブリケーションを埋め込むことができるようにCI環境を構成することは残っています。

リリースアーティファクトで公開するのはCIのみで、残りはスナップショットへの無料の読み取りおよび書き込みアクセスを追加します。 したがって、ルートgradle.propertiesファイルに変更を加えます。通常、このファイルは~/.gradle/gradle.properties



ます。 アーティファクトに公開するときのアクセス用に、{％username％}と{％password％}を登録します。 したがって、.gitignoreを変更せずにアクセスレベルを構成します。

 // ~/.gradle/gradle.properties artifactory_username=login artifactory_password=password
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マスターブランチにトリガーを追加して、マージ時にリリースアーティファクトで公開するためのビルドを作成します。 モジュールにテストがある場合は、アセンブリタスクのリストにテストの起動を追加します。 自動インクリメントバージョンを設定することをお勧めします。

 # Checkout git repository with modules #   ./gradlew test #     ./gradlew librarymodule:build #   artifactory ./gradlew libarrymodule:uploadArchives
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

製品でモジュールを使用します

CIがアセンブリを収集し、アーティファクトで満たすとすぐに、プロジェクトにこのモジュールの依存関係を追加できます。 しかし、ちょっと、アーティファクトにURLを追加する必要があります。URLはmavenのような典型的なリポジトリでは利用できないためです

 # {project}/build.gradle allprojects { repositories { maven { url artifactory_url/release-modules } maven { url {artifactory_url}/snapshot-modules } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでプロジェクトで使用できます。

 # {project}/app/build.gradle dependencies { implementation 'kz.kolesa-team: librarymodule:1.0.0' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちは何に直面していますか

Kotlinをモジュールに接続するとき、Kotlinファイルのドキュメントは取得されません。 そのためには、 Dokkaで gradleタスクを追加する必要があることがわかりました。

複数の開発者が公開時にライブラリの同一バージョンを指定した場合、もちろん、最新の公開はモデルの最新バージョンでした。 モジュールの開発プロセスでは、JiraからのチケットIDを使用して後置記号を指定する必要がありました。 1.0.1-AAS-1-SNAPSHOT



ます。

最終的に何が起こったのか

時間が経つにつれて、モジュールの数が増えてきました。 各モジュールは別々のgitリポジトリに保管しました。 多くのgitリポジトリは、モジュールが他のモジュールに依存している場合、開発プロセスに多くの不便をもたらします。 最終的に、1つのタスクを完了するには、各gitリポジトリにPRを作成する必要があることが判明しました。 PRの1つに変更が加えられた場合、PRの絶え間ない変化を考慮せずに、テストする順序が明確ではありません。 したがって、実際にはすべてのモジュールに1つのgitリポジトリを使用することが最も便利であることがわかりました。

このようなモジュールを多数持つことができます。 特定のプロジェクトで特定のモジュールが必要ない場合は、依存関係を簡単に削除できます。これにより、3つのプロジェクトのそれぞれで重複コードを記述できなくなります。

このようなビジネスの内部コンポーネントのモジュラー開発は、ユーザーへの機能の配信速度を向上させるのに役立ちます。 結論として、モジュラー開発の重要な利点に注目する価値があります-apkファイルのアセンブリは、gradleが変更が発生したモジュールの部分のみを再構築するため、はるかに短い時間で済みます。