連載 .NETでモバイル・サイト開発を始めよう（特別編） モバイルWeb開発に失敗しない鉄則 シグマコンサルティング　菅原 英治 2007/10/19
Page1 Page2 Page3

■第2の鉄則：画面を遷移するときは……

　第2の鉄則は、モバイル・サイトにおける画面遷移に関する鉄則である。

●モバイル・サイトでの画面遷移方法

　はじめに、モバイル・サイトで画面を遷移させる一般的な方法について考えると、次の2つの方法が考えられる。

【画面を遷移させる方法】

（1）ハイパーリンクで遷移する（GETリクエストで遷移する）
（2）リダイレクトで遷移する（MobilePageクラスのRedirectToMobilePageメソッドで遷移する）

　（1）の「ハイパーリンクで遷移する」方法は、最も単純な画面の遷移方法だ。具体的には、遷移先の画面へのURLを持ったハイパーリンクをユーザーにクリックさせて遷移させるということだ。いまさら説明するまでもないが、この場合は、遷移先の画面を（HTTPプロトコルの）GETコマンドでリクエストする。

　（2）の「リダイレクトで遷移する」方法は、ASP.NETで一般的な画面遷移の方法だ。具体的には、Commandコントロールで作成したボタン（たとえば［ＯＫ］ボタン）をクリックさせて遷移させるということだ。ただし、モバイルWebフォームのページでリダイレクトする際には、MobilePageクラスのRedirectToMobilePageメソッドを利用することになる。

　ここで、上述した2つの画面遷移方法の利用方針、つまり「どの場面ではどちらの方法を使うべきかという基準」を考えたい。

●なるべくリダイレクトは避けるべし

　基本方針としては、なるべくリダイレクトによる遷移を避けて、ハイパーリンクで遷移するのがよいだろう。その理由を述べる。

　（2）の「リダイレクトで遷移する｣方法では、ポストバック後、端末にレスポンスを返し、端末側で画面を遷移させることになる。そのため、「ハイパーリンクで遷移する」方法に比べて、データの通信量が多くなってしまうという欠点がある。

　いうまでもなく、データの通信量はなるべく抑えた方が、利用するユーザーにとっては都合が良い。またリダイレクトの利用時には、後述する注意点があるため、扱うのがやや難しいのだ。以上の理由から、（1）の「ハイパーリンクで遷移する」方法を選択するのが好ましいといえる。

　第2の鉄則をまとめよう。

【第2の鉄則】 画面を遷移する際には、 なるべくリダイレクトを避け、 ハイパーリンクで遷移するべし。

●リダイレクトを利用するときの注意点

　さて、「なるべく避けるべし」としたリダイレクトでの遷移だが、もちろんどうしても利用しなくてはならないケースもあるだろう。ここでは、リダイレクトで遷移する際の注意点を2つ述べておこう。

○注意点1：クエリ文字列の付加し過ぎに注意

　第1の注意点は、遷移先のURLに付加するクエリ文字列である。端末のブラウザでは、サポートするURLの文字数が制限されている場合がある。クエリ文字列を付加しすぎると、端末のサポートするURLの文字数を超えてしまいエラーとなってしまうことが考えられる。

　このようなエラーを起こしてしまう例としては、次のようなリダイレクトの利用法が挙げられる。

　例えば、会員情報を入力させるために、多数の入力項目を複数の画面に分割しているとする。仮にA、B、Cの3つの画面に分割しているとしよう。A画面で入力した項目を、B画面に遷移する際のURLにクエリ文字列として付加し、リダイレクトで遷移する。B画面から、C画面へ遷移する際にも同様に遷移する。このとき、クエリ文字列として付加した項目があまりに多すぎる場合、（例えばB画面からC画面への）遷移時にエラーとなってしまうことがあるのだ。

　このエラーを防ぐには、「セッション変数を利用してデータ（＝入力項目の情報）を渡すこと」もしくは「第1の鉄則に従い、1ページ内でフォームを分割すること」で対応できるだろう。

○注意点2：絶対URLでリダイレクトを行う際の注意

　第2の注意点は、絶対URLによるリダイレクトである。例えば、端末とIIS（＝Webサーバ）の間に、SSLアクセラレータやポート番号を付加するような変換サーバが存在するとしよう。それらがリクエストされたURLを変更する場合、意図しないURLにリダイレクトされる場合がある。

　エラーが起こる例を下の図に示す。この図は、SSLアクセラレータを利用した場合にエラーが発生する際の処理の流れを表している。SSLアクセラレータとは、通常はWebサーバ（IISなど）が行うSSLの暗号化／複合化の処理を、代行するハードウェアのことである。一般的に、データの暗号化／複合化は、Webサーバに大きな負荷を与える。そのため、このような専用のハードウェアを利用することで、Webサーバの負荷を軽減することができる。

SSLアクセラレータを利用した場合のエラーまでの流れ

