如何处理白标平台移动应用程序的部署？

Posted 2023-04-15

【中文标题】如何处理白标平台移动应用程序的部署？

【英文标题】：How to handle deployment of white-labeled platform mobile apps?

【发布时间】：2013-02-12 00:06:39

【问题描述】：

我正在开发一种产品，该产品将部署到许多不同的组织（理想场景，数十个）。系统的每次部署（由 ios 和 android 的原生应用组成）都将涉及以下内容：

特定于组织的品牌（即新皮肤） 与组织的身份验证系统和用户数据库集成 一些自定义功能取决于组织的需求

换句话说，核心功能在所有部署中都将保持不变，但每个实例的外观会有所不同，会与不同的身份验证系统挂钩，并启用/禁用某些功能。

我的问题：管理我们的 2 个移动代码库（iOS 和 Android）以尽量减少重复并简化部署过程的最佳策略是什么？

我们正在讨论的三个解决方案是：

创建一个跨所有实例共享的核心库（作为子项目/库项目或 git 子模块），并在顶部添加一个带有品牌和任何配置详细信息的薄层。

维护一个具有核心功能的 Git 分支，并为每个包含附加代码的部署创建一个新分支。

按照 *** 上一些聪明人的建议，做一些完全不同的事情。

你觉得哪个听起来最好？提前感谢您的任何反馈！

【问题讨论】：

我会选择选项 1。与 GIT 子模块中的库相比，GIT 分支会使维护变得更加困难 - 但这只是因为我喜欢子模块的功能保持不变，并且在每个使用/需要依据，可轻松更新。

噢，以及在启动应用程序后即时设置一些更动态数据的某种配置提要怎么样。至少在资源方面为您提供最大的灵活性 - 太糟糕了，苹果不允许动态库（通过下载使用）。

@bmat 您选择了哪种方法？我在这里也有同样的情况。

@Lizard 在 Android 端，我们最终将所有共享代码放入库项目中，并将其作为依赖项包含在白标项目中。在 iOS 上，我相信我们为每个部署创建了构建目标，并根据当前目标选择了白标资产。

@Lizard 您会将活动添加到白标项目中。需要注意的是，您必须设计共享代码，以便白标项目可以添加自己的屏幕而不会破坏任何内容。就我而言，部署之间唯一改变的是图像和字符串资产，因此您可能必须找到更灵活的解决方案。

【参考方案1】：

我会考虑的一种方法是依赖注入。

在 Android 上，如果您使用诸如 Square 的 Dagger 之类的依赖注入工具，您可以简单地创建一个 @Module 类，该类为您的应用程序提供和注入组件。这样，您可以将每个白标客户端的逻辑维护为单独的组件，并且在编译时，将通过 @Module 类中的引用选择特定组件。

这也是测试应用程序的好方法，它可以避免大量样板代码。

Square 还提供了以下会谈中的重要信息：

Dagger: A Fast Dependency Injector for Android and Java

Engineering Elegance: The Secrets of Square's Stack

iOS 也有类似的框架，一个是Objection。

框外选项：

移动客户端是否必须直接与白标服务器对话？如果没有，您可能需要考虑使用自己的服务器作为白标服务器的代理。这会将所有业务逻辑移至您的服务器，支持您的所有客户端。

我没有这方面的任何经验，但看起来很有希望的选项是 J2ObjC，它正在 Google 开发中。

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.

【讨论】：

依赖注入对于给定的任务绝对是一种值得一看的模式。它肯定不会是涵盖所有描述需求的唯一工具，但它可能有助于获得可维护的优质代码。 +1

我同意@Till 的观点——DI 并没有解决问题，但它确实让我开始阅读 Martin Fowler 在企业应用程序开发方面的一些工作。我还没有解决这个问题，但我觉得我现在走在了正确的轨道上。

【参考方案2】：

我们处于类似情况（我们有一个带有 Android 和 iOS 代码库的白标应用平台），我们将把我们的原生代码库转移到 C# 实现。我们将使用MonoTouch / Mono for Android。实际上，我从上周开始就开始研究这个（我一直在问一些关于 SO 的问题以弄清楚一些 Mono 基础知识）。

这实际上是您的选项 1，但每个平台都将基于 C# 代码构建（如果需要，还可以选择与“本机”代码库进行交互）。

Mono 应该使我们能够在平台之间共享 30-50% 的代码（目前是 iOS 和 Android，未来可能是 Windows Phone）。从我的一点经验来看，性能似乎不错（请记住：很多人也使用MonoGame 来创建high-performance games，我认为Unity 也将Mono 用于3D 游戏）。对我个人而言，这也是附加值。我仍然希望有朝一日能够制作游戏，并且对“严肃”应用程序的 Mono 框架的一些基本经验将降低将 MonoGame 框架用于游戏应用程序的障碍。

此设置的好处是您可以将所有代码（Android、iOS、Windows Phone）保存在一个解决方案中。创建一个核心“库”项目（模型、服务调用等）并为每个平台创建另一个项目。每个特定平台项目都将具有适当的 UI，并提供真正的原生体验。

如需了解如何使用 Mono 创建多平台应用程序，请read a small introduction here。

【参考方案3】：

如果你不依赖原生 GUI 使用 Unity3d， 制作您自己的具有所有主要功能的 Unity 包（并将其开发为适用于所有平台的单个应用程序）， 对于任何部署应用程序，您必须创建新的 Unity 项目并将此包导入其中， 自定义它（可能是通过替换资源和编辑配置）。 （如果您需要升级核心功能，您将需要简单的导入新版本 的核心包再次交付项目）。

或者使用您的选项 1：

C++ 核心库 可以为所有应用程序单独提供的资源包（可能是自动化和模块配置也在这里） Android-Java、iOs-Objective-C所有平台的原生UI实现