Косметическая проблема ScaleFactor
 

У нас есть:

• Приложение, которое скейлится под любой размер.
• Content.scaleFactor (например, если он равен двойке, то все значения и размеры нужно делить на два).

Задача:
Правильно "заресайзить" некоторые константы.

Например, есть константа BUTTON_OFFSET.
Чтобы получить её на маленьком экране я пишу BUTTON_OFFSET / Content.scaleFactor.
Это как-то некрасиво что-ли.

Сейчас делаю так:
То есть делаю оболчку для константы.
Но это тоже как-то не очень.

Какие у вас есть варианты?

Вы вот так делали ?

Хоть Content.scaleFactor не изменяется в процессе работы приложения, он рассчитывается в рантайме.
Так что такой вариант не подойдёт.

Если так не нравится, то сделайте вот так -
Добавлено через 3 минуты
Дело в том, что константы задают только для того, чтобы компилятор их винлайнел в место вызова.
Если такое условие не выполняется, то значит константа просто не нужна.
И Ваш вариант с getBackButtonOffset тоже не может быть заменой константе, так как не инлайнится, то есть не выполняет задачу константы и так же такая запись вообще каждый раз считает условие.
Вот такой get можно присваивать какой-то константе...

Чет я фигню сказал о ТОЛЬКО для инлайна:) Главная цель неизменяемость.
Сделайте getter, то же не меняется.

Я знаю для чего нужна константа :D
Я говорю как правильно и красиво решить проблему, чтобы не плодить на кажду константу геттер.
Но это пока что лучший для меня вариант.

А че тут сложного? Определяете константы метрических параметров для "стандартного" (по Вашему мнению или по задумке дизайнера) размера экрана. А потом для каждого события ресайза пересчитываете эти самые метрики и сохраняете их в соответсвующих переменных. Само собой, что приложение будет пользоваться переменными, а не константами. Если ресайз случится только на старте (подгонка под выделеный размер), то все круто. Но если есть возможность ресайзить в прцессе жизненного цикла прилжения, то есть два варианта:

Ребят, вы не ту проблему решаете)
Я уже всё сделал, мне интересно как красивее обернуть константу.
Перечитайте мой пост.

ЗЫ.: scaleFactor уже дан, он рассчитывается один раз вначале.
Экраны устройства статичные, не думаю что кто-то на андроид сможет поменять размер экрана во время работы приложения.
Потому и рассчитывается всего один раз.

Добавлено через 3 минуты
То есть меня интересует как бы вы поступили:
1. Создали перменную , которая будет равна константе / scale factor.
2. "Константа" изначально будет переменной и потом после расчёта scale factor я делю все "константы" на него.
3. Геттер, который возвращает константу поделенную на скейл фактор
4. ???

Первое, я не правильно понял вопрос и ответ дал тоже неправильный.
Второе, Вы спросили вообще не пойми чего.
Как красиво сделать константу... А делаете геттер. При чем тут константа?)
И или я опять не понял или Вы спросили -
И Вы даже не геттер, а обычный метод называете константой.

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

Хах, интересный вариант - отказаться от констант, "запихнув" их в геттеры.
Возьму на заметку, но посмотрю на варианты других участников форума.

Есть ли минусы у подхода, который предложил Nooob в конце своего поста?

Добавлено через 6 минут
Вы неправильно прочитали мои сообщения или я неправильно выразился :)

Опишу еще раз:
Есть константа const BUTTON_OFFSET = 30 например.
Но вдруг оказывается что у пользователя экран в два раза меньше чем нужно!
Изменяем размер всех кнопок, соответственно и расстояние между ними (offset).
Для этого вначале работы приложения рассчитывается scaleFactor (defaultWidth/stageWidth например).
Соответственно нам нужно "поделить константу" на scaleFactor, но суть константы от этого теряется.
Значит нам нужно красиво обойти эту преграду, чтобы константа формально оставалась константой, но при этом задавалась не при компиляции, а в рантайме (один раз при рассчёте scaleFactor).
Метод Nooob кажется подходит. Но интересны еще вариант :)

Не пойму, что красивого в получении значения параметра не через переменную/константу, а через вызов геттер-функции, если эта функция просто лишняя. Эх, посадить бы вас за мой старый комп, да подключить еще к нему слабенькую батарейку, вместо запитки от электор-сети, и под дулом пистолет заставить какой нибуть аляповатый шутер с открытым миром наваять, да так чтобы фпс не меньше 60 :).

Геттер, который возвращает наперед извесное значение (будь то скрывающееся за ним значение переменной или даже значение переменной, РАЗДЕЛЕННОЕ на жестко заданое значение) - это защита от дурака. Просто бьем по рукам жирным Еррором, если кто захочет поменять значение или определяем сеттер, который сможет произвести изменения по Вашему гениальному плану. Но такой подход имеет смысл, когда разрабатывается какой нибудь движок или фреймворк, реализацию внутренностей которого другие не знают, а Вы забудете месяца эдак через два. В противном же случае... Понимаю, что форум наш очень даже порядочный, но! Тупое следование стандартам или моде похоже на совокупление с родной бесплодной женой в презервативе с целью предотвращения нежелательной беременности :wacko:

Короче, конечному пользователю плевать на красоту и стройность Вашего кода, так как он получает его в компилированом варианте. И, как это не печально, за нормально работающее приложение Вас тоже никто по головке не погладит. Но если же Ваше детище доставит юзверям неудобства, то икать Вам прийдется очень долго. И дай бог, чтобы икота прошла еще при жизны, ато икающий труп, бьющийся лбом о крышку гроба - то еще зрелище.

А об ориентации экрана Вы ничего не слышали? АхВ похоже на ВхА только в случае квадрата! А если Ваше приложение жестко ориентировано, то что Вам не нравится в кешированиии нужных значений и подталкивает к глупому пересчету параметру каждый раз, когда к ним обращаются?

Так что же ты предлагаешь? :)

Я уже предложил: ресайз - пересчет.
Это же как загрузка ресурсов в начале уровня или на входе в локацию. Какой бы железной начинкой не располагал целевой исполнитель (десктоп, ноут, моб-девайс или даже микроконтроллер), следует помнить, что рано или позно его возможности исчерпаются... И тратя их попусту Вы, ка минимум, лишний раз садите батарею исполняющего девайса. Ну а в худшем случае - отсекаете потенциальных пользователей со слабыми девайсами (свою Nokia 2700 я сильно нагружал в игровом плане, но мало что смог после запуска играть, а из того что играл, не все смог пройти - ошибка нехватки памьяти).
Короче, выпендреж на форумах, гитхабе и гуглокодах это одно, но целевую железку кормите тем, что попроще - такая себе цифровая диета :)

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

Тоже непонятен вопрос, да и константы мне кажется тут не причем.
Если идет разговор про приложение, в котором Н элементов и все они ресайзятся по определнной переменной, то для этого должен быть метод

function resizeAll () :void
{
здесь имеем массив всех элементов, которые будут ресайзится. И делаем по алгоритму, resize(a[i])
где в методе ресайз расписывается алгоритм. o / 30 * scaleFactor к примеру.
}

В одной игре делал таким образом скинование, очень удобно оказалось. Прям наглядно пишу
[ a , b ,c ,d ] элементы которые скинуются ( по цвету всего лишь, hue ) и запускаю цикл по всем. В течении нескольких лет в зависимсти от задач заказчика стали появлятся все новые и новые элементы, и мне не составляет труда просто ручками вписать в массив еще один элемент, быстро и понятно, не надо никаких МВС и МММ )))

Как раз суть в том чтобы ДУМАТЬ О КАЧЕСТВЕ КОДА! Иными словами: "Что нужно - делай, что не нужно - не делай." Речь идет о том, чтобы в каждой строчке кода таилась ПРАВИЛЬНАЯ мысль, а не штамповалась целая канва на одном дыхании. К тому же я не агитирую за г***окод, а всего лишь предлагаю сделать все потенциально востребованые расчеты за один присест, когда юзверь вынужден подождать (будь то загрузка или перерисовка экрана под новый размер), а не дегать классы за методы при каждом чихе, лишь бы красиво код смотрелся.

ЗЫ: Если говорить о порядке, то его нарушают и разбросаные пивные банки с сигаретными бычкаи и разбросаные слитки золота с доларовыми банкнотами.
ЗЗЫ: Вот неполный путь того, что я прошел:
И что я там увидел из числовых типов данных? А вот что:
Как по мне, так этот, хоть и слабый, возврат к корням, это один из сигналов о том, что есть смысл выбирать оптимальный инструмент для решения конкретной задачи, а не списывать все на то, что железо нынче крутое и все потянет. В противном же случае продукты типа Winfows 8, Adobe %чтото там% CS/CC... станут нормой.
ЗЗЗЫ: Если найдутся кадры с мнением о вреде преждевременной оптимизации - отвечу сразу. Такое мнение может быть у любого, кто хоть раз писал код, НО!!! Высказывать такое мнение имеет моральное право только тот, кто на оптимизации остановил лбом ворох граблей и съел стаю собак. Такой человек заведомо мыслит оптимизированым кодом и если в его черновых набросках и остаются узкие места, то это уже очень специфические ситуации. Для всех других мнеие о пагубности преждевременной оптимизации - оправдание собственной лени и неосведомленности!

качество кода = (((понятность кода * память и желание объяснять) / количество сотрудников) * (удобная архитектура / количество изменений задачи)) * ЧСВ / деньги / время

Iнфокор, ты не понял задачу :)
У меня все текстуры при инициализации УЖЕ заресайзены.
Например, у меня есть меню уровней игры. В нем есть много уровней, между которыми есть небольшое расстояние BUTTON_OFFSET (например 30).
Кнопки у меня уже заресайзились, а вот BUTTON OFFSET остался таким как был, но его ведь тоже нужно подкорректировать соответствии с экраном!
Для этого я и делю везде BUTTON_OFFSET / Content.scaleFactor.
Но тогда код разрастается и становится неэстетичным.

profit

Как два программиста хлеб пекли...

@in4core
С высоты лисьего полета похоже, но если убрать эмоциональную часть моих высказываний, то не совсем

https://github.com/EnterpriseQuality...erpriseEdition
* когда я вижу код ооп-задротов

CHEATER!