Ссылка на stage

[Appleman]

Друзья, подскажите ещё один маленький технический момент, пожалуйста. Часто приходится что-то центровать по размерам сцены и вообще с этими размерами взаимодействовать, причём подобные ситуации возникают в разных классах. Ловить в каждом событие ADDED_TO_STAGE - муторно. Как лучше организовать и хранить ссылку на экземпляр stage для быстрого к ней доступа? И откуда её "протягивать"?

Спасибо.

[caseyryan]

Лучше подписываться каждый раз и делать вычисления по событию.
Если муторно делать это каждый раз, то вместо Sprite можно создать свой класс наследник, и в нем сделать нужные подписки, а потом просто наследовать свои классы от него и перезаписывать метод onAdded, который можно поменить модификатором доступа protected
Если хранить где-то ссылку на stage, то это приведет к дополнительной связанности. Уже нельзя будет просто скопировать какой-то класс из одного проекта в другой. Нужно будет и тот, что хранит stage тянуть, это во-первых, а во вторых ссылка может в какой-то момент, по разным причинам теряться, что приведет к рантайм ошибкам, тогда как по событию, stage будет доступен 100%

[Appleman]

Спасибо. Значит, будем терпеливо добывать свою ссылку в каждом заинтересованном классе.

[Wolsh]

"Муторно"
А знаешь как я делаю? У меня главная Вью подписана на событие RESIZE от stage, и когда это событие случается, Вью вызывает метод resize() у всех своих модулей, передавая им размеры (не размеры стейджа, а пересчитывает ИХ, модулей, размеры и задает им эти новые).
1) Если модуль будет сам себя пересчитывать так, как хочется ему, а не хозяину, этот модуль нельзя будет использовать в других приложениях или даже в других задачах этого приложения. Для примера доведем до абсурда — написал бы я кнопку, которая спрашивает размеры стейджа и задает себе размеры в зависимости от них, а так же свои координаты на экране (иначе я не знаю зачем вообще иметь ссылку на стейдж). Ну и куда я смогу использовать такую кнопку, кроме одного-единственного случая?
2) Если модуль будет реагировать только на ADDED_TO_STAGE, то при изменении размеров приложения все расползется.
3) Модуль понятия не имеет о том, что творится вокруг него. Это знает хозяин. Может, хозяину пришлось раздвинуть текстовое поле чтобы вместить новый текст, или еще какие пертурбации произошли. У хозяина должна быть возможность изменить размеры и координаты любого модуля. Иерархия и контроль.
4) Модуль должен уметь менять свои размеры без деформации (scale) — в разумных пределах конечно — при необходимости буквально перерисовывая заново какие-то свои элементы. Та же кнопка должна уметь быть любой ширины и любой высоты (не связано друг с другом), но не меньше какого-то разумного минимума (особенно если она с лейблом). Более сложный модуль должен уметь менять размеры, поддерживая какой-то приличный вид, передвигая, перерисовывая, меняя размеры текстфилдов и, в самом ужасном случае, даже добавлять полосы прокрутки, если уместить все свои элементы в заданном размере он не в состоянии.
Это все в идеале, конечно. В реальности такие страсти не всегда нужны; однако при написании игры тебе, как ни крути, придется заморочиться красивым заполнением экрана в режиме фуллскрин. А экраны сейчас какого только разрешения не бывают.

[Appleman]

А откуда твоя главная вьюха "знает", в каких пределах и на какие значения должны измениться те или иные компоненты? Или это для каждого проекта в зависимости от разметки экрана прописывается?

Если честно, я про RESIZE сцены пока вообще не думал. А привязка к stage потребовалась, чтобы центровать меню по высоте. Ведь в нём кол-во кнопок может меняться от случая к случаю, а значит, и координата y должна подстраиваться. Плюс ширина кнопок подбираться под самый длинный из лэйблов.

[ZergMaster]

