ホーム > タグ > flash

flash

「Yahoo! 3.11、検索は応援になる。」の検索ビッグデータのビジュアライザを作りました

3.11、検索は応援になる。 | Help Tohoku. Search “3.11”. – Yahoo!検索 (2014年3月31日まで公開)

今日、Yahoo!検索で「3.11」というキーワードで 検索された方おひとりにつき10円が、 Yahoo!検索から公益財団法人東日本大震災復興支援財団の「一般寄附金」へ 寄付されます。

とても意義のあるプロジェクトのビジュアライザをバスキュールがお手伝いさせていただきました。

震災前と震災後、そして現在に至るまでのYahoo!で検索された震災に関わるキーワードを可視化しています。

いくらか知見を得ましたので、ここでは

  • ビジュアライズの知見
  • ビジュアライズを実現するための高速プロトタイピング

という2点を書こうと思います。

ビジュアライズの軸のすえ方

データのどの特徴をx軸とy軸に置くのか?といった軸のすえ方が非常に重要でした。

今回のデータの大きな特徴は以下です。

  • 検索ワードの検索回数、順位
  • 時系列で検索ワードが増えたり減ったりする

いくらかプロトタイプを作り、試したが…

  • 見栄えはとてもいいが、データをわりと無視しているもの
  • データの大小を反映しているが、見栄えが悪いもの
  • データの順位を正確に表しているが、読みにくいもの

など、なかなかバランスが取れないものばかりでした。

もうすこし具体的に言うと

  • 色はワードごとに変えるのか?透明度は?
  • 出現したら場所は固定か?流動するか?
  • 大小をフォントサイズで表現するか?文字の領域の面積で表現するか?

などです。ちなみにフォントサイズで表現したほうが面積よりも正確に見えます。

これらの他に、ニュースマップボロノイ図なども検討しましたが、やはりしっくりきません。

Box2dで中央に配置

  • データの大小を美しく配置する
  • 日毎のデータの推移がわかりやすいようにする

という、二軸を重点に置きました。これが数多く試した中で、いちばんしっくり来た結果でした。

Box2dという物理演算ライブラリをつかい、画面中央に引力がある状態にし、自然と中央に集まるようにレイアウトしています。また、検索ワードの時間軸での移り変わりもわかりやすくなりました。

image

また、ずっと見ていても飽きないようにするには気持ちよいモーションだけでは持ちません。「おっ」と目を引く気持ち悪さもアクセントとして必要です。気持ちよさと気持ち悪さを絶妙のブレンドで仕上げています。

高速プロトタイピングで正解に近づく

どんなデータになるのか?どのくらいの量になるのか?どうすれば見栄えと意味を両立できるのか?

まったくの未知の課題であり、一発で正解にたどり着くことはありません。

効率よくスピーディに確かめるほかありません。

  • Flashでいろんなパターンをサクッとつくる
  • gitでいろんなバージョンを作りまくって巻き戻ったりできるようにする
  • 自分でデータを整形する
  • gruntですぐさまテストアップして確認してもらう

というサイクルを高速に回せればいい感じでした。

Flashで画面作成 + Nodeでデータ整形して、すぐに画面で確認する

Webで公開するのとあわせて、映像用素材としても書き出しが必要だったのでFlashで作っています。他の案件でCSS3 AnimationやCanvasゴリゴリしたりしてますが、やっぱりFlashだとできることが多いくて速いですね。

データ整形ですが、バスキュールでは他の案件でもビッグデータのビジュアライズをやっていますが、MySQLでデータを解析 + JSON書き出しという手段も使っていました。

が、どのようにデータを整形してどのようなJSONにすべきか?というのをサクッとやってしまわないといけなかったので、

NodeでCSVパース → ゴニョゴニョ → JSON 

としました。Nodeじゃなく、rubyでもpythonでもなんでもいいんですが、Nodeも手軽で楽ちんです。

あと、データはものすごく偏りが出る場合もあったり、震災直後はものすごく大きな数字だったりするので、対数変換などを使って慣らしていました。


こんな感じでいろいろいじくって、きれいな落とし所を探っていました。

gruntですぐさまテストアップ

を書くには長いので、Qiitaにでも投稿します!

みんなで「3.11」を検索しましょう

僕も阪神大震災を体験しています。友だちが死にました。毎年1.17になると「そいつのぶんまで生きよう」だとか「ダラダラ生きてきて、おれはそいつのぶんまで生きてないじゃないか」などという思いで心臓の下のほうが黒い煙でモヤモヤします。毎年です。

「3.11」は、とりわけ多くの感情がネットに広がっていることと思います。

自分の手で検索して、ネットの空間に存在している、誰かの何かの思いを見つけてみてはいかがでしょうか?

  • Comments (Close): 0
  • Trackbacks (Close): 0

[FlexUnit] 〜テストの拳〜 世紀末終わったけど、Flashまだ終わってないし、あべし言いたくないし、FlexUnitでテストする?

200X年!世界はSNSの炎に包まれた!

Tweenは枯れGraphicsは裂け・・・・・・あらゆるノウハウが絶滅したかにみえた

・・・・・・だが

・・・Flashは死に絶えてはいなかった!!

別に伝承するほどでもなく、簡単だったFlexUnit

SNSの登場とスマホアプリの普及、もはやAPIを叩かない日はなくなりました。そしてAIRやゲーム用途への接近によるFlashのアプリ化が起きています。しかし、制作はいまだレガシーな根性スタイルであることが多いかと思います。

とはいえ普段の開発では「ダミーのボタンを作ってAPIとの通信をテストする」というテストもどきをやってると思います。

テスト駆動開発とはそれを体系立ててやるだけです。ルールがあるぶん、むしろ楽だったりします。

ながれ

  1. testフォルダをつくる
  2. テストコードを書く
  3. Run/Debug Configurations(実行の構成)にてテストランナーの設定
  4. テストを走らせる!

うん、むずかしくない!

あべしと言わせるテスト(奥義)を書こう!

 [Test]
 public function 絶叫テスト():void {
    Assert.assertEquals('あべし', zako.断末魔());
 }

これだけ!簡単!Functionの上に[Test]って書くだけでテストコード! 伝承しやす!
でも!読みにくい!なにこれ!

さっそくテスト(奥義)も覚えたし、もうちょっと読みやすいテスト(奥義)を書こう

さっきのテスト(奥義)を日本語化すると

「’あべし’はzako.断末魔()を実行したときに期待される値である」

と、なんだかとても読みにくい。

なので、hamcrestというライブラリを使うと↓みたいな書き方になる。

assertThat(zako.断末魔(), equalTo(‘あべし’))

「zakoが断末魔()すると、’あべし’になる」

となり、こっちのほうが読みやすいね!

ちなみに、テスト(奥義)は最初に一発目は必ず失敗するのがルールなので、シンとかサウザーのことを思い出してやってください。

非同期のテスト(奥義)をしよう!

あんまり覚えたくないのでひとつだけ覚えよう!

image

 [Test(async, timeout='1000', description='お前はもう死んでいる')]
 public function 非同期のテスト():void
 {
      var context:Object = {};
      var you:Function = Async.asyncHandler(
          this, function (event:FlexEvent, ctx:Object):void {
               assertThat(context.result, equalTo('死んでいる'))
          }, 1000);

      var timer:Timer = new Timer(500, 1);
      timer.addEventListener(TimerEvent.TIMER, function(e:*):void{
          contenxt.result = '死んでいる'
          you();
      });
      timer.start();
 }
  1. metaデータに[Test(async)]を入れる (これは奥義じゃない)
  2. Async.asyncHandlerで待ち状態にする (秘孔をつく)
  3. 非同期が終わったら、Async.asyncHandlerで作った非同期待ち関数を叩く (決め台詞をいう)
  4. おわり (死んでいる)

非同期なときのassertcontextみたいなオブジェクトを作って受け渡しするいい感じにテストできるかと思います。

