tmty.jp

前回のエントリでは、サーバで生成した FlashLite コンテンツを配信するケータイサイトの開発/制作フローとして、以下のような流れを紹介しました。

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の繰り返し

前回は、このフローの4まで、つまり SWF をサーバ上でどのようにいじりたいかを検討し、そのための手段(ツール)として、swfmill を選択する、というところまで紹介しました。

今回は、具体的なコンテンツを想定しながら、このフローの5以降の流れについてまとめていきたいと思います。

サンプルコンテンツの概要

動的にいじるサンプルコンテンツとして、以下のような背景画像+キャラクタのアニメーションを再生するシンプルなFlashLiteコンテンツの動的生成要件を考えてみます。(上記のフローの 3 までの検討結果イメージについても併記してみます。)

• ステージサイズは 176×208
• 背景画像とキャラクタのアニメーションをステージ上に持つ
• SWF を動的に生成するときの入力(input)
  • 背景画像
  • キャラクタ画像
• SWF 再生後の出力(output)
  • なし。ただ再生するだけ
• SWF 中の何(what)をいじるのか
  • 背景画像とキャラクタ画像

文字だけだとどんなコンテンツなのかイメージがわきにくいので、サンプルも貼っておきます。(DeviceCentral で再生しているものをキャプチャしています。)

今回は、このコンテンツをベースに、

• 背景の jpeg 画像を指定のものに差し替え、
• 飛んでいるキャラクタの画像とアニメーションを指定のムービークリップシンボルに差し替える

ということをやってみます。具体的には、背景画像を以下のもの:

に差し替え、さらに、キャラクタのアニメーションを、別途作成した以下のようなムービークリップシンボル:

に差し替えたものを、新しい FlashLite コンテンツとして生成することとします。(余談ですが、FlashLite の動的生成が「FlashLite の(動的)合成」と表現されている事がありますが、その意味するところは、上記のように「ムービー中の画像素材などを指定して、これらを組み合わせて(合成して)FlashLite の生成をおこなう」ということと理解しています。)

それでは、以下、先に紹介した制作フローの続きを紹介していきます。

SWF 生成(合成) 時の入出力を決める

先に検討した入出力を精査し、何を入力パラメタとして SWF をつくり、ムービー再生後にどのような出力パラメタをもってサイト遷移に戻るか、を決定します。今回は、以下のように決定したとします。

• 入力
  • 背景画像: ステージサイズと同じ大きさの jpeg データ
  • キャラクタ画像: アニメーションを伴ったムービークリップシンボルとして指定される(元のキャラクタ画像は GIF89a)
• 出力
  • なし

なお、実際の要件や制作/開発の現場では、上のようにまとめられるとは限りません。「背景画像には jpeg と GIF の形式のどちらかが指定されうる」とか「キャラクタ画像は画像のビットマップのみ入力として与えるだけとし、アニメーションは固定で良い」などの要望が出る場合があります。今回は、この後のステップを紹介するのに都合が良いように要件を決めていますので、まずは以下をお読みいただいた上で、上記のような要件変更/要望の取り込みがどの辺りの開発ステップ/難易度/コストに影響を与えてきそうかを捉えていただければと思います。正直なところ、ここ以降の制作フローの詰めが、FlashLite コンテンツの動的生成をおこなう際の一番の難所(業務でやる場合は、リスク要因となりやすいフェーズ)と、個人的には感じています。

.flaの制作ルールを決める

SWF 中の差し替えをおこなう要素と、そのときに与えられる入力が決まったところで、デザイナと開発者との間でベースとなる SWF の制作ルールを決めていきます。なぜ、制作ルールを決める必要があるかと言うと、一番の理由は、プログラムから差し替えをおこなう要素が特定できるようになっていないことには、画一的な処理で要素の差し替え(SWF の動的生成)をすることができず、ベースとなる SWF ごとに処理をつくってやらなければならなくなるからです。

