3

Androidマーケットプレイス用のアプリを計画しています。

まず、フルアプリを有料アプリとして公開する前にフィードバックを収集するために、無料のRCとして公開テスト用にリリースしたいと思います。RCがフルバージョンに置き換えられた場合、いくつかの制限付きの無料のLiteエディションを公開します。

計画は、RCに制限なしで基本的な機能セットを追加することです。

後であります

  • より多くの機能を備えたフル有料版
  • フルと同じ機能を備えたLiteの無料バージョンですが、特定の制限があります。

アプリケーションの進化に伴うコードのリファクタリング/移動を回避するために、プロジェクト構造を計画する方法についてのアドバイスを探しています。

このようなものは合理的に見えますか？

  • メインブランチ
  • RC無料アプリはMAINブランチから派生し、準備ができたらマーケットに公開されます
  • RCライフサイクルが終了すると、RCからのすべての変更がMAINブランチにマージされ、RCブランチは中止されます。RCアプリもマーケットから撤退しました。
  • Lite無料アプリはMAINブランチから派生しており、Liteブランチにはいくつかの制限が適用されます
  • MAINブランチは、フル有料アプリのブランチになりました。フルアプリの新しいリリースの準備が整うと、変更がLiteブランチにマージされるため、制限を削除せずに新しい機能が追加されます。
4

2 に答える 2

1

しばらく前に同じ問題に直面していたので、次のような構造にすることにしました。（私はLITE / PAIDエディションのアプリを持っています）。

私は両方のエディションに単一のコードベースを使用していますが、Mavenのおかげでこれを行うことができます。これを使用すると、必要なターゲットバージョンをビルドできます。

My Maven（pom.xml）は、まったく新しいソースベースの作成、パッケージ名のリファクタリング、AndroidManifestの変更、アイコンの置き換え、プロパティファイルの置き換え、APKのビルドと署名を、すべて1つのコマンドラインで行うように構成されています。 ：

mvn install -Dedition=lite -P release

これは良い解決策だと思います。唯一の欠点は、pom.xmlを正しく構成するためにいくつかの作業が必要になることです（特にMavenをよく知らない場合）。

お役に立てれば

于 2012-10-19T18:56:15.400 に答える
0

Eclipse ADTに（より）慣れている/慣れている場合は、ライブラリプロジェクトと2つの依存プロジェクト（ライト、フル）をセットアップすることも別の方法かもしれません。firstlightassociatesとdonnfelkerの詳細。

  • com.example.myapp-すべてのコードと特定の機能のオン/オフを切り替えるためのパッケージ名のランタイムチェックを備えたAndroidライブラリ。
  • com.example.myapp.full-Androidアプリケーション。フルバージョン固有のアセット。
  • com.example.myapp.lite-Androidアプリケーション。ライトバージョン固有のアセット。
于 2013-01-18T09:38:24.403 に答える