これ以外にも非同期のメソッド(経絡秘孔)はあるみたいだけど、とりあえずこれ(奥義)を一つ覚えたらいいんじゃないかな。

以下、IntelliJ IDEA(すごい伝承者)でテストを走らせるやりかた

FlashBuilder(アミバ)でもだいたい同じかと思われます。IntelliJ IDEAもFlashBuilderもFlexUnit(奥義)を簡単に使えるようになってるので、この上なく楽です。

FlashDevelop派のひとはこちらの記事がよさげ

–ここからIDEAでの設定–

  1. Testディレクトリの設定
  2. Run/Debug Configuration (実行の構成)
  3. できたら実行ボタンを押す

1.Testディレクトリの設定

testディレクトリを作る→右クリでMark as → Test Source Root

testディレクトリ

ここにテストコードを書いたクラスをほりこんでいきます

2.Run/Debug Configuration (実行の構成)

実行の構成
実行の構成の追加。FlexUnitを追加する。

testディレクトリ
FlexUnitの設定

  • All in Package → パッケージ内の[Test]が書かれてるやつを全部実行
  • Classかスイートの実行
  • メソッド単位で実行

普段はパッケージ単位かClass単位で設定してテストをすると、実行時間も短くて楽です。

3.できたら実行ボタンを押す!

右下にFlexUnitの実行結果が出る!ここがグリーンのバーならOK
成功

失敗すると赤になる
失敗

IDEAでのtraceのだしかた

ながれ

  1. Run/Debug Configurations → Optionsでログが出るようにする
  2. 実行をすると、ログが見れる
    • (デバッグ実行では出力されたり、されなかったりと不安定)

やりかた

Run/Debug Configurations → Optionsでログが出るようにする
config

デバッグでなく、実行をする(Shift + F10)
config

すると、エラーでテストが止まったときにもログが出る。

テストに16秒くらいかかることがある→デバッグ実行でなおる

config
さっきまで2秒前後で終了していたものが、突然16秒になることがある。

そのときはデバッグ実行をすると直る。

これで救世主になれたかな?

これだけテスト(奥義)できるようになったら、もう、まちがいなくバグはない!!

なので「バグってます」と言われたら、こう言い返そう!

image

つぎの世紀末まで、いっしょにがんばろう!

AIRあげぽよ~!iPhone/Android両対応アプリを本格的に作ったよ!のまとめ

Flashはオワコンですか?そんなFlashのAIRでiPhone/Android両対応アプリを作りました。

ぼくはObjective-CでもPELOというアプリを作っていたのですが、Objective-Cは難しいなあーという印象でした。

そんな折に、AIRが3にバージョンアップし、動作速度が改善されたり、ANE(AIR Native Extension)でネイティブとのやりとりができる(要するに何でもできる)ようになって、なかなかいい感じに仕上がっていると聞き、仕事で使ってみました。

まだ本格的なAIRアプリが出まわっていないこともあって、世間的にも実際どうなの?というところなので、今回ざざーっとFAQ方式で書いてみますネ!

その前になんのアプリを作ったかといいますと、スポーツ応援アプリです。ぼくの所属する会社バスキュール号が「ソーシャルスタジアムシステム(Social Stadium System)」というスポーツ観戦応援システム開発しており、その仕組みを載せたAIRアプリを先日リリースしたのでした。

とりあえず、AIRのポイントを6つ!

まずざっくり6つ挙げましょう。

  • 20~30FPSは出ます。軽快です
  • 普通に作ればアプリが落ちたりしません
  • ANEがあれば、なんでもできます
  • AppStoreの審査にちゃんと通ります
  • ハマりポイントを抑えておけば、それほどハマりません
  • Flashそのままで作れてワークフローがそんなに煩雑じゃない

思ったより全然イケてました

イメージとしてはスマホの機能(カメラやセンサーとか)も使えるFlashPlayerがそのまま入ってる感じです。

Objective-Cはデザイナーには難しいと思うし、iPhoneアプリでアニメーションしようとしても、けっきょくFlashで作ってスプライトアニメーションに変換して……、とかそんな手間があったのが夢のようです。まったく楽ちんです。

動作速度は?

  • 思ったより速くて、20~30FPSくらいは出ます。
  • 描画モードにRenderModeというものが3つあります。
    • CPUレンダリング(ふつうのFlashと同じ)
    • GPUレンダリング(GPU使う。Flashのフィルター系エフェクトが使えない)
    • Direct(Stage3D、StageVideoを使うときに使う)
  • AndroidだとCPUが速くて、iOSだとGPUが速いです。iOSでGPUだと頑張らなくても60FPS出たりします。

使用メモリは?

  • 2010年前半までのAndroidの端末では使用メモリ80MBを超えると落ちちゃうらしいですが、むちゃくちゃでかい画像を大量にロードしない限り大丈夫です。
  • 作り方や画像の大きさによるところですが、普段は20~30MBくらいに収まるかと。

容量は?

  • AndroidはSWFの容量とほとんど変わらないです。
  • というか逆に軽いくらいです。SWFだとSWFの中で透過PNGをJPG圧縮したりできるので、大量の透過PNGを用意するより、ひとつのSWFのほうがずいぶんと軽いです。
  • ただ、AIRランタイムを同梱すると7-8MB増えます
  • iOSはAIRランタイムを同梱するので7-8MB増えます

ガベコレ、メモリリーク

  • Flashと同じく、きちんとやってくれているようです。
  • Objective-Cのように、すっごい気を使う必要はありません。

アプリは落ちないか?

  • きちんと作ればまったく落ちません。
  • 今回作ったアプリがスポーツ応援アプリということで2時間ずっと立ち上げっぱなしが求められていたのですが、落ちませんでした。
  • ただ、iOSではASでエラー処理をハンドリングしないと落ちます。
  • メモリリークも、ちゃんと画像を消すとか、要らなくなったものは消すとか、そういう基本をおさえればOK

通信速度は?

  • Twitterのアイコンを10000個ほどロードするテストを行いましたが、バリバリイケてました。
    • iOSではまったく遅くない
    • Androidはちょっともたつく
    • 感じでした。Androidはネイティブでも遅いので、それのせいかもしれません。が、特に落ちたりメモリリークしたりもまったくなく完璧でした

AIRで特別おぼえないといけないことは?

  • AIRじゃないけど、スマホアプリ制作に必須な知識と手間がいります。
    • 証明書・プロビジョニングファイルなど
  • Objective-C / javaはまったく覚える必要はないです。
  • Flashと違い、以下のポイントを抑えておけばよいでしょう。
    • アプリケーションの起動と終了
    • ローカルファイルの読み書き

ANEって難しい?

開発環境は?Flash CS5.5? FlashBuilder?

  • コードはFlashDevelopで書いて、デスクトップAIRとして書きだして作っていました
  • 実機転送するときは、最初はFlashCS5.5でやっていましたが、途中からFlashBuilderにしました。
  • FlashBuilderだと高速パッケージングというのがあって、10秒くらいでiOSのパッケージを作ってくれます。
    • (FlashCS5.5だと1分30秒くらいかかります。大規模になればもっとかかる)
    • Androidへの転送もFlashBuilderのほうが楽でした。デバッグもやりやすいです

開発期間は?

  • 普通のFlashを作る+iPhone/Android個別対応分、とハマりポイントでのタイムロスとかを考える感じです。
  • はじめてのときは単純にFlashの2倍くらいを考えればいいのではないかと思います。慣れたら普通のFlashと同じになると思います
  • 習得が容易ではないObjective-Cに比べると、非常に楽チンです。AIRのハマりポイントもあるので、そこをいかに速く抑えるかがポイントではないかと思います。
  • 一人ではやらないほうがいいです。検証するひとと、開発するひと、最低2人は必要だと思います。

