6

私は、多くの異なる組織 (理想的なシナリオでは数十) に展開される製品に取り組んでいます。システム (iOS および Android 用のネイティブ アプリで構成される) の各展開には、次のものが含まれます。

  • 組織に固有のブランディング (つまり、新しいスキン)
  • 組織の認証システムおよびユーザー データベースとの統合
  • 組織のニーズに応じたいくつかのカスタム機能

つまり、コア機能はすべての展開で同じままですが、各インスタンスは異なって見え、異なる認証システムに接続し、特定の機能が有効/無効になっています。

私の質問:重複を最小限に抑え、展開プロセスを簡素化するために、2 つのモバイル コードベース (iOS と Android) を管理するための最良の戦略は何ですか?

私たちが議論している3つの解決策は次のとおりです。

  1. すべてのインスタンスで共有されるコア ライブラリを (サブプロジェクト/ライブラリ プロジェクト、または git サブモジュールとして) 作成し、その上にブランディングと構成の詳細を含む薄いレイヤーを追加します。

  2. コア機能を備えた Git ブランチを維持し、追加のコードを含むデプロイごとに新しいブランチを作成します。

  3. スタックオーバーフローの賢い人が提案するまったく違うことをしてください。

どれが一番いいですか？フィードバックをお寄せいただきありがとうございます。

4

3 に答える 3

3

私が検討するアプローチは依存性注入です。

Android では、Square のDaggerなどの依存性注入ツールを使用する@Moduleと、コンポーネントを提供してアプリケーションに注入するクラスを簡単に作成できます。このようにして、各ホワイト ラベル クライアントのロジックを個別のコンポーネントとして維持でき、コンパイル時に、@Moduleクラス内の参照を介して特定のコンポーネントが選択されます。

これは、アプリケーションをテストする優れた方法でもあり、多くのボイラープレート コードを回避できます。

Square から提供された次の講演にも、すばらしい情報があります。

Dagger: Android および Java 用の高速な依存関係インジェクター

エンジニアリングのエレガンス: Square のスタックの秘密

iOS にも同様のフレームワークがあり、そのうちの 1 つが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.
于 2013-02-12T00:55:37.283 に答える
0

If you not depend on native GUI use Unity3d, make your own Unity Package with all main functionality (and develop it as single app for all platforms), for any deployment app you will have to make new Unity project and import this Package to it, customise it (might be by replace resources and edit configs). (if you need to upgrade core functionality, you will need to simple import new version of core Package again to delivered project).

Or use your option 1:

  1. C++ core library
  2. Resource package which is can be individual for all applications (might be autorizations & modules configs also be here)
  3. Native UI realisation for all platforms Android-Java, iOs-Objective-C
于 2013-02-14T16:15:28.447 に答える
0

私たちも同様の状況にあり (Android と iOS の両方のコードベースを持つホワイトラベル アプリのプラットフォームを持っています)、ネイティブ コードベースを C# 実装に移行します。MonoTouch / Mono for Androidを利用します。私は実際に先週からこれに取り組み始めたばかりです（モノの基本を理解するためにSOについていくつか質問をしています）。

これは事実上のオプション 1 ですが、すべてのプラットフォームは C# コードでビルドされます (オプションで、必要に応じて「ネイティブ」コードベースと対話する機能を使用できます)。

Mono を使用すると、プラットフォーム (現在は iOS と Android、将来的には Windows Phone) 間でコードの 30 ～ 50% を共有できるようになるはずです。私が経験した小さな経験からすると、パフォーマンスは優れているようです (覚えておいてください: 多くの人がMonoGameを使用して高パフォーマンスのゲームを作成しており、Unity も MonoGame を 3D ゲームに使用していると思います)。個人的にはこれも付加価値です。私はまだいつかゲームを作りたいと思っており、「本格的な」アプリ向けの Mono フレームワークで基本的な経験を積むことで、ゲーム アプリ向けの MonoGame フレームワークを使用する障壁が低くなります。

この設定の良いところは、すべてのコード (Android、iOS、Windows Phone) を 1 つのソリューションにまとめられることです。コア「ライブラリ」プロジェクト (モデル、サービス コールなど) を作成し、プラットフォームごとに別のプロジェクトを作成します。特定のプラットフォーム プロジェクトには、実際のネイティブ エクスペリエンスを備えた適切な UI があります。

Mono を使用してマルチプラットフォーム アプリを作成する方法の印象については、こちらの簡単な紹介をお読みください。

于 2013-02-12T04:04:01.017 に答える