RIA crumbs.

Тэд Патрик (Ted Patrick) поделился своими соображениями насчет как не “терять” память при разработке Flash/Flex/AIR приложений, а так же пообещал на этой неделе расскзаать по проблемах с памятью возникающие при использовании E4X.

Статью переводить не буду, сама статья тут.

Набрел в сети на интерестную статью от Арно Гурдола (Arno Gourdol) , довольно продвинутый чел, в данный момент  Арно один из разработчиков Adobe AIR runtime.

Статья состоит из четырёх советов,  о том, что нужно сделать для того, чтобы ваше AIR приложение “ело” меньше ресурсов (памяти, CPU).

Советы:

1. Используйте низкую частоту смены кадров (framerate);
2. Изменяйте частоту смены кадров динамически, в зависимости от потребностей приложения;
3. Используйте событие ENTER_FRAME только в случае крайней нужды;
4. Создавайте как можно меньше обработчиков события ENTER_FRAME и таймеров;

Сама статья и демка находится тут.

Для начала кратко о проблеме которая натолкнула на данный тест.

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

Проблема: Пользователь умудрился при помощи приложения создать путь (серию папок, одна из них 191 символ) которые превысили лимит ОС в 254 символа, в связи с чем AIR отказался копировать что-либо в эту папку, или вообще с ней хоть как-то работать.

Решение: Введен лимит на длину папок и имен файлов (exception catcher до этого был только)

В свете вышеописанных событий, возникла идея провести тест для трех “конкурентных” технологий. Дабы проверить их поведение в данных ситуациях.

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

1. Microsoft WPF (Windows Presentation Foundation) - отказалась создавать такой путь, при этом сообщив нам о том, что мы пытаемся превысить лимит (“The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.”);

2. MDM Zink (известная обертка для Flash/Flex приложений, которая дает доступ к файловой системе и не только) – отказалась создавать путь, но молча тихо и по партизански.

И наш “победитель”:

3. Adobe AIR – позволяет создать скольугодно длиные и вложенные пути, которые потом сложно удалить стандартными методами, можно удалить только отключив длинные имена в Total Commander или воспользовавшись старым добрым Volcov Commander. Казалось бы, что Adobe молодцы, но вся загвоздка в том, что они позволяют создать эти папки, но они не работают с ними (нельзя вних что-то скопировать к примеру) и не дают удалить потом созданные папки, выдавая нам File I/O Error.

Итог: Чем думаю Адобовские девелоперы? Позволяя делать то с чем они и сами не могут работать.

Адобовцы выпустили не так давно новый Adobe AIR run-time 1.1 + Adobe AIR SDK 1.1, с приятными багфиксами и нововведениями, одно из них мне очень понадобилось. Нововведение довольно простое – проверка свободного места на диске / папке.

Правда чтобы обновить у себя AIR SDK до версии 1.1, пришлось в руки брать бубен под названием Flex 3.0.2 SDK stable release Спасибо Адобовцам за то, что написали хорошие посты по обновлению AIR SDK.

Линки:

• http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403919

• http://www.adobe.com/devnet/flex/articles/flex_air1.1.html

Mike Chambers презентует финальное лого Adobe AIR.

Для тех кому лень читать что понаписал старик Майк, смотрим сюда: