Как вы организуете свои переменные дизайна пользовательского интерфейса, объекты и т. Д. В iOS? - PullRequest
3 голосов
/ 20 сентября 2011

Поскольку приложение для iPad, которое я создаю, растет, мне трудно отслеживать значения дизайна пользовательского интерфейса. Здесь я говорю о таких значениях, как ширина таблицы, цвета фона и шрифт заголовка.

Я бы хотел организовать все значения и объекты, связанные с дизайном пользовательского интерфейса, более эффективно.

Как вы их организовываете?

  • Вы # определяете значения в заголовочном файле?
  • Вы объявляете их глобальными переменными или нет?
  • Вы помещаете свои значения в один статический класс?
  • Или вы считаете, что неорганизовывать эти ценности лучше?

Я хотел бы услышать ваш совет. Спасибо:)

Ответы [ 4 ]

2 голосов
/ 20 сентября 2011

Да, это зависит, поэтому просто некоторые правила большого пальца ...

Do you #define values in a header file? 

... в случаях, когда я мог бы захотеть изменить это только локально, например, для констант, цветов, выравниваний, изображений кнопок, ... однако основная причина, по которой я это делаю, - это документация, которую он позволяет, давая локальные определения длинное объясняющее имя

Do you declare them as global variables or not?

... во всех моих приложениях у меня есть класс MainDataManager, который содержит все переменные, которые мне нужны в глобальном масштабе - для части пользовательского интерфейса часто у меня есть собственный глобально используемый объект. Это чрезвычайно полезно, упрощает код и, возможно, является одной из самых важных вещей, которые я узнал на ранних этапах. может также увидеть здесь Использование переменной AppDelegate в качестве глобальной переменной - вопрос относительно освобождения / сохранения

Do you put your values one static class?

... статические классы существуют концептуально. Статические переменные весьма полезны, когда вы хотите дать методу какую-то память. Тем не менее, никто не играет важную роль в моем интерфейсе.

In general, мне нравится использовать IB для разметки экранов, но в коде указываются все названия кнопок, метки, тексты. Зачем? Потому что, когда мне нужно локализовать приложение, поддерживающее несколько файлов XIB (для каждого языка будет поддерживаться один изолированный файл XIB), становится реальным бременем, даже если в макете только одно изменение.

Все глобальные постоянные настройки всегда хранятся в GloblDefinitions.h, в то же время в моем файле .pch есть эта запись #import "GlobalDefinitions.h"

Таким образом, комбинация переменной-делегата, предоставленной глобально + GlobalDefinitions.h для констант, является моим решением.

1 голос
/ 20 сентября 2011

Хороший вопрос.При объединении использования построителя интерфейса с настройками пользовательского интерфейса и / или пользовательскими компонентами, созданными вручную, у вас также возникает проблема дублирования значений между IB и кодом.

В некоторых ситуациях для удобочитаемости и простоты настройки третьей стороной легче, если значения просто жестко запрограммированы на месте, например, в тривальных случаях (например, в случаях, когда значение не повторяется где-либо еще или маловероятноизменить) это может быть допустимым вариантом.

В общем, если константы специфичны для компоновки конкретного компонента пользовательского интерфейса, то, кажется, имеет смысл # определить их в заголовочном файле для компонента пользовательского интерфейса, который их использует, - я думаю, поместив их все водин глобальный файл нарушает разделение, которое вы хотели бы иметь между компонентами пользовательского интерфейса, а также для удобства чтения другому разработчику легче найти их в заголовочном файле.

С другой стороны, если естьзначения, которые последовательно используются в нескольких компонентах пользовательского интерфейса в одном приложении, затем их можно определить в глобальном включаемом файле.Точно так же, если существуют «базовые» значения, которые используются для получения других длин и т. Д., Которые обычно используются в нескольких компонентах пользовательского интерфейса, они также могут храниться в глобальном включении.

Также всегда возможно использовать диспетчер компоновкинастройки гибкости полей и настройки гибкости ширины / высоты, чтобы минимизировать необходимость в жестких значениях кода.А когда это уместно, получайте значения из базового значения или системного значения (например, ширины экрана).

В конце дня, если значение присутствует в коде перед вами, иногда это намного легче выяснитьи настроить вместо изменения #define в каком-либо другом файле - с другой стороны - если одно и то же значение повторяется в нескольких местах и ​​#define не используется, тогда может быть очень запутанным, чтобы другой кодер пришел и изменил одинтолько из этих повторяющихся значений и постарайтесь понять и проанализировать возникающие побочные эффекты, а также указать, в каких других местах значение следует изменить.

0 голосов
/ 20 сентября 2011

Это то, что я узнал из нескольких моих предыдущих проектов.

1] Соглашения об именах - используйте соответствующий и стандартизированный префикс. ex tblRecordLis, viewControlPanel и т. д.

2] Храните константы вместе - хранение всех констант в одном месте уменьшает трудность поиска всего проекта, чтобы найти / исправить / заменить константы и их значения.

3] Группировка соответствующих классов вместе в соответствии с полезностью и их функциональностью.

4] Константы пользовательского интерфейса, такие как размер, смещения, значения кадра (которые вам нужны для жесткого кода), могут быть сохранены в константах

несколько из которых я использовал

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

5] Максимально возможное использование IB для большей гибкости.

6] ПРАВИЛЬНОЕ комментирование и документирование оказываются спасением при работе с отладкой Я считаю, что легко объявить ключи как константы, так как их использование в нескольких местах также увеличивает вероятность ошибки, если используется как таковой. Ключ eq с именем @ "method" может быть лучше объявлен как

#define kMethodKey @"method"

Эта очень простая вещь экономит мое время при отладке, когда размер проекта увеличивается.

** Получение подсказок из примеров Apple также поможет вам в стандартизации вашего кода.

0 голосов
/ 20 сентября 2011

Хорошо, Райан, который зависит от вас .. Вы можете либо использовать директивы препроцессора ... объявление в файле .pch.

, либо вы можете создать класс объекта, принимающий все константы ....

Надеюсь, что это поможет вам ..

Спасибо

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...