Блог Diestro

Биндинг в ActionScript проектах. Часть 3

Diestro — Fri, 08 Apr 2011 05:52:41 +0000

В предыдущих статьях мы рассмотрели возможности биндинга в плане привязки метатега [Bindable] к различным элементам нашего кода и кастомизации срабатывания биндинга с помощью событий. На этом возможности биндинга не ограничиваются. Подписка на события биндинга в методах BindingUtlis.bindProperty и BindingUtlis.bindSetter также дает большое количество возможностей для его реализации.

Для того чтобы слушать изменения свойства или метода, помеченного как [Bindable], необходимо использовать один из методов BindingUtlis.bindProperty или BindingUtlis.bindSetter.

public static function bindProperty (site:Object, prop:String, host:Object, chain:Object, commitOnly:Boolean = false, useWeakReference:Boolean = false):ChangeWatcher
public static function bindSetter (setter:Function, host:Object, chain:Object, commitOnly:Boolean = false, useWeakReference:Boolean = false):ChangeWatcher

Единственное принципиальное отличие этих двух методов заключается в том что в первом случае в результате срабатывания биндинга меняется значение указанного свойства prop в объекте site, во втором вызывается метод setter для обработки результата. В остальном эти два метода принимают одинаковые параметры и дальнейшее повествование будет иметь одинаковый смысл для обоих случаев.

Параметр host

Параметр host это объект в котором находится параметр или цепочка параметров за которыми необходимо следить.

Параметр chain

Итак, и метод bindProperty и bindSetter имеют обязательный параметр сhain типа Object, который может принимать следующие значения:

chain в виде строки

Определяет имя привязываемого свойства:

1	BindingUtils.bindSetter(onPropChange, host, "prop");

До сих пор мы в качестве chain всегда передавали именно строку и об использовании данного параметра в таком качестве можно прочесть в предыдущих статьях;

chain в виде массива

Непустой массив, содержащий последовательность свойств за которыми необходимо следить:

1	BindingUtils.bindProperty(this, "prop", host, ["a", "b", "c"]);

Массив в качестве цепочки крайне удобен и используется достаточно часто. Цепочка свойств должна быть указана в виде ["a","b","c"] что будет соответствовать привязке свойства host.a.b.c. Может возникнуть вполне резонный вопрос: “Почему в качестве host не указать сразу host.a.b, а свойство за которым следить не передать в качестве строки "c"?

1	BindingUtils.bindProperty(this, "prop", host.a.b, "c");

Цепочкой целесообразно пользоваться когда в ней встречаются изменяющиеся свойства тоже помеченные метатегом [Bindable]. Утилиты биндинга автоматически будут распознавать изменение любого из таких свойств в цепочке и нам не понадобится городить биндинг в биндинге, следить чтобы экземпляры ChangeWatcher были отписаны и т.п.

Представим что у нас есть класс Model в котором есть свойство item типа Item:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package{

import flash.events.EventDispatcher;

public class Model extends EventDispatcher{

[Bindable]
public var item:Item;

public function Model() {
super();
}
}
}

Класс Item в свою очередь содержит свойство color

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package{

import flash.events.EventDispatcher;

public class Item extends EventDispatcher{

[Bindable]
public var color:uint;

public function Item(){
super();
}
}
}

Так же есть класс отображения CurrentColorView который должен показывать текущий цвет для текущего элемнта item в классе Model.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

package{

import flash.display.Sprite;
import mx.binding.utils.BindingUtils;

public class CurrentColorView extends Sprite{

private var model:Model;

public function CurrentColorView(model:Model){
this.model = model;
super();
BindingUtils.bindSetter(onColorChange, model, ["item", "color"]);
}

private function onColorChange(value:int):void{
// меняем отображение цвета
graphics.clear();
graphics.beginFill(value);
graphics.drawCircle(0,0,50);
graphics.endFill();
}
}
}

