9月 17
EC ナビさんで開催されたモバイル勉強会にて、携帯の機種情報 DB についてお話してきました。
今回の勉強会は、第一線で大規模な自社サービスを展開されている方のスピーチが多く、大変参考になりました。僕の話が、前回同様、かなり地味なテーマだったので、かなり緊張しましたが、他のスピーカの皆さんの胸を借りるつもりでお話させていただきました。
僕の資料はこちらの trac にまとめましたのでご参考ください。
機種情報を集める手間然り、デバッグの繁雑さ/実機手配の費用と手間然り、絵文字処理の複雑さ然り、ケータイサイト開発には、技術的障壁とは言い難い観点での泥臭い障壁があります。今回のような勉強会やノウハウ共有の活動が、ケータイアプリ開発に興味を持っておられるクリエイタの方に、少しでも参考になり、もっと面白いモバイルサービスが生み出されるようになっていくのであれば、これ以上楽しいことはありません。
では、例によってメモを転記。
- 以前のケータイサイト .. 遅い NW 経由の断続アクセス .. より多くのコネクションが必要になる
- au の絵文字表記はバイナリコードを使うべし
- moxy は pluggable。最近の perl アプリは pluggable であることが大事
- サイト運用時のドメイン変更は注意。3割くらいのユーザにメールが届かなくなる = 3割くらいのユーザがドメイン指定してる
- ドコモでメールを送った後に「OK」を押すと接続が一旦切れる。メール返信処理をしてるときは、再接続が発生するので、「OK」を押さずに待つのが吉
- ニワンゴ郵便では Subject にセッション ID を埋めて会話セッションを管理してる。一時間有効。一期一会
- ニワンゴでコマンドメールの応答を自分でつくれる .. OpenAPI
- ニコ動モバイル
- 気合いでできている
- キャリアの通信制限をiアプリ, Flash で超える
- motionJPEG(のようなもの) + ADPCM(エセ着うた) で draw+play 繰り返し
- flv 素材 => 変換サーバ(C++) => jpeg + ADPCM => 再生サーバ(java) => クライアントアプリ
- クライアントへのデータフォーマットは、ヘッダ + 命令列。命令列は音再生 + 描画の羅列。音データは MFi や SMAF ベースの独自フォーマット。クライアントは、ほぼパーサのみの実装
- 一回のデータ単位は上限の 150KB でやっている。一番効率がいい
- 可変ビットレート .. 利用できる転送速度に応じて 150KB の中で送るフレーム数を変えている。クライアントが限界 fps を申告する。音声は 1 秒単位区切り
- play から音再生までタイムラグがある。AudioPresenter を切り替えながら再生
- 描画スレッドにsleep()を入れないと通信が止まる罠
- Flash版では、どの端末も 1fps が限度
- 繋いで見せるのが難しい。子 Flash の再生までの時間が不定
- モバゲー .. 142億PV/月間。画像チェックは全部人力。SH903i ユーザが多いらしい
- SWF::File .. SWF を生成する perl スクリプトを生成
- AS のバイトコードにダミーのジャンプコードを差し込んで、逆コンパイラを誤認(難読化)させるテクニック
- ドワンゴでの検証機 5000 台以上。server side browser .. ruby(rails?) で 3 日で書いた
最後になりましたが、今回の勉強会の発起人であり、スピーカの皆さんへの呼び掛け、裏方運営まで諸々ご尽力いただいた memokami さん、休日開催/多人数の参加にもかかわらず会場を快くご提供いただいた EC ナビさん、参考になるお話を惜しげもなくご披露いただいたスピーカの皆様に感謝いたします。お疲れさまでした＆ありがとうございました。
関連していそうなエントリ:
9月 18th, 2007 at 04:37
第2回モバイル勉強会で「キャリア判別と絵文字の扱い」を発表してきました
第2回モバイル勉強会を開催しました。 今回はモバイルに情熱を持ったスピーカー12名の方々にご賛同いただき、 密度の濃いモバイルの勉強会を開催することが出来ました。 本当に皆様のおかげで、このような素晴らしい会を開催することが出来ました。 ありがとうございまし…
9月 19th, 2007 at 11:28
機種情報DB ありがとうございます m(__)m
私も以前 同じようなものを作ったのですが、メンテンナンスが出来てなく困っていました !!
9月 21st, 2007 at 16:33
こんにちは、ke-tai.orgのmatsuiです。
記事内でサイトを取り上げて頂きありがとうございます。
スライド上でおっしゃっている通り、機種のリスト化は非常に単調でつらい作業です。
皆で情報を持ち合い、少しずつ作業することで、何とか全員が楽できるような環境が作れればと思っています。
ぜひぜひご協力をお願いいたします。
他にも「こんな機能が欲しい」というようなリクエストがありましたらぜひWikiに書き込んでください。
ではまた。
9月 30th, 2007 at 01:06
偶然に発見したのですが
機種情報 DB でこうなっていますが
デバイスID=KC15 データなし
デバイスID=KC24 機種名称=A5502K
デバイスID=KC25 機種名称=A1013K
au のページを見ると、以下のようになっています
デバイスID=KC15 機種名称=A1013K
デバイスID=KC2[45] 機種名称=A5502K
ご検討下さい。
9月 30th, 2007 at 02:28
yuumi3 さん、ご使用のご連絡ならびに情報違いのご連絡ありがとうございます！
A1013K のデータ、さっそく修正させていただきました。
ちょっと前の機種や 1x 機種での検証は追い付いていないので、フィードバックいただけるのは大変助かります。ありがとうございます。
9月 30th, 2007 at 02:47
matsui さん、コメントありがとうございます。
今のところは、自分が使っていく上で必要なものを整理していく形で、手が届く範囲で、少しずつ公開していこうかな、と思っています。
いろんな方がいろんな情報をお求めになりますから、画一的な整理って難しいようにも思うのですよね。。
思いついた点等ありましたら、ke-tai.org さんにもお伺いして書き込みさせていただきますね。今後ともよろしくお願いいたします。
10月 3rd, 2007 at 14:57
以前、私が作ったデータ(今年春くらいまで、画面データはブラウザ縦横のみ)と比較してみたところ、以下の間違い(?)が見つかりました。ご検討下さい。
docomo
・ F504iS の画面データが N504iSのデータでになっている
・ F506i の画面データが N506iのデータでになっている
・ SH700i のブラウザ高さ X 52 -> ○ 252
・ SO213i のブラウザ幅 X 129 -> ○ 120
au
・ CA21 機種名称 X W3012CA -> ○ A3012CA
・ CA36 機種名称 X W03CA -> ○ E03CA
・ KC15(A1013K) が KC25(A1013K) として登録されている
softbank
なし
10月 4th, 2007 at 13:07
yuumi3 さん、たびたびのご指摘、恐れ入ります。
ありがとうございます！
上記の部分については、すべて修正対応させていただきました。
ただ、KC15(A1013K) の件については、間違い箇所がわかりませんでしたので(正しいデータに見えます)、そのままとさせていただいております。もし、まだ間違いがあるようでしたら、大変申し訳ありませんが、再度ご指摘をいただけますと幸いです。
10月 16th, 2007 at 16:43
いつもプログラム側で振り分けてたんですが、httpd.conf でやる方法があったんですね、とても勉強になりました。目からウロコです。
ところでウェブサーバ側で振り分けるのと、プログラム側で振り分けるのと、どちらがコストかかるんでしょうね？
BrowserMatch の場合、 httpd.conf に書かれている条件すべてを探索してるみたいなんです。
つまりファイル先頭に書かれている DoCoMo F883iES でアクセスしたとしても、ファイル末尾の SoftBank 706SC まで、500回近くも正規表現によるマッチングが実行されてしまいます。
せめてキャリアを判別してから、そのキャリアの端末と比較するようにできればうれしいですね（プログラム側で振り分けるならそうします）。いい機会なので Apache のディレクティブについて勉強してみます。
10月 17th, 2007 at 01:45
yo さん、コメントありがとうございます。
httpd での機種情報チェックは、発表用に急ぎで試してみたネタでしたが、そこそこ使えるアイデアでは無いかな、と思っています。 既にご覧になったかもしれませんが、httpd で多量の BrowserMatch を評価する際のコストについては、勉強会での発表資料 http://tmty.jp/ms070917/ の後半部分で幾つか調査/考察しておりますのでご参考ください。
(続きます)
10月 17th, 2007 at 01:46
(yo さんへのお返事の続きです)
BrowserMatch を入れ子にできれば、仰るとおり、キャリア判別 – 機種特定に分けることが有効そうですね。httpd での設定シンタックスに制限が無く、httpd とアプリケーションで、まったく同じロジックを適用できるとすれば、(アプリの実行環境にもよりますが、)パフォーマンスはほぼ同等(に近付く)と見て良いのではないかな、と考えております(厳密に調査していないので、微妙ですが)。言語跨ぎで利用できるなどの利便性、PC サイトと兼用している場合の不都合や、httpd と密結合になってしまうために httpd の入れ替え/切り分けをしたいときに面倒になるなど、一長一短なところは付きまといますが。。
アプリの組み方でも工夫できますし、そのときどきで良い手段が選択できれば良いかな、と思います。もし、より良い方法や、面白い実用方法がありましたら、お教えいただけますと幸いです (_ _)
10月 21st, 2007 at 13:59
携帯機種情報DBの検索サービスを作ってみた
今月は、忙殺＆ネタ不足で何もできていなかったので、あり合わせで何か作ってみようということで、先に公開した 機種情報 DB の検索サービスを作ってみた。
てなわけで、機種情報検索サービスはこちら。
携帯機種名を入れて検索すれば、DB 上のデータを部分一致検索し….
2月 25th, 2008 at 21:34
ケータイサイトで機種情報を取得する Rails プラグイン mbterm_db
実は前から公開してたんだけど、最近の機種情報を追加ついで、あと Rails のプラグインを書く勘を取り戻しついでに、ちょっと手を入れたので、改めて紹介しときます。
mbterm_db は Ruby on Rails でケータイサイトをつくる際に、ブラウザのバージョンや画面サイズを取得….