これは逆を言えば、ベースとなる SWF が少なく、運用時の SWF 追加や更新も無い、などの理由で、個別の動的生成処理を実装していくのにコストがかからないのであれば、この時点で厳密な制作ルールの握りをつくる必要は無い、ということにもなります。

今回は、この後の説明を簡単にする都合で、以下のように制作ルールを決める事ができた、と仮定します。

• 背景画像は、jpeg を貼付けただけのムービークリップシンボルを別途作成しておき、これをステージに配置する際に “bg” というインスタンス名を付与しておく事にする
• キャラクタ画像は、アニメーションを含める形でムービークリップシンボルを別途作成しておき、これをステージに配置する際に “animation” というインスタンス名を付与しておく事にする

上記のように、今回は、差し替えをおこなう要素をふたつともムービークリップシンボル化しておくことを仮定しています。

ただ設置するだけの背景画像を、わざわざシンボル化して、インスタンス名まで付与するのは、制作側からすれば一見非効率かも知れません。ただし、これらのルールは、先にも述べた通り、プログラム側から差し替えをおこなう要素(ムービークリップ)を特定/識別するためのルールですので、ケースバイケースと考えていただければよろしいかと思います。たとえば、「SWF 中には、背景画像として唯一 jpeg 要素を使用する」という制作ルールがあれば、「背景画像として入力した jpeg を SWF 中の jpeg データと置き換える」という処理を作ってやれば、わざわざインスタンス名で特定する必要がないということにもなります。

本番用 SWF をパブリッシュし、必要に応じてテンプレート化し、差し替え処理を実装する

上記のルールに基づいて .fla を制作し、SWF をパブリッシュしたら、いよいよ、具体的な FlashLite 動的生成処理の実装に入っていきます。

まずは swfmill swf2xml を使って、できあがったベースの SWF の構造を確認してみます。(swfmill の基本的な使い方は、他のサイトでもわかりやすい説明が多いので、ここでは割愛します。)今回のサンプル SWF は以下のようになっていたとします。

  1 <?xml version="1.0" encoding="UTF-8"?>
  2 <swf version="4" compressed="0">
:
 13       <DefineBitsLossless2 objectID="1" format="3" width="30" height="30" n_colormap="7">
 14         <data>
 15           <data>eNq9kEsO...
:
 17       </DefineBitsLossless2>
 18       <DefineShape objectID="2">
:
 30               <ClippedBitmap objectID="1">
 31                 <matrix>
 32                   <Transform scaleX="20.00000000000000" scaleY="20.00000000000000" transX="-300" transY="-300"/>
 33                 </matrix>
 34               </ClippedBitmap>
:
 52       <DefineSprite objectID="3" frames="20">
 53         <tags>
 54           <PlaceObject2 replace="0" depth="1" objectID="2">
 55             <transform>
 56               <Transform transX="299" transY="299"/>
 57             </transform>
 58           </PlaceObject2>
 59           <ShowFrame/>
:
176       </DefineSprite>
177       <PlaceObject2 replace="0" depth="3" objectID="3" name="animation">
178         <transform>
179           <Transform transX="3541" transY="1031"/>
180         </transform>
181       </PlaceObject2>
:
182       <DefineBitsJPEG2 objectID="4">
183         <data>
184           <data>/9n/2P/Y/+AAEEp..
:
186       </DefineBitsJPEG2>
187       <DefineShape objectID="5">
188         <bounds>
189           <Rectangle left="0" right="3520" top="0" bottom="4160"/>
190         </bounds>
191         <styles>
192           <StyleList>
193             <fillStyles>
194               <ClippedBitmap objectID="4">
195                 <matrix>
196                   <Transform scaleX="20.00000000000000" scaleY="20.00000000000000" transX="0" transY="0"/>
197                 </matrix>
198               </ClippedBitmap>
:
216       <DefineSprite objectID="6" frames="1">
217         <tags>
218           <PlaceObject2 replace="0" depth="1" objectID="5">
219             <transform>
220               <Transform transX="0" transY="0"/>
221             </transform>
222           </PlaceObject2>
223           <ShowFrame/>
224           <End/>
225         </tags>
226       </DefineSprite>
227       <PlaceObject2 replace="0" depth="1" objectID="6" name="bg">