В данном примере свойство за которым нужно следить задается как раз в виде цепочки. При смене экземпляра в свойстве item класса Model биндинг сработает автоматически и метод onColorChange получит значение цвета уже для нового элемента. То же самое произойдет и при изменении свойства color в экземпляре класса, содержащемся в item класса Model.

Если бы не было возможности задавать отслеживаемые свойства в виде цепочек код пришлось бы усложнить, например написать следующим образом:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

// Внимание! Говнокод!
package{

import flash.display.Sprite;
import mx.binding.utils.BindingUtils;
import mx.binding.utils.ChangeWatcher;

public class CurrentColorView extends Sprite{

private var model:Model;

// хранилище для "наблюдателя" за свойтсвом color
private var colorChangeWatcher:ChangeWatcher;

public function CurrentColorView(model:Model){
this.model = model;
super();

// подписываемся на изменения свойства item в model
BindingUtils.bindSetter(onItemChange, model, "item");
}

// обработчик вызываемый при изменении свойства item в классе Model
private function onItemChange(value:Item):void{
// если мы уже наблюбаем за свойством color отписываемся от наблюдения
if (colorChangeWatcher)
colorChangeWatcher.unwatch();

// подписываемся на изменения свойства color в новом экземпляре свойства item класса Model
colorChangeWatcher = BindingUtils.bindSetter(onColorChange, value, "color");
}

// Цвет изменился
private function onColorChange(value:int):void{
// меняем отображение цвета
graphics.clear();
graphics.beginFill(value);
graphics.drawCircle(0,0,50);
graphics.endFill();
}
}
}

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

chain в виде объекта {name: имя свойства, getter: имя метода}

В случае когда для параметра chain мы передаем объект в виде {name: имя свойства, getter: имя метода} мы можем подписаться на прослушивание изменения свойства name указаного в виде строки для объекта host. В результате срабатывания биндинга будет вызван метод указанный в свойстве getter который в качестве параметра получит объект host. Этот метод должен возвращать значение, совпадающее по типу со свойством указанным в качестве приемника в случае bindProperty, либо совпадающее по типу с параметром, поступающим в метод обработчика в случае с bindSetter. Т.е. мы можем передать нашему слушателю (свойству или методу) не то значение которое получено, а новое вычисленное значение или объект другого типа после нужного нам преобразования.

Приведу пару примеров:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package
{

import flash.display.Sprite;
import mx.binding.utils.BindingUtils;

public class Viewer extends Sprite
{
private var viewObject:Sprite = new Sprite();

[Bindable]
public var keyWord:String = "";

public function Viewer()
{
BindingUtils.bindProperty(viewObject, "visible", this, {name:"keyWord", getter: function(host:Object):Boolean{return host.keyWord == "showIt!"}});
}
}
}

В данном примере у нас есть спрайт viewObject, параметр visible которого будет выставлен в true только в случае когда свойство keyWord примет значение "showIt!". Т.е. при изменении свойства keyWord вызовется анонимный метод, указанный в поле getter:, возвращающий булево значение. Это значение будет true только в случае совпадения со строкой "showIt!". Возвращенное значение будет присвоено параметру visible для viewObject.

Рассмотрим пример в случае использования bindSetter:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package
{

import flash.display.Sprite;
import mx.binding.utils.BindingUtils;

public class KeyWordLogger extends Sprite
{
public var viewObject:Sprite = new Sprite();

[Bindable]
public var keyWord:String = "first keyword";

public function KeyWordLogger()
{
BindingUtils.bindSetter(log, this, {name:"keyWord", getter: function(host:Object):String{return "New keyword is: " + host.keyWord}});

keyWord = "second keyword";
keyWord = "wrong keyword";
}
private function log(value:String):void
{
trace(value);
}
}
}

В результате выполнения данного кода в консоли мы увидим следующее:

New keyword is: first keyword
New keyword is: second keyword
New keyword is: wrong keyword

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

