ホーム DoRuby 【FlashLite】機種依存の不具合や仕様について7つの事例。

【FlashLite】機種依存の不具合や仕様について7つの事例。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

FlashLiteにはFlashLite固有の機種依存による不具合や仕様が数多く存在します。

今回は実際に自分が実際に直面した中から7つの事例をピックアップしてご紹介します。

(1) SH機種でFlashの再生が停止する

【現象】

・SoftBankのSH機種の場合は、画面が真っ白で表示(画像取得失敗と同様の表示)され、閲覧不可となる。
・DocomoのSH機種の場合は、「画像に誤りがあり、正しく動作しません」というメッセージが表示され、閲覧不可となる。

【原因】

無限ループが発生しているため。大半の携帯端末はFlash内で無限ループが発生した際に無視するが、一部SH機種はそのまま実行後、実行回数制限によりFlashの再生を停止する。

【解決方法】

無限ループが発生する場合のほとんどはコーディングミスである可能性が高いため、細かくtraceしながらデバッグを行うしかありません。
※次項にて意図しない無限ループが発生する特殊な事例についてご紹介しています。

(2) 一部端末で無限ループが発生する

【現象】

一部端末で無限ループが発生する

【原因】

「for(i=0; i < NaN; i++){}」となった場合に無限ループが発生するため。

【解決方法】

for文のlimit指定が「NaN」になっていないかどうかtraceをしながらデバッグするしかありません。 例えば、「int(“”)」等で「NaN」になっている可能性もあります。

(3) System.capabilities.hasSharedObjectsの判定結果が誤っている

【現象】

Panasonic製/TOSHIBA製のSoftbank端末で「System.capabilities.hasSharedObjects」を実行すると、Shared Object が利用できないにもかかわらず「true」が返される。
この結果を受けて、SharedObject.addListener を実行している場合はそのまま処理が停止する恐れがあるため注意が必要です。

【解決方法】

System.capabilities.hasSharedObjects と同等の判定を他の方法で行うことはほぼ不可能。

【代替案】

System.capabilities.hasSharedObjects の結果が「true」の場合に、SharedObject.addListenerを実行している場合、
一定時間Listenerが走らない場合は強制的にremoveListenerを実行後、次処理へ移行させる等の対応が必要です。
※設定時間が短すぎると、正常にデータをロード中の端末において読み込み完了前に次処理に強制移行されてしまうので注意が必要です。

(4) _rotationを指定すると、_xscale, _yscaleの値が勝手に変わってしまう

【現象】

_rotationにFloat型の数値を指定すると 対象MCの_xscale, _yscaleが伸縮されてしまう(_rotation後に_xscale, _yscaleを再定義する必要有り)

【発生例】

アナログ時計の針を動かす処理等

【原因】

45°毎の _rotation 指定しか保証されていないため(?)

【解決方法】

_rotation後に_xscale, _yscaleを再設定することで処理は増えてしまいますが、見た目の崩れを防ぐことができます。

(5) auの一部端末にてPOSTができない

【現象】

auの一部端末でPOST通信ができない

【発生例】

・swfから大量の入力テキストをPOSTでサーバーに送りたい場合等
・HTML内のPOSTが指定された検索フォームから検索した結果としてswfのページを表示させたい場合等

【解決方法】

なし

【代替案】

swfの前後の通信はGET形式で統一します

(6) デバイスフォントが勝手に縁取りされる

【現象】

古いSHARP製Softbank端末において、デバイスフォントの色を白に設定すると端末側で勝手に白で縁取りされてしまう
※参考:”【web creators】今“ 知っておくべき”ケータイサイト制作事情/第五回”:http://www.mdn.co.jp/di/articles/2145/?page=2

【解決方法】

なし
白デバイスフォントは使用しない、不具合が生じる機種は非対応機種とする等の対策が必要です。

(7) Docomoの文字コード

【現象】

Docomo端末からswf経由でマルチバイト文字が含まれるパラメータを送信した場合、端末によって文字コードがShift_JISのものとUTF-8のものがある

【発生例】

(例)「あ」をGETパラメータに付与した場合

(1) F905i

 swf内にてescape処理無しswf内にてパラメータ全体をescape処理swf内にてパラメータの名前, 値を個別にescape処理
パラメータの文字コードShift_JISパラメータとして認識されないUTF-8

(2) SH01-B

 swf内にてescape処理無しswf内にてパラメータ全体をescape処理swf内にてパラメータの名前, 値を個別にescape処理
パラメータの文字コードUTF-8パラメータとして認識されないUTF-8

通常、携帯HTMLサイトを構築する際にDocomo端末の場合はShift_JISのパラメータを受け取る前提で実装されることが多くありますが、 FlashLiteの場合、Docomo端末で表示されたswfからパラメータが送られた場合に、上記のようにパラメータの文字コードにばらつきがでてきます。

【解決方法】

暫定的に判別ロジックを組んではいますが、あまりスマートな方法ではないので公開は控えておきます…。

記事を共有

最近人気な記事