I have an app which I will call it the "base app". The app works with many brands. I need now to separate those brands, and to make a distinct app for every brand. Every app will have a slightly different design (including different images) and here and there maybe some specific-to-a-brand code. All of the apps should also use the same base code from the "base app" that deals with logic.
我有一个应用程序,我称之为“基础应用程序”。该应用程序适用于许多品牌。我现在需要将这些品牌分开,并为每个品牌制作一个独特的应用程序。每个应用程序的设计都会略有不同(包括不同的图像),这里可能还有一些特定的品牌代码。所有应用程序还应使用处理逻辑的“基础应用程序”中的相同基本代码。
I have some options I have thought, but I am not sure if any of them suit my needs. Will be happy for clarifying the difference among the options.
我有一些我想过的选择,但我不确定它们是否适合我的需要。很高兴澄清选项之间的差异。
The options I have thought are:
我想到的选项是:
1) Creating an app for each one of the brands and just copy-paste the class files from the "base app" as a reference, except the .xib files, which will be copied as a copy. The problem is that then I do not know how and where to write a brand specific code (because it will be shared among others).
1)为每个品牌创建一个应用程序,只需复制粘贴“基础应用程序”中的类文件作为参考,但.xib文件除外,它们将被复制为副本。问题是,我不知道如何以及在何处编写特定品牌的代码(因为它将在其他人之间共享)。
2) Creating a workspace that will include the projects for each one of the brand. Not sure how this works and if this is correct, will be glad for help clarifying here.
2)创建一个工作空间,其中包含每个品牌的项目。不确定这是如何工作的,如果这是正确的,将很高兴在这里澄清帮助。
3) Nest a "base app" project inside every brand's project. Any help clarifying what does it do will be appreciated.
3)在每个品牌的项目中嵌入一个“基础应用”项目。任何帮助澄清它做什么将不胜感激。
3) Using the base app as a static library which will be linked in every brand's project. Not sure what will happen with the UI (shared, not shared). Will be glad for help clarifying here too.
3)使用基础应用程序作为静态库,将在每个品牌的项目中链接。不确定UI会发生什么(共享,不共享)。很高兴在这里澄清帮助。
4) Using a simple way of maintaining each one of the brand's project, including the shared code (which will be a disaster, I guess).
4)使用一种简单的方法来维护每个品牌的项目,包括共享代码(我猜这将是一场灾难)。
3 个解决方案
#1
5
The simple solution in iOS is use targets.
iOS中的简单解决方案是使用目标。
For resources you can use different targets for each brand and then select different resources (images, xibs, etc) for each target.
对于资源,您可以为每个品牌使用不同的目标,然后为每个目标选择不同的资源(图像,xib等)。
Also if the changes in code are minimal you can then refactor some part of your code and create different classes with different implementation for each target (you can use some pattern like a Factory). Also you can simply use preprocessor macros.
此外,如果代码中的更改很小,则可以重构代码的某些部分,并为每个目标创建具有不同实现的不同类(您可以使用某些模式,如Factory)。您也可以简单地使用预处理器宏。
It's not the better, but this is the simplest and quick approach, but if your code changes a lot it's better to create a core library like the other answers say.
它并不是更好,但这是最简单快捷的方法,但如果你的代码发生了很大变化,最好像其他答案一样创建核心库。
#2
5
A good approach would be to split your app up into the following components:
一个好方法是将您的应用程序拆分为以下组件:
- Core Model Library
- Reusable views & view controllers. The views can be designed to support skinning and customization.
- Any other reusable code that can be encapsulated as its own 'identity'.
核心模型库
可重复使用的视图和视图控制器。视图可以设计为支持蒙皮和自定义。
任何其他可重用的代码,可以封装为自己的“标识”。
These core projects should ideally have their own continuous integration (quality control) builds and tests.
理想情况下,这些核心项目应具有自己的持续集成(质量控制)构建和测试。
And then use CoocaPods
然后使用CoocaPods
Instead of manually performing all this complex integration, use CocoaPods. CocoaPods will create the Xcode workspace, build the libraries and link them into your project. You then create a custom build just by gluing the pieces together.
而不是手动执行所有这些复杂的集成,使用CocoaPods。 CocoaPods将创建Xcode工作区,构建库并将它们链接到您的项目中。然后,只需将各个部分粘合在一起即可创建自定义构建。
In addition to this, CocoaPods also performs tasks such as:
除此之外,CocoaPods还执行以下任务:
- Resolving transitive dependencies - which just means building and fetching any libraries that your libraries themselves use.
- Managing versions of the libraries being integrated.
解决传递依赖性 - 这意味着构建和获取库本身使用的任何库。
管理正在集成的库的版本。
Private Spec Repo is possible, or just use GitHub
可以使用Private Spec Repo,也可以只使用GitHub
The main CocoaPods repository is of course public and contains open-source and/or freely available libraries.
主要的CocoaPods存储库当然是公共的,包含开源和/或免费可用的库。
You can host your own CocoaPods spec repository, or simply set up a private GitHub account, and include a PodSpec in each project, then resolve as follows:
您可以托管自己的CocoaPods规范存储库,或者只是设置一个私有GitHub帐户,并在每个项目中包含PodSpec,然后按如下方式解析:
pod 'MyLibraryName', :git => 'https://github.com/myOrgName/MyLibrary.git'
this will install all of your libraries into your workspace. To update your project to include any changes to the core libraries, simply:
这会将所有库安装到您的工作区中。要更新项目以包含对核心库的任何更改,只需:
pod update
Advantages of this approach
这种方法的优点
- You'll have a separate set of quality controls that gets applied to each core project.
- There'll be much less reputation.
- You can use more automation. More automation equals less waste equals more customer value.
- As the team grows, you can split up core product devlopment and solution integration into separate roles/teams. A team working on an integration build, need not pull the latest library features, if that would disrupt them.
- You can have two different customers on different builds of the core library. CocoaPods will manage this seamlessly. So you wouldn't necessarily have to update a build, until you get an enhancement request or scheduled maintenance. (Again reducing waste, thus increasing customer value).
您将拥有一组单独的质量控制,可应用于每个核心项目。
名声会少得多。
您可以使用更多自动化。更多的自动化等于减少浪费等于更多的客户价值。
随着团队的发展,您可以将核心产品开发和解决方案集成分离到不同的角色/团队中。从事集成构建的团队无需提取最新的库功能,如果这会破坏它们。
您可以在核心库的不同版本上拥有两个不同的客户。 CocoaPods将无缝地管理它。因此,在获得增强请求或计划维护之前,您不一定需要更新构建。 (再次减少浪费,从而提高客户价值)。
Inspired by Piggly Wiggly (but lean through and through)
灵感来自Piggly Wiggly(但精益求精)
This approach is modeled after the production line style approach that was popularized in Japan after World War II. Its called Lean Methodology, and is all about having a fast, small inventory and reducing waste. (Delivering more with less). . Japanese execs got the inspiration for this when they went to America and visited Piggly Wiggly Supermarket stores.
这种方法模仿了第二次世界大战后在日本推广的生产线风格方法。它被称为精益方法论,是关于快速,小量库存和减少浪费。 (少花钱多办事)。 。当他们去美国并参观Piggly Wiggly Supermarket商店时,日本高管得到了灵感。
#3
1
This is often something you encounter creating cheap flash-games or apps.
这通常是您在创建便宜的Flash游戏或应用时遇到的问题。
These have very generic frameworks like: kicking a ball, shooting at the screen, or generating a list with some data downloaded from a specific server etc...
它们具有非常通用的框架,例如:踢球,在屏幕上拍摄,或生成包含从特定服务器下载的一些数据的列表等...
Everytime they want to create a new shootergame, they just load up their shooting framework, add a bunch of graphics and can release a crappy game within a day.
每当他们想要创建一个新的射击游戏时,他们只需加载他们的射击框架,添加一堆图形,并可以在一天内发布一个糟糕的游戏。
How do they do it?
他们是如何做到的呢?
They often create a framework which contains shared models, handlers, interfaces etc. Put a lot of general utility functions like downloading files etc in a library. And you can also create some default framework views and view-controllers.
他们经常创建一个包含共享模型,处理程序,接口等的框架。在库中放置许多通用实用程序函数,如下载文件等。您还可以创建一些默认框架视图和视图控制器。
When you want to create a similar app, just import the library and re-use the base framework. Containing base-views, base-models etc.
如果要创建类似的应用程序,只需导入库并重新使用基础框架即可。包含基本视图,基本模型等。
You can find a good example in the demo-examples delivered with the ios SDK or android SDK.
您可以在随ios SDK或Android SDK提供的演示示例中找到一个很好的示例。
Good luck.
#1
5
The simple solution in iOS is use targets.
iOS中的简单解决方案是使用目标。
For resources you can use different targets for each brand and then select different resources (images, xibs, etc) for each target.
对于资源,您可以为每个品牌使用不同的目标,然后为每个目标选择不同的资源(图像,xib等)。
Also if the changes in code are minimal you can then refactor some part of your code and create different classes with different implementation for each target (you can use some pattern like a Factory). Also you can simply use preprocessor macros.
此外,如果代码中的更改很小,则可以重构代码的某些部分,并为每个目标创建具有不同实现的不同类(您可以使用某些模式,如Factory)。您也可以简单地使用预处理器宏。
It's not the better, but this is the simplest and quick approach, but if your code changes a lot it's better to create a core library like the other answers say.
它并不是更好,但这是最简单快捷的方法,但如果你的代码发生了很大变化,最好像其他答案一样创建核心库。
#2
5
A good approach would be to split your app up into the following components:
一个好方法是将您的应用程序拆分为以下组件:
- Core Model Library
- Reusable views & view controllers. The views can be designed to support skinning and customization.
- Any other reusable code that can be encapsulated as its own 'identity'.
核心模型库
可重复使用的视图和视图控制器。视图可以设计为支持蒙皮和自定义。
任何其他可重用的代码,可以封装为自己的“标识”。
These core projects should ideally have their own continuous integration (quality control) builds and tests.
理想情况下,这些核心项目应具有自己的持续集成(质量控制)构建和测试。
And then use CoocaPods
然后使用CoocaPods
Instead of manually performing all this complex integration, use CocoaPods. CocoaPods will create the Xcode workspace, build the libraries and link them into your project. You then create a custom build just by gluing the pieces together.
而不是手动执行所有这些复杂的集成,使用CocoaPods。 CocoaPods将创建Xcode工作区,构建库并将它们链接到您的项目中。然后,只需将各个部分粘合在一起即可创建自定义构建。
In addition to this, CocoaPods also performs tasks such as:
除此之外,CocoaPods还执行以下任务:
- Resolving transitive dependencies - which just means building and fetching any libraries that your libraries themselves use.
- Managing versions of the libraries being integrated.
解决传递依赖性 - 这意味着构建和获取库本身使用的任何库。
管理正在集成的库的版本。
Private Spec Repo is possible, or just use GitHub
可以使用Private Spec Repo,也可以只使用GitHub
The main CocoaPods repository is of course public and contains open-source and/or freely available libraries.
主要的CocoaPods存储库当然是公共的,包含开源和/或免费可用的库。
You can host your own CocoaPods spec repository, or simply set up a private GitHub account, and include a PodSpec in each project, then resolve as follows:
您可以托管自己的CocoaPods规范存储库,或者只是设置一个私有GitHub帐户,并在每个项目中包含PodSpec,然后按如下方式解析:
pod 'MyLibraryName', :git => 'https://github.com/myOrgName/MyLibrary.git'
this will install all of your libraries into your workspace. To update your project to include any changes to the core libraries, simply:
这会将所有库安装到您的工作区中。要更新项目以包含对核心库的任何更改,只需:
pod update
Advantages of this approach
这种方法的优点
- You'll have a separate set of quality controls that gets applied to each core project.
- There'll be much less reputation.
- You can use more automation. More automation equals less waste equals more customer value.
- As the team grows, you can split up core product devlopment and solution integration into separate roles/teams. A team working on an integration build, need not pull the latest library features, if that would disrupt them.
- You can have two different customers on different builds of the core library. CocoaPods will manage this seamlessly. So you wouldn't necessarily have to update a build, until you get an enhancement request or scheduled maintenance. (Again reducing waste, thus increasing customer value).
您将拥有一组单独的质量控制,可应用于每个核心项目。
名声会少得多。
您可以使用更多自动化。更多的自动化等于减少浪费等于更多的客户价值。
随着团队的发展,您可以将核心产品开发和解决方案集成分离到不同的角色/团队中。从事集成构建的团队无需提取最新的库功能,如果这会破坏它们。
您可以在核心库的不同版本上拥有两个不同的客户。 CocoaPods将无缝地管理它。因此,在获得增强请求或计划维护之前,您不一定需要更新构建。 (再次减少浪费,从而提高客户价值)。
Inspired by Piggly Wiggly (but lean through and through)
灵感来自Piggly Wiggly(但精益求精)
This approach is modeled after the production line style approach that was popularized in Japan after World War II. Its called Lean Methodology, and is all about having a fast, small inventory and reducing waste. (Delivering more with less). . Japanese execs got the inspiration for this when they went to America and visited Piggly Wiggly Supermarket stores.
这种方法模仿了第二次世界大战后在日本推广的生产线风格方法。它被称为精益方法论,是关于快速,小量库存和减少浪费。 (少花钱多办事)。 。当他们去美国并参观Piggly Wiggly Supermarket商店时,日本高管得到了灵感。
#3
1
This is often something you encounter creating cheap flash-games or apps.
这通常是您在创建便宜的Flash游戏或应用时遇到的问题。
These have very generic frameworks like: kicking a ball, shooting at the screen, or generating a list with some data downloaded from a specific server etc...
它们具有非常通用的框架,例如:踢球,在屏幕上拍摄,或生成包含从特定服务器下载的一些数据的列表等...
Everytime they want to create a new shootergame, they just load up their shooting framework, add a bunch of graphics and can release a crappy game within a day.
每当他们想要创建一个新的射击游戏时,他们只需加载他们的射击框架,添加一堆图形,并可以在一天内发布一个糟糕的游戏。
How do they do it?
他们是如何做到的呢?
They often create a framework which contains shared models, handlers, interfaces etc. Put a lot of general utility functions like downloading files etc in a library. And you can also create some default framework views and view-controllers.
他们经常创建一个包含共享模型,处理程序,接口等的框架。在库中放置许多通用实用程序函数,如下载文件等。您还可以创建一些默认框架视图和视图控制器。
When you want to create a similar app, just import the library and re-use the base framework. Containing base-views, base-models etc.
如果要创建类似的应用程序,只需导入库并重新使用基础框架即可。包含基本视图,基本模型等。
You can find a good example in the demo-examples delivered with the ios SDK or android SDK.
您可以在随ios SDK或Android SDK提供的演示示例中找到一个很好的示例。
Good luck.