Разработчики выделяют как основные особенности редактора:

• дружественный интерфейс разработчика/процесс разработки
• технология CodeSync для генерации кода, реверс-инжиниринг и устранение конфликтов
• поддержка ActionScript и MXML файлов
• поддержка рефакторинга
• поддержка командной работы

и много чего ещё...
Видео, фото редактора.

После закачки можно подсмотреть как правильно установить, а после установки -- как использовать.

Свои пожелания и предложения можете выказывать на этом форуме, а рассказать о найденых ошибках, на этом.

Регистрируйтесь!

А ещё пообещали каждому выдать бету за пост на эту тему с вот таким линком: Realaxy ActionScript Editor. Как оформите пост, отправляйте письмо на ivan.dembicki@gmail.com с сабжем [betatest] и ссылкой на новость.

Мне очень нравится в ActionScript 3 тесная интеграция с XML и популяризация пространств имён. Для поддержки свойств в различных пространствах имён даже создан отдельный класс – QName, объединяющий в себе указатель пространства имён и локальное имя. Но, получается что, для использования пространств имён отличных от базовых(AS3 и с пустым указателем) разработчик должен сам реализовать поддержку этих пространств имён, заранее объявив члены класса.

Динамические члены класса в пользовательских пространствах имён не поддерживаются, кроме XML объектов. Чтоб включить такую поддержку необходимо расширить класс flash.utils.Proxy и самому её реализовать. Это и было сделано в классах описываемых в этом посте – они разрешают добавлять в себя динамические члены класса в любых пространствах имён(кроме flash_proxy, в сочетании с зарезервированными локальными именами, методы которых уже реализованы).

Итак, есть 2 коллекции и 2 обёртки для них в виде классов расширяющих flash.utils.Proxy. Первый класс QNameCollection поддерживает пространства имён в именах динамических свойств, а XMLNameCollection дополнительно поддерживает атрибуты. Следует заметить, что QNameCollection игнорирует указатель атрибута в QName и если попробовать добавить атрибут, он просто добавит свойство под этим именем, при этом значение указателя теряется.

Коллекции используют методы аналогичные методам flash.utils.Proxy для доступа к элементам

• callProperty – вызвать метод с указанным именем
• getProperty – получить значение свойства по имени
• hasProperty – проверить наличие свойства по имени
• deleteProperty – удалить свойство по имени
• setProperty – установить свойство по имени

Все эти методы принимают выборки с не указанными(NULL в QName.uri означает любое пространство имён, а "*" – любое локальное имя) пространством имён или локальным именем.

И дополнительно методы:

• getPropertyList – список имён доступных свойств
• getPropertyNamespaceList – список использованных пространств имён
• forEach – перебор всех свойств объекта. Используется функция обратного вызова, принимает в качестве аргументов значение свойства и имя свойства

В конструкторе обе коллекции принимают атрибут "liveNameList", указывающий на необходимость содержать постоянно обновляемый список имён свойств, который используется для перебора свойств. Если эта опция выключена, то список имён создаётся по необходимости, к примеру, непосредственно перед перебором в цыкле.

А обё обёртки просто позволяют использовать привычный синтаксис

var ns1:Namespace = new Namespace('urn:some-uri-1');
var ns2:Namespace = new Namespace('urn:some-uri-2');
var ns3:Namespace = new Namespace('urn:some-uri-3');
var qNames:QNameDynamicCollection = new QNameDynamicCollection();
qNames.ns1::property1 = 'property1';
qNames.ns1::property2 = 'property2';
qNames.ns2::property1 = 'property3';
qNames.ns2::property2 = 'property4';
qNames.ns3::property1 = 'property5';
qNames.ns3::property2 = 'property6';
trace(qNames.*::*); // property1,property2,property3,property4,property5,property6
trace(qNames.ns2::*); // property3,property4
delete qNames.ns2::*;
trace(qNames.ns2::*.length); // 0
var xmlNames:XMLNameDynamicCollection = new XMLNameDynamicCollection();
xmlNames.@ns1::attribute1 = 'attribute1';
xmlNames.@ns1::attribute2 = 'attribute2';
xmlNames.@ns2::attribute1 = 'attribute3';
xmlNames.@ns2::attribute2 = 'attribute4';
xmlNames.@ns3::attribute1 = 'attribute5';
xmlNames.@ns3::attribute2 = 'attribute6';
xmlNames.ns1::property1 = 'property1';
xmlNames.ns1::property2 = 'property2';
xmlNames.ns2::property1 = 'property3';
xmlNames.ns2::property2 = 'property4';
xmlNames.ns3::property1 = 'property5';
xmlNames.ns3::property2 = 'property6';
trace(xmlNames.*::*); // property1,property2,property3,property4,property5,property6
trace(xmlNames.@*::*); // attribute1,attribute2,attribute3,attribute4,attribute5,attribute6
trace(xmlNames.@ns2::*.length); // 2
delete xmlNames.@*::*;
trace(xmlNames.@*::*.length); // 0

Особенности работы с этими объектами

• сollection.* – любой запрос по выборке возвращает массив, поэтому чтоб узнать наличие свойств в пространстве имён надо использовать свойство Array.length, как и в случае XML узлов – XMLList.length().
• var value:Array = сollection.* – вернёт только свойства находящиеся в базовом пространстве имён, чтоб получить все свойства во всех пространствах имён используйте collection.*::*, collection.@*::* для атрибутов.
• сollection.ns::* = value – не создаст новых свойств, но существующим свойствам присвоит новое значение.
• Второй аргумент в конструкторе обёртки "autoParseStringNames", указывает на возможность автоматической конвертации строк с "::" в экземпляры QName. Я добавил эту опцию из-за глюка в интерфейсе flash.utils.Proxy – если использовать цыкл for..in, то для получения имени свойства используется метод Proxy.nextName, который может вернуть только строку.

Скачать весь пакет одним файлом: QName & XMLName collections (41)

Flex cookbook entry: Accurate Timer class.

Во Flash player’е работа встроенного таймера зависит от проигрывания flash ролика. Такая зависимость приводит к большим погрешностям и не делает поправку при дальнейшем выполнении. Это достаточно известная тема и уже много раз об этом писали.

К примеру, класс приложения для подсчёта погрешностей в ролике с частотой в 24 кадра:

package{
	import flash.display.Sprite;
	import flash.events.TimerEvent;
	import flash.utils.Timer;
	import flash.utils.getTimer;
 
	[SWF(frameRate="24")]
	public class TestTimer extends Sprite{
		protected var _started:int;
		public function TestTimer():void{
			super();
			const timer:Timer = new Timer(1000);
			timer.addEventListener(TimerEvent.TIMER, timerHandler);
			_started = getTimer();
			timer.start();
		}
		protected function timerHandler(event:TimerEvent):void{
			const count:int = (event.target as Timer).currentCount;
			trace(count, (getTimer()-_started-1000*count)*0.001);
		}
	}
}

При выполнении, покажет, что уже до конца минуты таймер пропустит одну итерацию.

27 0.79
28 0.79
29 0.791
30 0.833
31 0.835
32 0.875
33 0.918
34 0.9580000000000001
35 0.966
36 1
37 1.002
38 1.042
39 1.083

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

package{
	import aw.events.AccurateTimerEvent;
	import aw.utils.AccurateTimer;
 
	import flash.display.Sprite;
	import flash.events.TimerEvent;
	import flash.utils.Timer;
	import flash.utils.getTimer;
 
	[SWF(frameRate="24")]
	public class TestTimer extends Sprite{
		protected var _started:int;
		public function TestTimer():void{
			super();
			const timer:Timer = new AccurateTimer(1000);
			timer.addEventListener(TimerEvent.TIMER, timerHandler);
			_started = getTimer();
			timer.start();
		}
		protected function timerHandler(event:AccurateTimerEvent):void{
			const count:int = (event.target as Timer).currentCount;
			trace(count, (getTimer()-_started-1000*count)*0.001);
		}
	}
}

То можно убедиться, что такого нарастающего отставания больше нет. Оно, конечно, осталось, но в самой минимальной величине.

27 0.027
28 0.025
29 0.026000000000000002
30 0.025
31 0.027
32 0.027
33 0.025
34 0.025
35 0.025
36 0.027
37 0.026000000000000002
38 0.025
39 0.027

Класс AccurateTimer расширяет flash.utils.Timer и добавляет в него методы pause()/resume() для останова текущей итерации(я понимаю,что это сомнительный функционал, но надо было идти до конца ) и свойство missedIterations, которое содержит общее количество пропущенных итераций. Так же, с этим классом идёт своё событие AccurateTimerEvent, которое расширяет событие оригинального таймера и добавляет свойство missedIterations, которое содержит количество пропущенных итераций за время завершённой итерации(если она выполнялась в два раза дольше и более).