На самом деле приведенной выше конструкцией chain в виде объекта {name: имя свойства, getter: имя метода} я никогда не пользовался, и честно говоря не могу придумать задач для которых это бы было единственным и правильным решением. Я не сторонник написания анонимных функций и считаю что их присутствие в коде влияет на его читабельность и прозрачность не в лучшую сторону, а всю логику, которую можно описать задавая анонимную функцию в качестве getter, можно вынести в метод обработки для bindSetter и сделать все там. Как показал беглый поиск по Flex фреймворку в SDK 3-их и 4-х версий его разработчики тоже не используют данный тип конструкции.

Если кто-то готов показать примеры когда использование анонимного getter дает какие-то преимущества по сравнению с другими способами биндинга готов выслушать и дополнить ими статью.

Параметр commitOnly

Использование данного параметра позволяет разделить изменения свойства за которым нужно следить на “текущее изменение” и “окончательное (фиксирующее) изменение”. Например пользователь в какой то форме с несколькими текстовыми полями делает изменения. Нам необходимо следить за изменениями текстовых полей и нужно знать окончательное это изменение в текстовом поле или пользователь продолжает туда вводить информацию, в зависимости от этого осуществлять валидацию введённой информации.

Если данный параметр выставлен в true, то это означает что мы подписываемся на прослушивания только окончательных изменений в наблюдаемом свойстве. Если же в качестве параметра будет передано false то слушать будем все изменения.

Для указания события для текущих (нефиксирующих) изменений существует метатег [NonCommittingChangeEvent(event="<имя события>")]. Выставлять commitOnly в true имеет смысл только когда перед наблюдаемым свойством присутствует этот метатег. Если commitOnly выставлен в true, то для событий указанных в данном метатеге биндинг срабатывать не будет. Таким образом указывая метатеги [NonCommittingChangeEvent(event="<имя события>")] и [Bindable(event="<имя события>")] в различных сочетаниях перед наблюдаемым свойством мы можем разделять срабатывание биндинга для фиксирующих и текущих изменений.

Приведу пример исользования данного флага. Допустим нам необходим компонент TextInputField со свойством inputText к которому можно привязать биндинг. Биндинг должен срабатывать при любом изменении текста в компоненте, фиксирующий биндинг должен сработать при потере компонентом фокуса.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package
{

import flash.text.TextField;
import flash.text.TextFieldType;

public class TextInputField extends TextField
{
public function TextInputField()
{
super();
type = TextFieldType.INPUT;
border = true;
}

// Измение текста в текстовом поле
[NonCommittingChangeEvent(event="change")]
// Потеря фокуса тестовым полем
[Bindable(event="focusOut")]
public function get inputText():String
{
return super.text;
}

}
}

Здесь для геттера inputText указано два события для срабатывания биндинга: изменение текста и потеря фокуса. В данном случае нам даже не придется генерировать эти события, их генерирует сам класс TextField от которого мы отнаследовались.

Теперь рассмотрим пример использования класса TextInputField

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

package
{

import flash.display.Sprite;
import mx.binding.utils.BindingUtils;

public class Form extends Sprite
{

private var inputField:TextInputField = new TextInputField();

public function Form ()
{
inputField.width = 200;
inputField.multiline = true;
inputField.wordWrap = true;
addChild(inputField);

// биндимся на все изменения свойства inputText
BindingUtils.bindSetter(onInputChange, inputField, "inputText");

// биндимся только на фиксацирующие изменения свойства inputText
BindingUtils.bindSetter(onInputCommit, inputField, "inputText", true);
}

private function onInputChange(value:String):void
{
trace("Текущее изменение: " + value);
}

private function onInputCommit(value:String):void
{
trace("Фиксирующее изменение: " + value);
}
}
}

В данном примере мы биндимся два раза на свойство inputText, первый раз для слежения за всеми изменениями этого свойства, второй раз для отслеживания только фиксирующих изменений. В первом случае для обработки будет вызван метод onInputChange, во втором onInputCommit.

Параметр useWeakReference