swfmill を使った FlashLite の動的生成処理を作る際は、(場合にもよりますが、)

• ベースの SWF をそのまま保持しておき、動的に swf2xml => 差し替え処理 => xml2swf するよりは、
• 上記のように XML 化したものを要素を差し替え可能な状態に適宜編集して保持しておき、動的に 差し替え処理 => xml2swf  したほうが、

応答速度的にも効率が良くなると思います。ですので、ここでベースの SWF の構造を XML 化しておき、差し替えをおこなう要素の構造を理解しておくとともに、この XML を差し替え可能な状態に編集し、テンプレートとして保存しておく事にします。

今回の要件では、ステージにムービークリップを配置した際のインスタンス名を “bg” または “animation” で指定してもらっているはずですので、まずはこれらがどこに位置しているかを見ていきます。FlashLite 1.1 でパブリッシュされた SWF では、ムービークリップは PlaceObject2 要素(Tag)で name 属性をともなって配置されているはずです。(このあたりの SWF の構造に関しては、Adobe 社が公開している SWF の仕様 – SWF Technology Center (必要に応じて Open Screen Project )も参考にしてください。)上記の場合では、

177       <PlaceObject2 replace="0" depth="3" objectID="3" name="animation">

の行と、

227       <PlaceObject2 replace="0" depth="1" objectID="6" name="bg">

が該当する事になります。

ここから、さらに PlaceObject2 が参照している object を辿っていきます。objectID 属性を確認すると、たとえば animation インスタンスは objectID=”3″ ですので、objectID=”3″ となっているムービークリップ要素 = DefineSprite 要素を探します。今回の例ですと:

 52       <DefineSprite objectID="3" frames="20">
 53         <tags>
 54           <PlaceObject2 replace="0" depth="1" objectID="2">
 55             <transform>

ここが該当します。このなかで、さらに PlaceObject2 により objectID=”2″ が参照されていますが、ここではムービークリップ内に設置されたキャラクタ画像が参照されているはずです。FlashLite 1.1 でムービークリップ内に画像を定義する方法は何種類かありますが、基本的には、

• DefineBitsLossless2 もしくは DefineBitsJPEG2 で定義した画像データを、
• //DefineShape/styles/fillStyles/ClippedBitmap で参照し、このシェイプを PlaceObject2 で配置する

というのが一般的な構造になるようです。今回は、上で指定されていた objectID=”2″ な DefineShape を辿って、さらにそのなかの ClippedBitmap というように、objectID をたどっていきます。最終的には、

 13       <DefineBitsLossless2 objectID="1" format="3" width="30" height="30" n_colormap="7">
 14         <data>
 15           <data>eNq9kEsO...

に行き着きます。ここの data 要素の中身が、アニメーションをおこなっているキャラクタ画像のビットマップデータということになります。今回はアニメーションとキャラクタ画像を丸ごと差し替えたいという要件ですので、このあたりの DefineBitsLossless2, DefineShape, DefineSprite の構造を、objectID の参照関係を維持したまま作り替えてやれば、アニメーション部分の差し替えができるということになります。

同様に、背景画像については上記 227 行目の PlaceObject2 で参照されている objectID=”6″ を追っていってやれば、

182       <DefineBitsJPEG2 objectID="4">
183         <data>
184           <data>/9n/2P/Y/+AAEEp..

に辿り着きますので、この data 要素を差し替えてやれば良い、ということになります。

対象の SWF の構造がわかったところで、この XML をテンプレート化します。差し替え処理の実装方法は幾つか考えられますが、

• XML 中の置き換えをおこなう部分を場所を一意に特定できる文字列にしておき、プログラムからは文字列置換により書き換える
• 置き換え対象部分を独自に定義した要素などに編集しておき、適当な XML 操作のための API (僕の場合は、PHP であれば SimpleXML、Ruby であれば REXML や Libxml-Ruby などを使ったりしてます) を介して書き換える

