タグ: flash

SecurityDomainで諸々メモ。（まだ間違っている部分があるかもしれない）
条件
・セキュリティポリシーファイルを読込先サーバに配置できない
として、どーやってそのサーバに配置されているソースを読み込むか？ということでProxyのような働きをするswfを用意し、それを介して読込先サーバのリソースにアクセスしてみるようなかんじ。
・Security.allowDoaminの設定。
Security.allowDoamin(“*”)でも良いが、危険なので

親：Security.allowDomain(loader.contentLoaderInfo.url);
子：Security.allowDomain(this.root.loaderInfo.loaderURL);

な感じで動的に設定した方がよさげ。
・LoaderContextの設定
checkPolicyFile = false;
securityDomain =null;
これらを設定するとcrossdomain.xmlを参照し、その時点で停止。
ApplicationDoaminの設定は問題ないが、Security.allowDoamin前に確認されるからか、適応されないっぽい。まぁLoaderContext無しで動くようにする必要がある。
・子swf内クラスのイベント
取得するにはdispatchを受け付けるように、親にもSecurity.allowDoaminが必要（当たり前ですが）
・子swfでのクラス定義のタイミング
ポリシーファイルが定義されている場合は、子swfの変数として
var a:hoge = new Hoge()
見たいにして定着させるが、Security.allowDoaminで開放する場合には、解放後定義しないと参照できない。つまりコンストラクタで

Security.allowDomain(this.root.loaderInfo.loaderURL);

とした後に
new Hoge();
等と空打ちして焼き付ける。
・子swfのクラスの取得
SecurityDomainが同じ場合は、ApplicationDoamin.currentDoamin.getDefinitionでクラスを取得できるが、前述の通りSecurityDomainが異なるためApplicationDoamin.currentDoaminに子swfが含まれていない。このため

loader.contentLoaderInfo.applicationDomain.getDefinition("Hoge") as Class;

みたいに取得する。ただし、これを親クラス側で変数に代入して流用は可能。

var hogeClass:Class = loader.contentLoaderInfo.applicationDomain.getDefinition("Hoge") as Class;
var hoge = new hogeClass();

ただし型指定をするとエラーになる。
簡単なのは子クラスを格納するクラスを作って、その中にStaticで格納するのが楽。
・Loader系
子swfで定義されたLoader拡張クラスを、親swfでgetDefinitionして取得した後は、親でインスタンス化しても使用可能。ただしcontnt等セキュリティエラーに抵当するプロパティもある。例えばBitmapDataを取得したい場合は、子swfに含まれるLoader拡張クラスの中で、BitmapData化して引き渡すなどの処理が必要。

public function get bmd():BitmapData
{
var bmd:BitmapData = new BitmapData(content.width, content.height);
bmd.draw(content);
return bmd;
}

こんなかんじ？このBtimapは親で自由に使える。Sprite系なども基本newしてしまえば自由に使えるが、SecurityDomainを超えた要素はやはりセキュリティエラーになるので注意。（この辺ローカルでは確認できないので、サーバ上で確認するしかないのだけど・・、そこが非常に面倒）
ただリダイレクト系の分散負荷のシステムだと、結局このproxySWFとそこから呼ばれるソースのIPがまた変わってしまうという延々とループな感じの挙動にってしまう。イメージやらswfやらが対象であればバイナリ化してLoadしたほうが圧倒的に楽。ただFLVの場合が・・・・汗
ということでとりあえずメモ。

さて、現実的に使うためにどーするか？ということを考えてみます。特にProgressionで・・・。
問題点としては
１）共有フォントの読み込みがドキュメントクラスのコンストラクタ前に発動してしまう。
２）ProgressionでRSLを配置するとCastDocumentの”_onInit”がロストしてしまう。
この2点をなんとか解決したいと思います。
２）はloaderInfoの”Event.COMPLETE”がRSLが存在すると発動しないというのが起因しているかと思います。（何故なのか？は不明。そもそもRSLのローディングが管理できないのでどーしていいのやら）
ということで、コチラは無理やり”CastDocument”のコンストラクタに

addEventListener(Event.ADDED_TO_STAGE, _onAdd);

