tmty.jp

以前、ケータイ Flash を中心に、細々と SWF バイナリを読んでいた時期があったのですが、そんなこんななご縁で、FlashLite コンテンツの動的生成(FlashIDEを介さずに、Webアプリケーションサーバ側で、SWF を自動作成する)方法について聞かれることが多いです。なんか、最近になってやけに多くなった気がするので、ちょっと理由を考えてみたのですが、

• 大半のユーザが FlashLite 対応機種を持つようになった
  • アバター系(キャラとか部屋とか)着せ替え提供サイトが、より高精細(キレイでなめらか)なアニメーション素材を提供できるようになった
  • ケータイでFlashゲームをやる、という文化/リテラシが浸透してきた
• FlashLite コンテンツは、通信制限や、1URLあたりのファイルサイズ制限などのケータイ特有の制限により、FlashLite 単独で動的なコンテンツにしづらい (ActionScript により、動的な処理をすべて SWF に入れ込む、というのが現実的でなく、Webアプリと絡めて都度 SWF を作り替える必要がある)
  • しかも、たいていの場合、FlashLite バージョンは下位機種に合わせて 1.1 にする必要があって、上記の制限がなかなか緩和されない

あたりの事が関係しているような気がします(もっとも、これ以外にも複数の理由が絡んでいるでしょうけど)。

もちろん、これ系のネタは検索すればいっぱい出てくるのですが、最近やけに聞かれるのは、新旧織り交ぜた情報が出てくるので、なかなか落としどころがわかりにくい、ということも関係しているような気がします。ということで、2009年4月現時点の情報として、僕の説明の省力化と知ってる事の整理も兼ねて、この件について、これから何回かに分けてまとめていこうと思います。

話題にするのは、たぶん、以下のような内容になります。

• FlashLite コンテンツを動的に作成するケータイサイトの開発ステップ
  • 選択できる FlashLite の生成方法について
• swfmill と適当な XML 処理系を組み合わせた方法による FlashLite コンテンツ動的生成
  • 画像を置き換えたつもりが、画像部分だけ真っ赤になった
  • jpegの部分にpngとかgifの画像を入れたい
  • swfmillでswf2xmlしたのを、そのままxml2swfしただけなのに再生できなくなった
  • 文字の入れ替えもやりたい。デバイスフォント以外も使える？
  • ActionScript 部分を書き換えたい

後半の swfmill を使う方法は、基本的なやり方はわりと Web で目にするので、上のような実際にサービスに入れ込んでいくときのハマりどころ/課題について、具体的に書けるといいなあ、と。

ただし、改めて書くまでもないことですが、あくまで僕の見解ですので、ご参考程度としていただければと思います。むしろ、実際どういう事やってるのかって聞く機会が少ないので、教えて欲しかったりします。あと、途中で書くのに飽きたらやめるかもしれません。すみませんすみません。

では、今回は、上記の前半部分、まずは FlashLite コンテンツを動的に作成するケータイサイトの開発ステップについて書いてみます。なお、ここで話題にするのは、「ケータイサイトの作り方」ではなく、「ケータイサイトのなかでも、FlashLite コンテンツを扱う部分の作り方」だけですので、ご期待に添えられなかったらすみません。

動的生成する範囲を見積もる

まずはじめに、サイト(サービス)のどの部分(Where)を FlashLite にするのかを見積もります。

画面遷移の資料やら、あとは、サイト全容の妄想やらをベースに、どこを FlashLite コンテンツにしたいのかを整理します。

(すくなくとも現時点では、)サイト全体が FlashLite コンテンツになる、ということは稀だとおもいます。たぶん、多くの場合、

• スプラッシュページ
• トップページの(階層)メニュー
• ユーザ別にカスタマイズされたコンテンツ(アバターとか)
• ゲーム

のいずれかに収まるんじゃないかとおもいます。