Данный параметр имеет тот же смысл что и в случае подписки на события посредством addEventListener. Он определяет является ли ссылка сильной (false) или слабой (true). По умолчанию ссылка является сильной. В случае слабой ссылки использование биндинга не будет влиять на удаление сборщиком мусора объекта указнного в host из памяти.

На этом позвольте откланяться, это все что я хотел рассказать о биндинге в ActionScript проектах.

p.s. Огромное спасибо друзьям и коллегам из родного Drimmi за помощь в обсуждении и написании этих постов.

Биндинг в ActionScript проектах. Часть 2

Diestro — Tue, 22 Mar 2011 17:21:44 +0000

Рамки использования метатега [Bindable] значительно шире указнных в статье Биндинг в ActionScript проектах. Часть 1. В данной статье расскажу о том куда можно применить данный метатег и о возможностях биндинга в случае использования собственных событий.

Куда можно воткнуть метатег [Bindable]?

Метатег [Bindable] можно использовать в следующих местах:

1. Перед свойством.

Свойство может быть как public, так и protected или private.

Например:

1 2	[Bindable] public var text:String;

О биндинге применительно к свойствам уже говорилось в первой части. Компилятор автоматически преобразует свойство, помеченное тегом [Bindable] к геттеру/сеттеру с отсылкой события.

2. Перед определением класса

1 2	[Bindable] public class SomeClass extends EventDispatcher

Это равносильно тому, что мы бы проставили метатег [Bindable] для каждого из public свойств этого класса. Private и protected или свойства из другого пространства имен автоматически не будут помечены как [Bindable]. Если нужно забиндить не public свойства к ним нужно дописывать метатег [Bindable] самостоятельно.

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

3. Перед get или set методом

Метатег [Bindable] так же можно использовать если свойства у класса оформленны в виде get/set методов:

1
2
3
4
5
6
7
8

private var _text:String;
[Bindable]
public function get text():String{
return _text;
}
public function set text(value:String):void{
_text = value;
}

Компилятор позволит вам поставить его как возле геттера, так и возле сеттера. Но! Как изветсно если мы для свойства напишем только сеттер то оно будет доступно только для записи (write only), если же напишем только геттер то только для чтения (read only). С помощью BindingUtils “забиндиться” на свойство доступное только для записи невозможно, но сделать это для свойства, доступного только для чтения – вполне. Я настоятельно рекомендую всегда писать тег [Bindable] только рядом с геттером, это позволит видеть событие (см. ниже) и избежать путаницы и ошибок.

Если указан только геттер и свойство доступно только для чтения, целесообразно использовать биндинг только совместно с событиями (см. раздел “Кастомные события”), иначе биндинг сработает только во время инициализации, а среда разработки будет выдавать предупреждения.

4. Перед методом

1
2
3
4
5

[Bindable(event="bindFunctionChange")]
public function bindFunction(prop:int):String{
...
return someString;
}

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

Кастомные события

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

Итак о событиях. Рассмотрим их при использовании с геттером. Представим что нам необходимо задать в каких конкретно случаях будет срабатывать биндинг, или чтобы он сработал после того как мы выполним все необходимые оперции в сеттере. Для этого в нашем метатеге мы можем указать событие в результате которого сработает биндинг:

1	[Bindable(event="textChanged")]

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

1	dispatchEvent(new Event("textChanged"));

Пример:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

private var _text:String;
[Bindable(event="textChanged")]
public function get text():String {
return _text;
}
public function set text(value:String):void {
if (value == _text) {
return;
}
if (value == "дурак"){
trace("Сам дурак!");
}
_text = value;
dispatchEvent(new Event("textChanged"));
}

В данном примере как только изменится свойство text (именно изменится) в консоль при необходимости выведется соответствующее сообщение и посредством отсылки события слушатели будут удовемлены об ее изменении.

Как только мы указали свое событие для биндинга он перестает стандартно срабатывать при изменении свойства для которого указан метатег. Биндинг сработает только в случае когда будет сгенерировано указннное в метатеге событие.

