2

アプリをアプリ ストアで承認しましたが、クライアントの 1 人がアプリにいくつかの追加機能を必要としています。そのクライアント用に別のコード ベースを使用することを考えていますが、将来、より多くのクライアント用にアプリをカスタマイズする必要がある場合はどうすればよいでしょうか。実際のコード ベースの拡張の場合、変更を実際のコード ベースから他のすべてのコード ベース (カスタマイズされたもの) にマージする必要があり、面倒です。任意のヘルプ、提案をいただければ幸いです。

4

3 に答える 3

3

私が働いている会社でこれを行っています。私たちが持っているすべての異なるアプリに同じコードベースを使用しており、それらを異なるブランドにすることもできます。このために、アプリに基づいているブランドに基づいてそれを行うブランディングシステムを作成したので、異なる、、を設定できtext、パーティクルブランドに固有である必要があるものをそのブランドだけに設定できます。したがって、これを行うための最良の方法は、必要なブランドごとに異なるターゲットを作成し（各ターゲットは独自のアプリになります）、ソースが正しくリンクされていることを確認することです。colorsimages

また、すべての共有コードを含むフレームワークを作成してから、すべての個別のコードをアプリ自体に配置するか、フレームワークに追加して、クラスのLogin Processクラスを個別の機能に分割することもできます。のクラスEmailingPrintingStoring data等々。次に、クライアントが別のクライアントが持っている機能を持ちたい場合は、すでにコードがあり、それを呼び出す必要があります。これにより、開発時間とバグ修正が節約され、古い機能を修正する代わりに、より多くの機能の開発により多くの時間を費やすことができます。また、SVNまたはGITを使用すると、コードを保存し、アプリを簡単に作成できるようになります。たとえば、フレームワークとテンプレートアプリのトランクバージョンを作成し、フレームワークとそこにあるすべての異なるブランドの各クライアントのインクリメンタルリリース用のブランチを作成できます。アプリの開発に関しては、ソース管理が非常に重要です。

私の会社のやり方の例は、1人のクライアントに対して1つのプロジェクトがあり、次に各ブランドのターゲットがあることです。したがって、ClientAがあり、同じアプリの3つの異なるバージョンが必要な場合は、プロジェクトを作成してClientAのような名前を付け、3つのターゲットを呼び出します。次にBrand1、アプリの1つにバグが発生した場合（ターゲット）そうすれば、それが他のアプリにも含まれることがわかり、1つの問題を修正するだけで、3つのアプリすべてに対して修正できます。Brand2Brand3

これにはいくつかの問題がありますが、維持するための巨大なコードベースを持つことができますが、すべてが1つの場所にあるため、維持が容易です。コードベースにバグが1つある場合、それはすべてのアプリにありますが、それはすべてのアプリの修正ではなく、1つの修正にすぎません。そして最後の問題は、非常に複雑になる可能性のあるフレームワーク自体を作成する必要があるということですが、これは役立つ場合があります。

フレームワークを作成することのすべての長所が短所を上回っていると私は信じています。したがって、すべてのアプリがリンクされるフレームワークを作成することをお勧めします。また、CSSに対して、iPhone、iPad、さらにはMacOSX用のよりシンプルなシステムの作成もご覧ください。私は過去2か月間、Objective-cを実際に知らなくてもアプリを非常に簡単にブランド化（スタイリング）できるシステムを開発してきました。そのため、現在、アプリにUIElementsを追加し、すべての要素の属性を設定できます。開発者がObjectiveと対話することなく-すべて。この理由は、私たちのチームには、モバイル開発会社ではなくインターネット開発会社であるため、CSSがないため、Objective-cを知っている人はそれほど多くないためです。これは、Windowsコンピューターでも実行できます。 Macサーバーを使用してビルドします。Macサーバーはをビルドします。

これが少し役立つことを願っています。

于 2012-09-28T14:06:39.763 に答える
0

SVN や GIT などのソース管理システムを使用します。中央リポジトリなしでローカルで使用でき、Xcode でサポートされている Git をお勧めします。

ソース管理により、同じアプリの異なるバージョンを非常に簡単に管理できます。あなたの場合、現在のバージョンをリポジトリにチェックインします。次に、ブランチを作成して、新しい機能をクライアントに実装できます。後で、変更をメイン コード ベースにマージできます。

于 2012-09-28T13:03:16.957 に答える
0

ソース管理は、コーディングしようとしているものは何でも必要ですが、この場合、さまざまな機能に対して複数のコード ベースを維持することはあまり効果的ではない可能性があります。2 つのコード ベースが大きく異なる場合に発生する競合の量は膨大になります。

あなたの機能がどれほど重いかに応じて、私はおそらく「一定の方法」に行きます。

アイデアは、すべてに同じコードを使用することですが、クライアントの名前などの定数に基づいて、これらの機能を表示または非表示にすることです。コンパイルして配布する前に、定数を正しい顧客に変更するだけです。

疑似コード

#define Customer = CUSTOMER_A

if (Customer in (CUSTOMER_A, CUSTOMER_B) {
  [self showButtonPickAContact]
}

アップサイド

  • 1 つのコード ベースのみ
  • メンテナンスが容易
  • 既存の機能を古いクライアントに簡単に追加できます
  • 1 人の顧客の地図だけを追加するなど、小規模な機能セットに非常に適しています

欠点

  • コードベースは誰にとっても大きくなります
  • 機能の 1 つが 50 MB のファイルを 1 人の顧客だけに含めるようにする場合、このシステムを使用することはできません。
  • コードとデザインは、書く/デザインするのが少し難しい
于 2012-09-28T13:58:55.297 に答える