簡単に作り方を教えて!

  • iOS
    • iOS dev Centerにて、デベロッパー登録→お金払う→証明書やプロビジョニングを取得
    • FlashCS5.5 or FlashBuilderでipa書き出し
    • iTunesかiPhone構成ユーティリティで実機に転送
    • リリース用にはリリース書き出しして、AppStoreに提出→審査
  • Android
    • 証明書を準備(FlashCS5.5 / FlashBuilderで作れる)
    • FlashCS5.5 / FlashBuilder で書き出し→そのまま実機に転送
    • リリース用にはリリース書き出しして、GooglePlayで登録

作成にあたって参考にしたものとかある?

AIR書き出しの際に、書いたらNGな関数があれば

  • 意外なことに、とくにないです

何故AIRだったのか?(Webアプリ・HTML5/CSS3じゃダメなの?)

  • アニメーションが楽
    • HTMLでアニメーションをやろうとすると結局Flashから書きだしてJSで制御、という流れもあって、画像入れ替えが生じたときも煩雑…。
    • まだ制作フローが完成されていないので、まだまだこれからというところですかね…。
  • クロスコンパイル
    • 少人数でiPhone/Android対応ができる、というのはお金的な面でも工数的な面でも品質的な面でも有利です

ハマりポイントは?

  • たくさんありましたよ…。それはまた別の機会に…。

まとめ

Flashそのまま作れてしまうし、よくわからないObjective-Cやjavaも覚えなくていいので、AIRだととにかく楽でした。

あと、やっぱりデバッグのしやすさ、アニメーション/演出の作りやすさはピカイチですね。

もちろん、ネイティブのUIフレームワークを使ったほうがよいアプリもたくさんあると思うので、適材適所ですが、Flash的なアプリだとばっちりなんじゃないでしょうか

またこんどはAIRのハマりポイントについて詳しく書きましょうー!

ご清聴ありがとうございました。

BulkLoaderで「もう悩まない!」ための6つのtipsをまずは14日間で売上No.1!!

海外製のライブラリは日本語の情報が少なくて、英語のASDocやwikiを見たりしますよね。でも英語って読むのが難しいですよね…。

僕なんかね、キィーーッ!!ってなりますね。ぜんぜん読めないから。みなさんもキィーーッ!!ってなってますよね。でもBulkLoaderに関しては安心してください。もう、傷つく事に怯えなくていいんです。

BulkLoaderプロジェクトのDebeloperGuideってところにおトク情報がありました

BulkLoaderに同梱されているサンプルはほとんど説明がないのですが、GoogleCodeのプロジェクトのwikiに結構な情報がありました。

http://code.google.com/p/bulk-loader/wiki/DeveloperGuide

このうち、おトク情報を6つピックアップすることにしました。
以下目次がわりのページ内リンクです。

  1. weightプロパティで各Itemのパーセントの重み付けをして、精度のいいパーセントを取得する
  2. BulkLoaderのインスタンスはプールされている
  3. stringSubstitutionsでパスの切り替えなどができる
  4. 設定を外部ファイル化して勝手にロードしてくれるLazyBulkLoader
  5. add()するときのプロパティ一覧
  6. 一つでもエラーがあると止まってしまうから、エラーハンドリングしとこう

1. weightプロパティで各Itemのパーセントの重み付けをして、精度のいいパーセントを取得する

この間「超便利なローダーBulkLoaderの落とし穴にハマってきました」という記事を書きました。その中で、パーセント取得がちょっと難しいなーという話をしました。

よくよく調べてみると、もうひとつ打つ手がありました。

BulkLoaderのドキュメント・見出し「By weight」のところ
http://code.google.com/p/bulk-loader/wiki/ReportingLoadingProgress

ここをかいつまんで説明しますね。
あと、これから「Item」と呼ぶものは「ロードするもの」っていう意味で使います。

weightってこんな感じで動いてる

  • ロードするItemが10個あって
  • それぞれのItemにweightが設定されていない

というケースでは、各Itemに割り当てられるパーセントは1/10、つまり10%ずつです。

このうち1つのItemがFLVなどで他のファイルより重いときにweightを設定します。この重いItemをweight=11と設定しましょう。あと、Itemのデフォルトのweightは1ということを覚えておいてください。

_bulkloader.add("hoge.flv", { type: BulkLoader.TYPE_VIDEO, weight: 11 } );

すると、

Item 割り当てられるパーセント
weightを11にしたItem 11/20
他のItem 1/20

こんな感じであがります。元の分母はItem数なので10。それに、増えた重みを足して10+10で分母が20になります。たぶん!これで、FLVのパーセントが55%分を占めるようになり、期待している値に近づきました。

このweightが設定されたパーセントを取得するにはweightPercentを使用します。

weightPercentでもうすこし正確なパーセント表示

BulkProgressEvent.weightPercentにweightを考慮したパーセントが入っています。

(item._bytesLoaded / item._bytesTotal) * item.weight;

いたってシンプルですね。こういった形で加算されていくので、かなり実際と近いパーセントが取得できそうです。

weightの設定にひと手間かける分、ratioLoadedbytesLoadedよりもわりと正確な値を取得できます。

2.BulkLoaderのインスタンスはプールされている

BulkLoaderのインスタンスはBulkLoaderクラスの静的なプロパティに保存されていて、いつでも再利用できるようになっています。

BulkLoaderクラスのstaticメソッドには取得・破棄の2種類があります。

//インスタンスの取得
BulkLoader.getLoader(name);

破棄メソッドについては、すべてのBulkLoaderインスタンスを削除するものしか用意されていないようです。

BulkLoader.removeAllLoaders();

再利用しないのであれば、removeするのがいいでしょう。

3.stringSubstitutionsでパスの切り替えなどができる

ロードしたいパスに変数ぽいものを仕込んで柔軟性を上げることができます。

_bulkLoader.stringSubstitutions = {
	"base_path": "http://example.com/test/"
}
_bulkLoader.add("{base_path}test.jpg");
// これが→http://example.com/test/test.jpg に変換されます。

テスト用パスと、本番用のパスを変えるときに便利そうですね。

4.設定を外部ファイル化して勝手にロードしてくれるLazyBulkLoader

ロードしたいItemとその設定を書いたxml・jsonを書くだけで、自動でロードしてくれるクラスがLazyBulkLoaderです。以下の2種類あります。

  1. LazyXMLLoader
  2. LazyJSONLoader

xml・json内部で設定できることはasで書けることとほぼ同じだと思われます。以下のxmlを見るとよくわかります。

BulkloaderのLazyサンプルに同梱されているサンプルxml

使い方はBulkLoaderのサンプルに含まれている
/examples/serialized-loaders/SerializedTestMain.as
に書いてあります。

使い方は簡単です。

lazy  = new LazyXMLLoader("http://www.emptywhite.com/bulkloader-assets/lazyloader.xml", "theLazyLoader")
lazy.addEventListener(LazyBulkLoader.LAZY_COMPLETE, onLazyInfoLoaded); //設定xmlを読み込んだときのハンドラ。特に何かするときだけ使う
lazy.addEventListener(Event.COMPLETE, onAllLoaded); //すべてのItemがロードされたら(いつもの)
lazy.addEventListener(ProgressEvent.PROGRESS, onAllProgress); //ロードのプログレス(いつもの)

AS側でやることがほとんどなくなるように見えますね。ロードしたあとのパースにしわ寄せがきますが、うまく使いこなせば楽になるかもしれません。

5.add()するときのプロパティ一覧

ASDocではわかりにくいので超意訳してみました。

プロパティ Classのconst データ型 説明
preventCache PREVENT_CACHING Boolean urlにランダム文字列を付与して、キャッシュを防ぐかどうか
id ID String getXML()などで取得するためのID。とくに指定しないとurlがIDになる
priority PRIORITY int 読み込みの優先順位。intが大きい順に読み込む。
maxTries MAX_TRIES int ロード失敗したときに何回リトライしにいくか。デフォは3
weight WEIGHT int weightPercentを使うときのパーセントの重み
headers HEADERS Array 追加のリクエストヘッダ
context CONTEXT LoaderContext or SoundLoaderContext 追加のContext
pausedAtStart PAUSED_AT_START Boolean VideoItemのみ。nestreamがロードした直後からVideoを再生するかどうか 