Очень важный нюанс при использовании биндинга с самостоятельным указанием имени события – это то, что очень желательно проверять старое и новое значение. В случае если оно не изменилось – слушателей, посредством отсылки событий, уведомлять не нужно. Когда событие в метатеге не указывается, код проверяющий старое и новое значение генерируется автоматически (см. Часть 1, код в разделе “Как это работает”) и биндинг без изменения значения свойства срабатывать не будет.

Итак, при использовании своих событий следите за тем чтобы биндинг лишний раз не срабатывал.

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

1 2	[Bindable] public var items:Array;

биндинг сработает только в случае

1	items = new Array();

Если просто добавлять элементы в массив

1	items.push(new Item());

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

1 2	[Bindable(event="itemsChanged")] public var items:Array;

и отсылать событие

1	dispatchEvent(new Event("itemsChanged"));

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

Рассмотрим биндинг для методов. Биндинг для методов целесообразен только вкупе с кастомным событием. Он может быть очень полезен и удобен в случаях когда нам не просто нужно получить значение свойства, на которое мы забиндились, а получить некоторое значение в зависимости от некоторых параметров, которые мы можем передать на вход методу. Например, для изменения локализации приложения “на лету”.

Пусть у нас есть класс LocaleManager который при смене локали должен оповестить всех заинтересованных слушателей о том что локаль изменилась и дать возможность взять новое значение нужной строки для текущей локали currentLocale. Все строки у нас хранятся в некотором хранилище localeRepository из которого мы можем взять нужную нам строку по ID в соответствии с текущей локалью.

В классе LocaleManager мы заводим метод:

1
2
3
4

[Bindable(event="localeChange")]
public function getLocaleString(stringID:int):String{
return localeRepository.getString(currentLocale, stringID);
}

При изменении локали нужно сгенерировать событие

1	dispatchEvent(new Event("localeChange"));

Все слушатели заинтересованные в получении актуальных значений строк для текущей локали должны подписаться на изменения getLocaleString посредством BindingUtils.

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

Подписываемся на изменения локали в localeManager:

1	BindingUtils.bindSetter(onLocaleChange, localeManager, "getLocaleString");

В случае смены локали будет вызван метод onLocaleChange, параметром к которому будет передан экземпляр класса Function. Далее мы можем вызвать полученный экземпляр, указывая ему на вход необходимый ID нужной строки.

1
2
3
4

private function onLocaleChange(func:Function):void{
myTextField1.text = func.call(this, 111);
myTextField2.text = func.call(this, 222);
}

В результате при смене локали автоматически поменяется текст в нужных полях элементов отображения.

При использовании кастомных событий возможно указание нескольких метатегов [Bindable (event="")] перед изменяемым обектом:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

[Bindable(event="xChanged")]
[Bindable(event="yChanged")]
[Bindable(event="widthChanged")]
[Bindable(event="heightChanged")]
public function get viewRect():Rectangle{
return _viewRect;
}

public function set x(value:Number):void{
if (_viewRect.x != value){
_viewRect.x = value;
dispatchEvent(new Event("xChanged"));
}
}

public function set y(value:Number):void{
if (_viewRect.y != value){
_viewRect.y = value;
dispatchEvent(new Event("yChanged"));
}
}

public function set width(value:Number):void{
if (_viewRect.width != value){
_viewRect.width = value;
dispatchEvent(new Event("widthChanged"));
}
}

public function set height(value:Number):void{
if (_viewRect.height != value){
_viewRect.height = value;
dispatchEvent(new Event("heightChanged"));
}
}

В этом примере биндинг для свойства viewRect сработает в случае изменения любого из свойств x, y, width или height.

На этом пока все, продолжение следует.

Unity вперед!

Diestro — Mon, 28 Feb 2011 06:02:32 +0000

Как стало недавно известно Adobe выпустила пререлиз нового флэш плеера “Incubator” с поддержкой API Molehill. Практически сразу же после этого Unity, занимающегося разработкой альтернативного плагина с поддержкой 3D, объявила что будет поддерживать экспорт проектов в формат Flash-плеера. В этой публикации не дается никаких упоминаний о том когда эта возможность полноценно появится в Unity.

Может ли это привести к вымиранию Unity как плагина к браузеру? В Unity говорят что никак нет, но упоминают о том что в ихней среде разработки помимо родного C# появится и поддержка ActionScript! По сути весь написанный код на C# или Javascript будет переводиться в ActionScript и после этого собираться компилятором.

Так что нас с вами ждет новая среда для создания Flash приложений. Чтож, Unity вперед!

Биндинг в ActionScript проектах. Часть 1

Diestro — Tue, 15 Feb 2011 17:49:33 +0000

Перед разработчиками часто встает вопрос о взамодействии различных классов в приложении. Как классы приложения будут обмениваться информацией между собой, сообщать о тех или иных изменениях? Это должно происходить своевременно. Для этих целей во Flex-фреймворке есть замечательный инструмент, значительно облегчающий жизнь разработчику – биндинг (binding). И как оказалось этой возможностью можно с успехом пользоваться и без использования Flex-фреймворка. Начиная с какой-то-там одной из третьих версий SDK адобовцы постарались максимально изолировать биндинг и все что с ним связано, и теперь его использование добавляет приложению считанные килобайты.

Как бы мы сделали

Немного отвлечемся и поговорим о частном случае. Когда же нам может все это дело пригодиться? Например, при разработке с использованием паттерна MVC встает вопрос о своевременном реагировании компонентов отображения на изменения в модели.

Как известно в MVC классы модели ничего не должны знать и не иметь ссылок ни на классы контроллера, ни на классы отображения. А вот на модель имеют ссылку и контроллер и отображение. Контроллеру нужна ссылка для того чтобы изменить модель, отображению – чтобы отреагировать на изменения. С изменением модели вроде все понятно – нужно поменять свойство. Но как отображение узнает о том что данные были изменены, чтобы самому измениться? Как правило для этих целей используются события. Мы создаем в модели сеттер на нужное нам свойство и в тот момент когда свойство меняется – посылаем соответствующее событие:

1
2
3
4
5
6
7
8
9

private var _text:String;

public function set text (value:String):void{
if (value == _text){
return;
}
_text = value;
dispatchEvent(new Event("textChanged"));
}

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

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

Как это делается с помощью биндинга

А как же все таки было бы здорово просто написать в классе отображения: “при изменении вот этого свойства вон в том экземпляре класса изменить вот это свойство” или вот так: “при изменении вот этого свойства вон в том экземпляре класса вызвать вот этот метод для обработки”. Так вот стандартный флэксовый биндинг работает именно так.

Давайте посмотрим как это будет выглядеть непосредственно в коде. То свойство за которым нам необходимо пристально следить нужно пометить как bindable. Делается это очень просто, с помощью метатега [Bindable]:

1
2
3
4
5
6
7
8
9

package{
import flash.events.EventDispatcher;

// Класс который использует метатег [Bindable] должен обязательно расширяться от EventDispatcher
public class ClassWithTextProperty extends EventDispatcher{
[Bindable]
public var text:String;
}
}

В классе который должен следить за свойством text в другом классе будет написано следующее:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

package{
import mx.binding.utils.BindingUtils;

public class MyClass{
//Экземпляр класса со свойством text, за которым нужно следить
private var classWithTextProperty:ClassWithTextProperty = new ClassWithTextProperty();

// Свойство которое будет изменяться при изменении свойства text в экземпляре classWithTextProperty
private var myText:String;

public function MyClass(){
// Та самая строчка, которая позволяет связать свойство myText со свойством text
BindingUtils.bindProperty(this, "myText", classWithTextProperty, "text");
}
}
}

В примере выше используя BindingUtils.bindProperty мы связываем свойство text со свойством myText, и теперь при изменении свойства text в экземпляре classWithTextProperty автоматически будет меняться и значение свойства myText. Здорово, правда?