などの方法があります。前者は単純な文字列置換なので、対象の SWF がシンプルであれば非常に簡単に実装できますが、その分、.fla の制作ルールや実行環境によってはバグやセキュリティホールを作り込んでしまう可能性もあるので、注意した方が良いかもしれません。

ちょっと長くなってきたので、実際の入れ替え処理を書いていくところは、次回以降にしたいと思います。

まとめ

以上、２回にわたってケータイサイトで FlashLite コンテンツを動的生成する方法の概要をまとめてきました。全体の流れが見えると、ベースとなる SWF の制作ルールと、システム開発コストがどのように関連してきそうか、が、なんとなく見えてくるんじゃないかな、と思います。

実際のところ、制作ルールの策定は、動的生成処理の開発コストを、システム開発側とSWF制作側とで分担する割合/バランスを探る作業であるようにも感じています。ですので、全体の流れや仕組みの見通しが立たない事には、実サービスにこういった仕組みを入れていくのは大変かもしれません。

FlashLite 動的生成のシステムには何回か関わらせていただいていますが、正直なところ、こういった流れ、とくに制作側にいろんな制作ルールをお願いするようなやり方が本当に良いのかどうかは見え切れていません。今でも、わりと試行錯誤しています。この手のシステムに関わった方と情報交換する機会がほとんど無いので、いろんな方のご意見をうかがってみたいです。

さて、次回以降は、今回紹介したサンプルコンテンツの動的生成の続きから、実際に FlashLite 動的生成をやっていて使用したコードや、ハマったところなどが紹介できればと思います。

長々と読んでいただいてありがとうございました。期待せずにお待ちください。

以前、ケータイ 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 以降のステップ)について、書いていければと思います。期待せずにお待ちくださいませ (__)

WifiSignalChecker

Android Market への初めてのリリースです。とは言っても、わかるひとには一瞬でつくれるような素人作品なのですが。。大したものではありませんので、ご笑覧いただきたく。

WifiSignalChecker は Android を搭載したデバイスでの Wifi (802.11無線LAN)電波強度をモニタするための電波測定ツールです。現在接続中のアクセスポイントから受信しているシグナルレベルをリアルタイムに表示します。

WifiSignalChecker は Android Market でフリーソフトウェアとして配布しています。Applications > Tools の下にあります。社内無線 LAN 環境のちょっとした電波調査や、PC で公衆無線 LAN を使用する際の座席選定などに、お気軽にご利用ください。

なお、日本国内での利用においては、端末の利用が制限/規制対象となっている場合があります。電波法を確認いただき、ご利用は自己責任にてお願いいたします。

こうしている間にも、レビューが付いたりコメントが付いたりで、嬉しいですね。ヘボアプリなので、いろいろ厳しい意見も来そうですが、ぼちぼち糧にしていければとおもいます。

ほんとはいろいろお遊び機能を盛り込む予定だったのですが、ちょっと忙しくなってきてしまったので、単一機能にて先にリリースすることにしました。今後更新することができれば、こちらのブログでも更新情報を流していく予定ですので、よろしくお願いします。

3/19, 20 に開催された Android Hackathon に参加してきました。参加者は 2 日間いずれかへの参加を選ぶ形式で、僕が参加してきたのは 3/19 のほう。主催は Android SDK Japan(User Group)、会場は Google さんの東京オフィスでした。というわけで、イベント概要やら、そこでつくったものの報告とか、メモとか、感じたこととかを書いておきます。

ところで、Hackathon というのは、Hack + Marathon の造語らしいですが、平たく言うと、お泊まり無し(そうでない場合もあるかもだけど)の開発合宿みたいなものです。で、今回は、Android Hackathon だったので、みんなで Android アプリ/サービスをつくろうぜ、的なイベントだったということになります。

今回の Hackathon では一週間ほど前に事前ミーティングが開かれており、そこで参加者のチーム分けや Ideathon なるアイデア出しの打ち合わせがおこなわれていました。チーム区分は以下の通り。