6. 一つでもエラーがあると止まってしまうから、エラーハンドリングしとこう

IO_ERRORやセキュリティエラーが発生したら、そのItemは失敗とみなされ放置されます。放置されると「すべてのItemがロードされました」というイベントCOMPLETEが呼ばれなくなります。

以下のようにエラーハンドリングすると、まあ、なんかできるでしょう!

_bulkLoader.addEventListener(ErrorEvent.ERROR, errorHandler)
private function errorHandler(e:ErrorEvent):void
{
 	//失敗したファイルをremoveする
	_bulkLoader.removeFailedItems();
 	//まだファイルのロードが残ってたら
	if (_bulkLoader.isRunning)
	{
		//コンプリートイベント待つなどする
	}
	else
	{
		//失敗したやつ以外は終了したので、終了処理に移る
		bulkLoadComplete(null);
	}

}

MultiProgressManagerのBulkLoaderのモデルも対応させました

ついでに、SparkにコミットしたMultiProgressManagerのBulkLoaderのモデルもweightPecentに対応させました。だいぶまともな動作になりそうです。

ハイ!ということでね!

今回はBulkLoaderを眺めるだけの記事でしたー。

特に何も茶々を入れなかったので、期待してくれてたみんなからは大ブーイングだね!むしろ大ブーイングの方が嬉しい!「今回みたいに普通に書いてよ。しょうもないこと書かんでいいから」とか思われたくないんです!

い、イヤー!心の声が聞こえるー!!それ以上言わないで!!やめてー!!ロマンティックとめてー!!もう、傷つく事に怯えたくないー!キィーーッ!!

複数ロードのプログレスを一本化できる「マルチプログレスマネージャー」で幸運パワーを掴め!

パーセント表示のとき、ちょっと面倒な複数のプログレスの監視

たくさん外部ファイルを読み込むコンテンツを作る際、ローディングの表示ををまとめるのって厄介だったりします。

そこで、あらゆるProgressEventをまとめちゃおうというクラスがマルチプログレスマネージャー(MultiProgressManager)です。

Spark Projectにコミットしました!

複数ロードのプログレスが多いと、ホントやっかいですよね!

最初のロード画面で、以下のような流れを行うFlashは比較的多いですよね。

  1. PreloaderからメインのSWFを読むプログレス
  2. xmlを読むプログレス
  3. 画像を読むプログレス
  4. 読み込んだ画像などからビルドするのに時間がかかるときのプログレス
  5. ようやくコンテンツがスタート

わかりにくい図にするとこのような感じです。
m_normal1

これらを最初にまとめて読み込んで、パーセントをうまく100%にまとめようとすると、下図のように、よくわからないことになります。
m_gonyo1

Preloaderがloader経由でmain.swfを読んで、そのプログレスを監視して、main.swf側でconfig.xmlを読んで、その中の…、ああー、もうややこしいわ!30歳近くなったし、将来に不安あるし、湿度高いし、イライラするわ!

そんな悩めるFlasherにお届けするのが今回のマルチプログレスマネージャー!

使い方はとても簡単!面倒だったパーセント表示が、たちどころにまとまります!

マルチプログレスマネージャーは、パーセント表示のMVCのM(モデル)部分

マルチプログレスマネージャーはモデルに徹します。大きな流れとしては以下の3点!

  1. MultiProgressManagerのインスタンスを作って
  2. それぞれのプログレスを見張るをモデルを突っ込むと、
  3. 全部をまとめて0~1までに変換された進捗率が吐き出されます
//マルチプログレスマネージャーのインスタンス生成
_progressManager = new MultiProgressManager();
//ローダーのプログレスを70%に設定して突っ込む
var loader:Loader = new Loader();
var model:AbstractProgressModel = new ProgressEventModel(loader.contentLoaderInfo, 0.7);
_progressManager.addProgress(model);