Скачать aw.utils.AccurateTimer (42)

Через два месяца они сообщили, что закончили работу и можно продолжать дальше. Я не хотел пожалеть ещё раз и промолчал о реализации.
Надо было быстренько подключить плеер сменив загрузчики данных с XML на AMF и быстренько я написал два класса, так чтоб не заморачиваться и не удвоить вес плеера.

ServiceCaller – объект связанный с одним методом на стороне сервера

ServiceCallerSequence – очередь выполняемых ServiceCaller, один за другим

Ничего особенного, использовать так же просто как и писать подобную приблуду. Для этого надо только указать путь к шлюзу для AMF соединения:

ServiceCaller.gatewayURL = 'http://somesite.com/flashservices/gateway.php'; 

Не плохо бы сделать класс в котором хранятся все AMF методы

package aw.projects.******.videoplayer.net{
	public class ServiceMethods extends Object{
		static public const GET_FULL_CONTENT:String = 'GetContent.get_full_content';
		static public const GET_VIDEO_URL:String = 'GetSettings.get_video_url';
 …
	}
} 

Пример использования ServiceCaller:

var caller:ServiceCaller = new ServiceCaller(ServiceMethods.GET_STATUS, this.getStatusSuccessHandler, this.getStatusErrorHandler);
caller.call(this._statusCode);
…
protected function getStatusSuccessHandler(status:Object):void{
	…
}

В конструкторе принимает имя удалённого метода(процедуры, если хотите) и ссылки на функции обратного вызова для вернувшегося результата и для ошибки. В метод ServiceCaller.call() передаются аргументы для удалённого метода.

Пример использования ServiceCallerSequence:

protected function loadData():void{
	var sequence:ServiceCallerSequence = new ServiceCallerSequence();
	sequence.call(ServiceMethods.GET_VIDEO_URL, this.setURLTemplatesSuccessHandler, this.setURLTemplatesErrorHandler);
	sequence.call(ServiceMethods.GET_CODE_URL, this.getCodeURLSuccessHandler, this.getCodeURLErrorHandler);
	sequence.call(ServiceMethods.GET_HTML_CODE, this.getHTMLCodeSuccessHandler, this.getHTMLCodeErrorHandler);
	sequence.call(ServiceMethods.GET_FULL_CONTENT, this.getFullContentSuccessHandler, this.getFullContentErrorHandler);
}

В метод ServiceCallerSequence.call() передаётся всё сразу – имя удалённого метода, ссылки на методы обратного вызова и аргументы для удалённого метода. Обработка запросов начинается сразу.

• Unfuddle – 200 Мб SVN & Git, 2 пользователя, своя система трекинга (напоминает Basecamp)
• Codesion – 200 Мб SVN & CVS, 1 пользователь, Trac & Bugzilla
• XP-dev – 200 Мб SVN, неограничено пользователей, Trac и текстовая реклама от Google
• ProjectLocker – 500 Мб SVN & Git, 5 пользователей, Trac и туча рекламы
• EZ subversion – 200 Мб SVN, 1 пользователь
• Slik subversion – 100 Мб SVN, 1 пользователь, Trac
• Beanstalk – 100 Мб SVN, 3 пользователя бесплатный аккаунт спрятан в ссылке под списком тарифных планов
• myVersionControl – 100 Мб SVN, 3 пользователя, Trac

Отсортировал по ИМХО, но пользовался только четырьмя из всех, поэтому они идут первыми в списке.

Ещё нашёл список тарифов SVN хостингов с возможностью фильтрации.

В общем, как-то в поисках истины я написал маленький классик для быстрого доступа к этому объекту:

package aw.utils{
	public class Global extends Object{
		static public function get instance():Object{
			if(!_instance) getInstance();
			return _instance;
		}
		static private var _instance:Object;
		static protected function getInstance():void{
			_instance = (function():Object{return this}).call(null);
		}
	}
}

Если воспользоваться им и протрейсить объект находящийся в Global.instance, то получите вот такой трейс:

[object global]

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

З.Ы.: С первым апреля!

UAFPUG

BAFPUG

RAFPUG Chat, как мне сказали, канул в лету. Если вы знаете ещё какой-нибудь полезный flash/flex/air чат, оставьте ссылку в комментариях, я добавлю к посту.
Кстати, ярлыки на рабочем столе всегда срабатывают(при наличии корректно установленного Skype приложения).
Flash Platform Skype Chats (116)

<?xml version="1.0" encoding="utf-8"?>
<s:Window minimizable="false" maximizable="false" resizable="false" showStatusBar="false" type="{NativeWindowType.UTILITY}"
		  xmlns:fx="http://ns.adobe.com/mxml/2009"
		  xmlns:s="library://ns.adobe.com/flex/spark"
		  xmlns:mx="library://ns.adobe.com/flex/halo"
		  preinitialize="preinitializeHandler(event)">
	<fx:Script>
		<![CDATA[
			import flash.display.NativeWindow;
			import flash.events.Event;
 
			protected function preinitializeHandler(event:Event):void{
				var windows:Array = NativeApplication.nativeApplication.openedWindows;
				for each(var window:NativeWindow in windows){
					if(window===this.nativeWindow) continue;
					window.addEventListener(Event.ACTIVATE, this.applicationWindowActivateHandler);
					window.addEventListener(Event.CLOSE, this.applicationWindowCloseHandler);
				}
				this.addEventListener(Event.CLOSE, this.windowCloseHandler);
				this.applicationWindowActivateHandler(null);
			}
			protected function applicationWindowActivateHandler(event:Event):void{
				this.orderToFront();
				this.activate();
				this.setFocus();
				this.nativeWindow.notifyUser(NotificationType.INFORMATIONAL);
			}
			protected function applicationWindowCloseHandler(event:Event):void{
				var window:NativeWindow = event.target as NativeWindow;
				window.removeEventListener(Event.ACTIVATE, this.applicationWindowActivateHandler);
				window.removeEventListener(Event.CLOSE, this.applicationWindowCloseHandler);
			}
			protected function windowCloseHandler(event:Event):void{
				var windows:Array = NativeApplication.nativeApplication.openedWindows;
				for each(var window:NativeWindow in windows){
					window.removeEventListener(Event.ACTIVATE, this.applicationWindowActivateHandler);
					window.removeEventListener(Event.CLOSE, this.applicationWindowCloseHandler);
				}
				this.nativeWindow.removeEventListener(Event.CLOSE, this.applicationWindowCloseHandler);
			}
		]]>
	</fx:Script>
	<fx:Declarations>
		<!-- Place non-visual elements (e.g., services, value objects) here -->
	</fx:Declarations>
</s:Window>

Как видите, всё очень просто и можно догадаться, что будут проблемы, если открыть не одно модальное окно. Но нужно было одно одновременно открытое окно и если понадобиться больше, будет пост.
Если у вас есть готовые решения, не только для Flex, кидайте ссылки в комментарии.

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

Суть работы в том, что аниматор по завершении работы оставляет специальные метки в качестве меток кадров.

Эти метки привязываются к заготовке и экспортируются со всем остальным содержимым в SWF/SWC файл. Когда программист получает экземпляр заготовки, он должен передать её в метод ModifierManager.apply(). При этом ModifierManager проводит поиск меток в кадрах и если находит необходимые метки, то заменяет код кадра на код, заранее подготовленного, модификатора. Код вставляется с помощью метода MovieClip.addFrameScript() в кадр с меткой, указателем на модификатор. Отдельно надо заметить, что в код кадра анимации попадает только описанный вами код, без дополнительных надстроек, поэтому анимация должна играть так же, как если бы вставили этот код прямо в кадр во Flash IDE.

Модификатор, это класс реализующий интерфейс IAssetModifier, способный возвращать экземпляр Function – эта функция и будет выполнять роль кода в кадре.

package aw.projects.assetmodifier.modifiers{
	import flash.display.MovieClip;
 
	/**
	 * @author Galaburda a_[w] Oleg
	 */
	public class AssetStopModifier extends Object implements IAssetModifier{
		static public const LABEL:String = 'stop';
		public function AssetStopModifier():void{
			super();
		}
		public function get label():String{
			return LABEL;
		}
		public function getHandler(clip:MovieClip, rawParametersString:String=''):Function{
			var handler:Function = function():void{
				arguments.callee.target.stop();
			};
			(handler as Object).target = clip;
			return handler;
		}
	}
}

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

