33 коровы

“Фичи” обновления Flex Builder и flex sdk

Все слышали о выходе очередного обновления Flex Builder 3.0.2 и Flex sdk 3.2

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

У меня 2 машины, где я обновлял билдер на обоих было продемонстрировано различное нелогичное поведение:

1-я машина. Апдейтер прописал то, что у меня установлено всего 2 sdk, 2.0.1 и 3.2.0 Естественно проекты перестали компилится т.к писались на sdk 3.0.0, пришлось ее подключать вручную, в процессе подключения я ее нашел в стандартной папке с sdk. ее просто “забыли” подключить.
2-я машина. Апдейтер я запустил давно и забыл о его запуске. Затем я таки решил посмотреть на сдк 3.2, но его не обнаружил. подумал что еще не апдейтил и запустил адоб апдейтер, он сказал, что у меня все последних версий! Полез папку сдк и нашел там заветную сдк 3.2. Как объяснение я могу лишь сказать, что я на этой машине баловался с Gumbo и ставил сдк 4. После нажатия кнопки “Reset sdk list” я увидел список из sdk 2.0.1, 3.0.0 и 3.2.0.

В связи с этим возникают вопросы, почему на первой машине все оно потеряло 3.0 но сразу увидело sdk 3.2, а на второй машине не увидело 3.2? Тяжело что ли проанализировать списочек из 3х пунктов?

Затем на одной из машин стоит русская винда, и апдейтер не спрашивая все “русифицировал” дебильным переводом. Что за фигня? вообще как могут быть ошибки в программировании на русском, когда все на английском? или Адоб купил часть 1C ?

UPD: вернуть английский можно добавив в eclipse.ini строки

-Duser.language=en
-Duser.country=US


Следующий пункт: после установки апдейтов полностью отваливаються старые AIR приложения, run не запускается и невыдает никаких ошибок, просто проваливаемся в пустоту, дебаг выдает непонятную фразу:

Process terminated without establishing connection to debugger.

Command:

“C:\Program Files\Adobe\Flex Builder 3 Plug-in\sdks\3.2.0\bin\adl.exe” D:\Local\MyApp\bin-debug\MyApp-app.xml D:\Local\MyApp\bin-debug

Output from command:

error while loading initial content

Я минут 15 выдумывал почему так, оказалось, что апдейт принес нам AIR 1.5 и посему мы должны в нашем файле MyApp-app.xml заменить цифиру в строке

<application xmlns="http://ns.adobe.com/air/application/1.1">

на

<application xmlns="http://ns.adobe.com/air/application/1.5">

Почему нельзя сделать внятное предупреждение/сообщение, если это настолько важно?!

Перейдем к более высоким материям.
Если стоит профешинал версия билдера, то к ней в бонус идут Data Visualization Components вместе с исходниками. При вводе ключа, автоматом идет распаковка их исходников в папочку с сдк. Но после апдейта вы никак не обнаружите новых исходников Data Visualization Components в папке с sdk 3.2.0! Их просто никто не распаковывает. Хорошо хоть есть шаманский способ достать их.
Я не заглядывал в исходники AdvancedDataGrid, но чартинги они практически не трогали (я видел только переделку для подержки модульности и загрузки приложения в приложение, если я правильно понимаю строки systemManager.getSandboxRoot()…, в старой версии было просто systemManager…). Ядро чартингов ChartBase, ох как стоило бы отрефакторить!

Недавно на баше была супер цитата:

вот зашел на хакер.ру, в граза бросилась фраза:

Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете…

Удачи в апдейтах!

Posted in Flex, Flex Builder 2, Flex Builder 3, flex framework, Mаразмы нашего городка | 2 Comments »

Custom chrome в AIR приложении и человеческий фактор

Пример приложения использующая исходники можно найти на сайте http://www.graviti.tv/blog/?p=46 (и http://www.graviti.tv/blog/?p=75 )

Но статья не о том как сделать кастомный хром, а неверном решении индийцев из адоб.

У кастомного хрома, как и у FlexChrome (showFlexChrome=”true”) есть проблемка, при максимайзе приложения оно выступает на 3 пиксела за экран во все стороны. При showFlexChrome=”true” как раз прячется скругление заголовка окна. Великолепный ход конем! :). При showFlexChrome=”true” это еще простительно, а вот когда у вас полностью свой кастом хром, то получается ужастно.