Кратко расшифрую параметры принимаемые методом

bindProperty(site:Object, prop:String, host:Object, chain:Object, commitOnly:Boolean = false, useWeakReference:Boolean = false):ChangeWatcher

Параметры:

site: объект содержащий свойство для изменения;
prop: свойство для изменения;
host: объект, содержащий свойство за которым необходимо следить;
chain: в самом простом случае содержит строку с именем переменной, за которой нам необходимо следить. Возможны варианты указания цепочек в виде массива.

Есть еще свойство commitOnly на котором я подробно останавливаться в рамках данной статьи не буду и свойство useWeakReference – это то же самое что мягкие ссылки для событий, принцип тот же.

Возвращает данный метод экземпляр класса ChangeWatcher. Иногда сохранять возвращаемый экземпляр бывает очень полезно. Это нужно для того, чтобы мы смогли в любой момент “разбиндить” установленную связь и отписаться от изменений. Для этого у класса ChangeWatcher есть метод unwatch().

Второй вариант установления слежки за свойством text будет вызов нужного нам метода при его изменении.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package{
import mx.binding.utils.BindingUtils;

public class MyClass{
// Свойство со ссылкой на экземпляр класса со свойством text, за которым нужно следить
private var classWithTextProperty:ClassWithTextProperty = new ClassWithTextProperty();

public function MyClass(){
// Та самая строчка, которая позволяет вызвать метод onTextChanged при каждом изменении свойства text
BindingUtils.bindSetter(onTextChanged, classWithTextProperty, "text");
}

private function onTextChanged(value:String):void{
trace("The new text value is: " + value);
}
}
}

В данном примере при каждом изменении свойства text в экземпляре classWithTextProperty, будет вызываться метод onTextChanged где в консоль будет выводиться её новое значение.

Кратко расшифрую параметры принимаемые методом

bindSetter(setter:Function, host:Object, chain:Object, commitOnly:Boolean = false, useWeakReference:Boolean = false):ChangeWatcher

Параметры

setter: метод, вызываемый при изменении указаного свойства или цепочки;
host: объект, содержащий свойство за которым необходимо следить;
chain: в самом простом случае содержит строку с именем переменной, за которой нам необходимо следить. Возможны варианты указания цепочек в виде массива.

Чаще всего используется именно метод bindSetter, он более гибкий и позволяет произвести нужную последовательность действий при изменении того или иного свойства.

Библиотека

А как же собственно использовать всю эту красоту в ваших ActionScript проектах? Есть вариант подключить все флэксовые библиотеки к вашему проекту в которых есть все необходимое для работы биндинга, но это очень скользкий путь, чреватый тем что в один прекрасный момент могут потянуться хвостом куча ненужных вам флэксовых классов, увеличивая размер конечной флэшки до немыслимых размеров. Гораздо надежнее собрать библиотеку из нужных для работы биндинга классов и использовать ее, не боясь что неожиданно потянутся хвосты, что собственно я и сделал. Размер получившейся библиотеки binding.swc получается порядка 15 Кбайт, а это не может не радовать. Таким образом использование биндинга незначительно влияет на объем конечной флэшки. Все что нужно сделать это подключить данную библиотеку к вашему проекту и “Вперед и с песней!”.

Как это работает?

На самом деле ничего уникального в работе флэксового биндинга нет. Выше был описан класс ClassWithTextProperty. Так вот компилятор перед тем как откомпилировать проект преобразует этот класс к следующему виду:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package{
import flash.events.EventDispatcher;
import mx.events.PropertyChangeEvent;

public class ClassWithTextProperty extends EventDispatcher{
private var _text:String;

public function set text(newValue:String) : void{
var oldValue:* = this._text;
if (oldValue !== newValue){
this._text = newValue;
this.dispatchEvent(PropertyChangeEvent.createUpdateEvent(this, "text", oldValue, newValue));
}
}

public function get text() : String{
return this._text;
}
}
}