絶対URLでリダイレクトを行う際に、SSLアクセラレータを利用しているケースでエラーが発生することがある。

端末からSSLアクセラレータに「https://」（SSL）でリクエストを行う。 　 SSLアクセラレータがSSLを処理し、IISへ「http://」（非SSL）でリクエストを行う。 　 IISより端末へ「http://」（※非SSL）でリダイレクトするようにレスポンスが返る。 　 端末からSSLアクセラレータに「http://」（※非SSL）でリクエストを行い、エラーとなってしまう。

　また次の図は、変換サーバを利用した場合にエラーが発生する際の流れだ。

変換サーバを利用した場合のエラーまでの流れ

絶対URLでリダイレクトを行う際に、変換サーバを利用しているケースでエラーが発生することがある。この例では「http://abc」という仮想サイトにアクセスしている。

端末から変換サーバに「http://abc」でリクエストを行う。 　 変換サーバがポート番号（:8080）を付加し、「http://abc:8080」でIISへリクエストを行う。 　 IISより端末へ「http://abc:8080」（※「http://abc」ではない）でリダイレクトするようにレスポンスが返る。 　 端末から変換サーバに「http://abc:8080」（※「http://abc」ではない）でリクエストを行い、エラーとなってしまう。

　絶対URLでリダイレクトを行う際には、このような問題が発生することに注意が必要である。

○絶対URLでリダイレクトを行う際に問題を回避する方法

　絶対URLでリダイレクトを行う際に、SSLアクセラレータや変換サーバなどを利用するとエラーが発生する問題があることを述べた。ここでは、SSLアクセラレータで発生する問題を例に、回避する方法を紹介する。

　具体的には、以下の2つの回避方法を行うとよい。これにより、端末からリダイレクトされるときのURLが常に「https://」となり、上述の問題を回避できる。

【回避する方法】

（1）Web.configファイルの<httpRuntime>要素のuseFullyQualifiedRedirectUrl属性をfalseに設定する
※ただし、端末に送られるURLは絶対URLではなくなるので注意してほしい。
※つまり、常にhttp://server/path形式でのリダイレクトではなくなる。そのため、（2）の方法によりhttpsでの遷移が可能となる。

<httpRuntime useFullyQualifiedRedirectUrl="false"/>

（1）の設定例：<httpRuntime>要素のuseFullyQualifiedRedirectUrl属性をfalseに設定したコード（Web.configファイル）

（2）Global.asaxファイルのApplication_EndRequestイベント・ハンドラ内で、Response.RedirectLocation属性の内容を改変する
※Response.RedirectLocation属性は、端末に送信されるリダイレクト用のURLが保持されている（.NET Framework 1.1から利用可能）。

……省略…… protected void Application_EndRequest(Object sender, EventArgs e) {   if (Response.RedirectLocation != null)   {     Response.RedirectLocation =       Response.RedirectLocation.Replace("http", "https");   } } ……省略……

（2）の実装例：Application_EndRequestイベント・ハンドラでResponse.RedirectLocation属性の内容を改変したコード（Global.asaxファイル）

この例では「http」リクエストをすべて「https」に置き換えている。

ソースのダウンロードはこちらから。

　絶対URLでリダイレクトを行う際の注意点は、以上である。

【コラム】DeviceProfilingToolについて 　マイクロソフトが提供する「ASP.NET Mobile Device Profiling Tool」（以下、DeviceProfilingTool）というツールがある。このツールは、デバイスの識別情報を判別し、ブラウザ情報を構成ファイル（＝.configファイル）で利用できるように生成してくれるツールだ。次のファイルは、筆者がDeviceProfilingToolを利用し、試しに生成したファイルである。 　・筆者が試しに生成したファイル（5303.config） 　一見すると便利そうなツールである。しかし実際のところ、残念ながら以下の理由からあまり使えない。 　（1）利用するのにデバイス（＝端末）の実機が必要である 　（2）生成されるファイルが1つの実機に限定されるため、定義情報が増えすぎる 　そのため、「第2回」で紹介したように、ブラウザ定義ファイルに自分で定義を記述した方がよいだろう。 【参考】 　・ASP.NET Device Profiling 　・デバイス プロファイリング ツールのインストラクション

　以上がモバイルWeb開発に失敗しない鉄則である。最後に、モバイルWeb開発に役立つ（裏技的な）TIPSとしてモバイルWebユーザー・コントロールを手軽に作成する方法を紹介する。

INDEX
	［連載］.NETでモバイル・サイト開発を始めよう（特別編）
	モバイルWeb開発に失敗しない鉄則
	1．第1の鉄則：1ページに入力項目が多くある場合は……
	2．第2の鉄則：画面を遷移するときは……
	3．裏技TIPS：ユーザー・コントロールの簡単な作成方法

「.NETでモバイル・サイト開発を始めよう」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）