Как побороть это нормально я не нашел, пошел по простому выходу, вставил все приложение в отдельный компонент, а его сделал меньше текущего хрома ровно на 3 пх с каждой стороны)

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"
			showFlexChrome="false"
			showStatusBar="false"
			showGripper="true"
			showTitleBar="false"
			width="700" height="500" frameRate="45"
			horizontalScrollPolicy="off" verticalScrollPolicy="off"
			xmlns:local="*"
			>
	<local:AIRApplicationContent 	width="{width-6}"
					height="{height-6}"
					x="{3}" y="{3}"
					filters="{[new DropShadowFilter(4,45,0,0.5)]}"
					/>
</mx:WindowedApplication>

В качестве бонуса получил использование тени от окна не сильно напрягаясь 🙂

Posted in AIR, Flex Builder 3, Mаразмы нашего городка | 2 Comments »

Вся правда о Видео во Flex. Часть 6. Camera и Microphone.

Индусы жгут, других слов нету! )

Работал я с ними мало поэтому пока только поверхностные отжиги).

Чтобы получить список доступных устройств (вебкамер и микрофонов) нужно использовать свойство names у соответствующих классов


Camera.names : Array [read-only]
Microphone.names : Array [read-only]

Вроде все логично, но только до этого момента дальше чтобы получить конкретное устройство у класса Camera есть метод getCamera(), а у Microphone – getMicrophone() и выглядит это следующим образом:

public static function getMicrophone(index:int = 0):Microphone
public static function getCamera(name:String = null):Camera

Как-то странно подумал я: “в одном случае мы инт отдаем в другом стринг”.

С микрофоном решил проблемы быстро ), а вот с камерой уже стало интереснее.
В хелпе параметр name у getCamera() описан так :

name:String (default = null) — Specifies which camera to get, as determined from the array returned by the names property. For most applications, get the default camera by omitting this parameter.

Отдав это имя я получил огромный болт, вернее null, а не камеру. 8 раз проверил – все равно болт. В ходе эксперементов над разумом, попробывал отдать индекс камеры в виде строки, и оно заработало!

Внимание правильный ответ для решения этой проблемы:


var camera : Camera = Camera.getCamera(myIndex.toString());
//где myIndex - это порядковый номер камеры в массиве Camera.names


Привет адоб!

Posted in ActionScript 3.0, Camera, Flex, Microphone, Video | 3 Comments »

Вся правда о Видео во Flex. Часть 4. VideoDisplay – практическое применение, где мой шоколад?

Почему же не получилось шоколада?

Причин в этом несколько.

1. Стабильность

Когда я был маленький, у нас вел программирование “злой дядя” Овсянник В.Н. , “злым” его считали за то, что он валил практически любую программу принесеную на ему на здачу (дз или курсач). Делал он это довольно просто – брал и вводил неадекватные данные (если нужно было ввести строку то пихал в нее этак символов 500, или нажимал клавиши кнопки не в той последовательности), и ПО юного программиста падало. Это было его первым действием и оно было на эффективно почти на все 100%. Естественно юные таланты отправлялись дорабатывать свою программу.

Таким способом я поступил со своим прототипом плеера. Получилось полная лажа.

Если у нас кроме плей и стоп, есть премотка, а еще не дай бог мы решили менять source у
VideoDisplay, то плеер наш “держится” аж 10-15 секунд усиленого клика ). Потом он уходит в ступор и уже не реагирует на кнопки и обратно уже не возвращается, о своем плохом состоянии он ничего никому не говорит. UPD: говорит, и возвращаеться! только ждать нужно ооооочень долго, в зависимости от наклацаного и коннекта у меня оказываеться просто не хвалило терпения дождаться, дождется ли пользователь? Помогает только F5.

2. Удобство для пользователя

Пользователь, сука, нервный.

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