• registerModifier(modifier:IAssetModifier):void – регистрирует экземпляр модификатора многоразового использования
• registerModifierByDefinition(label:String, definition:Class):void – регистрирует класс модификаторов, в таком случае для каждого кадра будет
  создаваться свой экземпляр модификатора

var manager:ModifierManager = new ModifierManager();
manager.registerModifier(new AssetStopModifier());
manager.registerModifier(new ExampleInstanceModifier());
manager.registerModifierByDefinition(ExampleDefinitionModifier.LABEL, ExampleDefinitionModifier);

Можно создавать экземпляры менеджера или использовать одноимённые статические методы, как вариант глобального менеджера. Каждый менеджер содержит в себе идентификатор меток, которые он обрабатывает – это символ предваряющий каждую метку. Глобальный менеджер или любой другой по-умолчанию используют символ точки в качестве идентификатора. Получается, что если модификатор регистрируется с меткой "label", то, с идентификатором по-умолчанию, использоваться она должна как ".label".

Ещё метка может нести с собой некоторые данные, заключённые в круглые скобки -- .label(raw parameters). Такие данные не обрабатываются и передаются в модификатор "как есть". Но в комплект поставки входит класс ModifierParserUtils, который способен обработать

• список аргументов в виде списка значений: .label("value1", "value2", "value3", true, 123). В таком случае будет возвращён массив
• список параметров в виде списка именованных значений: .label(parameter1="value1", parameter2="value2", parameter3="value3", parameterBool=true, parameterInt=123). В таком случае будет возвращён экземпляр класса Object со значениями в одноимённых параметрах этого объекта

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

• AssetBrakepointModifier – устанавливает брейкпоинт на кадр
• AssetCustomModifier – вызывает функцию полученную конструкторе(AssetCustomModifier.handler), не имеет метки по-умолчанию
• AssetEventModifier – вызывает событие
• AssetGotoModifier – производит переход, аналог gotoAndPlay/gotoAndStop
• AssetMultiModifier – контейнер для нескольких модификаторов, можно группировать модификаторы для вызова их в одном кадре. Не имеет метки по-умолчанию
• AssetStopModifier – останавливает воспроизведение анимации, stop
• AssetTraceModifier – выдаёт сообщение в консоль, trace

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

Так же, в проекте присутствуют конструкторы:

• AssetConstructor – обслуживает один экземпляр шаблона анимации
• MultiAssetConstructor – абстрактный класс для обслуживания группы шаблонов анимации

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

var constructor:AssetConstructor = new AssetConstructor(ASSET_DEFINITION);
asset = constructor.getAsset();
this.addChild(asset);

Как вам известно, при внедрении конкретных символов с помощью мета-тега [Embed]:[Embed(source="asset.swf", symbol="Asset")], весь код находившийся в кадрах или ещё где-либо теряется. Этот проект создавался изначально чтоб решить эту проблему, т.к. метки кадров остаются и их можно использовать, чтоб идентифицировать кадры в которых должен быть определённый код.

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

Скачать исходный код проекта Asset Modifier (61)

Пример консоли, можете попробовать в действии.

Использование сводится к вызову статического метода aw.utils.EvalUtils.evaluate(), которому в качестве обязательного аргумента надо передать строку для обработки, далее могут следовать два не обязательных аргумента – объект определяющий область видимости в которой должен выполняться код и объект итерации, в котором можно указать позицию с которой надо начинать обработку.

Этот парсер создавался для работы с ActionScript 3 командами и вот, что он может делать:

• "понимает" пространства имён, при условии, что необходимый объект Namespace лежит в области видимости

var scope:Object = {ns:new Namespace(""), parameter:"some value"};
trace(EvalUtils.evaluate('this.ns:parameter', scope)); // some value

• распознаёт и обрабатывает регулярные выражения и XML данные

trace(EvalUtils.evaluate('" s o m e   v a l u e ".match(/\\s+/g).length')); // 10
var data:XMLList = EvalUtils.evaluate('<root><data><![CDATA[Hello world!]]></data></root>.data.text()');
trace(data); // Hello world!

• обрабатывает бычные массивы и объекты, описанные литералами. Возможно использовать кавычки в случае, если имя свойства объекта содержит "не стандартные" символы

var data:Object = EvalUtils.evaluate('{list:[{name:"Oleg",  lastname:"Galaburda"}, {"super/monster<s>\\"-\\"name":"Hulk", lastname:"Hulk"}], xml:<root/>, regexp:/^\s*/, currentDate:new Date()}');
trace(data.list); // [object Object],[object Object]
for(var name:String in data.list[1]) trace(name); // super/monster<s>"-"name, lastname
trace((data.xml as XML).toXMLString()); // <root/>
trace((data.regexp as RegExp).source); // ^s*
trace((data.currentDate as Date).toDateString()); // Tue Feb 16 2010

• способен создавать экземпляры объектов, при условии что использовалось полное имя класса - package.ClassName

var sprite:Sprite = EvalUtils.evaluate('new flash.display.Sprite()');
trace(EvalUtils.evaluate('this.addChild(new flash.display.Shape())', sprite)); // [object Shape]
this.addChild(sprite);

Что он не может делать:

• Использовать логические конструкции switch, if-else, ?:
• Использовать любые цыклы
• Обрабатывать больше одного выражения, правда, может обработать вложенные выражения
• Создавать функции, методы; объявлять классы, интерфейсы и прочее

Основная цель этого проекта, это встраивание в другие проекты. Использовал его в GUIBuilder.org, JSInterface, Asset Modifier. Плюс в том, что он весит в несколько раз меньше и работает достаточно быстро.

Скачать aw.utils.EvalUtils (60)

Если нужно что-то мощнее, можете посмотреть вот эти проекты:

The D.eval API
As3 Eval
as3scriptinglib

Если вызывать метод напрямую то происходит операция call property и метод вызывается, мы получаем ожидаемый результат и всё хорошо.

var xml:XML = <root/>;
trace(xml.toXMLString());// <root/>

Если попытаться получить ссылку на метод, то происходит get property, которая возвращает не ссылку на метод, а экземпляр XLList и, скорее всего, пустой.

var xml:XML = <root/>;
trace(getQualifiedClassName(xml.toXMLString)); // XMLList

Если вызывать метод через динамическое имя, то сначала происходит get property, а потом виртуальная машина получает указание вызвать экземпляр XMLList, на что получаем законный экземляр Error’а.

var xml:XML = <root/>;
trace(xml['toXMLString']());

TypeError: Error #1006: value is not a function.

Если нужна ссылка на метод, то его можно достать через прототип XML.prototype.

var xml:XML = <root/>;
var method:Function = XML.prototype.toXMLString;
trace(method.apply(xml, [])); // <root/>

Или, как подсказали в комментарии, через встроенное пространство имён AS3:

var xml:XML = <root/>;
var method:Function = xml.AS3::toXMLString;
trace(method.apply(xml, [])); // <root/>

В общем, в подобных случаях надо предусматривать отдельный алгоритм работы с объектами XML(и экземплярами недобросовестно описанных детей класса flash.utils.Proxy), либо вызывать методы напрямую.

P.S.: Группа модерируется, поэтому спама не будет, но могут быть задержки с сообщениями, если я в offline.

• Полностью скинуемый плеер
• Обмен данными внутри плеера
• Устройство элементов скина
• Настройки плеера через XML
• Общее построение модели
• Защита от декомпиляции и демо режим

Перед началом работ было получено краткое указание:

Описание плеера для проекта "******"
Плеер состоит из трех функциональных частей, переключающихся по принципу "аккордиона":
- караоке плеер
              - прокрутка текста (простой XML с текстом и таймлайнами)
              - проигрывание фонограммы (mp3, возможно стриминг с Red5)
              - запись видео с вебкамеры или звука с микрофона (тут надо как-то
              накладывать голос на фанеру)
              - настройки камеры, микрофона, возможно что-то еще будет
              - полноэкранный режим (с небольшими изменениями оформления)
              - возможность использования разных типов фона: картинки, слайдшоу, видео, векторные шаблоны (в дальнейшем)
- видео плеер - проигрывание записанного ролика. Если записанного ролика нет, эта вкладка не появляется
              - проигрывание видео
- стандартное управление, но без фулскрина
              - код вставки
- голосовалка
- загрузка файла
- прогресс-бар

В обсуждении проявились технические детали:

1. Полностью скинуемый плеер
2. Резиновый интерфейс
3. Полный доступ к настройкам без перекомпиляции приложения

