‘スマートフォン’ タグのついている投稿
Mobile SafariのaudioタグでBASIC認証下の領域のmp3が再生されない
環境
iPhone5
iOS 8.4.1
他の環境はチェックしていない。
現象
audioタグで音声を再生させるテストページを作成。以下のようなざっくりシンプルなソースを書いた。
<audio src="./test.mp3" id="sound"></audio>
<p id="play">PLAY</p>
<script>
$("#play").click(function(){
document.getElementById("sound").play();
});
</script>
PLAYをタップしたらtest.mp3が再生される仕組みなのだけど、どうしても音が出ない。PCのブラウザでアクセスした場合は問題なく再生される。
間違った方向に悩む
これはmp3のエンコードがおかしくて音が出ないのでは無いか？という見当違いなことを考えてビットレートを変えてみたり、ステレオをモノラルにしてみたり、mp3をwavにしてみたりと試したのだが状況は変わらず。もちろんすべてPCでは再生される。
WEBサーバのMIME設定が漏れてるかな？と思いいじってみるも、元々PCでは再生されているわけでそんなはずもなく。
BASIC認証が足かせだった
なんかおかしいなあ、ということで試しに別サーバに置いたmp3を指定してみたら再生された。別サーバなので、環境は全然違うのだけど、これはBASIC認証なんじゃないか？ということに気付き、試しにBASIC認証外にソース一式持って行ったらあっさり動いた。
iOS関係のバグみたいだが
そもそもBASIC認証下でmp3再生するような要求は、公開前のテストサイトくらいなものなので、まあそういう不具合あっても仕方がないですよね、レアケースですよね、なんて思った次第。
ざっと検索すると似たような事例がiOSのバグとしてあるようだけど、いつまでたってもBASIC認証を記憶するようにならないMobile Safariに、多くを期待しても仕方がないのでは、という風に考えている。
スマホのFacebookアプリのブラウザをガラケーと誤判定
またもやニッチなノウハウ。
PC用URLを代表にして、mod_rewriteでUserAgent毎にページを振り分ける処理をしていました
RewriteCond %{HTTP_USER_AGENT} "KDDI" [NC,OR]
こういった記述でUserAgentで振り分けしていました。よくやる手法です。.htaccessなんかに書きます。
FacebookにPC用URLでシェア投稿しました
お知らせや宣伝でよくやりますね。スマホで見ても、UserAgentの振り分けでスマホ用ページに行ってくれるだろうという見込みです。
それが予期せぬページが表示されていました
うーん、謎ですね…ということで調査しました。
FacebookのスマホアプリだとUserAgent文字列が違いました
auのiPhone5の場合、こんな感じでした。
"Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Mobile/11D257 [FBAN/FBIOS;FBAV/14.0.0.25.26;FBBV/4017285;FBDV/iPhone5,2;FBMD/iPhone;FBSN/iPhone OS;FBSV/7.1.2;FBSS/2; FBCR/KDDI;FBID/phone;FBLC/ja_JP;FBOP/5]"
お尻の方に、まんまとKDDIが入っていました。
それが原因でガラケーの判定に引っかかり、結果ガラケーページに飛ばされていました。
他キャリアはどうかなと思い、ログをみたところ、DoCoMoは「NTT DOCOMO」が入っていました。ソフトバンクは入ってない様子。
判定の順番は上からなので、先にスマホの判定をいれるように順番を変えて解決しました。やれやれ。
ガラケーの判定はうしろに
今もガラケーの手当しているサイトはそんなに多くないと考えるのですが、逆に言えばそういう所はガラケーの対応の後にスマホの対応をしてきた経緯がある可能性が高いです。
ということは、記述も先にガラケーの判定があり、その後にスマホの記述したケースが多いかも知れません。その場合は今回のようなトラブルにぶつかる可能性があります。
今回もレアケースな対応例でした。
jQueryMobileのページ関連イベントの発生タイミングでちょっとはまる
スマートフォン用サイトを、jQueryMobileを使って開発している時にはまった事柄のメモ。分かってしまえばなんでも簡単。
$(document).ready()の代わりに使うというイメージ？
ブラウザ上にページが表示されるタイミングで色々と細工をしたいという場合、jQueryを使うならば
$(document).ready(function(){
//処理
});
なんて風にする。
ありきたりな手法だ。
jQueryMobileでは、それの代わりに
$(ページのセレクタ).live( "pageshow", function(){
//処理
});
といった具合に記述する、といった約束みたいなのだけど、これがうまく動かなかった。
うまくいかないというのは具体的にどういうことか
「うまくいかない」というのは便利な言葉で、それは具体的にどういうことですか？という質問をしなくてはならず、場合によってはうまくいかなくてイライラしている人を怒らせてしまったりもする。
思ったように動かないということだけは分かるんだけど、もうちょっと情報が欲しいということは珍しいケースではない。
今回は、A.html からB.html に遷移して、B.htmlのページが表示されるタイミングで動いて欲しかったわけなんだけど…動いてくれなかったわけです。
B.htmlのソース中に
$(ページのセレクタ).live( "pageshow", function(){
alert('hogehoge');
});
と書いておけば、B.html のページが表示されるタイミングでアラートダイアログがあがるハズ…なんだけどあがらない、という。
ページをリロードすると動く
見出しの通り。
何故かページをリロードすると動いてくれるということに気づいた。最初は動いたり動かなかったりするんだよなぁ…という具合だったわけで、色々やっていくうちに「どうやらリロードすると動くみたいだ」と。何事も粘り強く続けることが肝心だ。
ということは
jQueryMobileは、ajaxを使って遷移先のページのソースを読み込んで表示する仕組みだ。
なので、javascriptの評価もページのソースを読み込む前にしておかないといけないんじゃないか？と考えた。
リロードしたら動くというのは、つまりそのページがjQueryMobileとして最初のページなので、その場合だけソース読み込み後にjavascriptが評価されているんじゃないか？と。
つまり
$(ページのセレクタ).live( "pageshow", function(){
//処理
});
は、該当ページ中に書くのではなく、遷移前のページに書いておく必要があるということ。実際それで問題無く動いた。
遷移の流れは複数になったりするので、それぞれのページの動作を1つの外部ファイルにまとめて、常にそれを読み込むようにした。
当然のことながら、ページのセレクタはhtmlファイルを跨いで遷移する全部のページを一意にしておかないとおかしなことになる。
分かってしまえば、すごく簡単な話。
WAPっぽいですね
EZweb初期のマークアップ言語はchtmlでは無く、WAP(Wireless Application Protocol)というものだった。
これはchtml何かと違って、1ファイルに複数ページが書けるもので
ページ遷移時に読み直しをしないでもいける＝通信が遅くてもそこそこ大丈夫
という仕様だった。
jQueryMobileも何となくその手法に近くて、それを利用することでアプリケーションっぽい動作が出来るわけなんだけど、それが1ファイル内完結の仕組みではなく、全体として1つのアプリケーションを構成するようになっています、ということみたいだ。
繰り返すけれど、分かってしまえば何てことはない。ただちょっと頭の切り替えをしないとおかしな感じで躓きますね、という話。
サイトのスマートフォン対応はさらに分化する方向なのか
以前「PCサイトのスマートフォン対応時の考え方」という記事を書いた。スマートフォン用サイトをPCサイトと別に用意するというのは、携帯サイトを作るのが始まった時と同じような感じという内容。去年の秋のことだ。
それから半年近く経ち、状況が大分変わって来ている。ホットな分野だけに進むのが早い。
今月になって、Googleのウェブマスター向け公式ブログが以下のような記事を出した。
Android のユーザーエージェントの検出について
http://googlewebmastercentral-ja.blogspot.com/2011/05/android.html
Androidからのブラウジングでは、UserAgentからタブレットかスマートフォンかを見分けて対処できますよ、という内容。
Android のユーザーエージェント - Googleウェブマスター向け公式ブログより
携帯キャリアでも端末のUserAgentについての解説はあるけれど、それと同じことをAndroidについてGoogleが説明している。
利便性をあげるための提案として有難いことだし、これは
「スマートフォンとタブレットでユーザーの使い方が異なります。対処できるのでお願いします。」
というメッセージだともとれる。
つまり、スマートフォン対応とは
- PCサイト
- 携帯サイト
- スマートフォンサイト
なイメージがあるけれど、今現在では
- PCサイト
- 携帯サイト
- スマートフォンサイト
- タブレットサイト(PCサイトそのままでも可)
という内容で検討すべき、ということだ。
工数など仕事としての面では、出来ればタブレットサイトはPCサイトを表示する方向で進めることになるケースが多いかも知れないが、ユーザーの利用シーンがスマートフォンの普及でさらに増えた、という意識を持った方が良いだろう。
紀伊國屋書店 Forest Plus スマートフォンに対応
お手伝いさせていただいている「紀伊國屋書店 Forest Plus」がスマートフォン用のページをリリースした。
URLはPCと同じ http://forest.kinokuniya.co.jp/ で、スマートフォンでアクセスすると、専用ページが表示される仕組み。
トップページだけでなく、商品ページも同様に対応しているので、公式Twtterアカウントの商品を紹介するTweetからのリンクでも問題なくスマートフォンページが表示される。
トップページはPCページのメニューから要素を削って、商品検索と商品紹介の読み物系を配置しているので、移動中に情報を眺めるのに適している。
紀伊國屋書店ならではの商品ラインナップもあるので一度チェックしてはどうだろうか。
スマートフォン対応サイトへの導線
PCサイトのスマートフォン対応時の考え方 に引き続く感じで思いついたことをまとめたメモ。
サイトが用意出来たら、そこにどうやって人を引き込むかという課題は、サイトの企画段階からあるべきもの。とはいえ、サイト開発中に状況が変化したりもするし、リリース後にだって刻々と変わっていく。サイトの特性によって一般論にあわない部分もあるだろうし、現実にやってみないと分からないことだって沢山ある。
ということで結局は常にトライ＆エラーになるんだろうけど、そんなこと言っても仕方が無いので、思いつきをいくつか書いてみる。
- PCサイトとスマートフォンの自動振り分けを用意する
- PCサイトにスマートフォン用サイトへのリンクを設ける
- 告知ページやメールマガジンなどでスマートフォン対応したことをお知らせする
- TwitterやFacebook、mixiチェックなどSNSへのリンクを取り入れる
PCサイトとスマートフォンの自動振り分けを用意する
検索エンジンやブックマークなど、今までPCサイトを表示していたURLで、スマートフォンからのアクセスの場合にはスマートフォンサイトを表示するようにする。
これでスマートフォンユーザにとっては今までと変わりなくスマートフォンサイトへ誘導することが出来る。
ただし、PCサイトで閲覧したいという要望であったり、PCサイトと同じ機能を提供しないページの場合には検討が必要となってくる。
スマートフォンサイトに対応すべきページは、サイトに入ってくる所からになるということも言える。
PCサイトにスマートフォン用サイトへのリンクを設ける
スマートフォン用ページが用意されていない、用意はされているが機能が一部異なっている為PCサイトのURLではスマートフォンページを表示出来ない、などの理由で自動振り分けに対応できないページには、PC用ページ上でスマートフォン用のリンクを用意する。この場合のリンク先をどこにするかは検討が必要。
単純にPCからのアクセスの場合でも、スマートフォン用サイトが用意されていることをアピールすることで、認知を増やし、アクセスする機会を増やすことも考えられる。
告知ページやメールマガジンなどでスマートフォン対応したことをお知らせする
同じく、スマートフォン用サイトが用意されていることをアピールすることで認知を増やし、アクセスする機会を増やすことも考えられる。
メールマガジンや告知のRSSなどは別サービスからの閲覧が発生することも予想できるし、それらは、移動中などモバイル環境から閲覧するシーンが容易に想定できる。サイトに告知を上げるだけでは無く、色々な手段でアピール出来た方が可能性は広がる。
Twitterアカウントがあれば、定期的にアピールすることで、RTなどで情報が広まるなんてことも考えられる。
TwitterやFacebook、mixiチェックなどSNSへのリンクを取り入れる
上記の告知機会を作っていく為の手段。
SNSとスマートフォンの組み合わせは非常に相性が良く、モバイル環境から閲覧するシーンが容易に想定できる。その為、ユーザがSNSにリンクをアップ出来るような、「ReTweet」や「いいね」「チェック」などのボタンを用意する。
なんだか書いていて、当たり前のことばっかりだなぁと思ったりもするけれど、これが半年先ではどんな風になっているのか？比較することを考えるとちょっとだけ面白そうだ。
PCサイトのスマートフォン対応時の考え方
PCサイトのスマートフォン対応時の考え方について、ゴチャゴチャと頭のなかにあったので、まとめる意味でも書いてみる。
スマートフォンは、Flashが駄目だとか、マウスオーバーなど一部のjavascriptが思うように動かないといった若干の制約はあるものの、基本的にはPCと機能的には変わりが無いブラウザが動く為、それ専用のポーティングを急ぐ必要性は無かった。ちょっと使いづらくてもブラウザで見れば何とかなった。
つまり極端な言い方をすれば、対応するだけであれば最初から実現できているわけ。
では、それならばという考え方で、スマートフォン用に使いやすいサイトを用意したらどうだろうというのが基本にあると考えられる。
傾向として
- ページ内の情報を簡素化し、文字などを大きくしメインの情報に絞り込む
- リストは主要なものだけ表示し、それ以外はデフォルトでは見えないようにする
- 会員登録など、PCサイトで事前にしている前提で、スマートフォンでも使うという想定
- 押し間違いを減らすためにリンクやボタンのサイズと配置に気を使う
- 機能的に間に合わない部分などはPCサイトを表示する導線を残す
といったものが見受けられる。どれも利にかなった内容だと思う。
ここで、少しだけ面白い発見がある。
それは、PCサイトを携帯電話向けサイトに対応しはじめた時も、殆ど同じ傾向だったということだ。
もちろん、携帯電話はスマートフォンに比べたら貧弱な表現力と容量しか持っておらず、画面に入れられる情報もはるかに少なかった。
その為
- ページ内の情報を簡素化し、メインの情報に絞り込む
- リストは主要なものだけ表示し、それ以外はデフォルトでは見えないようにする
- 会員登録など、PCサイトで事前にしている前提で、携帯電話でも使うという想定
と、ほぼ同じ傾向での対応方針がとられることが多かった。iモードが登場した、2000年前後のサイト企画では、上記傾向を前提とすることが多かったと記憶している。
それから10年以上経つ現在、PCを使わず携帯電話からのみでインターネットアクセスを済ませるユーザーも増え、携帯電話だけで完結したり、携帯電話専用だけど、PCサイトも一部対応しているサイトなど、多種多様な状況が存在している。PCサイトの機能をポーティングするという考え方がそもそも存在しない企画も沢山存在する。
そしてその視点をもう一度スマートフォンに戻すと、同じように近い将来スマートフォン専用のサイトというのも登場するのではと考えられる。
もちろん携帯電話とユーザーの行動は異なるわけで、まったく同じということは無いと思うが、スマートフォンならではの文化が新たに生まれるのであれば、それはそれで楽しみなことだと思う。
でも、しばらくは、PCサイトの機能見直しの機会としてスマートフォン対応案件が存在してもらうと、個人的にはありがたいというのは本音でもある。