codeflex

Наступила сегодня на совершенно дурацкое поведение (ака баг) слайдера spark.components.HSlider. Родителя и вертекального брата на вшивость не проверяла, но уверенна там та же штука: если вы динамически выставляете значение свойства maximum выше того, которое было установленно при инициализации, значение не будет изменено. Если ниже – пожалуйста. При этом если вы динамически же выставляете value выше объявленного при инициализации maximum-а он (максимум) будет изменён на это самое велью… вот такая петрушка…
Воркэраунд – передавать при инициализации значение, заведомо выше вероятного максимума. Ну или вообще не передавать – тоже рабоатет

Статья-новость, кода здесь не будет – прощенья просим. Речь пойдёт о новом релизе флеш девелопа – в котром как известно есть дебаггер и профайлер. Скачать можно здесь , как доставить упомянутые плагины прочитать тут .
Ставим и балуемся. Ничего из старого не валится – уже хорошо. И почти сразу же обнаруживаем как повесить дебаггер: если его “запустить” и в окошке проджект эксплорера выбрать какой-нибудь swf, и “execute” его из контекстного меню, то бедаггер перестаёт выключаться при этом Tools > Kill Running Process не активен… вот так вот… Запросто может быть что дело в моих особых блонди-настройках проекта и среды. Но я не хочу разбираться с этим – я хочу писать код, дебажить его и смотреть в профайлер… Вобщем – не билдер

Итак, наша задача: навести в AIR-проекте порядочек и обложить классы юнит тестами. При этом тестами нужно обложить ещё и “точку входа” – экземпляр класса (или класса-наследника) WindowedApplication. Проект под AIR 1.5 и Flex SDK 3.5 – то есть наш родной mx. Flash Builder 4 релиз. Фактически нам и нужно-то всего вынести весь код в класс-наследник WindowedApplication и инстанциировать его как приложение. И ещё – я человек привычки Я всегда складываю базовые классы для Code Behind в кастомный пекадж (именно это имеется в виду в заголовке статьи ) cored. Тут хочу сделать так же. И сталкиваюсь с неприятной особенностью использования Code Behind подхода в AIR-проектах: вы не можете поместить базовый класс-наследник WindowedApplication в “кастомный” пакет – это вызывает flex-ошибку на этапе сборки проекта. Ошибка заключается в следующем: сборщик ожидает найти -app.xml файл в том же пакете что и .as- файл. Ок, даём ему что он хочет – и тут выясняется что файл какой-то не такой. Если вы оставляете и базовый .as файл и соответствующий ему .mxml в пакете src.default то всё работает.
А теперь представьте себе что будет если у нас хотя бы с десяток таких пар. На окошко Package Explorer-а становится страшно смотреть.
Поскольку статья написана – workaround я всё же нашла Качаем и смотрим тестовый проект . Хак заключается в том чтобы сделать кастомный пекадж в другой (не src) папке (можно добавить новую но я за ленностью использовала libs) добавив её в “Flex Build Path > Source path” в свойствах проекта. Итак у нас есть libs.cored пакет, который подключается как cored – чего мы и хотели. Я не знаю почему это так – что за особенно трогательное отношение с сборщика AIR к папке src. Знаете – пишите в комментариях
По проекту-примеру: в нём 2 приложения, скрипт для WindowedApplicationInst.mxml лежит тут же, в src – это WindowedApplicationBase.as. Скрипт для второго приложения – WindowedApplicationCoreInst.mxml лежит в папке libs/cored (желанный пекадж cored).

Первое впечатление человека со стороны: зачем нам ещё одна штука чтобы делать чаты?

Первое впечатление изнутри: это здорово! Это то что нужно для конференций, для игр и для тех же чатов.

Поэтому однозначно ответить на вопрос в заголовке я не берусь. Я сделала маленький прототип – как альтернативу огромной системе с Swiz – и мне понравилось. Для разработчика это просто конфетка, возможности и скорость разработки приложения для p2p возрастает в разы! И то что это “не совсем p2p” – впечатление от просмотренных презентаций с обменом “fingerprint”-кодами. Ещё мысль из презентаций: если клиент не поддерживает RTMFP то вначале руками (а в перспективе это будет происходить автоматически) будет переключен на  RTMP. Я слабо представляю себе как это будет выглядеть технически – ни одного примера, поясняющего эту загадочную фразу, мне выгуглить не удалось. Спорным остаётся и момент всяческих монетизаций и проприетарности: не рано ли разрабатывать под эту технологию незная сколько будет стоить сервер, появятся ли freeware-аналоги, не забросит ли Adobe эту идею как он поступил например с Durango? Тут просто моё мнение, поскольку никакой инсайдерской информации у меня нет: Надо изучать и пробовать, забрасывать проекты на других “рельсах” и срочно кидаться на эти – я бы не советовала. С другой сторона Adobe в состоянии войны…

Итак, перед тем как попробовать писать код, советую воодушевиться:

презентация ,

пример и

ещё презентация

