白いラベルのプラットフォームモバイルアプリケーションの展開を処理するにはどうすればよいですか？

Question

私は多くの異なる組織（理想的なシナリオ、数十）に展開される製品に取り組んでいます。 （iOSとAndroid向けのネイティブアプリケーションで構成）システムの各展開には、次のように関与します：組織に固有

• ブランディング（すなわち新しいスキン）
• 組織の認証システムとユーザーデータベース
との統合組織のニーズ言い換えれば

を依存

いくつかのカスタム機能は、コア機能は、すべての配置で同じままになりますが、各インスタンスが異なって見えるだろう、異なる認証システムにフック、および肝炎特定の機能を有効/無効にします。

私の質問：何が重複を最小限に抑え、展開プロセスを簡素化するために、私たち2つのモバイルコードベース（iOSの&アンドロイド）を管理するための最善の戦略でしょうか？私たちが議論している

3の解決策は以下のとおりです。

1. は（サブ・プロジェクト/ライブラリプロジェクト、またはGitのサブモジュールとして）すべてのインスタンス間で共有されるコアライブラリを作成し、薄いを追加しますブランディングと設定の詳細が表示されます。

2. コア機能を持つGitブランチを維持し、追加のコードを含む各デプロイメント用に新しいブランチを作成します。

3. stackoverflowのスマートな人が示唆していることとはまったく異なることを示唆しています。

どの音色がお使いですか？フィードバックに感謝します！

Answer 1

私が考えているアプローチは依存性注入です。

Androidの場合、SquareのDaggerなどの依存性注入ツールを使用すると、アプリケーションにコンポーネントを提供して注入する@Moduleクラスを簡単に作成できます。こうすることで、各ホワイトラベルクライアントのロジックを別々のコンポーネントとして管理することができ、コンパイル時に特定のコンポーネントが@Moduleクラスのリファレンスを通じて選択されます。

これはまた、アプリケーションをテストするための優れた方法であり、定型コードをたくさん避けることができます。

もスクエアで与えられ、次の交渉に大きな情報があります：

Dagger: A Fast Dependency Injector for Android and Java

Engineering Elegance: The Secrets of Square's Stack

のiOSは、同様の枠組みを持って、一つはObjectionです。ボックスのオプションの外

：それは、モバイルクライアントがホワイトレーベルのサーバーに直接話をしなければならない要件

ですか？そうでない場合は、ホワイトレーベルのサーバーへのプロキシとして独自のサーバーを使用することを検討することをお勧めします。これにより、すべてのビジネスロジックがサーバーに移行し、すべてのクライアントがサポートされます。

私はこれに関する経験はありませんが、一見有望な選択肢は、Googleで開発中のJ2ObjCです。私たちは似たような状況にいる

J2ObjC is an open-source command-line tool from Google that translates 
Java code to Objective-C for the iOS (iPhone/iPad) platform. This tool 
enables Java code to be part of an iOS application's build, as no editing 
of the generated files is necessary. The goal is to write an app's non-UI 
code (such as data access, or application logic) in Java, which is then 
shared by web apps (using GWT), Android apps, and iOS apps. 

Answer 2

は（私たちは、AndroidとiOSのコードベースの両方でのホワイトレーベルのアプリのプラットフォームを持っている）と我々はC＃実装に私たちのネイティブコードベースを転送することがあります。 MonoTouch/Mono for Androidを使用します。私は先週から実際にこの作業を始めました（私はSOに関するいくつかの質問をして、Monoの基本を理解しています）。

これは事実上オプション1ですが、すべてのプラットフォームはC＃コードでビルドされます（オプションで、必要に応じて "ネイティブ"コードベースと対話する機能もあります）。

Monoは、プラットフォーム間のコードの30〜50％をどこかで共有できるようにする必要があります（現在、iOS & Android、将来はおそらくWindows Phone）。私が経験した小さな経験から、パフォーマンスは良いと思います（覚えておいてください：high-performance gamesを作成するのに多くの人がMonoGameを使用していて、Unityも3DゲームでMonoを使用しています）。私の個人的には、これも付加価値です。私はまだゲームをいつか作ることが大好きで、 "真剣な"アプリケーションのためのMonoフレームワークの基本的な経験は、ゲームアプリケーションのためのMonoGameフレームワークの使用の障壁を下げるでしょう。

この設定に関する素晴らしい点は、すべてのコード（Android、iOS、Windows Phone）を1つのソリューションに保持できることです。コア "ライブラリ"プロジェクト（モデル、サービスコールなど）を作成し、各プラットフォーム用に別のプロジェクトを作成します。特定のプラットフォームプロジェクトには、それぞれ本物のネイティブエクスペリエンスを持つ適切なUIが用意されています。

Monoを使ってマルチプラットフォームアプリケーションを作成する方法についての印象は、read a small introduction hereです。

Answer 3

あなたはネイティブのGUIを使用Unity3dに依存していない場合は、 は、すべての主要な機能を使用して独自のユニティ・パッケージを作る（およびすべてのプラットフォームのための単一のアプリとしてそれを開発）、 どんな展開アプリの新しいユニティプロジェクトを作成する必要がありますし、このパッケージを にインポートしてください（リソースを置き換えてconfigを編集することもできます）。 （コア機能をアップグレードする必要がある場合は、配信プロジェクトにコアパッケージの新しいバージョン を再度簡単にインポートする必要があります）。

またはあなたのオプション1を使用します。

1. C++コアライブラリでは、すべてのアプリケーションのために、個々のことができ
2. リソースパッケージ（autorizations &モジュールのコンフィグもここにいるかもしれない）
3. のネイティブUIの実現をすべてのプラットフォームAndroid-Java、OSS-Objective-C