同じアプリケーションを異なるコンテンツ(またはスタイル、構成)で使用するための一般的に受け入れられている方法は、共通のコード(つまり、アプリケーション全体、「エンジン」、「アプリ」)にAndroidライブラリプロジェクトを使用することです。フレームワーク」)およびコンテンツ用の標準のAndroidアプリケーションプロジェクト(つまり、実際にはデータのみを含むアプリケーション)。ここの「ライブラリ」が実際には「アプリ」全体であるという理由だけで少し混乱しますが、これが進むべき道のようです。
詳細:
- Androidライブラリアプリケーションを作成し、できるだけ多くのコードをその中に入れます(変更されないものすべて)。このライブラリは起動できず、単独で配布することもできませんのでご注意ください。ホスティングアプリケーションに含まれている必要があります。
- 標準のAndroidアプリケーションを作成します。ライブラリをこのプロジェクトに含めます。/resと/assetにすべてのデータ(ファイル、XMLなど)を入れます。
- すべてをコンパイルして配布します。
別のバージョンが必要になるたびに、このサイクルを繰り返します。データ、スタイル、構成、またはその他の理由で異なります。結果のアプリを新しい名前で公開します。
私に関して言えば、私はこのアプローチに完全には満足していません。
考えられる代替手段は、Ruby、Python、Perl、GIT、bash、Ant、Maven、Rake、またはここからファイルを読み取り、あちこちで変更を加え、そこにファイルを書き込むことができるその他のツールを使用してソースコードを前処理することです。 。
一般的な概要は次のようなものです。
- 「テンプレート」アプリケーションを作成します。/resと/asssetは空のままにします。
- カスタムメイドのスクリプトを実行します。スクリプトは、構成ファイルを読み取り、リポジトリからプロジェクトの/resおよび/assetディレクトリに/resおよび/assetファイルをコピーし、Javaソースファイルを変更し、XMLファイルを作成/変更します。
- コンパイルして配布します(もちろん、新しい名前で)。
GITまたは他のSCMを使用すると、新しいバージョンごとに新しいブランチを作成してコンパイルするだけです。あまりエレガントではありませんが(SCMの通常の使用を強く妨げる可能性があるため)...
Web上にこれらのアプローチのいくつかの例があります。私も彼らに完全に満足しているわけではありません。
率直に言って、この問題を解決するためにAndroidエコシステムが提供する必要があるのは、ある種の「アプリ内パッケージマネージャー」です。EclipseUpdateManagerのようなもの。これにより、同じアプリケーションフレームワークを使用してさまざまなシナリオを処理できるようになります。
別の方法として、しっかりした、公式にサポートされている、テンプレートベースのコード生成メカニズムがあれば便利です。「ソフトウェア生産ライン」の精神に基づく何か:https://en.wikipedia.org/wiki/Software_production_line。fw4splを見てください。例:http ://code.google.com/p/fw4spl/ 。