Посмотрев на код видно что он делает тоже самое, о чем мы говорили вначале – посылает событие в результате изменения свойства text. Посредством BindingUtils мы по сути подписываемся на это событие и в результате либо меняется нужное нам свойство (bindProperty), либо вызывается нужый для обработки метод (bindSetter). Поэтому использование биндинга для разработчика это по сути упрощение рутинных действий по описанию и отлавливанию событий. Для того чтобы отловить изменение нужного нам свойства достаточно добавить две строки (метатег [Bindable] к свойству и BindingUtils.bind… в классе-обработчике) + добавить метод обработки в случае использования bindSetter.

Все должно быть в меру

При использовании биндинга, естественно, это нужно делать разумно и не вешать метатег [Bindable] на все свойства подряд. Важно помнить что в каждом таком случае при изменении этого свойства будет посылаться событие, а это лишняя нагрузка.

Из личного опыта бинднг в чистых ActionScript проектах используется очень часто и практически везде где это необходимо. При грамотном и осторожном его использовании нагрузка на процессор минимальна и незаметна.

Новая книга “ActionScript 3.0. Шаблоны проектирования”

Diestro — Thu, 03 Feb 2011 16:26:57 +0000

В феврале ожидается выход новой книги “ActionScript 3.0. Шаблоны проектирования”. В свое время я читал англоязычный вариант данной книги “ActionScript 3.0 Design Patterns” и почерпнул для себя много нового и полезного. Данная книга будет интересна не только ActionScript разработчикам.

Для тех кто хочет получить очередной профит книга к прочтению будет обязательна!

Ждем с нетерпением.

Новый Flash Builder “Burrito” 2

Diestro — Fri, 01 Oct 2010 06:33:11 +0000

Команда разработчиков Flash Builder продолжает радовать, появилось еще два ролика о новых возможностях “Burito” в плане удобства редактирования кода.
Автокомплит метатегов:

Темплейты кода, называемые также сниппетами:

В каждом видео по прежнему присутствует предупреждение о том что никаких гарантий что это все будет в новой версии нету. Хм.

Новый Flash Builder “Burrito”

Diestro — Wed, 15 Sep 2010 06:40:50 +0000

Появилась информация о том что команда разработчиков Flash Builder работает над новой версией с кодовым названием “Burrito”. Судя по видео, с кодом станет работать намного легче:

Немного смущает в первых кадрах текст о том, что никаких гарантий что все показанные “плюшки ” будут работать в новой версии Flash Builder.

Доступна русскоязычная документация для Flash Builder 4

Diestro — Mon, 22 Mar 2010 11:41:57 +0000

С выпуском релизной версии Flash Builder 4 на сайте Adobe появилась русскоязычная документация по Flash Builder. К сожалению переведено не все, но справочник уже можно использовать.

Релиз Adobe Flash Builder 4

Diestro — Mon, 22 Mar 2010 08:18:20 +0000

Вышел Adobe Flash Builder 4. Уже несколько дней упорно грызу гранит бета-версии. А тут такое счастье привалило. Теперь ждем релиз Adobe Catalyst.

Плагин Sourcemate для Flash Builder 4

Diestro — Sun, 21 Mar 2010 12:27:22 +0000

Отличная новость от Lee Brimelow! Flash Builder 4 еще в бете, а для него уже существует плагин, дополняющий его тем чего нам так не хватало – сниппеты, рефакторинг, генерация геттеров/сеттеров, автокомплит метатегов и др. Именно из-за нехватки подобных вещей многие использовали FDT либо вместо, либо вместе с Flex Builder, что доставляло ряд неудобств.

Новый плагин называется SourceMate. Стоит денег. 30 дней можно пощупать бесплатно. Ставится через Help > Install New Software -> Search for new features to install -> Next -> New remote site -> указываем url: http://updates.elementriver.com/sourcemate/v1 устанавливаем, щупаем.

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