として、_onInitに連結します。(override出来ないから）
これに関しては諸々調べていますが、問題が発生する可能性があるので、暫定的な処理とさせてください。実際にこの手法を用いる際にはリスクがあることをご理解の上、実装してください。（今のところ問題が発生するものとしないものの2つのパターンがあることは確認していますが、明確な切り分けは出来ていません。）

private function _onAdd(e:Event):void
{
_onInit();
removeEventListener(Event.ADDED_TO_STAGE, _onAdd);
}

一応_onInitの重複発動（Preloader経由だと”Event.COMPLETE”が発動するので）防止のために、”onInit”の最初に以下の一文を入れておく。

if (prog) return;

以前apeirophobia: 特定の文字だけを埋め込んだフォントのランタイム共有方法(AS 2.0)というエントリーを書いたけど、今度はAS3版。既出のリソースとしては
FACEs: as3:フォントのダイナミックなローディング
CS3版　フォントのダイナミックなローディング｜_level0.KAYAC
あたりが有名なところ。
で、このやり方で読み込む親SWFの中に同じフォントを用いた静止テキストを配置すると、フォントが表示されなくなるという問題がある。これはPlayer8以前に見られたフォントのconflictと同じような状態（詳細はapeirophobia: 特定の文字だけを埋め込んだフォントのランタイム共有方法(AS 2.0)）。恐らくフォントクラスが親SWFで先に設定されてしまうことで、外部SWFのフォントクラスが適応されないというのが理由だと思う。（そう考えるとPlayer8の原因とは違うのかもしれないけど）
簡単に検証したい人はCS3版　フォントのダイナミックなローディング｜_level0.KAYACのサンプルをDLして、loader.flaのステージ上にAXIS Std Hで静的テキストを配置すると再現できます。
AS3から外部SWFのクラスアクセスはApplicationDomainの設定も絡んできて、ちょっと原因の切り分けがややこしくなっているので、検証してみました。
なんか良く分からない部分もあるのですが、とりあえず忘れないようにダラダラ書いておきます。

Flashには幾つかundocumented functionが存在するのだけど、そのうちの一つ”addFrameScript”。
存在は知っていたのだけど、今まで上手く動作せず、どーしたもんかしら？と放置していた。ちと今回どうしても使いたくなってきたので改めてClassを見てみたらこんな感じだった。

// NON-DOCUMENTED (MANUAL ADDITION)
/**
* Attach a callback method to a frame. Note that this will replace any timeline code or
* previously attached callback.
* The callback method should not expect any parameter.
* @param frame Target frame number (starting from 0).
* @param notify Callback method to attach.
*/
public function addFrameScript(frame:uint, notify:Function):void;

やー (starting from 0).だった。これだけで長い間放置していた・・・汗
ちなみに複数フレームに一気に追加する場合には

addFrameScript(5, aho,6,aho2);

削除する場合には

addFrameScript(5, null);

となります。
ちなみにflashguruでは

addFrameScript(9,output,false,false);

というような記述がありますが、これは動作確認取れませんでした。
ちなみにProgressionの”ExMovieClip”クラスではループ再生制御のためにコンストラクタで

addFrameScript( totalFrames - 1, _complete );

されているので、ループさせる場合等には１フレーム程多目にフレームを定義しておかないとフレームアクションが上書きされてしまいます。
Ref.FlashGuru Consulting – Undocumented Actionscript 3

Inheritance — Flash CS3
この辺ではまり中・・・・。
EventDispatcherのStatic化も面倒だ。
なんか良い解決策は無いかしら？

今回は正確に言うと検証ではなく、改造です・・・。
今後のバージョンアップ等を考えると同期が取れなくなるのでお勧めしません。実装される方は一応自己責任でお願いします。
ドキュメントには掲載されていないのですが、
jp.progression.core.managers.HistoryManager
という履歴を管理するクラスがあります。基本的にはブラウザの「戻る」「進む」ボタンに対応してシーンを遷移させる働きをしています。これを使用しているクラスとしては
jp.progression.core.managers.KeyboardManager
jp.progression.core.managers.SceneManager
jp.progression.core.ui.CastObjectContextMenu
の3つがあります。ｺﾝﾃｷｽﾄとかは標準的に表に出てくるので使っている人も多いと思います。
で、これと同じ働きをする「back」「next」ボタンをFlash内で実装する場合

HistoryManager.back();//戻る
HistoryManager.forward();//進む

という感じになります。
ただ履歴とその中における現在の位置の関係が分からないため、これ以上戻れない、進めない状態になったときにボタンを殺したりすることができません。（その口を見つけられていないだけかもしれないけど）
つまりHistoryManager._positionとHistoryManager._histories.lengthの関係をチェックして、フロントのボタンの制御を行える口を用意したいなと・・。
ただposition、histories共にprivate static属性のためextendsもできず・・・ということでHistoryManagerに２つメソッドを追加してしまいました。

apeirophobia: Loaderの読み込み強制終了 Loader.close編、apeirophobia: Loaderの読み込み強制終了 Loader.unload編の続き。Progression3でやるとどうなるか？の検証。
主要なコードは以下の通り。本当はもっとスマートな書き方がCastImageLoaderにはありますが、敢えてここはcontentsLoaderInfoと比較するためにこの記述の仕方で・・。
CODE:1

_loader = new CastImageLoader();
//CastImageLoaderイベント
_loader.addEventListener(CastEvent.CAST_LOAD_COMPLETE, _loaded_Loader);
_loader.addEventListener(CastEvent.CAST_LOAD_START, function() { trace("CastImageLoader::ロード開始");_output.text = "CAST_LOAD_START"} );
_loader.addEventListener(Event.UNLOAD, function() { trace("CastImageLoader::アンロードされました"); _output.text = "CAST_REMOVED" } );
//contentLoaderInfoイベント
_loader.contentLoaderInfo.addEventListener(Event.COMPLETE, function() { trace("contentLoaderInfo::ロード完了"); } );
_loader.contentLoaderInfo.addEventListener(Event.OPEN, function() { trace("contentLoaderInfo::ロード開始"); );
_loader.contentLoaderInfo.addEventListener(Event.UNLOAD, function() { trace("contentLoaderInfo::アンロードされました"); } );
・・・
_bt_cancel.onCastMouseDown = function()
{
trace("CLOSE実行");
if (_loader.contentLoaderInfo && _loader.contentLoaderInfo.bytesLoaded < _loader.contentLoaderInfo.bytesTotal)
{
_loader.close();
}
_loader.unload();
}
・・・
private function _loaded_Loader(e:Event):void
{
trace("CastImageLoader::ロード完了");
addChildAt(_loader,0);
}

で、一点注意点としてはCastEventは”UNLOAD”イベントを持たないので、その部分だけはEvent.UNLOADを使用します。あ、あとcontentLoaderInfoではなく直接CastImageLoaderを監視します。
ﾌﾟﾚﾋﾞｭｰ/ﾀﾞｳﾝﾛｰﾄﾞｼﾐｭﾚｰﾄでの実行結果は

１：読み込み中にclose実行＞読み込みは中断されず、COMPLETEイベント発生。ただし_loaderは表示されない。
２：読み込み前にclose実行＞特に問題なし
３：読み込み後にclose実行＞_loader消去
４：読み込み中にclose実行後、再度読み込み＞2回目の読み込みCOMPLETEイベントが発生するが、_loaderが表示されない。
５：読み込み完了後にclose実行後、再度読み込み＞問題なく表示
６：読み込み後、再度読み込み中にclose実行＞unloadが無視され、COMPLETE発生後表示されてしまう。

という感じに。読み込みは中断されずCOMPLETEイベントは発生してしまいますが、表示されることはありません。
ただし４、５、６あたりが挙動が不審なところで、読み込み中にunloadを実行する、もしくは一度unlaod無しでCOMPLETEしてしまうとcontents(DisplayObject)の制御が利かなくなるようです。（ExLoader、ExImageLoader、CastImageLoaderの中を見てみましたが、ちょっと原因良く分からなかった）
HTTP経由での実行結果は

１：読み込み中にclose実行＞読み込み中断。
２：読み込み前にclose実行＞特に問題なし
３：読み込み後にclose実行＞_loader消去
４：読み込み中にclose実行後、再度読み込み＞問題なし
５：読み込み完了後にclose実行後、再度読み込み＞問題なく表示
６：読み込み後、再度読み込み中にclose実行＞問題なし

という結果になりました。ﾌﾟﾚﾋﾞｭｰ環境でおかしかった４、５、６辺りはHTTP経由では問題ないようです。
で、話はちょっと横にそれますが、contentsLoaderInfoのイベントとのタイミングですが、普通にLoadingした場合

CastImageLoader::ロード開始
contentLoaderInfo::ロード開始
CastImageLoader::ロード完了
contentLoaderInfo::ロード完了

というようにCastImageLoaderのイベントのほうが先に実行されています。ステキです。
では続いて、CastImageLoaderに最適と思われる記述の仕方をしてみます。

外部イメージのローディング途中で他の処理やｼｰﾝに遷移したい場合等、ローディングを任意に中止する部分で現在はまり中ということで検証を時系列的にメモ。
“Loader”ｸﾗｽには”close”と”unload”という似たようなﾒｿｯﾄﾞが2つほどある。
closeは

Loader インスタンスに対して現在進行中の load() メソッドの処理をキャンセルします。

一方unloadは

load() メソッドを使用してロードされた、この Loader オブジェクトの子を削除します。関連したLoaderInfo オブジェクトの property は null にリセットされます。他のオブジェクトが参照している可能性があるため、子は必ずしも破棄されるとは限りません。ただし、Loader オブジェクトの子ではなくなります。

と定義されている。
とりあえず”close”から検証してみる。
CODE:1

_loader = new Loader();
_loader.contentLoaderInfo.addEventListener(Event.OPEN, function() { trace("ロード開始");} );
_loader.contentLoaderInfo.addEventListener(Event.UNLOAD, function(){trace("アンロードされました")});
_loader.contentLoaderInfo.addEventListener(Event.COMPLETE, _loaded_Loader);
・・・
//キャンセルボタン（※CastButtonを使用）
_bt_cancel.onCastMouseDown = function(){ _loader.close(); }
・・・
private function _loaded_Loader(e:Event):void
{
trace("ロード完了");
addChildAt(_loader,0);
}

既にこの時点でCLOSEイベントを取得する口が見つからない（汗　EVENT.CLOSEは”Socket”,”XMLSocket”だけにしか用意されていないイベント。つまり発動したとしても結果を拾えないという謎な感じになっている。

Progressionの便利機能の一つに

sync : Boolean
ブラウザ上でコンテンツを実行している場合に、URL と Progression インスタンスのシーンを同期させるかどうかを取得または設定します。 同一コンテンツ上で有効化できる Progression インスタンスは 1 つのみであり、複数に対して有効化を試みた場合、最後に有効化された Progression インスタンス以外の sync プロパティは自動的に false に設定されます。

があるわけですが、”Index(CastDocument)”クラス内でコマンドを使って外部ファイルのローディング処理等をしつつ、”sync=true”にしていると、コマンド処理待ちをすっ飛ばして自動的にfirstSceneIdｼｰﾝに遷移してしまいます。（prog.goto( prog.firstSceneId );”を記述していない場合、ﾌﾟﾚﾋﾞｭｰ環境では遷移しないのですがﾌﾞﾗｳｻﾞ上でみると遷移しちゃう）
各シーン毎に必要なものを読み込む様な形であれば問題ないのですが、先読みデータ前提で各シーンの設定していると（例えば外部イメージをbitmapdataとして保持して、そこから呼び出したり）、読み込み前のためにnullになってしまってｴﾗｰが出てきます。
でわどするか？っつーと”prog.sync = false;”の設定をコマンドの中にいれて設定を同期させてしまいます。つまり先読み処理が終わった後、且つ最初のｼｰﾝへの移動の間で設定する。こんな感じ
CODE-1

_list = new SerialList();
_list.addCommand(
・・・
//先読み処理終了
,function() { prog.sync = true; }
,new Goto(prog.firstSceneId)
);
_list.execute();

これで多分大丈夫。
多分・・。