How do you organize your UI design variables, objects, etc. in iOS?

As the iPad app I am making has been growing its size, it is hard for me to keep track of UI design values. Here, I am talking about values such as a table's width, background colors, and a title's font.

I would like to orga开发者_如何学运维nize all UI design-related values and objects more efficiently.

How do you organize these?

• Do you #define values in a header file?
• Do you declare them as global variables or not?
• Do you put your values one static class?
• Or do you think not-organizing these values is rather better?

I would like to hear your advice. Thank you :)

Yes it depends, therefore just some rules of thumb...

Do you #define values in a header file? 

...in cases where I might want to change this locally only, eg for constants, colors, alignments, button images, ... the main reason why I do this however is the documentation it allows by giving the local defines a long explaining name

Do you declare them as global variables or not?

...an all my apps I have a MainDataManager Class, that holds all the variables I need globally - for the UI part often I have my own globally used object. This is extremely useful, simplifies the code, and probably one of the most important things I learned early on. might also see here Using Variable of AppDelegate as a Global Variable - question regarding release/retain

Do you put your values one static class?

...static classes exist kind of conceptually. Static variables are quite useful when you want to give a method some kind of memory of its own. However, none plays an important role in my UI.

In general, I like to use IB to layout the screens but set all the button names, labels, texts in the code. Why? Because when I have to localize the app maintaining multiple XIB files (for each language there will be one isolated XIB file to maintain) becomes a real burden even if there is only one single change in the layout.

All the global constant settings are always kept in GloblDefinitions.h while at the same time I have in my .pch file this entry #import "GlobalDefinitions.h"

So the combintation of a delegate variable provided globally + GlobalDefinitions.h for constants is my solution.

Its a good question. When combining use of interface builder with hand-coded UI tweaks and/or custom components you also have the problem of duplicated values between IB and code.

In some situations, for readability and for easy adjustment by a third party its easier if values are just hard coded in-place - so in trival cases (e.g. cases where the value is not repeated anywhere else or is unlikely to change) this might be a valid option.

In general, if the constants are specific to the layout of a particular UI component then it seems to make sense to #define them in the header file for the UI component that uses them - I think putting them all in one global file breaks the decoupling that you'd like to have between user interface components, and also for readability it can be easier for another dev to find them in the header file.

On the other hand if there are values that are used consistently across multiple UI components within the one application, then these can be defined in a global include file. Similarly if there are 'base' values that are used to derive other lengths etc. that are used commonly across multiple UI components these also can be stored in a global include.

Also whereever possible make use of the layout manager margin flexibility settings and width/height flexibility settings to minimise the need to hard code values. And when relevant, derive values from a base value or a system value (e.g. screen width).

At the end of the day if the value is there in code in front of you sometimes that much easier to figure out and tweak than changing a #define off in some other file - on the other hand - if the same value is repeated in multiple places and a #define is not used, then it can be very confusing for another coder to come in and change one of these repeated values only and try to understand and sift through the resultant side effects and which other places the value should be changed.

Well Ryan that depends upon you.. You can either use pre processor directives.. declaring in .pch file.

or you can either make an object class taking all the constants....

Hope that will help you..

Thanks

This is what I have learnt from few of my previous projects.

1] Naming conventions - use appropriate and standardized prefix. ex tblRecordLis, viewControlPanel etc.

2] Keep Constants together - keeping all constants at one place reduces the pain of searching entire project to find/fix/replace constants and their values.

3] Grouping relevant Classes together according to utility and their functionality.

4] UI constants like size, offsets , frame values (Which you need to hard code) can be kept in constants

a few which I used are

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

5] Using IB as much as possible as it gives us more flexibility.

6] PROPER commenting and documentation proves to be a life saver when dealing with debugging. I find it easy to declare keys as constants as using them at multiple places also increases the chances of error if used as such. eq key named @"method" can be better declared as

#define kMethodKey @"method"

This very simple thing saves my time while debugging when the project size grows larger.

** Taking hints from Apple's samples also gives you a great help in keeping your code standardized.