Воодушевились? Начинаем настраивать среду Как заявлено, технология рассчитана на 10,1 и вот-вот уже почти зарелизеный 11.0 плееры и работать будет даже с 3,5 SDK. Я не стала мелочиться и взяла 4,1 найтли билд от 8-го апреля ( тут ) вкупе с 3-й бетой 10,1 плеера (тут , читать файл ReadMe.txt для того чтобы подключить – если не знаете как). Подключили. А теперь идём в stratus-раздел сайта Adobe ( тут ), регистрируемся и получаем свой разработческий ключ. И начинаем кодить.

Из того что мне понравилось: классы связанные с работой с группами, flash.net.NetGroup и flash.net.GroupSpecifier. Это ж просто конфетка а не идея: инициируем группу (я правда пока не выяснила может ли один и тот же “клиент” входить одновременно в несколько групп, судя по коду да но надо придумать как красиво разруливать события разных групп)  и вещаем на всю группу. Если речь не идёт об стриминге то всё просто отлично: сообщения посылаются внутри объектов. В эти самые объекты можно добавить любые поля: я сделала прототип чата и добавила а этому объекту список получателей. Я не специалист по безопастности, но мне кажется если вы поместили человека в группу но по какой-то причине отфильтровали сообщение не адресованное ему хотя отправленное всей группе – вы знаете что делаете.  Из идей по поводу класса GroupSpecifier – при его инстантиировании ему передаётся строка с “идентификатором” группы. Тоесть пользователь может попадать в ту или иную группу просто лёгким движением руки – как логики на стороне клиента так и на стороне сервера: никто нам не мешает получать эту самую строку или грузить как результат запроса. Итак немного кода: вначале всё как обычно: если логип/пароль пользователя приняты мы обращаемся к Stratus-серверу, устанавливаем NetConnection:

public function login(username:String, password:String):void {

if(verify(username, password)) initConnection();

}

private function initConnection():void{

nc = new NetConnection();
nc.addEventListener(NetStatusEvent.NET_STATUS,ncStatus);
nc.connect(ProjectConstants.STRATUS_RTMFP_URL_1);

}

Handler событий в лучших худших традициях Flex-разработчиков будем делать один и для NetConnection и для NetGroup:

private function ncStatus(event:NetStatusEvent):void{

log(event.info.code);

switch(event.info.code){
case "NetConnection.Connect.Success":
myPeerID = nc.nearID;
setupGroup();
break;

case "NetConnection.Connect.Rejected":
log("Oops! the connection was rejected");
loginFailedHandler();
// try to connect again
break;
case "NetConnection.Connect.Failed":
log("The server may be down or unreachable");
loginFailedHandler();
// display a message for the user
break;
case "NetConnection.Connect.AppShutDown":
log("The application is shutting down");
loginFailedHandler();
// this method disconnects all stream objects
nc.close();
break;
case "NetGroup.Connect.Success":

loginSuccessHandler();
break;

case "NetGroup.Posting.Notify":
receiveGroupMessage(event.info.message);
break;

case "NetConnection.Connect.Closed":

nc.removeEventListener(NetStatusEvent.NET_STATUS,ncStatus);

break;
}

}

Итак, после успешно установленного конекшена инициализируем группу:

private function setupGroup():void{

var groupspec:GroupSpecifier = new GroupSpecifier("myGroup/groupOne");
groupspec.postingEnabled = true;
groupspec.serverChannelEnabled = true;

group = new NetGroup(nc,groupspec.groupspecWithAuthorizations());
group.addEventListener(NetStatusEvent.NET_STATUS,ncStatus);

}

Имя группы тут константа – но поскольку на этом этапе мы уже всё знаем о пользователе – тут конфетка номер один о котой я говорила. Вторя сокрыта в методе

private function receiveGroupMessage(message:Object):void{

...

}

Получаем мы объект – с теми же кастомными полями которые определили, например в методе в котором события рассылаем:

private function sendGroupMessage(txt:String):void{

var message:Object = new Object();
message.text = txt;
message.sender = group.convertPeerIDToGroupAddress(nc.nearID);
message.recipient = "Vanya";// here array of recipients - chat conversators
message.userName = accepted_login;

group.post(message);

receiveGroupMessage(message);
}

При выходе пользователя из чата группы в зависимости от логики группу можно закрыть:

public function logout():void {

group.close();
group.removeEventListener(NetStatusEvent.NET_STATUS,ncStatus);

nc.close();

chat_messages = "";
login_status = "Logged Out";

}

Кроме вышесказанного скажу что мне пока неясно: неясно как делать видеоконференции. Ну не так чтоб совсем неясно – неясно как они (разработчики и евангелисты Stratus) это видят, то есть как их делать правильно. Разберусь – расскажу Прятного полёта

Не так страшен новый SDK.  В большинстве случаев миграция проекта займет совсем немного времени.

Делаем “раз”: устанавливаем тему.  По-умолчанию билдер предлагает использовать Spark, но для минимизации потерь лучше выбрать Hallo.

Делаем “два”: добавляем неймспейс к нашим стилям.

@namespace “http://www.adobe.com/2006/mxml“

Вуаля!

Если вы вдруг дорожите внешним видом вашего прелоадера, то можно еще добавить в рутовый тег

 preloader="mx.preloaders.DownloadProgressBar"

Ну и самое последнее: вся эта прелесть работает только в 10-м плеере, так что не забудьте поменять версию плеера в html.