![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Apple が iPhone と iPod touch をリリースした後、たちまち Mobile Safari は米国で最もよく使われるモバイル Web ブラウザーとなり、その市場シェアは伸び続けています。iPhone のフォーム・ファクターとユーザー・インターフェース (UI) モデルは他のモバイル・ブラウザーとは大きく異なるため、多くの開発者は自分たちの Web サイトを Mobile Safari 特有の UI モデルをサポートするように設計し直すという決定をしています。
iPhone 向けのカスタム・コンテンツを作成するという決定は、両極端にある 2 つの選択肢の中間をとっています。両極端の一方は何もしないことです。Mobile Safari のタップ・アンド・ズーム方式のインターフェースは、Web サイトがモバイル・デバイス用に設計されていないとしても、ユーザーが簡単にサイトをブラウズできるように設計されています。Apple でこのような方針を取っているのは、iPhone ユーザーは当然、完全な Web へのアクセスを期待するという見解からです。両極端のもう一方は、新しくリリースされた iPhone ソフトウェア開発キット (SDK) を使ってアプリケーションを iPhone 専用にするという選択肢です。この場合、アプリケーションの UI には計り知れない柔軟性がもたらされるだけでなく、Web アプリケーションでは使用できない iPhone の機能 (加速度計やカメラなど) も利用できるようになります。ただし、ネイティブな SDK アプリケーションを作成する際のオーバーヘッドは、Web アプリケーションを作成する際のオーバーヘッドを上回ります。既存の Web アプリケーションがある場合には、カスタム iPhone Web バージョンを作成することが iPhone の UI をユーザーに提供する最短の方法となります。
この記事では、iPhone または iPod touch ブラウザー (記事では一貫して iPhone と呼びますが、ここに記載するすべての内容は iPod touch にも当てはまることを覚えておいてください) を動的に認識すると同時に、Mobile Safari のユーザーが必要に応じて完全な Web コンテンツを表示することもできる Ruby on Rails アプリケーションを構築する方法を紹介します。今回の記事で重点を置くのは、個別のコンテンツを iPhone ユーザーに提供するために必要なサーバー・サイドの構造、そして iPhone コンテンツの提供を開始する方法です。このコンテンツを iPhone のルック・アンド・フィールにする方法については、この連載「Ruby on Rails と Eclipse による iPhone アプリケーション開発」の第 2 回で詳しく説明します。
この記事では、Ruby on Rails と iPhone をサポートするための Aptana プラグインを追加した Eclipse を使用します。Ruby on Rails プラグインが Ruby および Rails に特有の構文強調表示、ショートカット、実行環境などを提供し、iPhone プラグインが Web アプリケーションを iPhone サイズのビューポートで表示するためのプレビュー環境を提供します。
この Eclipse/Aptana の組み合わせを用意する方法は 2 つあります。その 1 つは、上述の 2 つの Aptana プラグインを既存の Eclipse 環境に追加するという方法です。もう 1 つの方法では Eclipse ベースの統合環境、Aptana Studio をダウンロードして、インストール後に Aptana の起動画面からプラグインを追加します。Eclipse 環境がセットアップ済みの場合には、通常の Eclipse プラグイン検索を行ってください。つまり、ヘルプ > ソフトウェア更新 > 検索およびインストールを選択して、「参考文献」セクションに記載してあるプラグインの更新用 URL を追加します。この記事には、2 つの Eclipse プラグインが必要です。Eclipse for Rails 環境を使用している場合には、おそらく RadRails プラグインはすでに追加されているはずでが、その他に iPhone 開発プラグインも必要となります。iPhone の模擬画面を提供するこのプラグインにより、iPhone サイズのビューポートで開発したアプリケーションをプレビューできるようになります。このプラグインは静的 HTML ページのプレビュー用には設計されていませんが、Rails アプリケーションにアクセスするように構成することもできます。図 1 は、このプラグインが動作している様子です。
図 1. iPhone プラグイン
このプラグイン・ディスプレイを見ると、まず、実際の iPhone よりもサイズが大きいことに気付くと思います。これはピクセル対ピクセルの互換性を維持するためで、プラグイン・ディスプレイのピクセル・サイズは iPhone ディスプレイと同じですが、ピクセル密度は iPhone のほうが遥かに高いからです。Macintosh を使用している場合には、iPhone シミュレーターの選択肢として、iPhoney または iPhone SDK に組み込まれた公式 iPhone シミュレーターを選ぶこともできます。
iPhoney は、Aptana プラグインと同様の模擬 iPhone ディスプレイを提供する専用アプリケーションです。先ほどのディスプレイとこのディスプレイとでは、サイトが iPhone ビューポートに収まりきらない場合の表示方法が異なります。ご覧のように、Aptana プラグインはコンテンツをフルサイズで表示してスクロール・バーを提供します。一方の iPhoney では、Web ページがビューポートのサイズに合わせて縮小されます (実際の iPhone ディスプレイでのページの表示に合わせるため)。いずれのアプリケーションにしても、Mobile Safari のダブルタップによるズームイン、ズームアウトはサポートしないので、実際の iPhone でのテストに完全に代わる手段はありません。
公式 iPhone SDK にサインアップしてダウンロードしている場合には、このパッケージに含まれる公式 iPhone シミュレーターも使用できます。このシミュレーターは正しいユーザー・エージェント文字列を送信し、ダブルタップによるズームを含めた Mobile Safari の振る舞いすべてを再現します。多少の欠点として挙げられるのは、Mac OS X V10.5 を実行していることが動作条件となっていること、そして iPhone オペレーティング・システム全体をシミュレートするため、起動時に明示的に Mobile Safari を立ち上げなければならないことです。また、デスクトップ・ブラウザーと同じようには HTML ソース・リストを取得することができません。それでも使用条件を満たしているとしたら、使用可能なシミュレーターのなかではこれが最も忠実な Mobile Safari シミュレーターとなります。
ここでは、あなたは暖かくて美味しいスープのすべてに関するオンライン情報源、Soups OnLine サイトの所有者であるという設定です。このサイトはデスクトップでは素晴しい見映えとなっていますが、外出先でスープの情報を調べるために iPhone からサイトにアクセスするユーザーが次第に増えてきました。現在、このサイトは iPhone ユーザーに対して以下のように表示されます。
図 2. iPhone でのデスクトップ・ビュー
それほど悲惨な表示ではありません。また、Mobile Safari の優れたズーム UI のおかげでユーザーはサイトをナビゲートすることもできます。それでもこのサイトは、さらに簡潔でモバイル・ユーザーのニーズにあった適切な外観にできるはずです。
ここで断っておきますが、Soups OnLine は私の著書、『Professional Ruby On Rails』のなかで作成したサイトです。これは既に存在している完成したサイトであり、いろいろいじっても他人の著作権を侵害することにはならないので、記事の大半ではこのサイトを使用します。この記事で Soups OnLine をいじったコード、そして元のコードのベースとなったテンプレートへのリンクについては、「参考文献」を参照してください。
モバイル・ユーザーに対応するには、Rails アプリケーションで以下の動作が可能でなければなりせん。
- ユーザーが iPhone または iPod touch でサイトにアクセスした場合には、それを検知する。
- ユーザーがサイトのモバイル・バージョンと通常バージョンを自由に切り替えられるようにする。
- 個別の CSS (Cascading Style Sheet) ファイルと JavaScript ライブラリー (該当する場合) を含め、Mobile Safari ユーザーに対しては異なるレイアウトを使用する。
- モバイル・ユーザーには異なるコンテンツを提供する。
この記事に記載した上記の動作を実現するためのコードは、そのまま使用できます。また、このコードは rails_iui という名前の Rails プラグインにまとめておきました。このプラグインをプロジェクトに追加すれば、1 つのパッケージで同じすべての機能を実現できます。
iPhone カスタム・コンテンツを提供するには、Rails アプリケーションが iPhone を認識できなければなりません。サーバー・サイドで主な識別手段となるのは、ブラウザーがサーバーに送信するユーザー・エージェント文字列です。iPhone のユーザー・エージェント文字列の一例を以下に記載します (バージョン番号はいずれ変わります)。
Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML,
like Gecko) Version/3.0 Mobile/1A543 Safari/419.3
|
iPod touch のユーザー・エージェント文字列は、括弧内の表現が iPhone ではなく iPod で始まっている点が異なります。Apple では新しいタグまたは CSS 設定が使用可能であるかどうかを判断するために WebKit ビルド番号 (上記の例では AppleWebKit/420+) を使用することを推奨しているようです (サーバー・サイドではなくクライアント・サイドをテストする場合には、Apple ではユーザー・エージェント文字列を使用する代わりに特定機能の有無をテストするように推奨しています)。
Rails 内では、ApplicationController の中で iPhone のユーザー・エージェントを識別して最終的に before フィルターで使用できるようにする必要があります。それには文字列で「iPhone」を検索するだけでは足りません。その場合、iPod touch を見落としてしまうからです。今の時点で iPhone ユーザーを識別する方法として今後も使えそうなのは、以下のように「Mobile」と「Safari」を突き合わせる方法です。
def is_iphone_request?
request.user_agent =~ /(Mobile\/.+Safari)/
end
|
次の目標は、iPhone を Rails V2.0 respond_to フレームワークに組み込み、iPhone が擬似 MIME タイプとして自動処理されるようにすることです。それには以下に示すようにコントローラーを増補します。
リスト 1. iPhone を処理するサンプル・コントローラー・メソッド
def index
@recipes = Recipe.find_for_index(params[:format])
respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => @recipes }
format.iphone # index.iphone.erb
end
end
|
これにはいくつかのステップが必要になります。まず、以下の行を config/initializers/mime_types.rb ファイルに追加してください。
Mime::Type.register_alias "text/html", :iphone
|
Rails の最近のバージョンでは上記の行がファイルにコメントとして含まれているので、単にコメントを外してください。config/initializers ディレクトリーのない古い Rails バージョンの場合は、この行を config/environment.rb に追加します。これによって、アプリケーション内で使用するためのカスタム iphone MIME タイプになります。iphone タイプはアプリケーション外部では text/html として処理されますが、内部では 2 つのタイプそれぞれに応じて応答することができます。
ApplicationController に戻り、今度は before フィルターとしてもう 1 つのプライベート・メソッドを追加します。
リスト 2. before フィルターとしての iPhone フォーマットの追加
before_filter :set_iphone_format
def set_iphone_format
if is_iphone_request?
request.format = :iphone
end
end
|
これで、iPhone または iPod touch からのすべてのリクエストに、:iphone というリクエスト・フォーマットのフラグが設定されます。ここまでのところ、このコードに記事のサンプル・サイト特有の点は一切ありません。このスニペットを現在取り組んでいるサイトに遠慮なく追加してください。
rails_iui プラグインを使用している場合は、ApplicationController の中、または iPhone リクエストに応答させるコントローラーに以下の行を挿入するだけで済みます。
acts_as_iphone_controller
|
前述のとおり、Aptana プラグインは上記に記載したユーザー・エージェント文字列を送信しませんが、Rails の命名規則によってこの問題は簡単に解決できます。つまり、URL で iphone 拡張子を使用すると (例えば、http://localhost:3000/recipies.iphone)、リクエスト・フォーマットは自動的に :iphone に設定されて iPhone コンテンツが提供されるようになるので、Aptana シミュレーターで iPhone コードをテストできるようになります。rails_iui プラグインを使用している場合は、上記のコマンドを acts_as_iphone_controller(true) に変更してください。これによってアプリケーションがテスト・モードになり、すべてのリクエストが iPhone リクエストとして処理されるため、シミュレーターやその他のブラウザーでのテストが至って簡単になります。
iPhone 用に最適化した Web サイトを開発中に表示する方法は、前にも述べたように以下の 4 通りがあります。
- Aptana の iPhone Eclipse プラグイン
- iPhoney
- iPhone SDK シミュレーター
- iPhone または iPod touch
Aptana プラグインには、いくつか利点があります。まず、このプラグインは Eclipse が稼動している限りどこででも実行できるクロスプラットフォーム・ツールです。また、サイトのモバイル・バージョンと従来のバージョンを横に並べて表示することが可能で、他の Eclipse 開発ツールとも問題なく統合します。複数のブラウザーで同時にアプリケーションを表示できるこのプラグインは、モバイル・ユーザーと従来のユーザーの両方を対象にしている場合に役立ちます。その上、iPhone でクライアント・サイドの JavaScript コードを使用している場合には、Aptana に備わった便利なコンソール機能を使って接続中の iPhone からのイベントをログに記録することも、さらにはアプリケーションから JavaScript コマンドを iPhone に送信することもできます。この記事が焦点としているのはサーバー・サイドの開発なので、これらの機能については説明しません。
一方、Aptana プラグインの欠点は、他の開発環境として Eclipse を使用していない場合は、Aptana プラグインによる動作はやや重たいかもしれません。さらに、特定のページでこのプラグインを有効にするように指定するのが多少厄介なこと、そして iPhone ディスプレイよりも幅の広いサイトでは実際の iPhone の動作を完全には模倣しないことも欠点として挙げられます。また、Aptana プラグインは iPhone または iPod touch のユーザー・エージェント文字列を使用してプラグイン自体を認識することはしません。前にも説明したように、Aptana で iPhone コンテンツを表示するには次善策が必要になるということです。
Aptana プラグインをインストールしたら、iPhone タイプの新規プロジェクトを開始し、プロジェクトに名前を付けてください。Aptana プラグインはデフォルトで、プロジェクトに静的 index.html ページのテストを設定しますが、これは実際の目的とは違います。ここではアプリケーションの索引ページにアクセスする必要があるため、iPhone プロジェクトの Properties ウィンドウで以下のステップを実行します。
- HTML Preview タブを表示し、Override workspace settings をクリックします。
- Preview Type パネルで Use absolute URL をクリックします。
- ローカルで実行している Rails サーバーの URL を入力します (Rails プロジェクトを Eclipse 内で実行する必要はありません。プラグインに指定した URL で実行されてさえいれば、それで構いません)。
以上のステップを完了すると、このウィンドウは図 3 のような内容になっているはずです。
図 3. iPhone プロジェクトのプロパティー
iPhone コンテンツのプレビューには iPhoney も使用することができます。これは軽量のシミュレーターで、任意の URL をアドレス・バーに入力できます。さらに幅の広いページでも正確に縮小されます。主な欠点は、Macintosh 専用のアプリケーションだという点です。iPhoneyを使用するのであれば、必ず iPhoney メニューで iPhone のユーザー・エージェント文字列を使用するようにプリファレンスを設定してください。デフォルトの振る舞いでは iPhone のユーザー・エージェント文字列を使用しません。
iPhone SDK シミュレーターも同じように機能します。このプログラムを立ち上げたら、Safari ボタンをクリックしてブラウザーを起動してください。iPhone ソフト・キーボードも表示されますが、どうしても必要だという場合にはキーボードを使ってアドレス・バーに直接 Web サイトを入力することができます。このシミュレーターが優れている点は、Mobile Safari のブックマークと「ホーム画面に登録」する機能をどちらもサポートすることです。その一方、Safari シミュレーターというわけではないので、他のすべてのシミュレーターのように簡単には表示中の HTML ソースを見る方法がないという欠点があります。
最後の選択肢は iPhone または iPod touch を実際に使うことですが、その場合にはネットワーク問題が主な障害となります。ルーターの背後に配置され、IP アドレスがプライベート IP アドレス範囲 (10.*.*.*、172.16-31.*.*、または 192.168.*.*) のいずれかになっているサーバー上で開発を行っているような一般的な状況では、iPhone に開発サーバーが見えるようにするには、サーバーが置かれたローカル Wi-Fi ネットワークを介して iPhone をインターネットに接続するしかありません (IP アドレスを直接使うと、作業が楽になります)。このような環境を用意できなければ (サーバーへのアクセス権を持つ Wi-Fi ネットワークが使用できないなど)、一般公開されているステージング・サーバーにアプリケーションをデプロイしてアプリケーションをテストしなければならなくなります。
どのオプションを使って iPhone を表示するかに関わらず、自分のサイトでページにアクセスしてみてください。この記事の例では、ページは http://localhost:3000/recipes に設定されています (この設定は、Aptana ブラウザーの場合は recipes.iphone、rails_iui プラグインを使用している場合はテスト・モードに相当します)。前に説明したようにコードが変更されていれば空白の画面が表示されるはずです。これは正常な振る舞いです (任意のデスクトップ・ブラウザーでこのサイトを表示して確認してください。正常に機能するはずです)。この振る舞いは、before フィルターが Mobile Safari を識別したためにレスポンス・フォーマットを変更し、今度は Rails の規則に合わせてレスポンスを提供しようとしていることを意味します。この場合の Rails 規則は、iphone に対応する respond_to ブロックを検索することです。該当するブロックが見つかると、Rails はレイアウト用の layout.iphone.erb ファイルを探し、ページの内側に app/views/recipes/index.iphone のコンテンツを設定します。現在このコンテンツは 1 つもないことから、Rails はブランク・ページを提供するわけです。具体的には、Rails にはまだレシピ・コントローラーの index メソッドが iphone フォーマットのリクエストに応答するように指定していないため、Rails はブランク・ページを提供しています。
ユーザーが iPhone でサイトをブラウズしていることがわかれば、ユーザーの環境について数々の有力な前提を設定することができます。現時点での Mobile Safari エコシステムには、同一サイズの画面とブラウザー・ソフトウェアを持った 2 つのデバイスしかありません。iPhone でページ上部にある可視の表示域は幅 320 ピクセル、高さ 356 ピクセルです。ユーザーがスクロール・ダウンすると、ページ上端にさらに 60 ピクセルの URL バーが追加されます。Mobile Safari ページはマージンなしで画面の両端いっぱいに表示されます。
Mobile Safari のデフォルトでの振舞いでは、Web サイトの幅を 980 ピクセルという前提にし、iPhone の表示域に収まるように約 3分の1 に縮小します。多くのサイトではこの振る舞いで有効に機能しますが、サイトの幅が非常に狭い場合や、サイトを実際の iPhone のサイズに合わせようとしている場合はその限りではありません。幸い、Mobile Safari にはサイトを表示する幅を正確に指定するためのメカニズムがあります。
Mobile Safari ビューポートのプロパティーは、特殊な meta タグを使って指定することができます。リスト 3 に、このタグが新しい app/views/layouts/recipes.iphone.erb レイアウト・ファイルではどのように配置されているように見えるかを示してあります。
リスト 3. Mobile Safari ビューポート・タグを使用したヘッダー・ファイル
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
<title>Recipes: <%= controller.action_name %></title>
<meta name = "viewport"
content = "width = device-width, user-scalable = no">
<%= stylesheet_link_tag 'iphone' %>
</head>
<body>
<h1 id="header"><%= "Soups OnLine" %></h1>
<%= yield %>
</body>
</html>
|
上記のビューポート・メタデータが設定するビューポートのプロパティーは 2 つです。最初のプロパティーでは width = device-width と設定して、Mobile Safari にデバイスの現行の幅でサイトをレンダリングするように指示しています。この値は 200 から 10,000 までの固定値に設定することもできます。2 つ目のプロパティー、user-scalable = no は、Mobile Safari のダブルタップ・ズームの振る舞いを無効にします。このサイトは iPhone の表示画面専用に設定しているためです。この 2 つのプロパティーに加え、ページの高さも設定することができます。ユーザーによる拡大縮小の振る舞いを詳細に制御するには、initial-scale、minimum-scale、maximum-scale を設定してください。この 3 つはすべて、デフォルトで 1.0 に設定されますが、0.0 から 10.0 の範囲で値を変更できます。
このレイアウト・ファイルの抜粋に含まれる iPhone 特有のもう 1 つの行は、iPhone 専用の新しいファイル CSS を指定する CSS スタイルシート・タグです。おそらく目にすることと思いますが、資料によっては iPhone コンテンツに条件付き CSS を使うように推奨しています。そのようにすることもできますが、私が思うに、条件付き CSS を使用すると構文が曖昧になってしまいます。ここではサーバー・サイドのどのブラウザーを対象にレンダリングするかはわかっているため、条件付き CSS を使用しなければならないというわけではありません。該当するブラウザーに必要なファイルそのものを指定することができます。
リスト 4 は、Soups OnLine の iPhone バージョンの初期ヘッダーを処理するために私が作成した CSS ファイルです。
リスト 4. Mobile Safari 用の CSS ファイル
h1, h2, h3 {
font-family: "Trebuchet MS", Arial, Helvetica, sans-serif;
color: #000000;
}
h1 {
font-weight: bold;
font-size: 175%;
margin: 0;
}
body {
margin: 0;
padding: 0;
}
#header {
width: 320px;
height: 40px;
margin: 0 auto;
background: url(/images/img02_iphone.gif) no-repeat;
}
|
このファイルは、元の CSS ファイルでの対応するエントリーと比べると、ほんの少しの違いしかありません。具体的には、h1 要素のフォント・サイズが小さくなっていること (実際、多少の試行錯誤によって必要なサイズを見つけ出しました)、h1 タグが太字になり、マージンが明示的にゼロに設定されていることです。太字にすることで h1 要素をもう少し目立たせ、マージンをゼロに設定することで h1 要素をビューポートの左上端ぴったりに配置しています。#header ID クラスのサイズが iPhone ビューポートと同じになったので、背景画像はスペースに収まるように手動で変更しました。
app/views/recipes/index.iphone.erb ファイルも作成する必要がありますが、今のところは空白のままにしておいてください。以上の変更によって、iPhone バージョンのサイトが順調に出来上がりつつあります。ヘッダーは図 4 のように表示されます。
図 4. Soups OnLine のヘッダー
ほとんどのシミュレーターでは、ビューポートを回転させると画像が新たにデバイスの 480 ピクセル幅に合わせてスケーリングされることがわかります。これは、デバイスの幅を基準にスケーリングするように指定したためです。
最後に追加するのは、Mobile Safari ユーザーがモバイル・ビューからデスクトップ・ビューへ切り替え (オプトアウト) を行い、さらにモバイル・ビューに戻せる (オプトイン) ようにするためのメカニズムです。これにより、モバイル・ユーザーは必要に応じて、おそらく多くの機能を持つ (ただし、ナビゲートはしにくくなる) 完全なインターフェースをいったん表示してから、iPhoneインターフェースに戻ることができます。この場合、デスクトップ・ユーザーが iPhone インターフェースに切り替えるためのリンクと同じようなリンクは設定できません。なぜなら、最終的に (つまり、第 2 回で) Mobile Safari 固有の CSS と JavaScript コードを使うようになったときにサイトが機能しなくなるからです。
このメカニズムは単純なものです。流れを説明すると、まず iPhone インターフェースのフッターにリンクを追加して、ユーザーのブラウザー・タイプのプリファレンスを指定する cookie を設定します。次に、送信用のフォーマットを決定するときに、このプリファレンスによってユーザー・エージェント文字列を上書きできるようにします。まずリンクを追加するために、app/views/layouts/recipes.iphone.erb ファイルにある body タグを以下のように変更します。
リスト 5. デスクトップ・ビューへの切り替リンクを設定したレイアウト本文
<body>
<h1 id="header"><%= "Soups OnLine" %></h1>
<%= yield %>
<br/>
<%= link_to "Switch To Desktop View",
{:controller => "browsers", :action => :desktop},
:class => "mobile_link" %>
</body>
|
このリンクに設定する新しい CSS クラスは、iPhone CSS ファイルに定義されています。
リスト 6. デスクトップ・ビューへの切り替リンクの CSS コード
.mobile_link {
font-size: 14px;
font-weight: bold;
font-family: Helvetica;
color: #00f;
text-decoration: none;
text-align: center;
display: block;
width: 320px;
}
|
Helvetica は、iPhone システムのリンク用に選んだフォントです。フォント・サイズは本文に推奨されるサイズより小さくなっていますが、これは本文にはなりません。これ以外の項目はビューポートでリンクをセンタリングするためのものです。結果的には、図 5 のような表示になります。
図 5. デスクトップへの切り替えリンク
次のステップは、cookie の設定です。リスト 5 のリンク定義を見るとわかるように、私はこのコードを管理する新しいコントローラー・クラス、BrowsersController を作成しました。リスト 7 に、cookie を設定するためのコードを記載します。
リスト 7. ビューの切り替えを行うための
BrowsersController コード
class BrowsersController < ApplicationController
def desktop
cookies["browser"] = "desktop"
redirect_to recipes_path
end
def mobile
cookies["browser"] = "mobile"
redirect_to recipes_path
end
end
|
ご覧のように極めて単純なコードです。このコードは cookie を設定して、index ページとして使用されているページにリダイレクトするに過ぎません。続いて必要になるのは、ブラウザー・プリファレンスを考慮するように set_iphone_format メソッドを変更することです。
リスト 8. デスクトップへの切り替えを使用した iPhone フォーマットの設定
def set_iphone_format
if is_iphone_request? or request.format.to_sym == :iphone
request.format = if cookies["browser"] == "desktop"
then :html
else :iphone
end
end
end
|
上記で実際に変更されているのは、2 つです。最初の if 文では、request.format.to_sym == :iphone 節を追加します。この節によって、.iphone 拡張子を使用した iPhone リクエストである URL がそのフォーマットを cookie で上書きさせることも可能になります。この文は主に、このコードを Aptana シミュレーターでテストするためにあるものです。その後に続く request.format は、ユーザー cookie に BrowserController メソッドで設定される desktop という値の有無に応じて設定されます。
後は、モバイル･ビューへの切り替えリンクをデスクトップ・ビューに追加するだけです。このリンクは iPhone ユーザーだけに表示するようにしたいので、まずは以下の行を ApplicationController に追加します。
helper_method :is_iphone_request?
|
上記の行では、is_iphone_request? メソッドをビューのどこからでも呼び出し可能なヘルパー・メソッドにしています。具体的には、このメソッドを使用してリスト 9 のコンテンツを app/views/layouts/recipes.html.erb ファイルに含まれる元のデスクトップ・レイアウトの最後に追加します。
リスト 9. iPhone が存在しているという条件付きで配置されるタグ
<% if is_iphone_request? %>
<%= link_to "Switch To Mobile Safari View",
{:controller => "browsers", :action => :mobile},
:class => "big_link" %>
<% end %>
|
この追加により、デスクトップ・ブラウザーには先ほどモバイル・ビューに設定したリンクと類似のリンクが設定されます。また、デスクトップの CSS ファイル (上記では、public/scaffold.css) に CSS クラス (以下を参照) も追加しています。
リスト 10. デスクトップでのモバイル・ビューへの切り替えリンクの CSS リスト
.big_link {
font-size: 40px;
font-weight: bold;
font-family: Helvetica;
color: #00f;
text-decoration: none;
text-align: center;
display: block;
width: 980px;
}
|
この CSS クラスは、大きく見逃しにくいリンクをデスクトップ・ペインの一番下に追加します。このリンクは実に大きいものでなければなりません。Mobile Safari は表示域に収まるようにリンクを縮小しますが、ユーザーがディスプレイをズームしなくてもリンクを見てクリックできるようにするためです。デスクトップ・ユーザーには表示されないので、リンクは大きく、注意を引くものにして構いません。iPhone ディスプレイでは、このリンクは図 6 のように表示されます。
図 6. モバイルへの切り替えリンク
このリンクはユーザー cookie を mobile に設定し、索引ページにリダイレクトします。索引ページでは、リンクは再びモバイル・ブラウザー用として解釈されます。
この記事で重点を置いたのは、iPhone および iPod touch ユーザー用のコンテンツを区別できるようにするための構造です。ビューポートを管理して Mobile Safari のコンテンツを適切なサイズとスケールで表示する方法を説明するため、この記事ではモバイル・サイトの基本レイアウトに配置する内容を説明するところから始めました。
連載第 2 回では、Mobile Safari ブラウザーでコンテンツを表示する方法を説明します。iPhone のコンテンツを管理するための UI ガイドラインにも目を向け、それぞれの Rails アプリケーションでこれらのガイドラインの本領を発揮させる方法を探っていきます。
学ぶために
- 本著者による著書、『Professional Ruby on Rails』を読んで、初歩的な Web サイトを大きく改善する方法を学んでください。
- Aptana Studio を Eclipse に統合する手順については、Plugging Aptana into an existing Eclipse configuration を参照してください。
- 「iPhone on Rails - Creating an iPhone optimised version of your Rails site using iUI and Rails 2」は、iPhone と Rails の使い方についてのブログです。
- iPhone Web アプリケーションに関する豊富なリソースを揃えた Apple Developer Connection にアクセスしてください (登録が必要です)。
- Aptana の iPhone 開発プラグインについての概要は、developerWorks 記事「Eclipse で開発する iPhone の Web アプリケーション」を参照してください。
- ソフトウェア開発者を対象とした興味深いインタービューや討論については、developerWorks ポッドキャストをチェックしてください。
- developerWorks の Technical events and webcasts で最新情報を入手してください。
- 世界中で近日中に予定されている IBM オープンソース開発者を対象とした会議、見本市、ウェブ放送やその他のイベントをチェックしてください。
- オープンソース技術を使用して開発し、IBM の製品と併用するときに役立つ広範囲のハウツー情報、ツール、およびプロジェクト・アップデートについては、developerWorks Open source ゾーンを参照してください。
- 無料の developerWorks On demand demos で、IBM およびオープンン・ソースの技術と製品機能を調べて試してみてください。
製品や技術を入手するために
-
developerWorks blogs から developerWorks コミュニティーに加わってください。
議論するために
-
Aptana にアクセスして、Aptana Studio、RadRails プラグイン、iPhone プラグインをダウンロードしてください。
- Aptana Update Site から、Aptana の RadRails および iPhone プラグインを入手してください。
-
iPhoney について調べてください。
- この記事で使用した Soups Online バージョンのコードを確認してください。
- 元の Soups OnLine サイトの設計および CSS は、FreeWebTemplates.com に用意されたテンプレートから作成しました。
-
rails_iui プラグインについて調べてください。
-
IBM ソフトウェアの試用版を使用して、次のオープンソース開発プロジェクトを革新してください。ダウンロード、あるいは DVD で入手できます。
-
IBM 製品の評価版をダウンロードして、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を使ってみてください。
Noel Rappin は、Pathfinder Development (http://www.pathf.com) で Rails 業務の責任者を務めています。Web アプリケーション開発では 10 年の経験を積んでいます。彼が博士号を取得した Georgia Institute of Technology では、オブジェクト指向の設計概念の教授法を学びました。彼の著書には『Professional Ruby on Rails』、共著書には『wxPython in Action and Jython Essentials』があります。詳しくは、http://www.pathf.com/blogs、http://10printhello.blogspot.com を読んでください。