//他の素材読み込みを残り30%に割り当てて突っ込む
var urlLoader:URLLoader = new URLLoader();
_progressManager.addProgress(new ProgressEventModel(urlLoader, 0.3);

//読み込み開始
_progressManager.start();
loader.load(new URLRequest("main.swf"));
urlLoader.load(new URLRequest("config.xml"));

パーセント表示はMultiProgressManagerのイベントを監視するだけ。それもプログレスとコンプリートの2つだけ!

MultiProgressManagerを稼動させるとプログレスのイベントが通知されるのでそれをリスンします。

//このイベントにまとめられたパーセントのプログレスが入っています。
_progressManager.addEventListener(ProgressPercentEvent.PERCENT_PROGRESS, progressHandler);
//パーセントの完了イベント
_progressManager.addEventListener(ProgressPercentEvent.PERCENT_COMPLETE, completeHandler);

//プログレスのイベントハンドラ
private function progressHandler(event:ProgressPercentEvent):void 
{
	//パーセント表示を更新
	loadingBar_mc.scaleX = event.percent; //event.percentは0~1までのNumber
}
private function completeHandler(event:ProgressPercentEvent):void 
{
	trace("終了");
}

さっきのわかりにくい図が驚くほど簡単に!

担当すべきクラスを分けることで、みるみるあっさりしました!これこそ宇宙の波動!

m_result1

UMLっぽくするとこうなります(でっちあげのUMLです)
m_uml

モデルの拡張も簡単!いろんなプログレスに対応できる!

AbstractProgressModelを継承すれば、標準のプログレス以外にも対応できます。しかも、考えるのは2点だけ!

  1. progressイベントをリスンすることを書く
  2. 完了したときの処理を書く

を書くだけで簡単に拡張できます。同梱しているBulkLoader用のBulkLoaderProgressModelがまさにこれです。

「main.swfは全体の50%くらい、config.xmlは10%くらいで」といった、割り当てもサクっとできる!!

個別にプログレスを監視するクラス(AbstractProgressModel)にはpercentRangeというプロパティがあります。こいつが「main.swfは全体の50%にしよう」といったプロパティになります。

//50%で読み込む
var model:AbstractProgressModel = new ProgressEventModel(loader.contentLoaderInfo, 0.5);

下図のような割合でやるときも、引数を割り当てるだけで実現できちゃいます。

さらに、今回は「パーセントが上昇するときのスムージング(線形補完)」もお付けします!

new MultiProgressManagerするときの第二引数をtrueにするだけで、スムージングします。
いちいちView側で操作する必要がありません。

//引数は EnterFrameの監視にStage
//スムージングをtrue
//スムージングのfrictionを0.3
//パーセントがいっきに上がりすぎないための、最大の上昇幅
new MultiProgressManager(stage, true, 0.3, 0.05)

未対応なところもあるけれど、今後もっと成長する余地があるってことだネ!

  • エンターフレームで監視しているときに、常にProgressPercentEvent.PERCENT_PROGRESSを飛ばしている(以前のフレームと比較して、パーセントに変化がなければ飛ばさなくてもいいかも)
  • IOエラーなどは監視していない(これは監視しなくてもいい?ロードしてる本体が処理すべき?)
  • キャンセルがちょっと雑?

というわけで、みなさんの風水パワーを待ってます!

無人島でもくもくとやってきたので、ライブラリとはどういう流儀で、どのようなものが求められるのかあまりわかっていません。とにかくコミットしてみました。

「ここおかしい!」というところがございましたら、ガンガンつっこんでください!

サンプルの中身を普通に説明

サンプルも作りました。Sparkのリポジトリに入っています。

サンプルでは普通のFlashでありがちな流れをやっています。

  1. preloader.swf起動
  2. main.swf読み込み
  3. 設定xml読み込み
  4. 複数画像の読み込み
  5. パーセント表示の終了処理
  6. main.swfの表示開始

1.preloader.swf起動(Preloader.as)

2.preloaderがmain.swf読み込み(Preloader.as)

reloader.as 66行目付近から

  1. インスタンスの生成(シングルトンバージョンを使用します)
    SiMultiProgressManager.getInstance(stage, true, 0.3, 0.05);
  2. イベントハンドラの設定
  3. 読み込み開始

3.main.swfを読み終えたら、設定xmlの読み込み

  1. Preloader.as 95行目付近 mainLoadCompleteHandler内部で
  2. Main.as の86行目 start()を呼び、Mainの構築用のスレッドを開始します
  3. LoadConfigThread.as内部でxmlを読み込みます。

4.設定xmlに指定された複数画像の読み込み

AssetsLoadThread.as内部で複数画像の読み込みを行います。
ここではBulkLoaderを使って複数読み込みをまとめています。

5.読み込んだ素材を配置していきます

複数読み込みが終われば BuilderThread.asで配置します。

6.パーセント表示の終了処理

  1. すべての読み込みが終了し、パーセントが100%になったら、パーセント表示をフェードアウトさせて消します。
  2. Main側ではOpenContentsThread.asでパーセント表示が消えるまで待機状態になります。
  3. Preloader.as の116行目付近 completeHandler()が呼ばれるので、そこでパーセント表示をフェードさせます。

7.main.swfの表示開始

パーセント表示のフェードアウトが終わったら、待機していたOpenContentsThreadが動きだし、mainの表示を行います。

ハイ!ということでね!

そないたいしたクラスでもない上に、書き方の幅ちょっとを広げようとして、また失敗してしまいました。「イライラするわ!」のくだり以降、途中で飽きてきてるのもわかりますね。

はい。今回の記事はスクリーンセーバーの記事で使う予定のライブラリの説明でもありました。複数ロードを使うので、ここらで説明する必要があったのでした。

あと、Threadライブラリにも影響を受けてます。ほんとはThreadのIProgressも対応したかったのだけど、まだまだ理解不足なので次のバージョンで対応とかしたいです。

あーあ、なんつーか、輝いてへんわ。ガイアのやつ、ぜんぜん囁いてくれへんから輝きもせえへんわ。全部ガイアのせいや。ガイア君、どこいってもうたんや。

更新できるスクリーンセーバーを作ろう(3):fla:verでの制作の流れと注意点

前回では作る手前の話をして、ずいぶんウコンウコンしましたね。またfla:verの開発者さんからもコメントがありました。自動更新に対応してくれるかもしんない!スゲー!応援して待ちましょう。

さて、今回からは技術的なことをお話したいと思います。具体的なコードの手前、設計まわりから見ていきましょう。

fla:verでの制作の流れ

Macで再生するときにいくらかの地雷がありますが、知っていれば回避できるので恐くありません。

1.小さなプレビュー画面かどうか

fla:verでは、小さなプレビュー画面でもスクリーンセーバーの本体(swf)が再生されます。小さなプレビュー画面とは以下のものです。

  • Win「画面のプロパティ→スクリーンセーバー」上の小ないプレビュー画面
  • Mac「システム環境」→「スクリーンセーバ」上の小さなプレビュー画面

そのまま本体のswfを再生すると画面サイズが小さすぎて不都合が生まれることも多いので、ここで分岐をとり、プレビュー画面ならプレビュー用の画面を見せる、といったことをします。

スクリーンセーバーで再生されているとFlashvars"flavermode"にプレビューかどうかのstateが入ります。

trace(stage.loaderInfo.parameters["flavermode"]) //preview プレビュー
                                                 //normal  スクリーンセーバー再生時
AS3での簡易チェックコード
 public static function isPreview(stage:Stage):Boolean
 {
 	var mode:String = stage.loaderInfo.parameters["flavermode"];
 	var result:Boolean;
 	switch (mode)
 	{
 		case "normal" :
 			result = false;
 			break;
 		case "preview" :
 			result = true;
 			break;
 		default :
 			result = false;
 			break;
 	}
 	return result;
 }

補足)previewのときでもstageWidthとheightがゼロじゃないかをチェックする必要があります。Macでは初期値がゼロになります

2.ネットワークチェックとSWFの縦横サイズがゼロじゃないかのチェック

2-1.ネットワークにつながってるかどうかのチェック

  • ネットワークにつながっていれば、サーバから最新の情報をダウンロードする
  • ネットワークにつながっていなければ、ローカルに同梱したファイルを見るようにする

実装方法は外部サーバの適当なファイルに接続を試し、IOErrorが返るかどうかでチェックをします。

という分岐があるので、ここでネットワークのチェックをします。

チェックするファイルにはキャッシュ対策をする

スクリーンセーバーもファイルをキャッシュするので、対策を施します。以下のような簡単なもので大丈夫です。

new URLRequest(url + new Date().getTime());

2-2.stageWidthとstageHeightがゼロじゃなくなるまで待つ(Mac対策)

Macで再生するとstageWidthとstageHeightの初期値がゼロになり、意図しない配置になります。以前のエントリに詳しい実装方法を載せていますので参考にしてください。

SWFObjectのDynamic Publishingを使うとIEとかでStage.stageWidthとheightが一瞬ゼロになるという都市伝説は実在した! | Katapad Design

3.外部設定ファイル読み込み

外部の設定ファイルを読みに行きます。この設定ファイルには

  • 本体となるswfが最新の状態かどうか
  • 読み込む素材はどれどれ

などといったことを記述しておきます。

4.素材読み込み

外部設定ファイルに書いてある素材を読み込んでいきます。

たいていの場合、複数の素材を読み込むことになるので、まとめて読み込めるローダーを使うと便利です。僕はBulkLoaderを使ってガスガス読み込みます。BulkLoaderについてはこないだ書いたのも参考にしてください。

また、すぐに必要のない素材は少しずつ先読みしていくだけのプリローダーを裏で動かし、キャッシュ化しておくと効果的なケースもあります。ドデカいFLVとかは厳しいかもしれませんが、いずれすべて読み込むことになるのなら、ささっと読み込んじゃいましょう。

5.コンテンツビルド

素材のロードが終わり、さまざまな設定を格納したら、ページや配置する画像などの要素をビルド(生成して配置)していきます。

6.コンテンツスタート~ループ

要素の準備ができたら、やっとコンテンツをスタートできます。

スタートさせればあとはループするだけです!

さてさて、大雑把なスクリプトの流れはご理解いただけたでしょうか?ちょっと駆け足過ぎたかもしれないですね。

続いてはちょっとした注意点を見てみましょう。

知っておくと健康にいい注意点4つ

mailto:でメーラー立ち上げようとすると、ブラウザまで立ち上がってしまう

winならIEも開いてしまうので、実質使えません。

「友達に教える」機能を付けるときはWebサイト側にリンクを貼って、

  • 「友達に教える」フォームを用意する、もしくは
  • mailtoのリンクを置く

のがベターです。

インストール時に一緒にインストールされる追加ファイルにフォルダを作れない

fla:verではどの素材も、スクリーンセーバーの本体となるswfと同じ階層に置かれてしまうので、素材の名前付けに注意しましょう。

これには前回のコメント欄で開発者さんが補足してくれました。セキュリティ的に階層がない方がいいそうです。

スクリーンセーバーを再生している途中で「ネットあり」→「ネットなし」になったら落としたほうがいいときもある

途中で設定を「ネットあり」から「ネットなし」に変更すると大変な労力が必要になることがあります。ならば、いっそのことスクリーンセーバーを強制的に落としてしまいましょう

スクリーンセーバーが再生されている=「PCが放置されている状況」が多いので、落としてもしばらくすると「ネットなし」としてスクリーンセーバーが立ち上がります。

ロードする状況化でIO_ERRORなどを見張っておいて、エラーがでたらスクリーンセーバーを落とすコマンドfscommand("quit");を叩くようにします。

あと、落とす前にエラー画面として

「ネットに繋がらなくなったので、落としますね」

と出すのが優しいかと思います。

Macでマウス操作などを許可しているときにブラウザを開いてもスクリーンセーバーが落ちない

マウス操作許可し、親サイトへのリンクやRSSのリンクを張ったりすることがあります。Windowsではリンクを押してブラウザが開くタイミングで、スクリーンセーバーも一緒に落ちてくれます。

このケースではMacでうまくいきません。スクリーンセーバーが落ちずに、裏でブラウザが開きます。ですので、明示的にスクリーンセーバーを落としてやる必要があります。


//リンクを押したら、落とすことも明示する
navigateURL(~~~);
fscommand("quit"); //スクリーンセーバーを落とすコマンド
		

インストーラ用の素材:アイコン素材と背景画像を用意する

http://flaver.jp/からProfessional版をダウンロードし、実際のインストーラがどんなものかを体験してみてください。
シリアルを入力せずに開始すると「試用版」になるので、気軽に試せます。試用版ではスクリーンセーバーを再生したときに「試用中です」と文言がでますが、すべての機能が使えます。

windows用の素材

アイコン素材 icon形式。48、32、16をそれぞれTrueColorと256色を用意します。vista用に特大サイズのアイコンを用意してもいいかもしれません。
IcoFXというソフトを使うと簡単に作れます。IcoFXはMacのicns形式も作れます。
インストーラ画面用の画像 64px * 294px: png, jpg

mac用の素材

アイコン素材 icns形式。img2icnsというソフトが簡単です。
インストーラ画面用の画像 最大567px * 320px: png, jpg

さてさて、こうして骨組みは出来上がりましたね。いっきに説明したので、わけわかんないところもあると思います。

今回もまじめに書いてしまいました。楽しみにしてくれていたみなさん、本当にすみません。ただ、頭にパンティーをかぶって記事を書いていたことだけは覚えておいてください。

次回は実際にサンプルを作ってみましょう。

スクリーンセーバーのことシリーズ

大阪teraco23でRed5のことを話してきました

大阪てら子23に参加してきました。発表する人がたくさんいて、とても有意義でおもしろかったです。みんなすごいんです。刺激的な一日でした。

僕はRed5というFMSクローンアプリの軽い紹介をしてきました。

マルチユーザのサンプル・ENGACHO

発表内容のスライド(wiki)

サンプル http://lab.unko.me/engacho/
(サーバの問題で期間限定です。1ヶ月くらいたったら消えます)

Red5を使ったマルチユーザのサンプルです。一人でやってもまったくつまらないので、お誘いあわせの上、触ってみてください。人数が多いとほんのすこしだけマシになります。

  • unkoに触れるとunko状態になります
  • unko状態で他のユーザに触れると伝染します
  • unko状態でステージ左に配置されてるハブラシでこすると、きれいになります
  • 右上のフキダシに触れると、感情を表示します(キーボードの1~4でもできます)
  • コナミコマンドを叩くと全員が感染します
  • よくグダグダになります。グダグダになったら広い心でリロードしてあげてください

サンプルのスクリプトなど、細かい解説ができなかったので、ここで補足

sequence

サーバサイドの処理の流れ

  1. サーバサイドに接続されたら、サーバの中でアプリケーションインスタンスが生成される
  2. appStartが呼ばれるので初期化
  3. appConnect()で接続してきたユーザにユーザIDを発行して返す
  4. appDisconnect()で切断されたユーザからユーザIDを取り出して、SharedObjectにsetしたそのユーザのプロパティを削除する

といったことをしています。

クライアントサイド(SWF)の処理の流れ

  1. rtmpにコネクト
  2. ユーザIDを取得
  3. SharedObjectに自分のIDとデータ(マウスの座標などのプロパティ)を登録
  4. SharedObjectの更新にあわせて他人のマウスカーソルを追加する
  5. EnterFrameで描画の更新をする
  6. 接続が切れたらサーバ側で、切断されたユーザのプロパティをSharedObjectから消す
  7. SharedObjectのプロパティが削除されたイベントが飛んでくるので、それを受けて他人のマウスカーソルを除去する

といったことをしています。文字だとちょっとわかりにくいですね。

SharedObjectのSyncEventが鬼門で慣れるまでが大変ですが、けっこう簡単に作れそうな感じです。

サーバへのインストールとかはwikiで

実はひっそりとwikiを書いてたりしてました。メモなのでそこまで裏は取っていませんので間違いもあると思います。何かの役に立つかもしれませんのでそんな目でみてもらえると助かります。

その他わけわからん現象とか作った感想とか

