Во-первых, я 100% рекомендую изучить эту презентацию EffectiveUI :
и это Майкл Лабриола из Цифровые приматы :
Они охватывают вещи, которые вы никогда не найдете в документах, но которые очень полезны для понимания жизненного цикла компонентов Flex.
Исходя из моего опыта, вам нужно беспокоиться только о переопределении основных методов жизненного цикла, если вы создаете компонентов. Я делаю различие между Приложениями и Компонентами .
- Компоненты - это вещи, которые должны быть почти идеальными, оптимизированными и чрезвычайно универсальными / абстрактными.
- Представления - это то, что вам может понадобиться только в одном приложении, но при желании их можно использовать повторно (LoginScreen, ContactForm и т. Д.).
Представления, по большей части, просто добавляют вещи в список отображения более общего компонента (Canvas, Group, Container, VBox, List и т. Д.). Вы, как разработчик View / Application, на самом деле не заботитесь о том, как «dataProvider» создает свои itemRenderers, он просто работает.
Компоненты - это отдельная история. Когда вы создаете компонент, вы хотите, чтобы он идеально вписался в ту систему, которую настроил Flex: жизненный цикл компонента. Это довольно сложно, когда вы впервые пытаетесь создать компонент, как они, но после того, как вы обернетесь вокруг него, это будет очень легко. Вот как я думаю о методах разработки компонентов :
createChildren ()
- Вызывается один раз при создании компонента
- Вызывается сверху вниз. Поэтому, если
Panel вызывает createChildren, метод createChildren будет вызывать addChild для всех своих дочерних элементов, что вызывает initialize, что вызывает createChildren.
Если вы создали пользовательский компонент, скажем StarRatingComponent, вы можете добавить 5 звезд на сцену при создании компонента. Поэтому вы должны переопределить createChildren() для добавления звездочек к компоненту, в котором вы находитесь. Однако по умолчанию все компоненты-контейнеры в Flex SDK добавляют своих потомков (списки делают это немного по-другому), поэтому вам никогда не придется сделайте это, если вы создаете представления MXML или что-то не подлежащее повторному использованию.
Следующие 3 метода называются через 1 кадр после установки свойств.
мера ()
- Если родитель не имеет какого-либо размера (в процентах или в явном виде), его необходимо будет измерять в соответствии с размерами его детей. Это может произойти только снизу вверх (мне потребовалось довольно много времени, чтобы по-настоящему обдумать это).
- Если родитель имеет явные или процентные размеры, этот шаг пропускается.
Вы переопределяете measure, если хотите:
- Возвращает
measuredWidth или measuredHeight полезное значение. Таким образом, если вы создаете пользовательский компонент CoverFlowContainer, а measuredWidth/measuredHeight не установлены (поскольку measure не был переопределен), то если вы не укажете размеры для CoverFlowContainer, это будет 0 ширина 0 высота. Поэтому вместо этого переопределите measure и установите для measuredWidth значение radius * 2 или что-то в этом роде, и теперь вам не нужно указывать его размер!
- Если у компонента нет явного или процентного размера, для измерения будет использоваться мера. В противном случае оно пропускается.
commitProperties
- Вызывается после
measure.
- Применяет все изменения свойств (от установки свойств для компонента) к компоненту (они были сохранены в частных переменных для этого первого кадра).
- Вызывается кадр после первоначальной настройки свойств.
На мой взгляд, это самый важный метод для переопределения. Итак, для вашего CoverFlowContainer, скажем, вы установили гипотетические свойства distance, gap, selectedItem и tilt. Когда вы устанавливаете их, храните их в частных переменных. Флекс будет ждать кадра и позвонит commitProperties. В своем переопределенном commitProperties вы можете сказать, так сказать, layout.updateEverything(selectedItem, distance, gap, tilt);. Так что это метод, который вы переопределяете, чтобы все изменения свойств были применены сразу.
updateDisplayList
- Вызывается после
commitProperties
- Вызывается сверху вниз.
Вы переопределяете это только для установки видимых свойств компонента, таких как setActualSize, graphics и т. Д. Но сейчас (из-за `commitProperties) у вас есть все необходимые переменные для обновления набора отображения до правильные значения.
В целом
Итак, исходя из своего опыта, я много работал с этими методами жизненного цикла при создании библиотеки компонентов для вещей, которые я бы использовал в миллионе проектов:
- TitleWindow (моя собственная версия)
- View3D (для Away3D / Papervision)
- Дерево и стек для Flex 4
- TextArea (с подсказкой, возможностью расширения и т. Д.)
- Подсказка (легче всплывающая подсказка)
Мне нужно было убедиться, что все было обновлено и отрисовано в соответствии с жизненным циклом. Чтение и понимание Исходного кода Flex 4 Spark действительно помогает уточнить, когда следует переопределять эти методы. Как и исходный код Openflux (очень простая, понятная альтернатива Flex Framework. Не настолько многофункциональная, поэтому демонстрирует, как полностью переопределить эти методы для выполнения некоторых довольно сложных задач).
Когда я разрабатываю приложения и создаю такие вещи, как AdvertismentView, MenuView и LoginView, я никогда не задумываюсь об этом, потому что все компоненты, которые я использую, уже решили эти проблемы (ViewStack, Group, List , так далее.). Я просто устанавливаю свойства, которые они определили и обновили в их собственной commitProperties переопределении.
Единственный раз, когда я начинаю переопределять методы жизненного цикла в представлении, это когда мне нужно получить доступ к пользовательским переменным вне представления. Допустим, у меня был собственный RichTextEditor, и я создал некоторые свойства с именами showFontControls и showStylePanel. Когда я устанавливаю эти переменные, я, вероятно, буду делать то, что они описали в Представлении привязки данных : средство доступа устанавливает закрытую переменную и вызывает методы аннулирования, методы жизненного цикла выполняют кадр позже, и я переопределил commitProperties и updateDisplayList, чтобы показать эти панели и шрифты. Но на практике это, вероятно, излишне, потому что это не принесло бы такой большой выигрыш в производительности по сравнению с объемом работы. Я бы просто установил некоторую привязку к свойству visible в этом случае. Тем не менее ....
Лучшее, что можно сделать, чтобы по-настоящему разобраться в этом, - это просто загрузить Flex SDK Source и посмотреть, что они делают.
Надеюсь, это поможет.
Lance