Ситуация 2:
Я пользователь смотрю видео, но некоторые места мне не интересны я начинаю кликать по перемотке и если не дай бог какие-то тормоза (коннект, или машина слабая) и плеер не успевает мгновенно отреагировать то я кликаю еще раз что только усилывает тормоза, затем еще раз… а потом я решаю вернутся назад… вобщем кликаю много.
В при использовании VideoDislpay это вообще фатально ибо, у него не точный seek, что особенно заметно на очень маленьких роликах, он хранит всю(!) истории этих кликов (вернее команд перемодки). т.е. при перемотки он перематывает сначало на первый клик, раздупляется, мотает на второй, и т.д. А пользователь за время раздупления может сделать 5 кликов. И они все отобразятся. Выглядит просто это супер особенно если мотать на разные места, такая машина времени ), пользователь начинает нерничать и кликает еще и еще и плееру становится все хуже и хуже… Я пробовал – можно наклацать так что этот дергаться будет еще секунд 30 :D, а иногда оно просто уходит в ступор.

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

3. Удобство для разработчика

После того как я обернул VideoDisplay захотев шоколада, я захотел исправить ситуацию с неточностью у seek’a. Seek живет все в том же VideoPlayer, уже стало немного страшно. Но не теряя оптимизма я ринулся в бой. В VideoDisplay, плеер (VideoPlayer) объявлен как
[code lang=”actionscript”]
mx_internal var videoPlayer:VideoPlayer = null;
[/code]
вроде ниче страшного, дальше у VideoPlayer есть public метод seek – вообще замечательно, т.е. если сделать класс наследник от VideoDisplay и ему всесто VideoPlayer подсунуть наследника от VideoPlayer с оверайднутым seek’oм ситуация будет спасена. Но не тут то было публичный seek у VideoPlayer’а это иллюзия, фактическая перемотка происходит в приватном методе _seek который использует приватные переменные VideoPlayer’а причем одна из перменных является экземпляром класса VideoPlayerNetStream (наследник от NetStream), который объявлен в самом VideoPlayer.as, т.е. видимость этого класса начинается и заканчивается VideoPlayer’ом. Ну и за ними также тянуться все классы из mx.controls.videoclasses.*. Вобщем-то приплыли.

В результате получили чтобы доработать напильничном пару методов нужно копипастить все классы из mx.controls.videoclasses.* в свой пакетик, делать децельный рефакторинг (небольшой минут 15), потом брать свое приложение и менять в нем mx.controls.VideoDisplay на moy.mega.noviy.VideoDisplay и после этого мы готовы переписать требуемые методы.

Скажите не правдали удобно? на онанизм не похоже? Помоемому похоже.

Вобщем так и было вначале сделано, потом полезли всякие неприятности по стабильности плеера, это “приятная” очередь из seek’ов, уходы плеера в астрал если слишком много клацали по клавишам и т.д.

Сначало была мысль вылечить сам VideoPlayer, но посмотрев еще раз код, всего 3к строк (правда включая коментарии) + то что еще он супер универсальный

VideoPlayer is an easy to use wrapper for Video, NetConnection,
NetStream, etc. that makes playing FLV easy. It supports streaming
from Flash Communication Server (FCS) and http download of FLVs.

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

Выводы

• Не все то золото что блястит.
• VideoDisplay тупиковая ветка развития. UPD: все еще можно исправить? Лучшее решение это ждать что адоб сам исправит ситуацию
• Вывод VideoDisplay из тупика своими не поддается оценке времени в человекочасах и никому это особо не нужно при таких раскладах UPD: не все потеряно) Достаем бубен из кармана?
  
• Возвращаемся к истокам (Video) и пытаемся родить свой работоспособный, пользователеустойчивый(с) аналог VideoDisplay учитывая, что
  • нам не нужно (пока) support streaming
    from Flash Communication Server (FCS)
  • Конструкция должна быть легкая и устойчивая в примении
  • Постаратся использовать чуть меньше таймеров 🙂
  • Нам не нужен хоровод из сиков
  • его внедрение в готовый код должно занять минимум усилий

Текущий результат

Имеем пока кучу потраченого в никуда времени и плеер который работает, если ничего не трогать.

В следующих сериях вы услышите увлекательные рассказы о NetStream и Video.

UPD: Мотыль Нарожняк подсказал новую ветку развития событий и еще раз показал, что не нужно суетится, а нужно изучать доки как можно внимательнее, [тут еще пара отмазок почему это произошло]).

Но всеравно NetStream”y достанется 😉

Posted in ActionScript 3.0, Flex, Video | 5 Comments »