マウスのロールオーバーがおかしい(追記:意味がわかった!

マウスのロールオーバーが、左から右へマウスを移動しているときにしか利かなかったり、おかしな挙動をしています。
右上のフキダシも同様、マウスの移動方向でおかしくなってます。
追記:カーソルに色をつけたかったので、Mouse.hide()をして、カーソルのビットマップを置いているのですが、そこに問題がありました。mouseChildrenをfalseにすればokぽいのですが、衝突判定をhitTestObjectでやっていて、mouseChildrenをfalseにするとhitTestが効かなくなってしまいます。とりあえず放置!
ストーリーや目的、オチがないと、劇的につまらない
これがいわゆる出オチというやつです!

反省

スライドを作って行かなかった

htmlをスクロールして見せてました。u-stream見てる人には文字が細すぎて見えてなかったかと思います。次はそのへんを改善します。

何をしゃべってるのかわからなかった

スライドを読み上げているだけだったなーと思います。ここが一番の失敗でした。スライドと原稿をわければよかった。

芸風がダメなんじゃないかと思った

国道43号線ネタはしばらく公の場では封印します。ポップさが圧倒的にたりませんでした。そんで新しいのを考えました。二次会で期待してください。

収穫

作ることはいいこと

「どうやって楽しませよう」とか「どうやって驚かせよう」とか、久しぶりにそういうことを考えれてよかったですし、なにより反応を間近で見れるのはいいですね。稚拙な内容でしたが、ライブ感が楽しかったです。今度はもっとクオリティをあげていきます。

更新できるスクリーンセーバーを作ろう(2):作成ツールを比較したらどれも一長一短あるね!

前回はスクリーンセーバーの基礎知識や周辺などを考察し、ずいぶんアヘアヘしましたね。
今回はスクリーンセーバー作成ツールの比較をしましょう。

スクリーンセーバー作成ツール比較

まずはおおまかな特徴だけを比較してみましょう。GIZMOはまだ使ったことがないので、サイトの情報から推測してたりします。

  スクリーンタイム fla:ver GIZMO
vista対応 非公式
MacLeopard対応 まだ(でもベータ的なものはある)
FlashPlayerのバージョン win:Player8まで
Mac: Player9まで
制限なし たぶん制限なし
as3対応 ×
再生の有効期限 ×
ローカルディレクトリ、
ファイルの操作
× たぶん○
自動更新 × ×
スクリーンセーバー
停止方法が複数ある
日本語入力 たぶん× 不明
外部ファイルを
インストール時に追加できる
不明
外部ファイルの
ディレクトリを保つ
× 不明
マルチモニター再生の選択肢 ×
(すべてのモニターで再生される)
win版とmac版の
合計価格
74,550円 34,800円 320,000円~
(winのみ?、macは不明)

スクリーンタイム(ScreenTime for Flash)


http://www.screentime.jp/

特徴

  • いいところ
    • コンポーネントをfla側に埋め込んで「STFコマンド」を打つといろいろできる
      • ローカルファイルを読み書きできたりするコマンドがいろいろある
    • 有効期限付き
  • 残念なところ
    • AS2.0まで
    • vistaに正式対応してない
    • win版はFlashPlayer8まで
    • mac版はFlashPlayer9まで(AS2)
    • ヘルプがかなりわかりにくい

as2までしか対応していないなど、イケていない面もありますが、最大の特徴としてディレクトリを保ったまま様々な外部ファイルを同梱できるという強みを持っています。

また、スクリーンタイムにはコンポーネントのインストールmxpが配布されています。mxpをインストールすればFlashのヘルプにスクリーンタイムのヘルプが追加されます。

事例

昔はSTFしか選択肢がなかったようで、プリミティブなスクリーンセーバーによく使われています。

zozotownにたくさんあります(ログインの必要あり)
http://gallery.zozo.jp/

見分け方

  • winならインストーラの詳細に「会社名 FIVESTAR~~」と出ます。これは消したり変更はできないようです。
  • スクリーンセーバーのインストーラ画面(win)

    (スクリーンタイムではこの白場に任意の画像を埋め込めます)

fla:ver


http://flaver.jp/

特徴

  • いいところ
    • as3使用可
    • win, mac対応
    • 安い(Win/Mac2つのバージョン合わせて34,800円)
  • 残念なところ
    • 同梱させるファイルにディレクトリ階層を設けられない。
  • それ以外
    • winはActiveXプラグインFlashPlayer、macはsafariのプラグインFlashPlayerで再生する
    • ローカルファイルの読み書きはできないが、スクリーンセーバーとしての基本的な機能は網羅してある

大量のファイルを同梱させるとちょっと大変になりますが、問題がないといえば問題ありません。

それとスクリーンセーバーの再生の機能は強いですが、有効期限やネットワークにつながっているかどうかのチェック機能などもありません。しかし、そういった機能はFlashで代替できるので、ごまかせます。

事例

G’z One CA002 by CASIO
http://gzone.jp/
ぷっちょくんをつくろう!
http://create.pucchokun.jp/
Play MUJI
http://www.muji.com/playmuji/
エディックス(公開終了)
http://www.honda.co.jp/Edix/editSCR/

見分け方

  • スクリーンセーバーのインストーラ画面(win)

    (インストーラ左にある画像はfla:ver側で変更可能です)
  • macならスクリーンセーバーの設定画面のオプション→アンインストールというボタンがあります。

GIZMO


http://gizmo.anthill.jp/

スクリーンセーバー作成代行もしているが、基本的にはフォーマットに則ったswfを渡し、スクリーンセーバー化してもらうサービスとのことです。

Web Designing2009年 06月号のP64にHONDA INTERNAVIの事例とあわせてGIZMOのことも少し書いてありました。

特徴

  • いいところ
    • 自動アップデートあり
    • 超大手で使われた実績
  • 残念なところ
    • 高い

      http://gizmo.anthill.jp/service_screensaver_pack/

      • 初期費用 300,000円(税込315,500円)~
      • 月額費用 20,000円(税込21,000円)~

      (パッケージに、スクリーンセーバーにするFlashコンテンツの制作費用は含まれておりません。)

さすが高いだけあって、自動アップデートがついています。不明な点も多く、詳細は問い合わせなければなりませんが、いろいろカスタムできるようです。

簡単には試せないけれど、失敗が許されない状況や、それを凌駕するコンテンツならこれがベストなのでしょうかね。なにより実績があるのでとても安心できそう。

見分け方

  • winだと裏でGIZMOが立ち上がります
  • スクリーンセーバーのインストーラ画面(win)
  • macならsaverファイルの中を見るとGIZMOのフレームワークが入っています。

まとめ fla:verで十分、より安心感を求めるならGIZMO

案件規模にもよるでしょうが、fla:verである程度カバーできるかと思います。自動更新っぽいことも全部外部にすればなんとかなりますね。それ以上の複雑なことになればGIZMO、といったところでしょうか。

僕はこのfla:verで作るようにしています。次回はfla:verにおける制作のポイントをお話します。

あー、まじめに書いたよー、はぁーまじ疲れるわー、あー、あー、うー、う、ウコンー!!

スクリーンセーバーのことシリーズ

更新できるスクリーンセーバーを作ろう(1):最近の動向と消費者とのかかわりや基礎知識

昨年の末から「クライアントが更新可能なスクリーンセーバーを作る」というお題で5,6個作りました。そこで得た作り方やつまづきポイントなどをまとめてみます。ちょっと長くなるので数回に分けて連載してみます。

今回は基礎知識とスクリーンセーバー作成ツールの比較です。「作る前」の段階ですね。

スクリーンセーバーを配布する戦略と消費者意識

スクリーンセーバーはCRTモニタの焼きつき防止のためにあったそうです。しかし、最近の主流である液晶モニタでは焼きつきが起きにくいそうです。そんな進化の流れに逆行するように、スクリーンセーバーは流行しつつあります。

一般の方もPCの操作にもだいぶ慣れたのでしょう。壁紙を変えるように、あるいは昨日とは違うシャツを着るような感覚でスクリーンセーバーも簡単に変更できるような時代になりました。

また、我々の作るコンテンツは、ブラウザ上(Webサイトであり、ブログパーツである)から切り離され、スクリーンセーバーへと変化したときに、消費者の意識に変化を与えられると考えられます。ブラウザではユーザが主体となって操作をし何らかの体験を獲得しますが、スクリーンセーバーはまったく逆です。勝手に立ち上がり、映像や画像、つまりユーザの好きなものを流してくれるのです。

自分からアプローチしなければ振り向いてくれなかった人が、進んでこちらにアプローチしてくれる、といったことかもしれません。

あるいは、かっこいいサイトをクリップして自分のそばにおいておきたい、という所有欲求であるかもしれません。youtubeやDailyMotionから動画や音楽をぶっこ抜いて、iPodにぶち込むことと似ているとは思いませんか?

一見するとWebサイト化しているように見えるスクリーンセーバーではありますが、Webサイトとは別の道から消費者を刺激しています。

更新することで飽きさせないスクリーンセーバーに

天下のUNIQLOCKや、オサレなHONDA INTERNAVIも、更新されるコンテンツが楽しみの一つとなっています。

UNIQLOCK
http://www.uniqlo.com/show/
HONDA INTERNAVI REALIZATION
http://www.honda.co.jp/internavi/realization/#/downloads
Play MUJI
http://www.muji.com/playmuji/

スクリーンセーバーの変更を簡単にできるようになった今、簡単に変更させずに「チャンネルはそのままで」とさせるスクリーンセーバーが求められています。せっかく好意を持ってインストールまでしてもらった優良顧客の心を、いかに引き止め、惹き付け続けるのか。ちょっとした更新性を付加することで、そういったブランドイメージを構築するに十分な媒体になりえます。

でもね、僕は頭がパッパラパーだからこれより難しいお話は頭の上に放り投げて、次の話題へ移ろうと思うんだ!アヘアヘアヘ!!

スクリーンセーバーの基礎知識

さて、一通りアヘアヘしたので、簡単にスクリーンセーバーで気をつけることをリストしましょう。

  • いったん配布してしまうと、自動アップデートが難しいのでミスすると大変な目にあうかも
  • だいたいのスクリーンセーバ作成ソフトがwinとmac用に分かれていて、別々に購入する必要がある
  • スクリーンセーバー作成ツールはどれも一長一短ある

そんなたいしたことはありませんね。さて、次へいきましょう。

更新可能なスクリーンセーバーにするための3つの手段

更新可能にするには以下の3つの手段があります。しかし、ツールによってはできないことや苦手なこともあります。ひとまずこの3つの手段を押さえておきましょう。

1.サーバに設定xmlを置き、更新する

サーバにあるxmlを読みに行かせ、xmlで画像を変更したり、レイアウトを変更したり、などといったことをします。

2.スクリーンセーバーの本体となるswf自体をサーバに置いて更新する

サーバに本体のswfを置きます。読み込みに時間がかかるときもありますが、不具合があってもすぐに差し替えられる安全性があります。

3.ローカルファイルを置き換えて更新する

作成ツールによってはローカルファイルを書き換えてくれるものもあります。

ローカルファイルを置き換え、中身をごっそり入れ替えることが一番いいのですが、なかなか簡単ではありません。


さてさて、その辺も踏まえて次回は作成ツールの比較をしましょう。

See you next AHEAHE!!

スクリーンセーバーのことシリーズ

SWFObjectのDynamic Publishingを使うとIEとかでStage.stageWidthとheightが一瞬ゼロになるという都市伝説は実在した!

IEとかでstage基準の中央寄せができなくなることがある

特定の状況で一定時間、swfの「stageのwidthとheightがゼロ」になり、stageの中心にモノを置いたはずなのに、変な位置にきてしまうことがあります。今回はその問題を肩パッド探検隊が追います。

基本的な対処法は以下のblogにおまかせ!

崖っぷちWEBデザイナーブログ | stage幅取得のタイミングをテストしてみた

二番煎じですが、ちょこっと書いていきます。対処するクラスが見たい方はページ内リンクで!

SWFObject1.5、SWFObject2.1のDynamic PublishingでWinIEがダメで、MacのFirefoxも怪しいらしい。あとMacのFla:verで作ったスクリーンセーバーもダメ

SWFObjectのDynamic Publishingの場合

SWFObjectで空divを起点に動的にObjectタグを埋め込むやつをすると

  • IE全般
  • MacのFireFox

で、一瞬だけstage.stageWidthとstage.stageHeightが0になります。

Dynamic Publishingってのは以下のjsコードで空divに埋め込むやつです

//SWFObject1.5
var so = new SWFObject("hoge.swf", "topFlash", "100%", "100%", "8", "#FFFFFF");
so.write("flashcontent");

//SWFObject2.xならDynamic Publishingと呼ばれるタイプ
swfobject.embedSWF("hoge.swf", "flashcontent", "100%", "100%", "9.0.45", "expressInstall.swf", flashvars, params, attributes);
			

widthとheightがゼロになるサンプル

サンプルでテストしてみてください。
サンプルのasはこちら

  • wmodeはtransparent
  • 最初にstageの中心に文字を書こうとしますが、ダメブラウザだと文字が(0,0)にきます
  • swfの中心に「うんこ」と書かれたらOKブラウザ!
  • 崩れてたらStageの初期サイズが0のダメブラウザ。IEかMacのFirefoxです
  • traceされているテキストは以下です
    • 一発目にStageのwidthとheightをチェック
    • ENTER_FRAMEイベントと何回ENTER_FRAMEが回ったか
    • ENTER_FRAMEでStageのwidthとheightをチェック
    • stageのResizeイベント
    • stageWidthがゼロだったらADDED_TO_STAGEイベントを取得
    • それぞれのgetTimer

サンプルの結果

win
IE6~8 Firefox3 Opera9.6 Safari3 Safari4 chrome
×
キャプチャ
win_capture
mac os10.5
Firefox3 Opera9.6 Safari3 Safari4
(崖っぷちさんとこではMacのFirefoxでもアウトでしたが私の環境ではOKでした)

ENTER_FRAMEの方がRESIZEイベントよりも速くStageのwidthが変わったことを知る

このサンプルを作っていてわかったのですが、ENTER_FRAMEでwidthとheightを監視して、ゼロじゃなくなったあと(ENTER_FRAMEのイベントハンドリングが終わったあと)にRESIZEイベントが飛んできます。なので、無意味なタイムラグが生じます。

SWFObjectでの原因

SWFObjectの原因は以前のエントリで妄想を膨らませましたが、これは間違っていると思います。詳細ご存知のかた、おしえてください!

fla:verで作ったスクリーンセーバーをMacで再生するとき

fla:ver(http://flaver.jp/)というスクリーンセーバー作成ソフトで作ったスクリーンセーバーでも起こります。
ref) Mac OS X 10.5で MovieClip が表示されないことがあります

対処するクラスを作りました

大変つまらないクラスですがどうかご査収くださいませ
stagesize問題を対処したサンプルの実行結果

対処法について

  • Event.RESIZEよりEvent.ENTER_FRAMEの方がstageの幅高の取得が早いので、ENTER_FRAME監視がベター
  • dispatchEventしてるのは入口と出口を分けないため。
    (newする前にif(stage.stageWidth * stage.stageHeight != 0)を挟めばOKブラウザをスルーできますが、OKブラウザとNGブラウザで出口がバラバラになるとややこしいのでこうしました。)

クラスとサンプル

サンプルとソースzip

StageSizeChecker.as
package com.katapad.utils 
{
	import flash.display.Stage;
	import flash.events.Event;
	import flash.events.EventDispatcher;
	import flash.utils.getTimer;
	
	/**
	 * WinIEやMacFFでSWFObjectのDynamic Publishingをしたときにおこる
	 * Stage.stageWidthとstageHeightが0になる問題を
	 * EnterFrameで監視してチェックするクラス<br />
	 * Event.RESIZEが飛んでくるタイミングがEvent.ENTER_FRAMEより遅いので、
	 * EVENT.COMPLETEのついでにstageからEVENT.RESIZEも飛ばします(オプション)。
	 * 
	 * @author katapad.com
	 * @version 0.1
	 * @since 2009/03/17 3:40
	 * @usage
	 * <p>MainクラスやPreloaderクラスの最初に</p>
	 * <pre>
	 * var StageSizeChecker:StageSizeChecker = new StageSizeChecker(stage);
	 * StageSizeChecker.addEventListener(Event.COMPLETE, delayInit);
	 * StageSizeChecker.start();
	 * </pre>
	 * <p>を書いて、あとはEvent.COMPLETEの受取先で</p>
	 * <pre>event.target.removeEventListener(Event.COMPLETE, delayInit);</pre>
	 * <p>すればOK</p>

	 */
	public class StageSizeChecker extends EventDispatcher 
	{
		/**
		 * stage.stageWidthとstage.stageHeightが0以外になったら配信します。
		 * @eventType flash.events.Event.COMPLETE
		 */
		[Event(name = "complete", type = "flash.events.Event")]
		
		//----------------------------------
		//  static var/const
		//----------------------------------
		
		//----------------------------------
		//  instance var 
		//----------------------------------
		private var _stage:Stage;
		private var _isResizeEvent:Boolean;
		
		/**
		 * ステージサイズを見張り、ゼロ以外ならEvent.COMPLETEを配信します。
		 * @param	stage
		 * @param	isResizeEvent	_stage.dispatchEvent(new Event(Event.RESIZE))も同時に発動させるかどうか
		 */
		public function StageSizeChecker(stage:Stage, isResizeEvent:Boolean = true) 
		{
			init(stage, isResizeEvent);
		}
		
		private function init(stage:Stage, isResizeEvent):void 
		{
			_stage = stage;
			_isResizeEvent = isResizeEvent;
		}
		
		//--------------------------------------------------------------------------
		//
		//  PUBLIC
		//
		//--------------------------------------------------------------------------
		public function start():void
		{
			if (isValidSize())
			{
				complete();
				return;
			}
			_stage.addEventListener(Event.ENTER_FRAME, check);
		}
		//--------------------------------------------------------------------------
		//
		//  PROTECTED
		//
		//--------------------------------------------------------------------------
		
		//--------------------------------------------------------------------------
		//
		//  EVENT HANDLER
		//
		//--------------------------------------------------------------------------
		private function check(event:Event):void 
		{
			if (isValidSize())
				complete();
		}
		
		//--------------------------------------------------------------------------
		//
		//  PRIVATE
		//
		//--------------------------------------------------------------------------
		private function isValidSize():Boolean
		{
			//trace( getTimer(), "_stage.stageWidth : " + _stage.stageWidth );
			return _stage.stageWidth * _stage.stageHeight != 0;
		}
		
		private function complete():void
		{
			_stage.removeEventListener(Event.ENTER_FRAME, check);
			if (_isResizeEvent)
				_stage.dispatchEvent(new Event(Event.RESIZE));
			dispatchEvent(new Event(Event.COMPLETE));
			_stage = null;
		}
		
		//--------------------------------------------------------------------------
		//
		//  GETTER/SETTER
		//
		//--------------------------------------------------------------------------
	
	}
	
}

Home > Tags > flash


Search
Feeds
Meta

Return to page top