2011-02-03 4 views
9

考えてみましょう。テンプレートという異なるクライアント用にカスタマイズしなければならないアプリケーションがあります。主な目的は、ほぼ同じ機能を持つ多数のパーソナライズされたアプリケーションを提供することです。コントロール、ビュー、アイコンのビジュアル要素に設定されたXcodeプロジェクト管理:単一のエンジン - 異なるパーソナライズアプリケーション

  1. 必ず異なる画像(:

    各クライアントのアプリケーションのために、以下の点を達成するためにXcodeのプロジェクト組織(そしておそらく管理)の最良の方法は何ですか等);

  2. 小さなUI構造の変更のためにまったく異なるXIBファイル。
  3. ビジュアルなカスタマイズ - コードレベル。小さな機能的修飾;
  4. 以前のパーソナライズされたバージョンに戻る可能性があります。
  5. 1つの機能エンジン(検索機能など)。

私は同じプロジェクトのルートディレクトリ 新しいプロジェクトファイルに作成するすべてのパーソナライゼーションの要求のために現時点で

、および対応するXIBファイルがは、画像は、いくつかのために(ソースファイルを設定しました機能要求)ディレクトリ。各プロジェクトファイルには、のメインソースファイルディレクトリ(エンジン)への参照があります。

しかし、私はそれがこのタイプのプロジェクトを編成する最良の方法ではないと思います。

+0

@Joe静的ライブラリは、エンジン自体を表します。しかし、周りの他のものはどうですか? –

答えて

2

プロジェクトテンプレートを作成するか、テンプレートを含むzipファイルを作成します。

最初に、上書きやその他のソースレベルの変更ではなく、xmlのdefを使用できる場所を特定します。

(コントロール、ビュー、アイコンなどの)視覚要素には常に異なる画像が設定されます。プロジェクトテンプレートに

追加プレースホルダ資源小さなUIの構造の変更のため

まれ異なるXIBファイルが

は(それが変わったの場合)、VC

を経由して、変更を参照して、プロジェクトに追加します

視覚的なカスタマイズ - コードレベル。

すべてのプロジェクトで共有されるコアライブラリ。ライブラリが大きくなる場合は、cまたはC++を使用することを検討してください。 objcは削除できません。これには、実装スタブ、共通コード、基本クラス、およびインタフェースが含まれます。サブクラスが容易頻繁に変更を実装することができるよう

小さな機能変更

は、コアクラスのインターフェースを拡張します。これらのファイルはテンプレートの一部です。

以前のパーソナライズされたバージョンに戻る可能性があります。

これはvcでなければならず、依存バージョンも追跡する必要があります。

1つの機能エンジン(検索機能など)。

未定義のファクトリ関数は十分に簡単です:

id<MONSearchEngineProtocol> MONAppCoreCreateSearchEngine(); 

静的libにそれを宣言しますが、定義(とは何が必要かを実装する)は、プロジェクトの特定の源の一つに。あなたはこの他の場所を追加することができます - 一部の人々はそれをアプリコントローラに入れて、それを上書きします。

これらを多く管理している場合は、リソースをコードに移動することを検討してください(多数のペン先を管理するのではなく)。ペン先は多くのコードを定義しています。これは管理するコードがほぼ重複しています。これはいくつかのリソースには意味があり、他のリソースにはあまり意味がありません。

1

Xcodeのターゲットを使用します。 1つのターゲットに含まれるさまざまなリソースおよび/またはソースファイルを指定できます。

1つのファイルに複数のコードをカスタマイズする場合は、すべてのターゲットに対してコンパイラマクロを定義し、#ifdef MY_MACROを使用してその特定のターゲットのコードを組み込みます。

+0

+1(ただし、オールインワンは「必須」ではありません)。しかし、 '#ifdef MY_MACRO'はおそらく2〜3のプロジェクトの良い解決策です。私は15以上あり、これは混乱を招くでしょう:) –

10

バージョンコントロールを使用してこのようなことを行うことを選択し、カスタマイズされたバージョンごとに別々のブランチを維持することをお勧めします。そうすれば、マスター/トランクはカスタマイズされていないコードになる可能性があります。

カスタムバージョンを作成する必要がある場合は、別のブランチを作成するだけです。あなたのコアアプリケーションを変更する必要がある場合、トランクからブランチへの変更を簡単にマージする必要があります。これにより、すべてのカスタマイズされたコード/ファイルを別々に保つことができます。

これはあなたのワークフローにどれくらい簡単にフィットするかわかりませんが、以前のバージョンに戻ることができるなど、すべてのボックスに目を通すと思います。

+0

数日後、私はコードで解決策を提案する1つおきの答えを見たり、Xcodeのターゲットシステムを使用したりすることに本当に驚いています。何か不足していますか?私にとってこれはまともなバージョン管理ツールが行うように作られているようです。 – paulbailey

+0

これはまったく別のワームです。私の個人的な好みはGitですが、私はMercurialもまともな仕事をしてくれると確信しています。またはSubversionをプッシュしても(IMHOをマージするほど良いわけではありませんが)。 – paulbailey

+1

私はポールに同意します。 SCMは私の心の中で最善の方法です。私もgitを提案します。 gitを使いたいのであれば、 "エンジン"をサブモジュールにすることさえできます。つまり、視覚的なカスタマイズは実際にはエンジンの「支店」ではない)、あるアプリの機能を変更してもその機能が使用されているかどうかを確認するのに役立ちますが、他の機能を無効にすることはありません。 – mohsenr

0

1つのファイルで複数のコードをカスタマイズする場合は、「コンパイラマクロ(定義と使用)」を使用します。

Xコードターゲットを使用することはできますが、これはあまり役に立ちません。

私も作業を開始しました。 :-)

ハッピーXCoding

1

あなたは、コンテンツを提供するためのXMLを使用してコンテンツ管理の多くを行うことができます。例。あなたはどちらかのiPad用の画像に異なるグラフィックをしたいか、iPadの場合は、このようなタグの何かを作成することができます

<MyLogo logoID="0"> 
<ipad image="someImage2X" height="50" width="50" position="100, 100"/> 
<iphone image="someImage2" height="50" width="50" position="100, 100"/> 
</MyLogo> 

をそしてofcourseのXMLのパーサを作成します。これにより、異なるタイプの同じタイプの多くの異なる製品を作成することができます。

また、作業中のデバイス/コンテンツを確認し、必要に応じてパーサーを使用してタグを修正します。

Hench:エフェクトのコア機能を実装していれば、さまざまなエフェクトに異なるxml属性を作成できます。

ハッピーコーディング

2

すべての基本機能を持つ静的ライブラリを作成します。その後、すべてのプロジェクトがこの静的ライブラリにリンクできます。つまり、バグが見つかった場合は、一度修正するだけで、すべてのクライアントプログラムを再構築するだけです。

関連する問題