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

Question

随着我制作的iPad应用程序的规模不断扩大，我很难跟踪UI设计的价值。在这里，我正在讨论诸如表格宽度，背景颜色和标题字体等值。

我想更有效地组织所有UI设计相关的值和对象。

你如何组织这些？

• 你是否在头文件中定义了值？
• 你是否将它们声明为全局变量？
• 你把你的值放在一个静态类吗？
• 或者你认为不是组织这些价值观更好？

我想听听您的建议。 谢谢:)

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? 

...静态类存在一种概念上。当你想给某种方法某种自己的记忆时，静态变量非常有用。但是，在我的用户界面中没有任何重要的角色。

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

所有全局常量设置始终保持在GloblDefinitions.h，而在同一时间，我有我的.PCH文件中的此项＃进口“GlobalDefinitions.h”

所以委托变量的combintation在全球提供+常量的GlobalDefinitions.h是我的解决方案。

Answer 2

好赖安，取决于你.. 你可以使用预处理器指令.. 声明在.pch文件中。

，或者你可以让一个对象类把所有的常量....

希望这将帮助你..

感谢

Answer 3

它是一个很好的问题。将界面生成器与手动编辑的UI调整和/或自定义组件结合使用时，您也有IB和代码之间的重复值问题。

在某些情况下，为了便于阅读和第三方进行调整，如果值只是就地硬编码，则更容易 - 所以在分数情况下（例如，在其他地方不重复该值或不可能改变）这可能是一个有效的选择。

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

另一方面，如果在一个应用程序中存在跨多个UI组件一致使用的值，则可以在全局包含文件中定义这些值。同样，如果存在用于派生其他长度等的“基本”值，这些长度等常用于多个UI组件，则这些值也可以存储在全局包含中。

同样尽可能地利用布局管理器边缘灵活性设置和宽度/高度灵活性设置来最小化对硬代码值的需要。当相关时，从基本值或系统值（例如屏幕宽度）导出值。

在一天结束时，如果代码中存在的值有时比在其他文件中更改#define更容易理解和调整 - 另一方面 - 如果相同的值在多个地方重复，并且#define没有被使用，那么对于另一个编码器进来并且仅改变这些重复值中的一个并且试图理解和筛选所得到的副作用以及在其他地方值应该改变。

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]在处理调试时，正确的注释和文档证明是一种救命。 我发现很容易将键声明为常量，因为在多个地方使用它们也增加了出现错误的可能性。 EQ键名为@“方法”可以更好地申报为

#define kMethodKey @"method" 

这很简单的事情可以节省我的时间在调试时，项目的规模变大。

**从Apple的示例中获取提示也为您在保持代码标准化方面提供了很大的帮助。