8

「ベースアプリ」と呼ぶアプリがあります。アプリは多くのブランドで動作します。これらのブランドを分離し、ブランドごとに異なるアプリを作成する必要があります。すべてのアプリはわずかに異なるデザイン (異なる画像を含む) を持ち、あちこちにブランド固有のコードが含まれている可能性があります。また、すべてのアプリは、ロジックを処理する「ベース アプリ」から同じベース コードを使用する必要があります。

考えたいくつかのオプションがありますが、それらのいずれかが私のニーズに合っているかどうかはわかりません. オプションの違いを明確にしていただけると幸いです。

私が考えたオプションは次のとおりです。

1) ブランドごとにアプリを作成し、コピーとしてコピーされる .xib ファイルを除いて、参照として「ベース アプリ」からクラス ファイルをコピーして貼り付けます。問題は、ブランド固有のコードをどこでどのように記述すればよいかわからないことです (他のユーザーと共有されるため)。

2) 各ブランドのプロジェクトを含むワークスペースを作成します。これがどのように機能するのかわからず、これが正しい場合は、ここで明確にするのに役立ちます.

3) すべてのブランドのプロジェクト内に「ベース アプリ」プロジェクトをネストします。それが何をするのかを明確にする助けがあれば幸いです。

3) すべてのブランドのプロジェクトにリンクされる静的ライブラリとしてベース アプリを使用します。UI がどうなるかわからない (共有、非共有)。ここでも明確にするのを手伝ってくれてうれしいです。

4) 共有コードを含む、ブランドのプロジェクトのそれぞれを維持する簡単な方法を使用する (これはおそらく惨事になるだろう)。

4

3 に答える 3

5

アプリを次のコンポーネントに分割することをお勧めします。

  • コア モデル ライブラリ
  • 再利用可能なビューとビュー コントローラー。ビューは、スキニングとカスタマイズをサポートするように設計できます。
  • 独自の「ID」としてカプセル化できるその他の再利用可能なコード。

これらのコア プロジェクトには、独自の継続的インテグレーション (品質管理) ビルドとテストが理想的です。

そして、CoocaPodsを使用します

この複雑な統合をすべて手動で実行する代わりに、CocoaPodsを使用してください。CocoaPods は Xcode ワークスペースを作成し、ライブラリをビルドしてプロジェクトにリンクします。次に、ピースを接着するだけでカスタム ビルドを作成します。

これに加えて、CocoaPods は次のようなタスクも実行します。

  • 推移的な依存関係の解決- これは、ライブラリ自体が使用するライブラリをビルドしてフェッチすることを意味します。
  • 統合されているライブラリのバージョンを管理します。

プライベート スペック リポジトリが可能、または単に GitHub を使用

メインの CocoaPods リポジトリはもちろん公開されており、オープンソースや自由に利用できるライブラリが含まれています。

独自の CocoaPods 仕様リポジトリをホストするか、単にプライベート GitHub アカウントをセットアップして、各プロジェクトに PodSpec を含め、次のように解決できます。

pod 'MyLibraryName', :git => 'https://github.com/myOrgName/MyLibrary.git'

これにより、すべてのライブラリがワークスペースにインストールされます。プロジェクトを更新してコア ライブラリへの変更を含めるには、次のようにします。

pod update

このアプローチの利点

  • 各コア プロジェクトに適用される個別の品質管理セットを用意します。
  • 評判はかなり落ちます。
  • より多くの自動化を使用できます。自動化が進むほど無駄が減り、顧客価値が高まります。
  • チームが成長するにつれて、コア製品の開発とソリューションの統合を別々の役割/チームに分割できます。統合ビルドに取り組んでいるチームは、最新のライブラリ機能をプルする必要はありません。
  • コア ライブラリの異なるビルドで 2 人の異なる顧客を持つことができます。CocoaPods はこれをシームレスに管理します。したがって、機能強化のリクエストまたは定期的なメンテナンスを受けるまで、必ずしもビルドを更新する必要はありません。(再び廃棄物を減らし、顧客価値を高めます)。

Piggly Wiggly にインスパイアされた (ただし、ずるずると傾いている)

このアプローチは、第二次世界大戦後に日本で普及した生産ラインスタイルのアプローチをモデルにしています。それはリーン方法論と呼ばれ、迅速で小さな在庫を持ち、無駄を減らすことがすべてです. (より少ない費用でより多くを提供します)。. 日本の幹部は、アメリカに行って Piggly Wiggly Supermarket の店舗を訪れたときに、これについてのインスピレーションを得ました。

于 2013-11-05T08:59:47.337 に答える
5

iOS での簡単な解決策は、ターゲットを使用することです。

リソースについては、ブランドごとに異なるターゲットを使用し、ターゲットごとに異なるリソース (画像、xib など) を選択できます。

また、コードの変更が最小限である場合は、コードの一部をリファクタリングし、ターゲットごとに異なる実装で異なるクラスを作成できます (Factory などのパターンを使用できます)。また、単純にプリプロセッサ マクロを使用することもできます。

それは良いことではありませんが、これが最も簡単で迅速なアプローチですが、コードが大幅に変更される場合は、他の回答が言うようにコア ライブラリを作成することをお勧めします。

于 2013-11-05T10:13:21.460 に答える
1

これは、安価なフラッシュ ゲームやアプリを作成する際によく遭遇するものです。

これらには、ボールを蹴る、画面に向かって撃つ、特定のサーバーからダウンロードしたデータを含むリストを生成するなど、非常に一般的なフレームワークがあります。

新しいシューティング ゲームを作成するたびに、シューティング フレームワークをロードし、大量のグラフィックスを追加するだけで、1 日以内にくだらないゲームをリリースできます。

どうやってやっているの?

多くの場合、共有モデル、ハンドラー、インターフェースなどを含むフレームワークを作成します。ファイルのダウンロードなどの多くの一般的なユーティリティ関数をライブラリに配置します。また、いくつかのデフォルトのフレームワーク ビューとビュー コントローラーを作成することもできます。

同様のアプリを作成する場合は、ライブラリをインポートしてベース フレームワークを再利用するだけです。ベースビュー、ベースモデルなどを含みます。

ios SDK または android SDK で提供される demo-examples で良い例を見つけることができます。

幸運を。

于 2013-11-05T08:59:02.317 に答える