Заказчик согласился и я приступил к работе определив для себя дополнительный пункт – в демо придётся показывать полноценный плеер, надо будет ограничить в возможностях свою работу до оплаты и поскольку не было ни слова сказано по поводу исходников, по умолчанию исходники остаются мне, а значит надо защитить плеер от декомпиляции. Дизайнер вспомнил о анимации интерфейса(движение аккордеона и прочие плюшки) уже на стадии тестирования, поэтому я предложил её делать за дополнительные деньги. Вообще, очень мучительно проходила работа над плеером, потому что дополнения появлялись по мере тестирования плеера(когда заказчик увидел где-то и говорит хочу такое же) и иногда приходилось многое менять, поэтому разработка очень затянулась.

Полностью скинуемый плеер

Для начала работ мне предоставили вот такое изображение

На много позже появился дизайн во FLA файле, который пришлось пересобирать под свои нужды – все символы сгруппировать, расставить и задать классы. Из иллюстрации видно, что весь скин разделён на три части, на три скрина – для записи, для воспроизведения записанного и для загрузки неких файлов. Цель третьего скрина мне не была понятна, даже не смотря на объяснения, я её реализовал, но она до сих под отключена и по моему о ней забыли. В общем, не долго думая, я разделил весь дизайн на контейнеры – скрины, которые назвал соответственно Record Screen, Play Screen, Upload Screen. Сразу было решено что надо отделить основное приложение – модель от скина/вида и загружать скин перед стартом приложения, таким образом получаем скинуемое приложение без необходимости в изменениях в основном приложении, а точнее – заказчик не имеет доступа к исходному коду приложения и за разработчиком остаётся поддержка.

Вот, получившиеся, в итоге, скрины приложения:

Проигрывание записи

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

Запись песни

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

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

Загрузка файлов

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

Основной принцип работы

Я сразу решил отделить классы приложения на два лагеря – одни идут с моделью, а другие с видом. Классы которые были связаны с моделью получили стандартный пакет aw.projects.project_name.*, а классы скина/вида обосновались в "локальном" пакете проекта skin.*. Классы вида в основном были привязаны к символам во FLA файле и весь скин компилировался в отдельный SWF файл, который потом надо было загружать.

Модель была построена таким образом, что главный класс Model, загружал XML настройки, потом инициализировал модель и под конец загружал скин. В модели было реализовано по медиатору на каждый скрин вида – Record Screen, Play Screen, Upload Screen. Эти три класса получали в конструкторе экземпляр IEventDispatcher(в нашем случае экземпляр Stage) и объект настроек, полученный из загруженного XML файла. Все три подписываются на определённые события от скина и отправляют события к скину.

После загрузки скина, он проходит инициализацию контролов вглубь дерева DisplayObject'ов. Каждый элемент скина при создании подписывается на событие Event.ADDED_TO_STAGE и, когда оно происходит, инициализирует себя. После полной инициализации скина, которая происходит лавинообразно в один кадр, скин считается готовым к приёму событий, он отправляет первое событие SkinEvents.RESIZE_SKIN.

Благодаря тому, что все события вещаются через Stage, элементы управления могут располагаться где угодно и быть какими угодно, главное, это перенести события и их типы из скина в скин.

Обмен данными внутри плеера

Обмен данными между скином и моделью я возложил на стандартные события, которые вещал через самый доступный объект в среде DisplayObject’ов – Stage, доступный через свойство DisplayObject.stage. Этот объект передавался в модель как экземпляр IEventDispatcher и через него вещались события в обе стороны – Observer/контроллер, если хотите.

Возникла небольшая проблема – необходимо передавать сообщения между разными приложениями, хоть и загруженными одно в другое, от этого конфликт в классах. Событие хоть и называется одинаково aw.projects.project_name.events.SomeEvent, но в каждом приложении свой класс, соответственно разные классы и разные типы, отсюда ошибка. Но я не долго мучался, поскольку у обоих flash'ек хозяин один(в смысле, не будет сторонних скинов и можно не ждать подвоха от "скинодела"), значил я могу позволить себе грузить скин в тот же ApplicationDomain, в котором находится основное приложение. В такой способ конфликт с классами рассасывается сам по себе, т.к. они становятся общими.

Следующей проблемой оказалось спрятать классы из модели(контроллеры какие-нибудь, к которым я разрешал доступ) таким образом, чтоб они не компилировались вместе со скином и чтоб не было необходимости делится их исходниками, даже в SWC виде. Для этого я использовал интерфейсы, т.е. в скине и в событиях везде фигурируют интерфейсы, таким образом реальные классы оказались "за бортом". Зато остались события, классы всех событий использованных в скине были переданы вместе с классами самого скина заказчику.

Сами типы(Event.type) события были двух видов – SET и CHANGE события. Первое испускается моделью для скина и указывается элементам скина, что нужно "по тихому" перейти в определённое состояние, а CHANGE событие в основном служит оповещением о действиях пользователя для модели, через них модель получает ценные указания от скина.

Все такие типы событий хранятся в отдельных классах, а не в классах событий. Это связано с тем, что типы были созданы конкретно под данное приложение, а сами классы событий абстрактны(ValueEvent, ListEvent, CheckboxEvent, StreamEvent) и могут быть использованы где угодно. Вот, пример такого класса со списком типов событий:

package skin.record{
 
   public class RecordScreenEvents extends Object{
      static public const RECORD_ALLOWED:String = "RecordScreen(recordAllowed)";
      static public const RECORD_DISALLOWED:String = "RecordScreen(recordDisallowed)";
      static public const INVALIDATE:String = "RecordScreen(invalidate)";
      static public const PLAY:String = "RecordScreen(play)";
      static public const PAUSE:String = "RecordScreen(pause)";
      static public const STOP:String = "RecordScreen(stop)";
      static public const RECORD:String = "RecordScreen(record)";
      ...
      static public const PLAY_PROGRESS_SET:String = "RecordScreen(playProgressSet)";
      static public const PLAY_PROGRESS_CHANGE:String = "RecordScreen(playProgressChange)";
      static public const LOAD_PROGRESS_SET:String = "RecordScreen(loadProgressSet)";
      static public const MICROPHONE_SET_LEVEL:String = 'RecordScreen(microphoneLevelSet)';
      static public const MICROPHONE_CHANGE_LEVEL:String = 'RecordScreen(microphoneLevelChange)';
      static public const VOLUME_SET:String = 'RecordScreen(volumeSet)';
      static public const VOLUME_CHANGE:String = 'RecordScreen(volumeChange)';
      static public const MICROPHONELIST_SET_DEVICE:String = 'RecordScreen(microphoneListSet)';
      static public const MICROPHONELIST_CHANGE_DEVICE:String = 'RecordScreen(microphoneListChange)';
      static public const TEXT_SET_TYPE:String = 'RecordScreen(textSetType)';
      static public const TEXT_CHANGE_TYPE:String = 'RecordScreen(textChangeType)';
      static public const VOCAL_SET_VALUE:String = 'RecordScreen(vocalSet)';
      static public const VOCAL_CHANGE_VALUE:String = 'RecordScreen(vocalChange)';
      static public const CAMERALIST_SET_DEVICE:String = 'RecordScreen(cameraListSet)';
      static public const CAMERALIST_CHANGE_DEVICE:String = 'RecordScreen(cameraListChange)';
      static public const CAMERA_SET_VALUE:String = 'RecordScreen(cameraSet)';
      static public const CAMERA_CHANGE_VALUE:String = 'RecordScreen(cameraChange)';
      ...
 

Как видите, в значении типа чётко обозначена принадлежность к скрину, т.к. события между ними могут быть одинаковыми(PLAY, PAUSE, STOP). А сам класс расположен в локальном пакете, а это означает что он кроме этого приложения больше нигде использован не будет. Позже это вызывало некоторые неудобства, но если немного поработать с такой записью, быстро привыкаешь, главное, это адекватные имена констант.

Позже появилось специальное событие RequestEvent, оно содержит в себе ссылку на URLLoader и URLRequest, которые должны выполниться сразу после этого события. Оно возникает всякий раз, когда модель должна отправить запрос на сервер, а это событие способ провести ревизию запроса или подписаться на события загрузчика, т.к. модель изменять, у заказчика и его разработчиков, способа не было я организовал такой способ влияния на запросы.

Устройство элементов скина

Все элементы скина имеют компонентную основу и строятся от простого к сложному, т.е. в проекте реализованы базовые классы, такие как Asset и SkinItem, которые являются прародителями всё и вся.

Asset, это подвижный элемент скина, он должен реагировать на изменения размеров области Flash player’а, а SkinItem заранее предрасположен слушать SET и вещать CHANGE события. К примеру, наследником Asset’а является контрольная панель с кнопками, а сами кнопки – SkinItem. Каждый скрин сам по себе является Asset'ом, но поскольку является аксиомой то, что для него координаты X/Y всегда равны нулю и он никогда не масштабируется, я смело использовал Asset’ы и внутри самих скринов. SkinItem предоставляет возможность задавать SET/CHANGE события для наследующего компонента.

Визуальные элементы которые не попали в скин

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

Такие визуальные объекты хоть и находятся выше всех UI элементов в иерерхии визуальных объектов, должны занимать только определённую область в плеере, к примеру, в PlayScreen, текст может по вертикали занять место от верхних Title Bar'ов до нижнего Control Bar'а. Указанием размеров этим компонентам занимется активный скрин(это либо Play Screen, либо Record Screen) – он должен отправить событие *ScreenEvents.INVALIDATE.

package skin.player{
   import aw.projects.project.events.InvalidateScreenEvent;
   import aw.projects.project.events.ScreenEvent;
 
   import flash.geom.Rectangle;
   ...
   public class PlayerScreen extends Asset{
      public var playScreenButton:ActiveEditableTitleBar;
      public var startPanel:PlayStartInfo;
      ...
      public function PlayerScreen():void{
         super();
      }
      ...
      override public function resize(width:Number, height:Number):void{
         super.resize(width, height);
         ...
         var bounds:Rectangle = this.getScreenBounds();
         this.startPanel.x = bounds.x+(bounds.width-this.startPanel.width)/2;
         this.startPanel.y = bounds.y+(bounds.height-this.startPanel.height)/2;
         this._stage.dispatchEvent(new InvalidateScreenEvent(PlayScreenEvents.INVALIDATE, bounds));
      }
      public function getScreenBounds():Rectangle{
         var y:int = this.playScreenButton.y+this.playScreenButton.height;
         return new Rectangle(0, y, this.playScreenButton.width, this.settingsTabs.y-y);
      }
      ...

Зрительные образы сопровождающие фонограмму

В обычных караоке плеерах есть визуальный ряд, проигрываемый во время воспроизведения фонограммы, для данного плеера это могло быть видео, ряд изображений или изображение с камеры, при записи фонограммы с видео. Я давно мечтал привести к общему виду подобные медиа-объекты в системе, которая позволяла бы одинаково просто использовать любые графические данные. И создал систему медиа-скринов, все они был переведены к общим интерфейсам(IScreen, IMediaScreen, IVideoScreen). Начало для этой системы было положено намного ранее, в этом проекте был неплохой тест драйв и в следующем проекте(Flog.com, но об этом в одном из следующих постов) я окончательно отшлифовал эту систему.

Последовательность отображаемых медиа-ресурсов можно задавать через конфигурационный XML, там же можно указать настройки эффекта затухания(продолжительность, к примеру), и для изображений время отображения(для видео тоже можно, но если не задано, то будет оно сменено когда завершится проигрывание). Каждый медиа-скрин имеет свой фон и соответственно, его настройки цвета и прозрачности, все они получают указатели на источник данных, приведённые к общему виду – MediaAddress.

Текст песни

Всегда было интересно как можно реализовать подобный функционал, а у меня была задача создать его так чтоб все настройки можно было вывести в XML при поддержке embed fonts. Было проверено несколько разных реализаций и самой устойчивой и скоростной оказалось простое наложение одного текстового поля на другое. Накладываемое поле получало значение autoSize TextFieldAutoSize.NONE, потому что была необходимость изменять его размер по мере проигрывания текста, а нижнее поле – TextFieldAutoSize.LEFT, чтоб иметь полный размер текста. Сразу был заметен визуальный артефакт, по краям уже закрашенного текста выступали пиксели от нижнего текстового поля, решилось всё наложением фильтра GlowFilter в один пиксель, заодно края текста сгладились при полноэкранном просмотре.

Иерархия визуальных объектов в точности повторяет конфигурационный XML, в котором описан текст и тайминги.

• TextManager
  • Couplet – отображает куплет
    • Line – отображает строчку текста
      • Passage – отображал конкрентый слог, текст который описывает, но в последствии остался пустой единицей.

Passage, как атом данной структуры, управляет только сам собой, изменяя своё состояние по ENTER_FRAME событию. Остальные объекты структуры работают с очередями. Все эти объекты наследуются от TextContainer, а тот, в свою очередь – от TimeDepend/ITimeDepend, а очереди ещё и от TimeManager/ITimeManager. Все эти объекты являются наследниками от DisplayObject и все, кроме Passage содержат в себе визуальные объекты. В первых версиях Passage содержал в себе текстовые поля, которые он описывал, но оказалось что визуально это добавляло расстояния между слогами, поэтому Passage были переведены в более виртуальное состояние, а объекты Line взяли на себя нагрузку по отображению текста. Каждый объект всей структуры испускает события оповещающие о изменении его состояния, это позволяет очереди оперировать своими внутренними объектами.

Дополнительно к этим объектам был создан интерфейс IXMLTextParser и по нему реализован общий парсер XMLKaraokeChannelParser(название от сайта с которого, мне сказали, будет формат текста фонограммы), который воссоздавал всю иерархию по данным из XML. Так же интерфейс ITextStyle, которые реализованы в объектах TextStyle и TextLayout и передавались от родительского к дочернему объекту. И последний, о котором хотел рассказать, интерфейс ITextLayout, который передаётся в TextManager для построения текста. Мною было реализовано два вида построения:

• TextLayoutSimple – простая смена куплетов, когда данный куплет проигрался, он сменяется следующим.
• TextLayoutFadeLine – смена строк куплетов, когда проигралась строка, она исчезает, а вместо неё появляется строка из следующего куплета.

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

Дополнительно в XML можно задать фильтры которые будут использованы для отображения текста, преобразователь XML -> BitmapFilter был взят из моей давней разработки GUIBuilder.org.

Резиновый интерфейс

С этим мне помог справиться набор правил/аксиом для скина, которые я вывел до создания кодовой базы:

• Весь скин поделён на три функциональные части, не зависимые друг от друга, но разделяющие интересы, такие как громкость или кнопки-ссылки на другие скрины.
• Каждая тематическая единица должна служить контейнером для управляемых ею символов.
• Все скрины всегда имеют нулевую позицию относительно левого верхнего угла и всегда занимают 100% всей области Flash player’а.
• В интерфейсе нет удаляемых элементов, за редким исключением, соответственно можно все интерактивные элементы подписывать на события без отписки(но я не использую weak reference для событий, поэтому создавать методы отписки от событий уже привычка).

Из всех этих рассуждений я вывел базовый класс для основных контейнеров интерфейса:

package skin{
   import flash.display.Sprite;
   import flash.display.Stage;
   import flash.events.Event;
 
   public class Asset extends Sprite{
      protected var _stage:Stage;
      protected var _width:Number;
      protected var _height:Number;
      public function Asset():void{
         super();
         _width = super.width;
         _height = super.height;
         this.addEventListener(Event.ADDED_TO_STAGE, this.addedToStageHandler);
         this.addEventListener(Event.REMOVED_FROM_STAGE, this.removedFromStageHandler);
      }
      override public function set width(value:Number):void{
         this._width = value;
         this.resize(this._width, this._height);
      }
      override public function set height(value:Number):void{
         this._height = value;
         this.resize(this._width, this._height);
      }
      private function addedToStageHandler(event:Event):void{
         this._stage = this.stage;
         this._stage.addEventListener(Event.RESIZE, this.resizeHandler);
         this._stage.addEventListener(SkinEvents.RESIZE_SKIN, this.resizeSkinHandler);
         this.initialize();
      }
      protected function initialize():void{
         this.resize(this._stage.stageWidth, this._stage.stageHeight);
      }
      private function removedFromStageHandler(event:Event):void{
         this._stage.removeEventListener(Event.RESIZE, this.resizeHandler);
         this._stage.removeEventListener(SkinEvents.RESIZE_SKIN, this.resizeSkinHandler);
      }
      private function resizeHandler(event:Event):void{
         this.resize(this._stage.stageWidth, this._stage.stageHeight);
      }
      private function resizeSkinHandler(event:Event):void{
         this.resize(this._width, this._height);
      }
      public function resize(width:Number, height:Number):void{
         this._width = width;
         this._height = height;
      }
   }
}

Как видите, он не имеет системы валидации новых значений, т.к. его назначением было "передать дальше". Предполагалось что такой контейнер не может быть сложным объектом, соответственно незачем делать валидацию и откладывание применения значений. А более сложные элементы скина, вроде интерактивных списков уже включают системы валидации и откладывают расчёты визуальной части на событие ENTER_FRAME. Такие контейнеры абсолютно автономны и слушают только глобальное изменение размеров изменяя позицию и размеры вверенных им элементов пользовательского интерфейса. В общем, для такого маленького проекта подобные принципы построения интерфейса очень даже оправданы, а для более сложных, просто "не прокатят"(позже, явно потребуется усложнить интерфейс и это может оказаться не большой, но проблемой, при таком подходе).

Вот пример наследника Asset'а:

package skin{
   import flash.display.DisplayObjectContainer;
   import flash.display.Graphics;
   import flash.display.Sprite;
   import flash.events.Event;
 
   [Event(name="open",type="flash.events.Event")]
   [Event(name="close",type="flash.events.Event")]
   public class AbstractAlert extends Asset{
     static public var container:DisplayObjectContainer;
     static private var _instance:AbstractAlert;
     protected var _locker:Sprite = new Sprite();
     public function AbstractAlert():void{
       super();
       if(_instance) hide();
       _instance = this;
     }
     override protected function initialize():void{
       super.initialize();
       this.addChildAt(this._locker, 0);
       this.dispatchEvent(new Event(Event.OPEN));
     }
     override public function resize(width:Number, height:Number):void{
       this.clearLocker();
       super.resize(width, height);
       this.x = int((width-this.width)/2);
       this.y = int((height-this.height)/2);
       this.drawLocker();
     }
     protected function clearLocker():void{
       this._locker.x = 0;
       this._locker.y = 0;
       this._locker.graphics.clear();
     }
     protected function drawLocker():void{
       var g:Graphics = this._locker.graphics;
       g.clear();
       this._locker.x = -this.x;
       this._locker.y = -this.y;
       g.beginFill(0, 0.4);
       g.drawRect(0, 0, this._width, this._height);
       g.endFill();
     }
     static public function hide():void{
       if(!_instance) return;
       if(_instance.parent){
      _instance.dispatchEvent(new Event(Event.CLOSE));
      _instance.parent.removeChild(_instance);
       }
       _instance = null;
     }
   }
}

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

Итоги о визуальной части

В итоге о визуальной части(о скине), хотел бы сказать что не понравилось больше всего. Во Flash CS4 появилась замечательная возможность создавать символы с другими внутри наследуясь от спрайта(В CS3 этого нельзя было делать, просил наследовать от MovieClip’а). Для меня этот проект оказался замечательным способом опробовать Flash CS4 с новыми возможностями. Но я напоролся на одну очень не приятную особенность – Flash CS4 всегда пытается объявить недостающие элементы сцены. К примеру, если у вас есть спрайт контейнер и в нём кнопка simpleButton, то у вас в классе при компиляции обязательно появится поле public var simpleButton:SimpleButton. Но Flash CS4 при этом не учитывает возможность объявления этого свойства в родительском классе и если это так, то при компиляции возникает очень неприятная ошибка. Единственное, что пришло в голову:

• Создавая символы давать им имена в виде "имясимвола_symbol", а в классе описывать геттер

          public function get имясимвола():InteractiveObject{
            return this.getChildByName("имясимвола_symbol");
          }

• После тестирования класса делать его dynamic и комментировать объявления символов перенося их в дочерний класс. Но этот метод использовался уже в конце работ, когда вносились срочные правки и возиться не было времени.

Настройки плеера через XML

Все возможные настройки визуальной части, которые нельзя поменять перекомпилировав скин, я снёс в один XML файл, путь к которому указывается через Flashvars.

Благодаря тому, что был использован XMLLoader(ещё одна разработка из набора GUIBuilder.org), можно загружать один XML по частям из разных источников. Принцип его работы очень прост – он загружает первый, главный XML по указанному пути, а потом анализирует весь документ с помощью переданного экземпляра IXMLLoaderFormat(т.е. каждый желающий может описать свой тип меток), в поисках специальных меток указывающих URL части документа и тип вставки загруженной части. Вот пример формата метки использованного в данном проекте с единственным возможным вариантом вставки – замена узла метки на загруженный узел:

<?xml version="1.0" encoding="utf-8"?>
<main>
     <?xml-loader xml/settings.xml?>
     <screens>
          <image url="snapshot20090526001158.jpg" duration="5"/>
          <video url="video10sec.flv"/>
          <video url="video.flv"/>
     </screens>
<phonogram url="Mymalenkie_deti.flv" title="Mymalenkie deti" hasVideo="false">
          <vocal url="" hasVideo="" master="false"/>
          <original>
            <?xml-loader xml/karaoke.xml?>
          </original>
<translit>
            <?xml-loader xml/karaoke.xml?>
          </translit>
     </phonogram>
</main>
 

В этом XML файле есть три метки на загрузку частей, это всё исполняемые инструкции . С помощью этих меток можно разделить большой XML файл на более мелкие и отделить статические части от динамических, таким образом статические будут, после первой загрузки, браться из кеша, а динамические –перегружаться каждый раз. Для клиента весь набор будет загружен как один файл и событие COMPLETE будет вызвано, когда все части загружены и вставлены.

А, вот пример полного файла настроек:

<?xml version="1.0" encoding="utf-8"?>
<main>
     <settings>
          <skin url="skin.swf"/>
<play autoPlay="false">
            <text font="Verdana" size="5" scale="0.6" embedFonts="false" colorBefore="0xFFFFFF" colorAfter="0x127fb3" italic="false" bold="false" uppercase="false" animated="false">
                 <layout type="fadeLine" horizontalAlign="center" verticalAlign="center" textAlign="center" lineHeight="0" horizontalPadding="0" verticalPadding="50"/>
                 <filters>
                   <filter type="glow" color="0xAAAAAA" strength="2" blurX="3" blurY="3"/>
                 </filters>
                 <antiAlias type="advanced" gridFitType="subpixel" thickness="0" insideCutoff="0" outsideCutoff="15" colorType="dark"/>
            </text>
          </play>
          <record keyFrameInterval="20" microphoneLevel="0" useCamera="false" enableVocal="false" textType="original" cameraQuality="60" cameraBandwith="0" videoWidth="320" videoHeight="240" videoFPS="24" favorArea="true" cameraBrightness="0.4">
            <text font="Verdana" embedFonts="false" size="38" scale="1" colorBefore="0xFFFFFF" colorAfter="0x127fb3" italic="false" bold="false" uppercase="false">
                 <layout type="fadeLine" horizontalAlign="center" verticalAlign="bottom" textAlign="center" lineHeight="-20" horizontalPadding="0" verticalPadding="20"/>
                 <filters>
                   <filter type="glow" color="0x000000" strength="5" blurX="6" blurY="6"/>
                 </filters>
            </text>
          </record>
          <upload sendCookies="true">
            <dialog description="Video File(*.avi;*.mov;*.mp4;*.mpg;*.mpeg;*.3gp;*.asf;*.wmv;*.vob;*.mkv;*.flv)" extensions="*.avi;*.mov;*.mp4;*.mpg;*.mpeg;*.3gp;*.asf;*.wmv;*.vob;*.mkv;*.flv" macTypes="MooV;MPEG;VfW;MOV;FLV"/>
          </upload>
     </settings>
     <screens backgroundColor="0x000000" fitScreen="showAll" effectDuration="1">
          <image url="http://localhost/spivaimo/defaultAudioThumbnail.gif"/>
     </screens>
<phonogram url=".../source.mp3" title="Fairytale" hasVideo="false" type="mp3">
          <original>
            <karaoke id="4358" d="159" genre="Country">
<pg t="18.78" d="7.46">
                   <ln>
                     <lyr s="Years " t="18.78" d="0.61"/>
                          ...
                   </ln>
                 </pg>
            </karaoke>
          </original>
     </phonogram>
     <record host="rtmp://localhost/oflaDemo" stream="record" volume=".3">
          <save url="http://localhost/spivaimo/save.php"/>
          <delete url="http://localhost/spivaimo/delete.php"/>
     </record>
<play username="Username" url="http://localhost/spivaimo/rcord.flv" count="http://localhost/spivaimo/count.php" type="flv" hasVideo="false" volume=".8">
          <rating url="http://localhost/spivaimo/rating.php" value="4.5000" votes="8"/>
     </play>
     <upload url="http://localhost/spivaimo/upload.php"/>
</main>

Основной узел настроек, это settings, в котором содержатся общие настройки для скринов, текста и отображения плеера в общем. Это статические настройки т.к. не привязаны к определённой фонограмме, а действуют на все запускаемые экземпляры плеера. Так же, в корневом узле содержаться узлы настроек для конкретного экземпляра плеера – динамические настройки, т.е. там находятся пути к конкретной фонограмме, к скрипту с параметрами указывающими на конкретного пользователя и т.д.

После загрузки весь XML преобразуется в объекты настроек, почти Value Object’ы, только с методами шорткатами, к примеру XMLTextSettings.getTextFormat() возвращает экземпляр TextFormat основанный на настройках полученных из XML. При переносе данных в объекты происходит конвертация типов(к примеру, строка "true" преобразуется в булево true и т.д.) и подстановка значений по умолчанию, если не задано другое.

Общее построение модели

Вся модель инициализируется в классе приложения, после загрузки и обработки XML настроек. Во время инициализации модели создаются классы обслуживающие скрины вида – PlayScreen, RecordScreen, UploadScreen, каждому из них передаются общие и личные настройки, ссылка на IEventDispatcher через который будет происходить обмен событиями. Так же заранее создаются отображаемые тексты, чтоб не притормаживать старт проигрывания. Все объекты загрузчики, видео, аудио и прочее медиа управляется исключительно классами модели, так же эти классы принимают и фильтруют/обрабатывают все CHANGE события и рассылают SET события, к примеру, при инициализации плеера. В общем, как и в любом другом приложении есть абстрактные классы перетекающие из проекта к проекту, это система медиа-скринов, управление медиа-потоками и прочие полезные составляющие и другой планктон(как я назвал их выше, медиаторы и адаптеры), который связывает все эти составляющие в систему и преобразует данные из одного формата в другой, к примеру, секунды в миллисекунды или значение от 0 до 1 в позицию на таймлайне.

Система стримов для проигрывания нескольких потоков и синхронизация

Это самая интересная часть проекта из-за которой я и взялся за этот плеер, уж очень было интересно попробовать свои силы. Я сразу писал картину заказчику, чтоб он понимал что полностью свести рассинхрон на нет будет нереально, по можно свести к минимуму – в пределах 50-150 миллисекунд. Это, в основном, заслуга формата FLV, т.к. видео этого формата можно перемотать исключительно по ключевым кадрам, а качество веб видео не позволяет расставлять слишком частые ключевые кадры, поэтому приходилось ухищряться, чтоб добиться синхронизации звука фонограммы и записи.

У меня уже были заготовки для описания потоков аудио и видео, ведь даже заказчик(имеется введу технический персонал заказчика с которым я работал) не знал какие форматы будут использоваться(предполагалось, что будем использовать всё что сможем, а для начала FLV и MP3), поэтому одинаково использовал NetStream(видео/аудио) и Sound, для аудио. Лучшим решением, для их использования, было привести к общему интерфейсу и задать общий набор событий испускаемых этими классами. К примеру, у NetStream есть статусы оповещающие о состоянии буффера, а у Sound только свойство Sound.buffering, поэтому для него я задал внутренний интервал, который проверяет состояние этого свойства и если оно TRUE, то испускается событие BUFFER_EMPTY и наоборот. Так же, у Sound и NetStream разные форматы времени, секунды и миллисекунды, поэтому пришлось приводить к общему дочерних классах.

Далее были реализованы RecordStream для записи: у него вызов RecordStream.pause() вызывает ошибку т.к. недопустимое действие для записи – её можно либо начать, либо остановить. И последний из этой группы – класс MultiStream, который контролирует вверенные ему потоки и, как все остальные, реализует интерфейс IStream и испускает общие события. Основная функция MultiStream заключается в том, что он умеет останавливать все потоки если один или несколько из его внутренних потоков остановились для буферизации и восстанавливает воспроизведение, когда все потоки готовы воспроизводится.

Сначала для синхронизации существовал только метод вызываемый по определённым событиям(BUFFER_FULL, BUFFER_EMPY) и интервалу. Позже я выделил класс PositionValidator, который получает список потоков и TextManager, сортирует их по значимости – несомненно, экземпляр RecordStream будет важнее всех остальных и через определённые промежутки времени проверяет значение рассинхрона между потоками. Если рассинхрон превысил определённое значение, то происходит валидация, т.е. потоки вырвавшиеся вперёд возвращаются немного назад и наоборот. Вторым по значимости я оставил отображаемый текст, т.к. при определённом качестве MP3 звука на некоторых моментах записи он серьёзно тормозил всё остальное и мало приятного наблюдать постоянно скачущий назад текст. При валидации есть возможность указать наиболее приоритетный поток, если есть необходимость(в некоторых случаях это был поток записи).

Защита от декомпиляции и демо режим

Поскольку проект был небольшой, я подобрал идеальный способ защитить исходный код проекта. Необходимо было избавиться от угрозы декомпиляции я пошёл напрямую – всю логику плеера я поместил в отдельное приложение, которое внедрялось в плеер на стадии компиляции с помощью эмбеда. Получается, что весь код плеера находился в SWF приложении находящемся в другом SWF приложении ка набор байт, в виде ByteArray. Во время выполнения плеера, этот ByteArray выполнялся с помощью Loader.loadBytes() и плеер стартовал. Поскольку плеер весит не больше сотри килобайт я пренебрёг полосой загрузки для основного приложения – учитывая то, что люди используют плеер для воспроизведения мегабайт информации индикатор загрузки самого плеера вряд ли был бы замечен.

Исходный код загрузчика плеера:

package{
     import aw.projects.project.Model;
 
     import flash.display.DisplayObject;
     import flash.display.Loader;
     import flash.display.Sprite;
     import flash.events.Event;
     import flash.system.ApplicationDomain;
     import flash.system.LoaderContext;
     import flash.utils.ByteArray;
 
     [SWF(width="436", height="286", frameRate="24", backgroundColor="#000000")]
     public class main extends Sprite{
          [Embed(source="../bin-release/Model.swf",mimeType="application/octet-stream")]
          static public const modelDefinition:Class;
          public var loader:Loader;
          public function main():void{
            super();
            this.loadDefinition(modelDefinition);
          }
          protected function loadDefinition(definition:Class):void{
            loader = new Loader();
            var data:ByteArray = new definition();
            data.position = 0;
              loader.contentLoaderInfo.addEventListener(Event.COMPLETE, this.completeHandler);
            loaer.loadBytes(data, new LoaderContext(false, ApplicationDomain.currentDomain));
          }
          protected function completeHandler(event:Event):void{
              this.loader.contentLoaderInfo.removeEventListener(Event.COMPLETE, this.completeHandler);
            var content:DisplayObject = this.loader.content;
            this.stage.addChild(content);
          }
     }
}

И main, и Model являются приложениями в проекте, но Model приложение по-умолчанию, а main использовалось только при публикации приложения. Получается что разрабатывать и тестировать приложение можно не заморачиваяcь а в релизе сначала компилировать Model, а потом main.

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

     public class Model extends Sprite{
          ...
          public function Model():void{
            super();
            //fixme DEMO
            if((new Date(2010, 1)).time<(new Date()).time) return;
 
            this.addEventListener(Event.ADDED_TO_STAGE, this.initialize);
          }
          protected function initialize(event:Event):void{
            var params:Object = this.stage.loaderInfo.parameters;
            ...
 

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

Мелочи

• Локализация – от неё вообще отказались, но плодить строки по коду не кошерно, поэтому я поступил "как всегда" – загнал весь текст в константы класса Localization, так что при смене языка можно просто переписать значения и перекомпилировать.
• Локальные данные были реализованы как адаптеры для объектов SharedObject, чтоб получать адкватуню справку, а внутри адаптеров простое присвоение динамическим свойствам к объекту SharedObject.data.

package aw.projects.project.model.local{
     import aw.projects.project.model.xml.PlaySettingsXML;
 
     public class PlaySettingsLocal extends LocalSettings{
          static public const LOCAL_NAME:String = 'playSettings';
          public function PlaySettingsLocal():void{
            super(LOCAL_NAME);
          }
          public function merge(settings:PlaySettingsXML):void{
            if(this.hasVolume()) settings.volume = this.volume;
          }
          public function get volume():Number{
            return this._sharedObject.data.volume;
          }
          public function hasVolume():Boolean{
            return 'volume' in this._sharedObject.data;
          }
          public function set volume(value:Number):void{
            this._sharedObject.data.volume = value;
          }
     }
}

• Группировка воспроизводимых объектов – в модели скрина для записи предопределено три состояния: проигрывание фонограммы до записи, запись, проигрывание записанного перед сохранением. Эти состояния имеют разный набор объектов и часто возникали конфликты из-за не удалённых объектов, а это приводило к дублированию звуков и прочим неприятностям. Чтоб особо не заморачиваться, я запер эти состояния в соответствующие объекты – PlayCollection, RecordCollection, PlayRecordedCollection, которые создаются на старте и умирают при останове.
• Индикатор таймаута между куплетами был реализован прямо в скине, поэтому я вывел события текста на Stage. Суть его работы в том, что он получает событие старта куплета с объектом ITimeDepend, у которого есть свойства startTime, duration и position. По информации из этого объекта он определяет позицию и отображает прогресс бар.
• Для выбора микрофона по-умолчанию был создан отдельный класс DefaultMicrophone, который содержит логику по выбору микрофона, если таковой не был выбран пользователем в настройках Flash Player и настойках самого караоке-плеера. В этом классе есть набор слов, которые не должны встречаться в названии микрофона(line, input) и слова которые должны присутствовать(mic). С помощью этих слов подбирается микрофон, ведь мало приятного сразу после записи песни обнаружить, что звук писался из Line input.
• Мастер настроек основан на тех же принципах, что и весь скин – Asset’ы и события испускаемые через Stage. Кроме того, он может испускать SET события, чтоб установить значения выбранные по-умолчанию. Если нет доступа к микрофону(Microphone.muted), он вызывает панель настроек Flash player’а и если микрофон остаётся недоступным повторяет это ещё пару раз, но не настаивает. Если же микрофон доступен, то данная страница мастера автоматически пропускается и начинается настройка микрофона.

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

Файл upload.php:

<?php
if(!file_exists('./files')) mkdir('./files');
$time = (string)time();
$dir = './files/'.$time.'/';
mkdir($dir);
$dump = "\r\n\r\n\r\n".print_r($GLOBALS, true);
$f = fopen($dir.'__dump.txt', 'a');
fwrite($f, $dump);
fclose($f);
if(count($_FILES)){
              foreach($_FILES as $key=>$value){
                            $tmp = $value['tmp_name'];
                            $name = $value['name'];
                            echo move_uploaded_file($tmp, $dir.$name);
              }
}else{
?>
<form action="./upload.php" method="post" enctype="multipart/form-data">
<input type="text" name="text">
<input type="file" name="file">
<input type="submit">
</form>
 
<?php
}
?>

Вот, результат такой выборки в XML документе:

var xml:XML = <root xmlns:ns="urn:some-uri">
	<node1/>
	<node2/>
	<node3/>
	<ns:node4/>
	<ns:node5/>
	<ns:node6/>
</root>;
trace(xml.*.toXMLString());
/*
<node1 xmlns:ns="urn:some-uri"/>
<node2 xmlns:ns="urn:some-uri"/>
<node3 xmlns:ns="urn:some-uri"/>
<ns:node4 xmlns:ns="urn:some-uri"/>
<ns:node5 xmlns:ns="urn:some-uri"/>
<ns:node6 xmlns:ns="urn:some-uri"/>
*/

Выбраны все узлы, не зависимо от пространства имён в котором он лежит.

Если реализовать метод flash_proxy::getProperty() для наследника flash.utils.Proxy, то в случае такой выборки в этот метод будет передаваться экземпляр QName в базовом пространстве имён, т.е. его свойство uri будет равно пустой строке. Это может вызвать проблемы, т.к. все свойства в любых других пространствах имён будут опущены. А для того чтоб выбрать все значения во всех пространствах имён из наследника flash.utils.Proxy необходимо делать выборку через .*::*(для XML эта выборка коснётся исключительно узлов типа ELEMENT) - так вы указываете любое пространство имён и в метод flash_proxy::getProperty() будет передан экземпляр QName c uri равным NULL, что и требовалось, собственно.

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

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

В ActionScript 3 у простого типа QName есть возможность хранить информацию о происхождении экземпляра, т.е. можно узнать, это имя атрибута или узла/свойства. Но я не смог найти простого и прямого способа «выдернуть» эту информацию из экземпляра QName. Поэтому дальше горожу свой огород.

В классе flash.utils.Proxy есть метод flash_proxy::isAttribute, который возвращает булево значение – имя атрибута передано или нет. Я воспользовался этим методом немного не по назначению и появился метод QNameUtils.isAttribute:

package aw.utils{
	import flash.utils.Proxy;
	import flash.utils.flash_proxy;
 
	public class QNameUtils extends Object{
		static private const proxyIsAttributeMethod:Function = (new Proxy()).flash_proxy::isAttribute;
		static public function isAttribute(name:QName):Boolean{
			return proxyIsAttributeMethod(name);
		}
		...
	}
}

Далее, стало интересно, как можно влиять на это значение – простого способа, опять таки, нет. Единственный способ , это создать в XML атрибут с таким же именем и потом получить xml.@attribute.name() – вот это будет имя атрибута. Но появилась проблема в том, что XML атрибут не может находиться в пространстве имён NULL(это обозначает «любое пространство имён»), а экземпляр QName может ссылаться на него и при создании такого атрибута он перемещается в базовое пространство имён(с uri = “”). И опять на помощь спешит flash.utils.Proxy – при попытке запросить атрибут он сам создаёт имя атрибута без изменений пространства имён или локального имени. В общем, я опять воспользовался обходным путём.

package aw.utils{
	import flash.utils.Proxy;
	import flash.utils.flash_proxy;
 
	public class QNameUtils extends Object{
		...
		static private var _converter:ConverterProxy;
		static public function setAttribute(name:QName, isAttribute:Boolean=true):QName{
			if(isAttribute){
				if(!_converter) _converter = new ConverterProxy();
				_converter.@[name];
				name = _converter.getLastUsedName();
			}else name = new QName(name.uri, name.localName);
			return name;
		}
		...
	}
}
 
import flash.utils.Proxy;
import flash.utils.flash_proxy;
 
class ConverterProxy extends Proxy{
	private var _lastName:QName;
	public function ConverterProxy():void{
		super();
	}
	public function getLastUsedName():QName{
		return this._lastName;
	}
	override flash_proxy function getProperty(name:*):*{
		this._lastName = name;
		return null;
	}
}

Создал скрытого наследника flash.utils.Proxy исключительно для целей конвертации и использую его в методе QNameUtils.setAttribute.

В общем, встречайте aw.utils.QNameUtils, класс для работы со скрытым ключом атрибута в экземплярах QName.

Вот небольшой пример его работы:

import aw.utils.QNameUtils;
 
var name:QName;
var xml:XML = <node attr="value"/>;
 
name = xml.@attr.name(); // получаем имя атрибута
trace(QNameUtils.isAttribute(name)); // true
 
name = new QName('', 'attr'); // создаём обычный экземпляр QName
trace(xml.@[name]); // value
 
name = QNameUtils.create('', 'attr', true); // создаём экземпляр QName для атрибута
trace(xml[name]); // value 

Как видите, нет необходимости хранить информацию о происхождении отдельно или указывать при запросе – можно в один способ запросить узел и атрибут по динамическому имени без дополнительных хранилищ данных, ведь всё хранится прямо в экземпляре QName. А вопрос сериализации QName с ключом пусть ляжет на конкретного разработчика в конкретном случае , если кто решит воспользоваться.

Это свойство есть у всех объектов расширяющих Object класс, но природа наследников flash.utils.Proxy такова, что любой «получить значение свойства» запрос проходит через метод flash_proxy::getProperty(), кроме тех случаев, когда запрашивается свойство или поле описаное в наследнике flash.utils.Proxy. Поэтому если не описать это свойство вовремя – при запросе происходит вызов метода flash_proxy::getProperty(), а дальше приходит неизвестность, т.е. вы теряете очень важную и полезную особенность присущую обычным объектам т.к. наиболее быстрый и правильный способ узнать тип объекта, это обратиться к свойству constructor любого объекта.

Я обычно описываю это свойство двумя способами:

Для абстрактного класса:

public class AbstractWrapper extends Proxy{
	…
	public function get constructor():Class{
		return getDefinitionByName(getQualifiedClassName(this)) as Class;
	}

В таком случае не будет ошибки, если в дочернем классе забыть переписать этот метод.

А для конкретного класса:

;public class Wrapper extends Proxy{
	…
	public function get constructor():Class{
		return Wrapper;
	}

Можно, конечно и так:

public class Wrapper extends Proxy{
	…
	public const constructor:Class = Wrapper;
	}

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