管理相关iOS应用系列的最佳实践

3
我目前正在将一个现有的iOS应用程序改编成一组非常相似的应用程序(每个应用程序实例可能映射到不同的国家/地区)。
我计划为这些实例中的每一个都设置一个不同的构建目标,它们之间唯一的区别应该是:
- 图像(可能只是启动画面和图标) - 本地化 - 字符串变量:远程服务的基本URL、应用程序ID、支持电子邮件等(可能有一些这样的变量)
代码本身在所有应用程序中应该是相同的。
我想知道你认为管理这样一组应用程序的最佳做法是什么。
关于图像和本地化(或资源总体),它应该只是添加/删除目标中的适当文件的问题(我想我甚至可以在不同的目录中使用相同的图像名称)。
我不确定的主要事情是其他配置变量。
我听说/想到了一些选择:
- 使用预处理器宏和一个带有不同URL、ID等的主配置头文件。 - 每当应用程序启动时从plist(或类似的配置文件)中加载它们,并为每个目标设置一个这样的文件。 - 创建一个空的.sqlite文件(此应用程序已经使用Core Data),并使用默认配置变量填充它,并为每个目标设置一个这样的文件。
我认为第一个选项一旦我有几个此应用程序实例,就会最快失控,而且每次更改这些设置时都必须重新编译。
第三个选项我也不确定,因为我将向我的数据库添加不属于其中的实体,而且它似乎有点过度设计,因为它可能只涉及5-10个设置。我还不确定如何在更新时添加新设置。
所以我更倾向于第二个选项。
你有什么想法?这些有没有其他选择?
关于第二个选项,缺点是那些字符串(ID、URL等)会比它们在源代码中更暴露(即如果有人打开应用程序并浏览plist),但这并不是很大的问题,只是需要考虑一下。
第二个更新:
如何直接使用应用程序的info.plist并在那里存储它?(因此为每个目标配置都有一个info.plist)尽管最初我想要一个单独的plist,并且有一个“配置单例”,它会在启动时从那里加载所有内容,但我认为将其放在info.plist中然后通过[[[NSBundle mainBundle] infoDictionary] objectForKey:@"com.example.mykey1"]读取可能更简单。
3个回答

4
我会选择预处理器选项。您可以将所有预处理器放在一个文件/方法中,这样不会太混乱。正如oefe所说,更改.sqlite是过度的。而且使用多个plist,您会发现自己拖动很多东西并执行许多容易出错的操作。
然而,我不会制作很多应用程序。我只会制作一个应用程序,让用户在启动时选择他的城市。您还可以添加应用内购买功能,以便用户在需要时添加更多城市。
您的应用程序将更易于维护:您是否想要在每次更新时上传、更改描述和屏幕截图等10个以上的应用程序?我发现这很痛苦,但只有1个应用程序...
您不会在AppStore上进行垃圾邮件:在AppStore上拥有10个以上的具有完全相同目的的应用程序是荒谬的...这正是为什么苹果公司推出应用内购买的原因,以避免这种情况。
您必须为每个城市找到不同的图标:您的图标是销售AppStore上您的应用程序的最重要方面之一。您希望它尽可能精致。苹果不允许多个应用程序具有相同的图标,并通过在其上放置标签来区分图标不是一个好选择。

虽然我理解您关于不制作大量应用程序的观点,但它们的内容 - 这些内容是从远程服务器访问的 - 是使它们与众不同的原因,甚至可能是我们仅在应用商店的特定国家发布每个版本而不是其他国家。我们更感兴趣的是使每个应用程序在其所在的国家具有吸引力,而不是制作一个对任何人都不那么吸引人的通用应用程序。此外,在应用内购买也不适用于这里 - 所有这些应用程序都将是免费的。 - André Morujão
预处理器也是我的首选,很可能是最快实现的选择,但我担心在有5-6个不同版本之后可能会出现潜在的混乱。 - André Morujão
如果你只有一两个地方需要使用条件语句,那么并不会很复杂。但是我发现拥有六个同名文件更加混乱...! - gcamp

2

最终我选择使用 plist,但并非新建一个文件,而是直接使用 info.plist 文件,因此不需要为每个目标创建额外的文件,因为我已经需要为每个目标分别拥有单独的 info.plist。 我可以通过以下方式直接从包中加载它们:

[[[NSBundle mainBundle] infoDictionary] objectForKey:@"com.example.mykey1"]

我还使用了预处理器(在目标设置中设置了标志)来完成一些事情,但这主要是为了在我想禁用/完全删除应用程序的某些部分时使用的(例如,为了确保我得到所有内容,我注释了枚举值甚至包括一些地方的包含文件)。

我认为它相对清晰,我可以很容易地复制这个过程以进行未来的构建,而不会太混乱。


1
鉴于变量是按国家/地区分的,并且这些变量是字符串,为什么不将它们视为可本地化字符串,从而将问题简化为已经解决的问题?
否则,我会选择 plist。Sqlite 似乎过度Kill,而且不方便源代码控制。条件编译也会很快变得混乱。

没想到这一点,确实可以保持简单...但我不确定是否想将每个构建仅绑定到特定的语言(集)。另外,关于sqlite源代码控制问题的观点很好,我之前没有考虑过。 - André Morujão

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接