Results tagged “Progression4”

Jul 072011

ProgressionでSWFAddressのExternalChangeが発動しない件

走り書き。

Progression4 + SWFaddressでindexにQueryって駄目だったっけ?
#?id=112
みたいなの。
この形だとexternalChangeeがWebSynchronizer内のSceneId.validatePathに引っかかってgotoまで遷移しない。(Queryの場合はSceneEvent.SCENE_QUERY_CHANGEも呼ばれない)

とりあえず間にひとつシーンをかませば問題なく動作する。
#/v/?id=2
みたいなかんじ。

SWFAddress単体では動作していたような気もするのだけど、記憶が定かではない。

Ref.Asual | SWFAddress - Deep linking for Flash and Ajax
Progression - Framework for Flash

Jun 262011

LoadBitmapData

久々Progressionネタを書いてみる。
LoadBitmapDataのcompleteの処理はL193から以下のように記述されている。
private function _complete( e:Event ):void {
	// 対象が Bitmap であれば
	try {
		// データを保持する
		super.data = Bitmap( _loader.content ).bitmapData;
	}
	catch ( err:Error ) {
		// データを破棄する
		super.data = null;
		
		// 破棄する
		_destroy();
		
		// エラー処理を実行する
		super.throwError( this, err.message );
		return;
	}
	
	// 破棄する
	_destroy();
	
	// 処理を終了する
	super.executeComplete();
}
これ、
super.throwError( this, err.message );
この部分
super.throwError( this, new Error(err.message) );
にしないと動かないんじゃないかしら?と思った。

そんなこたーないかしら? もうライブラリに手を入れないようにしようと思っているけれど、ちょっとここは直さないと動かないんじゃないかなぁ?

Feb 262011

managerの違い

SceneLoaderで外部Progressionを子供Sceneに設定した場合、子Progressionの中でのmanagerの参照先が参照場所によって変化します。

簡単書くと
SceneObject@manager > 子Progressionを参照
DisplayObjectを継承したCast系@manager > 親Progressionを参照

シーンはProgressionセグメントのレベルで管理されますが、Cast系はその辺には関与せず、純粋に最上位のProgressionの管理下に置かれるってな感じなのだと思います。

詳しい中身の管理ロジックについてはよく分からないですけど・・。

これ具体的に何が困るかというと、子Progression内で遷移の際の行き先や、出発点によって何かを制御しようとした際に、
getSceneBySceneId(manager.destinedSceneId)
としたときに、SceneObject上では問題ないのだけど、Cast系だと親Progressionを参照してしまうため、SceneObjectを参照できずエラーが戻ってくるという部分です。

なんか便利機能とかあるのかもしれないけれど、判別式で参照managerを切り分けて処理するようにしますた。

Jan 222011

SceneLoaderで読み込んだ外部Progressionのcontainerを設定する

Progressionで初期Loadの負荷を下げるために、シーンファイルを個別のswfで作成し、SceneLoaderで制御するという事は多々あります。

その際に外部swf内の子ProgressionコンテンツをAddchildする先を親Progressionのcontainerにすると、各コンテンツの深度制御がちょっと面倒になる時があります。(シーン移動のトランジション時など) その場合、子Progressionのcontainerを親Progressionの任意のDisplayObjectContainerにしてしまうと楽ちんです。

こんな感じ
親Progression
_boxContents = new CastSprite( { id:"box:contents" } );
addCommand(new AddChild(container, _boxContents));
var sLoader:SceneLoader = new SceneLoader("hoge");
sLoader.onScenePreLoad=function():void{
	var loader:LoadScene = new LoadScene(new URLRequest("hoge.swf", sLoader);
	loader.loaderContainer = _boxContents;
	sLoader.addCommand(loader);
}
addScene(sLoader);
これで、子Progression内における、"container"は、自動的に_boxContentsを参照することになります。

ちと自分はカスタムクラス化して、上記のような記述をしていないので、実際きちんと動くか?は分からないですけど・・・。こんな感じなのは間違いない。

で、もし親Progressionのcontainerにアクセスしたい場合はgetManagerByIdを用いて親Progressionのmanager経由でアクセスしてやればよいかと・・・。
これウソ。managerにcontainerを参照するproperty無かった。 あれー?

追記: Progression4から、各シーンのcontainerを変えれるので(って上でやってますけど)、manager.containerではなく、manager.root.containerでアクセスするかんじですね。(これもトップシーンのcontainerってだけですけど)もし、厳密にアクセスしたいのであれば、getSCeneByIdでシーンに直接参照する感じかな?しらんけど。

Nov 042010

Google Analyticsの新しいやつとProgression

ちょくちょく変わるGoogle Analytics。
ga.jsになったのは去年の12月。久しぶりに見たらまたちょっと埋め込みコードが変わっているっぽい。(headの中に入れるようになっていた)
まぁ昔のやつでも動作するし、特に問題は無いのだけど、Getting Started with the Asynchronous Snippet - Google Analytics - Google Codeこの辺のやつにチラッとProgressionで対応できるように。

Progression純正のやつは"WebSynchronizer"になるのだけど、この中で定義されているのは
pageTracker._trackPageview
urchinTracker
の2タイプ。

新しいやつはswcコンポーネントから"GATracker"生成してやれということなのですが、"WebSynchronizer"の中に手を入れる必要があるので面倒だなと・・。
"GATracker"を使うメリットはそれなりにあるので、一応それのProgression連動クラスは作ってはいるけれど、使う必要が無い場合に純正のProgressionのまま対応する方法を考えてみた。

Continue reading Google Analyticsの新しいやつとProgression.

Oct 012010

LoadBitmapData.defaultCacheAsResourceなど無い

最近あまりFlash実装の機会がありませんけれど、唐突にProgression。

LoadBitmapDataのdefaultCacheAsResourceを設定しようとして、
LoadBitmapData.defaultCacheAsResource
とか書いてエラーになって困っていたが、ドキュメントのURLをよくよく見たら、リンク先がsuperClassのLoadCommandになっていたアルヨ。

LoadCommand - Progression 4.0 API Reference

つまりLoadCommandのサブクラスも一括設定ということで、他のサブクラスでCache有効にしたい場合とかは個別インスタンスで設定すべし。
べしべし。

なんか前も似たようなことをやっていた気がするけれど・・・。忘れた。

ちなみにキャッシュ有効にして、LoadCommand.disposeを使用しないで、BitmapDataを直接disposeするとリソース管理が把握できなくてヌルっちゃいます。注意。

Mar 192010

API系の画像取得の際

最近はAPIでGETから画像を取得したりすることがありますが(hogehoge/thumb?id=1234みたいな)、その際にLoadCommand系でアクセスするならcacheAsResourceをきちんとfalseに設定してあげましょう。


1つ目を読み込んだあと、次のデータを読み込むために引数を変更してコマンド実行しても、リクエストを発生させず、completeが発動させ、キャッシュリソースとして格納されているデータを戻してきます。


よく考えれば動作としては至極正常。つまりLoadVarsはResourceの一意性を保証する要素では無いというだけの話。一見不便に思えるがCashBusterなどのことを考えると至極当然。


このResource機能はとても便利なのですがね。元々この手のリソース情報は別途リソース管理用のクラスで管理する方なので、ちと失念していた。これはProgressionの初期化の際にConfigで全体としてONN/OFFとかできてもいいんじゃないかなあ・・って思った。(今は毎回LoadCommand系を全部Offにする必要がある)
※Saqooshaさんからのご指摘の通り、Static propertyの
LoadCommand.defaultCacheAsResource = false;
で設定してあげれば一括設定可能でした。失礼しましたー。


何回読んでも違うデータが出てくるとか、リクエストが発生しないとかそういう場合、ちょっとこれを思い出してみればいい。

1

Search and Archives

Tags