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

[elder_Nosferatu]

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

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

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

Сообщение от MikroAcse

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

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

[MikroAcse]

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

[elder_Nosferatu]

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

[MikroAcse]

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

[in4core]

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

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

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

[elder_Nosferatu]

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

ЗЫ: Если говорить о порядке, то его нарушают и разбросаные пивные банки с сигаретными бычкаи и разбросаные слитки золота с доларовыми банкнотами.
ЗЗЫ: Вот неполный путь того, что я прошел:

Turbo Pascal (Delphi) -> Javascript -> Actionscript 3.0

И что я там увидел из числовых типов данных? А вот что:

Pascal: Byte, ShortInt, Word, Integer, LongInt, Single, Real, Double, Extended, Comp
javascript: Number
Actionscript 3.0: Number, int, uint

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

[Nooob]

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

[MikroAcse]

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

[nubideus]

package  
{
	public class test 
	{
		public static const tet:uint = Main.value; // твоя константа
		public function test() 
		{
 
		}
	}
 
}

public class Main extends Sprite
{
	public static var value:uint; // твоя не-константа
	public function Main ()
	{
		value = stage.stageWidth;
		trace(test.tet); // 800
	}
}

profit

[in4core]

Как раз суть в том чтобы ДУМАТЬ О КАЧЕСТВЕ КОДА!

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