Question

由于我正在制作的iPad应用程序的规模越来越大，我很难跟踪UI设计值。在这里，我谈论的是诸如表的宽度，背景颜色和标题字体等值。

我想更有效地整理所有与UI设计相关的值和对象。

你如何组织这些？

你在头文件中#define值吗？
您是否将它们声明为全局变量？
您是否将您的值设为静态类？
或者你认为不组织这些价值会更好吗？

我想听听你的意见。谢谢:)）

Answer 1

是的，这取决于，因此只是一些经验法则......

Do you #define values in a header file?

...如果我可能只想在本地更改此选项，例如常量，颜色，对齐，按钮图像，......我这样做的主要原因是它允许通过给出本地定义的文档一个很长的解释名称

Do you declare them as global variables or not?

...我的所有应用程序我有一个MainDataManager类，它包含我需要的所有全局变量 - 对于UI部分，我通常拥有自己的全局使用对象。这非常有用，简化了代码，可能是我早期学到的最重要的事情之一。也可以在这里看到Using Variable of AppDelegate as a Global Variable - question regarding release/retain

Do you put your values one static class?

...静态类在概念上存在。当你想给某个方法提供某种类型的内存时，静态变量非常有用。但是，没有一个在我的UI中扮演重要角色。

In general，我喜欢使用IB布局屏幕，但在代码中设置所有按钮名称，标签和文本。为什么？因为当我必须本地化应用程序时，维护多个XIB文件（对于每种语言，将有一个要维护的隔离的XIB文件）成为真正的负担，即使布局中只有一个单一的更改。

所有全局常量设置始终保存在GloblDefinitions.h中，同时我在.pch文件中输入此条目#import“GlobalDefinitions.h”

因此，为全局提供全局+ GlobalDefinitions.h的委托变量的组合是我的解决方案。

Answer 2

这是一个很好的问题。当将界面构建器与手动编码的UI调整和/或自定义组件结合使用时，您还会遇到IB和代码之间重复值的问题。

在某些情况下，为了便于阅读和易于第三方调整，如果值只是就地硬编码就更容易 - 因此在繁琐的情况下（例如，值不会在其他任何地方重复或不太可能发生变化的情况）这可能是一个有效的选择。

通常，如果常量特定于特定UI组件的布局，那么在使用它们的UI组件的头文件中#define它们似乎是有意义的 - 我认为将它们全部放在一个全局文件中打破了用户界面组件之间的分离，并且为了便于阅读，另一个开发人员可以更容易地在头文件中找到它们。

另一方面，如果在一个应用程序中有多个UI组件一致使用的值，则可以在全局包含文件中定义这些值。类似地，如果存在用于导出在多个UI组件中共同使用的其他长度等的“基础”值，则这些值也可以存储在全局包含中。

此外，还可以使用布局管理器边距灵活性设置和宽度/高度灵活性设置，以最大限度地减少对硬编码值的需求。相关时，从基值或系统值（例如屏幕宽度）中导出值。

在一天结束时，如果你面前的代码中有值，那么有时候比在其他文件中更改#define更容易理解和调整 - 另一方面 - 如果相同的值是在多个地方重复并且没有使用#define，那么另一个编码器进入并改变其中一个重复值并尝试理解并筛选出由此产生的副作用以及其他值放置的值可能会非常混乱改变了。

Answer 3

瑞安依赖你...... 您可以使用预处理器指令.. 在.pch文件中声明。

或者你可以使一个对象类获取所有常量....

希望能帮到你..

由于

Answer 4

这是我从之前的几个项目中学到的东西。

1]命名约定 - 使用适当的标准化前缀。 ex tblRecordLis，viewControlPanel等。

2]将常量保持在一起 - 将所有常量保持在一个位置可以减少搜索整个项目以查找/修复/替换常量及其值的痛苦。

3]根据实用程序及其功能将相关类组合在一起。

4]大小，偏移，帧值（你需要硬代码）等UI常量可以保存在常量中

我使用的是

#define MenuPopoverFrame  CGSizeMake(278, 550);
#define LandscapeContentSize @"{{0,0},{719,734}}"
#define PortraitContentSize @"{{2,0},{765,980}}"

5]尽可能使用IB，因为它为我们提供了更大的灵活性。

6]在处理调试时，正确的评论和文档证明可以节省生命。我发现很容易将键声明为常量，因为在多个位置使用它们也会增加出错的可能性（如果这样使用的话）。名为@“method”的eq键可以更好地声明为

#define kMethodKey @"method"

当项目规模变大时，这个非常简单的事情会节省我的调试时间。

**从Apple的样本中获取提示也可以帮助您保持代码标准化。

如何在iOS中组织UI设计变量，对象等？

4 个答案: