Блог Diestro » ActionScript 3.0

Биндинг в 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.

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

Биндинг в 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 проектах используется очень часто и практически везде где это необходимо. При грамотном и осторожном его использовании нагрузка на процессор минимальна и незаметна.

Знакомство с MVCS фреймворком Robotlegs

Diestro — Sun, 14 Feb 2010 18:28:04 +0000

Впервые об этом фреймворке я услышал на BURAFPUG, прошедшем 6 февраля 2010 г. После некоторого изучения документации я пришел к выводу, что Robotlegs действительно очень интересный фреймворк.

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

Robotlegs это MVCS фремворк реализующий паттерн MVC с добавлением еще одного элемента – Services, использующегося для реализации взаимодействия с «внешним миром», будь то Web-сервисы, файловая система, базы данных, взаимодействие с другими Flash-приложениями через Local Connection и т.п.

Внедрение зависимостей (Dependency Injection)

Современные фреймворки, базирующиеся на паттерне MVC теми или иными способами поддерживают реализацию принципа Inversion of Control (Ioc) или Dependency Injections (DI). Robotlegs также основан на этом принципе.

Для чего нужно использование паттерна Dependency Injection? ООП приложение состоит из классов. Классы могут получать доступ к другим классам имея ссылки на них. Они взаимодействуют друг с другом, используя эти ссылки. Смысл Dependency Injection – уйти от высокой связанности приложения, заменив описание взаимодействия между конкретными классами на интерфейсы. Т.е. класс X будет использовать не класс Y а реализациею его интерфейса I. В результате мы получаем низко связанное приложение, классы которого знают только о интерфейсах для работы с другими классами. Например в приложении для работы с почтой мы будем работать с интерфейсом IMailLoader, вызывая метод load(), а не с конкретной реализацией класса IMAPMailLoader. В этом случае IMAPMailLoader будет легко заменить на POPMailLoader,реализующий интерфейс IMailLoader или на любой другой класс реализующий нужный интерфейс.

В Robotlegs DI реализован с помощью SwiftSuspenders. Это легковесный DI фреймворк для реализации этого паттерна посредством метатегов [Inject].

Работая с Robotlegs с классом наследуемом от Context (о нем я расскажу ниже) мы имеем доступ к переменной injector. Это экземпляр класса, реализующего функционал фреймворка SwiftSuspenders. injector – это менеджер внедряющий нужный экземпляр класса в классы нашего приложения.

Возвращаясь к примеру с почтовым сервисом реализация DI с помощью Robotlegs выглядит следующим образом:

1 2	//Когда запрашивают интерфейс IMailLoader вернуть экземпляр класса IMAPMailLoader injector.mapClass(IMailLoader, IMAPMailLoader);

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

1 2	[Inject] public var mailLoader:IMailLoader;

В результате переменная mailLoader будет содержать экземпляр класса IMAPMailLoader.

Если же мы напишем:

1 2	injector.mapClass(IMailLoader, IMAPMailLoader, "IMAP"); injector.mapClass(IMailLoader, POPMailLoader, "POP");

В нашем классе мы можем задать name, для инстанцирования нужной нам реализации:

1 2	[Inject(name="POP")] public var mailLoader:IMailLoader;

В результате переменная mailLoader будет содержать экземпляр класса POPMailLoader.

Создавая карты с помощью injector можно также внедрять конкретные экземпляры классов (mapValue), классы «одиночки» (mapSingleton) и пр. Подробнее об этом написано в документации Robotlegs.

Немножко разобравшись с реализацией DI в Robotlegs перейдем к реализации MVCS архитектуры.

Контекст

Сердцем фреймворка Robotlegs является класс Context, от которого собственно и наследуется наш главный класс приложения. В этом классе задаются основные связи между компонентами приложения.

Карты команд

С помощью commandMap задается какую команду нужно вызывать при возниковении того или иного события.

1	commandMap.mapEvent(MyEvent.SOME_HAPPENED, MyCoolCommand, MyEvent);

Карты отображения

Так же как и PureMVC в Robotlegs для взаимодействия с view-компонентами используются посредники, называемые медиаторами. View-компоненты и их медиаторы сопоставляются с помощью mediatorMap.

1	mediatorMap.mapView(MyAwesomeWidget, MyAwesomeWidgetMediator);

Интересной особенностью медиаторов является их автоматическое инстанцирование только в случае добавления view-компонента, связанного с этим медиатором, в список отображения,что впрочем можно отключить во время задания правила для mediatorMap. Существует еще и viewMap, о котором в официальной документации не сказано ничего, но насколько я понял он используется для «внедрения» view-компонентов в классах приложения, т.е. является полным аналогом прямого использования injector.

Карты внедрения (иньекций)

Здесь описываем все классы или их экземпляры, которые необходимо «внедрять» в классы нашего приложения посредством использования метатега [Inject]. В частности здесь мы описываем наши классы с данными и сервисами необходимыми для реализации MVCS:

1 2	injector.mapSingleton( ApplicationModel ); injector.mapSingletonOf( IGalleryImageService, GalleryImageService );

Все классы описанные с помощью commandMap и mediatorMap автоматически подготавливаются фреймворком для «внедрения» в классы приложения.
Таким образом в нашем главном классе приложения перед запуском мы конфигурируем все необходимые компоненты и взаимодействия.

События

Для системы событий Robotlegs использует «родные» события Flash-плеера. Для их распространения внутри фреймворка используется следующий синтаксис:

1	dispatch(new ContextEvent(ContextEvent.STARTUP));

Чтобы слушать события используется следующий синтаксис:

1	eventMap.mapListener(dispatcher, ContextEvent.STARTUP, startupHandler);

Либо как уже было сказано выше во время конфигурации приложения можно указать на какое событие должна запускаться та или иная команда:

1	commandMap.mapEvent( ContextEvent.STARTUP, StartupCommand, ContextEvent);

Распространять и слушать события могут далеко не все фигуранты фреймворка. Кратко рассмотрим «Актёров» Robotlegs (MVCS).

Модель и сервисы (M и S)

Я позволю себе объединить описание этих двух составных частей фреймворка в одном месте, так как оба этих компонента должны наследоваться от класса Actor. Для фреймворка не имеет значение модель это или сервисы, это просто «Актер», наделить их функционалом должен уже разработчик.

Для того чтобы иметь доступ к модели или классу сервиса из других классов фреймворка достаточно будет написать [Inject] перед объявлением переменной. Например если класс с данными называется ApplicationModel, то в классе, где необходимо будет его использовать, достаточно написать:

1 2	[Inject] public var myModel:ApplicationModel;

Перед этим, естественно, нужно не забыть его добавить в карту внедрения, как это было указано выше.

Наследники класса Actor могут посылать события приложению используя метод dispatch.

Отображение (V)

Как правило каждый компонент отображения в Robotlegs состоит из двух элементов – cобственно компонента отображения и элемента, являющегося частью фреймворка – медиатора. Медиатор является посредником между компонентом отображения и фреймворком. Его основная задача информировать приложение о действиях пользователя и наоборот – изменять элементы отображения в соответствии с изменениями в приложении.

Медиатор должен наследоваться от класса Mediator. Элемент отображения связанный с медиатором доступен в переменной viewComponent. Медиатор имеет доступ к dispatch() и eventMap, а это значит что он может как распространять так и слушать события внутри приложения.

Для инициализации медиатора крайне не рекомендуется пользоваться конструктором. Для этого существует метод onRegister(), который необходимо переопределить и писать код инициализации в нем.

Для доступа к модели достаточно внедрить класс модели с помощью метатега [Inject] , так как это было описано выше.

Контроллер (С)

Функционал контроллера реализуется в Robotlegs посредством вызова команд. Класс команды должен наследоваться от класса Command. Команда создается только на время выполнения и после выполнения попадает в Garbage Collector. Команда появляется как результат возникновения события. Код, который должен выполнить команда должен быть помещен внутри переопределенного метода execute(). Сопоставления команд событиям происходит в commandMap Контекста приложения. Тот же самый commandMap доступен и внутри любой из комманд.

Доступ к модели организуется так же как и в классах отображения.

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

1 2	[Inject] public var event:MyCustomEvent;

Команда может также посылать события приложению используя метод dispatch.

Кратко резюмируя хотелось бы сказать что реализация Robotlegs действительно очень интересная и заслуживает внимания. В чем то она похожа на PureMVC, об этом же говорит и автор Robotlegs. Однако в Robotlegs иначе организована система событий, не нужно писать switch/case в обработчиках событий, как это реализовано в PureMVC. Достаточно подписаться на нужное событие и назначить метод обработчик, так как мы это привыкли делать со стандартными событиями Flash. По другому организовано и взаимодействие между компонентами приложения. В отличии от PureMVC в Robotlegs для доступа к другим компонентам приложения уже не используются retrieveProxy, retrieveMediator и т.п., а используется метатег [Inject].

Firebug для Flash

Diestro — Fri, 29 Jan 2010 17:16:38 +0000

Поковырявшись сегодня в аддонах для Firefox нашел пару полезных расширений для Firebug, позволяющих упростить жизнь Flash-разработчику.
Само собой для работы каждого из них необходим установленный Firebug.
Итак:

Flashbug
Данное расширение позволяет увидеть все “трейсы” на новой панели “Flash Console” плагина Firebug. Плагин имеет “Policy log”, позволяющий увидеть лог сообщений безопасности Flash-плеера. Для открытого в данный момент ресурса также можно увидеть сохраненные Shared objects. Flashbug так же дает возможность увидеть отсылаемые данные AMF в панели Net (Сеть):

AMF в Firebug

Для своей работы требует debug версии Flash-плеера.
На сайте автора можно подробнее почитать о расширении. Но почему то кажется что активность автора спала и доработку своего детища он отложил в долгий ящик. Будем надеяться на лучшее. Тем не менее это достойная замена FlashTracer’у, которым я пользовался до этого.

FireFlash
Посредством FireFlash Console API позволяет отображать объекты, массивы, XML и другие данные через Firebug console. Очень удобное и мощное средство для дебага и логинга. Позволяет группировать выдаваемые сообщения, есть механизмы запуска и остановки таймера для определения времени работы скрипта. На сайте автора расширения есть подробное описание API, примеры и видео помогающее понять как это работает.

Ложное срабатывание MOUSE_MOVE на Stage в MacOS

Diestro — Thu, 14 Jan 2010 06:26:57 +0000

Эх, где же та самая кроссплатформенность.

Разрабатываю свои проекты я под Windows, поэтому для отлавливания бага, проявляющегося только под MacOS пришлось заимствовать макбук.

Выяснилось что Flash-приложение открытое в любом из браузеров подвисает во время потери фокуса самим браузером (переключение на другое приложение). Причина зависания – в момент потери фокуса приложением, содержащим Flash-контент, на Stage флэшки приходит событие MOUSE_MOVE, содержащее какие-то немыслимые координаты курсора (x:-100500,y:-100500). Соответственно подвешенный на это событие обработчик, занимающийся отрисовкой шлейфа мыши, входил в безумно длинный цикл и Flash-приложение подвисало.

Еще раз повторюсь это происходит только под MacOS, под Windows “ложного” срабатывания MOUSE_MOVE не происходит.

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