Я кстати тоже делал подобным образом, только более варварски. У меня были в главной вьюхе (main) были private static переменные mainWidth и mainHeight, у которых были только геттеры. И точно также по событию Event.RESIZE у каждого ребенка вызывалась функция .resize(). По разному я делал - иногда width и height были статическими переменными мэйна, иногда - передавались в каждого ребенка. Кажется, тогда я так и не определился, какой вариант оптимальнее)) Хотя сейчас кажется очевидным, что можно по ресайзу менять эти переменные в модели, которая будет рассылать события по всем и вся.

Appleman

А откуда твоя главная вьюха "знает", в каких пределах и на какие значения должны измениться те или иные компоненты?

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

Добавлено через 3 минуты
хотя блин, что я говорю, ведь каждый спрайт имеет доступ к stage.stageWidth и stageHeight)) Правда, это если он добавлен на сцену. А у меня просто размер менялся из js окружения, поэтому параметры ширины приходили из ExternalInterface

[Wolsh]

Конечно, Вьюха знает. Это ее единственная ответственность, расположить все красиво на экране.

Но для этого не нужна ссылка на стейдж. Ну то есть, она нужна Вью, и Вью ее получает один раз при добавлении на сцену. Далее Вью создает экземпляры своих модулей. Допустим, у тебя есть вверху полоса интерфейса с каким-то заголовком и парой кнопок (например, вызов глобального Меню, он же канает и за общую Паузу в игре, и, допустим, вызов окна Инвентаря и вызов окна Задания), и внизу полоса интерфейса со всякими данными о состоянии персонажа. А в центре окно текущего стейта — Поединок, или Торговля, или Диалог. Вот три модуля, верхний, нижний и центральный. Вью знает размер стейджа. Вью знает, что верхняя полоса должна быть 24 пикселя высотой, а нижняя 36, и их высота постоянна, её нельзя менять, а вот центральный модуль "подвижен". Так она вычисляет высоту центрального модуля, stage.stageHeight - 24 - 36; Так же узнает координаты Y для центрального модуля и для нижнего: 24 и stage.stageHeight - 36. Ширина всех модулей одинакова — stage.stageWidth. Все эти расчеты помещаются в метод ресайз(), чтобы можно было пересчитать в любой момент, если размеры сцены поменяются. После пересчета у модулей вызываются их методы ресайз(), в которые передаются новые значения.

Горизонтальные модули пытаются подстроиться под изменение ширины (высоту они не меняют по определению). Допустим, в модуле одна кнопка должна быть прижата к левому краю, а вторая — к правому. А посередине какой-то текст. Левую кнопку мы не трогаем, а правой надо пересчитать координату Х, верно? Затем мы узнаем ширину оставшегося пространства между кнопками и подстраиваем ширину текстфилда. УзнаЁм, влазит ли текст; если нет то меняем размер шрифта, пока не влезет.

Это все только звучит страшно; на деле ты бы все это же проворачивал, имея ссылку на стейдж чтобы спросить его размеры, а здесь получаешь размеры в метод ресайз() от Хозяина компонента, вот и вся разница. Но мимимишность использования такого компонента на порядок выше, чем если он сам будет звонить в генштаб по каждому поводу кроме тех, когда надо.

[Nooob]

нужно оперировать анкерами(пределами) и точками опоры, а не ссылками на родителя/сцену и только при добавлении/изменении куда-то значения анкеров и точек опоры переводить в координаты и размер
посмотри API Flex https://help.adobe.com/en_US/FlashPl...Component.html или Unity UI https://docs.unity3d.com/ScriptRefer...Transform.html или Node в cocos2d http://www.cocos2d-x.org/reference/n..._1_1_node.html

[Appleman]

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

Конечно, Вьюха знает. Это ее единственная ответственность, расположить все красиво на экране. Но для этого не нужна ссылка на стейдж. Ну то есть, она нужна Вью, и Вью ее получает один раз при добавлении на сцену. Далее Вью создает экземпляры своих модулей.

Получается, все ключевые размеры основных компонентов хранятся в главной вью, верно? Иначе как она узнает, что такой-то компонент имеет фиксированную высоту в столько-то пикселей. И тогда выходит, что размеры компонентам также передаёт в конструктор вью, так?

Nooob, спасибо, читаю.

[ZergMaster]

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