• Lifestyle & Travel – 日常生活や旅行先で使える便利系アプリ/サービス
• Multimedia – マルチメディアを駆使(?)するもの
• News & Weather – ニュースとか天気とか。RSSフィード使ってごにょごにょとか。
• Specific Device(Feature) – デバイス固有の機能を使ってごにょごにょ
• Tutorial – テーマは決めず、チュートリアル的になんか作ってみる

僕は Specific Device のチームに参加させていただきました。で、Ideathon でいろいろ討議した結果、「端末によるモーションジェスチャを検知する仕組み(ライブラリ)の開発」＆「その仕組みを使ってかめはめ波を撃つ」という壮大な目標にチャレンジすることとなったのでした。

さて、Hackathon 当日の成果ですが.. 結果から言うと、「かめはめ波」の捻出には至りませんでした。まだまだ修行が足りなかったようです。残念。

ただ、以下のような見栄えの、「単純なジェスチャの検知」アプリまでは行き着くことができました。

上の画像は、アプリ起動後、端末を上方向に持ち上げたときの画面表示です。とりあえず、端末を平面方向タテヨコナナメに直線に動かした際の8方向について、なんとなくジェスチャが検知できています。ほんとは、ここからこういったシンプルなジェスチャを組み合わせたジェスチャコマンドを認識させ、かめはめ波を撃って、あと、昇竜拳くらいまで行きたかったのですが、残念ながら力及ばず.. でした。

当日開発されたソースコード一式は、以下の hackathon-jp リポジトリから取得できますので、ご興味のある方、どうぞご覧ください(コミット権限はHackathon参加者に限っているようですので、read-onlyにてご了承ください)。

http://code.google.com/p/hackathon-jp/

さて、以下、今回の Hackathon 参加で自分なりにやってみたことや感じたことをメモしておきます。

今回は、事前準備として OpenIntents の Sensor Simulator を動かしてみたり、OpenIntents の trunk にいつのまにか入っていた SensorGestureDetector の実装を読んでみたり、なんとなくヒントがあるんじゃないかと Firefox の All-in-one Gestures の実装を読んでみたりしてました。

また、「ジェスチャを複合して『かめはめ波』のような複雑なジェスチャを組み立てるより、任意のジェスチャパターンを学習させられるようなトレーニングアプリを作って、ジェスチャパターンを数値化していくのが良いんじゃないか」とも考え、ジェスチャ時の各種センサの値をcsv出力するデモアプリを作ってみたりもしました。そんな折に、チームの方から、「HMM(隠れマルコフモデル)による学習/識別が主流らしい」との情報もあり、ググってみて、なんだか難しい論文に行き着いたりしていました。

ただ、Hackathon 当日は、なんだかんだで時間制限に押され、

• ジェスチャで取得できたcsv値も隠れマルコフモデルとかもよくわからん.. 深みにハマりそう
  • やっぱしとりあえずはシンプルなジェスチャを認識させるところを作ろう
• どうも加速度センサの値がオカシイ
  • 重力加速度の影響を受けてしまっているみたいだ
    • 重力加速度をキャンセルできるように、逆向きの加速度を渡してみよう
      • 端末のどちら側が地表側を向いているのかを適切に数値化するのが難しい..
        • とりあえず、端末の向きは固定で使うってことにしよう
• Z軸方向のジェスチャの認識を加えると、認識精度が落ちるみたいだ
  • とりあえず、今日のところは X-Y 2方向の平面ジェスチャのみでいこう
• 平面でもイマイチ精度が悪い
  • 一定時間(回数)以上、同方向の加速度が取れることをジェスチャ認識の条件にしよう
  • センサデータ取得時の速度を変更させるオプションがあるらしい => 最高速度(SENSOR_DELAY_FASTEST)に！

と、まあ、こんな感じに試行錯誤の繰り返しに多くの時間を使ってしまっていたような気がします。最後のプレゼンが終わった後になって、他の参加者の方に「重力加速度のキャンセルにはローパスフィルタ使うといいよ！」って教えてもらったり、既に試行錯誤されていた方のエントリを発見したり、という感じで、なんだかんだで準備不足、力不足を痛感したわけでした..

とはいえ、こういった開発は久しぶりに新鮮でした。「時間制限(のプレッシャー)」と「チームでの開発」があったおかげでしょうか。意見交換したり、コード見せ合ったりしながらも、ひとりで深みにハマる前に、上のような「問題の単純化(「あきらめ」ともいう)」や、「仕様の割り切り」「当座の目標決定」を短いサイクルで繰り返し、一日での成果を出すことに集中する、ということができたような気がします。で、しかも、それが、とても楽しかったわけです。良いですね、こういうの。僕、いわゆる「開発合宿」には参加したことが無いんですが、その楽しさの一端が垣間見えたような気がしました。

そんなこんなで、当日の他のチームのプレゼンや飲み会の部まで含めると、とても書き切れないほどの多くが得られた、楽しいイベントでした。同じチームの皆様はじめ、ご参加の皆様、主催や協力の皆様、お疲れさまでした。ありがとうございました。

先日 GitHub というのを初めて使ってみて、テキトーな小物をちょいちょい晒していくにも都合が良さそうだということがわかったので、今回、標記のプログラムも晒してみる事にしました。使用許諾条件は、基本的には the MIT License に基づきますが、「(迷惑メール送信に用いるなど)悪用・乱用を禁止する」という条件を付加したいと思います(っていうほど作り込んでないので、まあ、あんまし意味のない付加条件だと思いますが)。



MbSmtp – GitHub



MbSmtp は、Net::SMTP の拡張クラスで、日本の携帯向けにできるだけ効率よくメールを送る事を目的とした SMTP クライアントです。



MbSmtp は以下の機能を提供しています。

• SMTP セッションあたりの送信通数が設定値以下になるよう、セッションを自動分割制御します
• キャリアからの通信ブロックが発生した際、 設定時間待機した後、
  設定回数、失敗したメールのみ再送リトライします
• メール送信処理中にエラーとなるアドレスが含まれていた場合、同一セッションで未送信のアドレスリストからエラーアドレスを除去します
• セッション終了時、 送信リポートの構造体を返します
  • リクエストメッセージ数, 送信完了メッセージ数, エラーメールアドレスなど

各種設定値は lib/mb_smtp.rb 内で指定されていますが、必ずしも適正値ではありません。適宜設定を変更してご利用ください。



以下、簡単な使用例です。基本的には Net::SMTP と同じように使えますが、キャリアメールサーバは :docomo, :au, :softbank などといったシンボル指定で open できます。また、以下のようにセッション内である程度まとまった数を送信したとしても、1 セッションでの送信通数が設定値を超えないよう、勝手にセッション分割してくれます。その他、キャリアのメールサーバからの応答に応じて、エラーアドレスの振り分けや送信成功数のカウント、キャリアブロックに対する待機などをおこない、最後に MbSmtp::Result 形式でのレポートを生成する、といった動きをするようになっています。

@mail = TMail::Mail.new # MbMail::DMail とかでもOK
## @mail を適当に組み立てる
@result = MbSmtp.start(:docomo) do |smtp|
50.times do
smtp.send_mail @mail.encoded, @mail['from'].to_s, @mail['to'].to_s
end
end
puts @result # => MbSmtp::Result による送信結果レポート

この他の使い方や、動きの詳細については spec/mb_smtp/*.rb にある spec ファイルや lib/mb_smtp.rb 本体をご覧ください。



ちなみに MbSmtp は、元々は、個人的にメール配信時のキャリアのメールサーバの振る舞いを調べてみようとごにょごにょやっていたときの副産物です。実サービスでの利用実績はありませんし、これにより高速に携帯メール配信ができるという保証も検証結果も一切ありません。もちろん、これを使用した事で、キャリアブロックされまくってマトモにメールが送れなくなった、とかになっても、僕の方で責任はとれませんです。あくまでご参考まで、ということで。。