Мастер-класс Farata Systems. День второй.

Второй день был не хуже, чем первый.

Архитектурные фреймворки

День начался с рассмотра архитектурных фреймворков для флекс, где Яков забил пару гвоздей в гроб мертвого Cairngorm и полуживого PureMVC, сказал пару хороших слов про Mate, кое что про Robotlegs, и высоко оценил Parsley.

Насчет Cairngorm говорить вообще нечего, RIP.

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

Mate в общем хорош. Из недостатков Яков назвал отсутствие релиз версии и отсутствие поддержки Data Managment Services от LCDS. Это делает его непригодным для энтерпрайза, ибо заказчики боятся даже того, что пронумеровано версией 1.x, чего уж говорить про версию 0.8, в которой Матэ пребывает последние 3 года без всяких изменений :)

В последние годы во флекс разработке стали модны фреймворки поддерживающие Dependency Injection. Очевидное их преимущество в том, что они упрощают автоматическое тестирование. А что касается низкой связанности, то она во флексе легко обеспечивается и без DI. Достаточно опираться на события и биндинг.

Robotlegs более-менее терпимый, хотя тож с оверхедом. Но там коряво сделаны Dependency Injection. Объекты различаются только по типу, поэтому на каждый объект должен быть свой класс (что по мне полный бред).

А вот Parsley Фарате очень нравится. И Swiz тоже, причем Фарата не видит существенный различий между Parsley и Swiz. Уменьшает объем кода, не инвазивный, можно использовать его компоненты частично, а не весь фреймворк, хорошо вписывается в архитектуру флекс. Единственный недостаток -- сложен в освоении.

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

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

И я склонен с этим согласится, но от Mate не откажусь :)

Automated Functional Testing и Flex Monkey

Потом была очень интересная тема об автоматизации функционального тестирования. Эта тема для меня вообще новая, до этого я не вникал, что там к чему.

Рассказывал Сергей Язловецкий. Он рассказал про архитектуру automation во флекс фреймворке, что нужно сделать в своем коде, чтобы поддерживать automation, какие тулы для тестирования можно подключать. И показал, как использовать Flex Monkey.

Это было круто, сразу стало ясно и понятно, как оно все работает. И этих знаний достаточно для быстрого старта.

Андроид, Флекс и "сервер в кармане"

Потом Виктор Распутнис еще раз повторил свой доклад про разработку под андроид на флексе и джаве, с BlazeDS. На этот раз в более быстром темпе, и со смещением акцента на другие детали.

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

Это нужно, чтобы дать доступ флекс приложению к нативным API андроида, чего Адоби пока не дает, но обещает дать к концу года. Что это будет за доступ, насколько он будет полным, и когда будет готов -- никто не знает. А BlazeDS работает уже сейчас, и дает полный доступ к API.

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

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

Правда я сам еще призадумался бы, а кто бережнее обращается с ресурсами мобильного девайса (память, проц и заряд аккумулятора), BlazeDS или нативный сервис, общающийся с приложением через сокет? Но все из-за моей склонности к сокетам, которая так же велика, как склонность Фарата к BlazeDS :)

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

Grid на 4,5 миллиона строк

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

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

Грузить больше данных плохо по двум причинам: во-первых, это лишний траффик, во-вторых (что может быть более важно) это лишняя нагрузка на проц. Ибо все пришедшие данные десериализуются. Если их много, то десериализуются они долго, и замораживают приложение, которое перестает откликаться на действия пользователя.

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

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

Реализация Валерия позволяет отобразить 4,5 миллиона записей в спарковском гриде, и 10 миллионов в mx гриде. Решение это привязано, конечно, к BlazeDS. И конечно, сортировку и фильтрацию данных нужно делать на сервере.

Разница между mx и spark гридом обусловлена интересным нюансом. В mx компонентах списочные данные хранятся в Array, а в spark компонентах в основном в Vector. Array -- разреженная структура данных. Создать Array на 10 млн элементов ничего не стоит, и памяти особо не занимает, если этих элементов там реально нету. Тогда как Vector -- это линейная структура данных и занимает больше памяти. Как обычно, за лучшую производительность нужно платить большим расходом памяти :)

Модульность во флексе

Тут было теоретическое занятие и workshop. Особо останавливаться на этом не буду. В общем-то, ничего нового, в сравнении с тем, как эта тема освещалась 2 года назад, не было.

Упомяну пару моментов:

• первый экран должен быть минимальным, не содержать ничего лишнего, чтобы появляться максимально быстро. Все остальное должно быть вынесено во внешние модули и загружаться по требованию;
• шрифты, css-стили и прочие ресурсы должны быть вынесены во внешний swf файл и загружаться в рантайме;
• Для общения модуля с основным приложением можно привести класс модуля к интерфейсу, но не желательно. Лучше общаться только через SharedEvent;
• Можно особо не бояться, что модуль не выгрузится и застрянет в памяти. Код модуля обычно не большой. Лучше заботиться об освобождении памяти от входящих данных. Впрочем, если использовать SharedEvent с мягкой ссылкой, то модуль в памяти не застрянет;
• Remoting и все, с ним связанное нужно выносить в главное приложение. Ибо если они будут в модулях, то первый модуль захватит эти ресурсы, а остальные не смогут к ним обратиться;
• Все registerClassAlias, [RemoteObject] и все DTO должны быть в главном приложении. Если регистрировать классы в модуле, то модуль застрянет в памяти и его нельзя будет выгрузить;

По моему мнению Фарата эту тему переусложнила. Много сложных и ненужных (ну или редко когда и кому нужных) деталей. Материал можно упростить.

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

А еще я обзавелся автографами Якова и Виктора на своем экземпляре Enterprise Development with Flex :)