FlashLite コンテンツへの入出力と、そのなかで動的に取り扱いたい部分を確認する

以下、FlashLite コンテンツを SWF と表記します。

サイト内に SWF を入れ込む範囲が見えたら、具体的に、その SWF のなかの何(What)を動的に扱いたいのかを確認します。もうちょっと細かくいうと、

• SWF が再生される際、どういう入力(input)をもらって、
• その入力の結果、SWF のなかの何(What)を書き換えて、
• SWF を操作(再生)した結果、どういう出力(output)を持って違う画面に遷移するのか

を整理する事になるのですが、ここでは、少なくとも２番目のWhatを押さえておきたいです。具体的には、以下のようなものが挙がるとおもいます。

• 画像
• 文字列
• アニメーション
• その他 ( ActionScript 内のロジックとか変数とか)

ここで挙がったものの種類/組み合わせと分量、それから、この後で検討する制作フロー云々が、動的生成の難易度に大きくかかわってきます。

制作フローを確認する

サイト内でFlashLiteを入れ込む範囲が見えたら、そのコンテンツ(SWF)の制作フローを確認します。サイトの運用(コンテンツ更新)まで見据えて、「誰が(Who)」「いつ(When)、どれくらいの頻度で(How often)」制作するかを確認し、見通しを立てます。

サービス開発時に、企画、デザイナ(というのは抵抗があるんですが)、開発者という３役割があるとすれば、恐らく、多くの場合において、SWF を制作するのはデザイナであると思います。たぶん、以下のようなフローになるような気がします。(ここでは、前の項の「input/output/What」の検討を含めたフローを書きます。)

1. SWF への入出力(input/output)に見通しを立てる (全員で)
2. Flash IDE でプロトタイプの fla ファイルを制作し、SWF でパブリッシュ (デザイナ)
3. SWF 中の何(What)を、どのように動的にいじりたいかを整理 (全員で) (ここまでが前の項)
4. 動的にいじる手段を選択 (主に開発者で)
5. 決定した手段に応じて、SWF への入出力を決定 (主に開発者とデザイナで)
6. fla の制作ルールを決める (主に開発者とデザイナで)
7. 上の制作ルールに基づいて Flash IDE で fla ファイルを制作し、本番用の SWF をパブリッシュ (デザイナ)
8. 制作した SWF を必要に応じてテンプレート化する (開発者もしくはデザイナで)
9. テンプレート化した SWF をいじるアプリケーションを実装する (開発者)
10. できあがり。運用時の更新は、7〜８〜9の繰り返し

ここでは、たとえば「毎週火曜日に」「毎月初に」などの SWF の定常更新があると想定し、更新フローまで考えてみましたが、サイトの性質によっては、サービス開始時にひとつ SWF のテンプレートをつくってしまえば、SWF の更新が必要ない場合もあるかもしれません。

ここでのポイントは、4 の「動的にいじる手段を選択」する部分と、それ以降のフローを作成する部分にあると思います。上記の全体のフローをなんとなく踏まえて、次の項でこれを検討してみます。

SWFを動的にいじる手段を選択する

ここでは、これまでの検討材料を受けて、実際に SWF をどのように(How)動的にいじっていくかを検討していきます。まずは、比較的大きな意思決定として、

• 有償の SWF 動的生成ソフトウェアあるいは ASP を購入/契約し、導入する
• OSS を併用するなどしながら、自社開発する

のどちらかを選ぶ事になると思います。これの判断材料を整理するのはむずかしいのですが、僕の感覚的には、次のいずれかに当てはまるようであれば、有償のものを検討した方が良いような気がします。

• ここまでの項の検討が思うように進まない、あるいは、わからない
• ここまでの項で検討した結果、ぴったり要件に当てはまるプロダクト/サービスが既にあって、自社でつくるよりもどう考えても安く、さらに、自社戦略的にその仕組みを自社でつくっておく必要もなさそう
• 組織や開発体制の都合で、前項で検討したような制作フローの後半 = SWF の制作ルールやフローの検討に各担当者を巻き込んでいくのが難しい

恐らく、ここのブログを読む人は、「FlashLite 動的生成」などのキーワードで来られてるのではないかな、と思いますが、有償のプロダクト/サービスを検討する際は、検索ワードに「エンジン」あるいは「ASP」と追加してみると、プロダクトっぽいものが引っかかりやすいようです。ここで、特定の有償プロダクトを紹介する事はしませんが、最近はそこそこの月額コストで簡単に利用できるものもありますし、ASP やソフトウェアパッケージでありながらもコンサルティングサポートや簡単なカスタマイズに対応してくれる場合もあるようです。

いっぽう、有償のプロダクト/サービスを導入した場合は、以下のようなリスク/デメリットもあります。

• サービスがトラブったときに、手を出しにくい (とくにブラックボックスの場合)
• 比較的自由度が低いため、サービス仕様に対応できない場合や、運用開始後の仕様変更/サービス追加に対応できない場合がある

これらのリスク/デメリットや前項までに検討した input/output/What/When/How often を鑑みた結果、OSS を併用しながら自社開発する、という選択もあると思います。また、先の What を検討した際、SWF のいじくりたい部分が多様で複雑になった場合は、有償プロダクトで対応できない、いずれのプロダクトにも要件を満たせるものが無い、ということにもなったかもしれません。その場合は、大きく分けて、次の選択肢から選ぶ事になるような気がします。

1. SWF バイナリ構造を理解し、スクラッチで所期の SWF いじくり処理を実装する
2. ming を使って、プログラムから SWF を作成する
3. flasm を使ったプログラムを実装し、ActionScript 部分だけ書き換える
4. swfmill を使ったプログラムを実装し、SWF の中身を置き換える

ここでは、1 は長くなりそうなので説明しません。やってみると面白いんですけどね。ただし、ちょっとした工夫で、手間はほとんどかけずに所期の動的生成の要件を達成する事ができるケースもあります。これは、機会があれば書きます。

2 についてですが、ming って、プログラムから SWF を作るには便利なんですけど、既にある SWF をいじくるのにはあんまし向いてないように思います。(ming 派の方がいらっしゃったら教えて欲しい点でもありますが。)

3 は、わりとやってる人多いみたいな気がします。が、僕は SWF の画像をごりごりいじるところから入った人なので、あまり詳しくありません。

ということで、ActionScript もがんばれば書き換えできるし、かつ、SWF 中の任意の要素をいじくることができる、4 の swfmill を使う方法について、今後書いていこうと思います。

ちなみに、ActionScript を書き換える場合は mtasc という選択肢もあるのですが、mtasc は FlashLite1.1 コンテンツに対応していませんので、ここでは除外しています。あと、swfmill でダンプされた ActionScript コードは若干操作しにくいですので、ActionScript は flasm、それ以外は swfmill という合わせ技もアリかもしれません。

ちなみに、お気づきかもしれませんが、ここでは、「FlashLiteコンテンツを動的に生成したい」というニーズを、「既にあるSWFに含まれる何かを入れ替えてユーザ端末に送信したい」というニーズに置き換えて話を進めてきました。これも僕の感覚なので、全然違うかもなんですけど、多くの場合、「FlashLite 動的生成」を探してる人は、こういうニーズであるような気がします。

では、次回は、swfmill を使った SWF の動的生成と、これをケータイサイトのシステムに組み込んでいく場合の流れ(前項の 5 以降のステップ)について、書いていければと思います。期待せずにお待ちくださいませ (__)

関連していそうなエントリ:

• ケータイサイトでFlashLiteコンテンツを動的生成する(その2)
• ケータイサイトでFlashLiteコンテンツを動的生成する(その3)
• 「Ruby on Rails携帯サイト開発技法」の執筆に参加しました