Расширение проектора: Продолжение 4. Синхронные вызовы.

---

Мда.. перерывчик вышел долгонький. Но он того стоил.
В "Продолжении 2" я говорил о том, что реализация оболочки на основе только класса LocalConnection не позволяет осуществить синхронное выполнение АС-кода и кода оболочки.
.. и далее по тексту.
Но, кто ищет - тот найдет! И нашел, кажется.
Общение плеера в внешним миром во время выполнения кода ролика может быть построено разными способами. Для этого есть классы, позволяющие подгружать данные из-вне и отправлять данные наружу. Те же LC, XML, XMLSocket, MovieclipLoader... Но работа с этими классами не подразумевает синхронного выполнения кода изначально, что диктуется логикой клиент-серверного взаимодействия: отправили запрос - ждем ответа. А ответ придет не мгновенно..
Но есть класс, который общается с внешним миром синхронно, это SharedObject.
Этот класс работает с файловой сисемой непосредственно, скажем возврат метода SharedObject.getLocal() произойдет, когда нужный шаред-файл будет считан и его содержимое будет разложено по полям в соответствующем объекте. Сравним два примера работы с XML и SO:
Разбор ошибок при чтении/загрузке я опустил.
Разница в том, что при работе с SO плеер выполняет файловые операции и AS-код в одном потоке. А значит, можно перехватить обращение плеера к диску, выполнить "оболочечный" код, и вернуть управление обратно. Т.е. код оболочки будет выполнен синхронно с АС-кодом.
В обращение к шареду на этапе записи можно зашить команду:
А на этапе чтения шареда подставить результат ее выполнения:
Осталось организовать два предыдущих фрагмента в виде функции, принимающей параметрами команду и ее аргименты, и возвращающую то, что пришло в so_answer.data.
Вот так это выглядит в упрощенном изложении.
Технически реализовать на строне оболочки перехват не так уж и сложно. Труднее подстроиться под реализацию работы c SO в плеере. Дело в том, что операции чтения/записи сопровождаются некоторыми предварительными действиями, как-то проверка файла на существование, определение его размера, чтение и применеие настроек LocalStorage, да и сам порядок этих действий варьируется в зависимости от последовательности действий с SO в АС-коде. Более того, как оказалось, 8-ой и 9/10-ый плееры применяют разные АПИ вызовы при работе с шаредами. Есть разница и в протоколе, т.е. 9-ка поддерживает и AMF0 и AMF3, 8-ка только AMF0. Есть некоторые заморочки с именами файлов SO. Вобщем, есть чисто технические сложности, но принципиальных препятствий для осуществления синхронных вызовов по такой схеме нет.
В настоящий момент мне удалось заставить работать синхронно с оболочкой 8-ой и 9-ый плеер (10-ку не проверял, но бегло осмотрев, увидел, что там то же, что и в 9-ке).
Потому, следующее "Продолжение", видимо будет не скоро. В связи, так сказать, с вновь открывшимися...
Но, преимущества такого подхода на лицо: упрощение кода, возможно создавать что-то на-вроде геттеров/сеттеров для классов оболочки, неограниченный объем передаваемых данных в обе стороны. Плюс остается LC, через него можно засылать ивенты в плеер, и осуществлять асинхронные операции, скажем, "анимировать иконку в трее в течение 10 сек." и т.п.)).

Ну, и в заключение, небольшой оффтоп.
Когда-то давно, я писал в каком-то топике (если вспомню, покажу) про глюк в цинке (<= 2.5.0.34), точнее про mdm.FileSystem.saveFile(). Глюк заключался в том, что при попытке сохранить за раз больше 100кб данных вываливалось плеерное окошечко "Settings.." c предупреждением о превышении размера LocalStorage. Если учесть, что по дефолту этот размер как раз и есть 100кб, то все это наводит на мысли, что разработчики цинка в тех версиях тоже юзали перехват обращений к диску через SO. Ни фига себе! Никогда бы не подумал! Вот тебе и ... mdm. Им что, СОМ-интерфейсов мало было? Хотя, скорее, неспроста все это ...
Косвенно это подтверждается еще и глюком с невозможностью сохранять шареды из цинка, кроме как в папку "/". Возможно, чего-то там с перенаправлением путей накосячили.
Во всяком случае, у меня это окошечко не вываливается)).