Android と iPhone のブラウザー戦争: 第 1 回 WebKit による救いの手

ブラウザーのためのネットワーク監視アプリケーションを作成する

最近の生活のなかで、モバイル機器が果たす役割は大きくなっていく一方です。私たちはモバイル機器を使って通信し、ナビゲーションにもモバイル機器を使用し、さらには手近な懐中電灯としてもモバイル機器を使っているほどです。iPhone および Android プラットフォームではカスタム・アプリケーションが絶大な人気を集めていますが、そこに入り込む余地はモバイル Web アプリケーションにもあります。この記事は、iPhone と Android に対応したブラウザー・ベースのアプリケーションを開発する方法を説明する 2 回シリーズの第 1 回です。このシリーズをとおして、デスクトップ・ブラウザーと iPhone および Android 両方のモバイル・ブラウザーで動作する単純なネットワーク監視アプリケーションを構築します。

Frank Ableson, Software designer

Frank Ableson はニュージャージー州北部の起業家、ソフトウェア開発者であり、モバイルおよび組み込みアプリケーション・ソフトウェアを専門としています。彼は現在、Android によるアプリケーション開発に関する本を執筆中です。この本は Manning Publications から出版される予定です。彼は組み込みシステムとワイヤレス通信、そしてカー・エレクトロニクスにプロとしての関心を持っています。彼の最大のファンは、彼の妻の Nikki と彼らの子供達です。



2009年 12月 08日

はじめに

iPhone と Android プラットフォームのアプリケーション・ストアからダウンロードできるアプリケーションは、合わせて 100,000 タイトルを超えています。プラットフォームの SDK で作成されてから、機器にコンパイルされてインストールされるアプリケーションは、ネイティブ・アプリケーションと呼ばれます。ネイティブ・アプリケーションは機器に内蔵されている機能 (無線 LAN 接続、Bluetooth、データ・ストレージ、加速度センサー、コンパスなどの機能の他、機器を魅力的なものにするために搭載された高度な機能など) に完全にアクセスすることができます。iPhone と Android プラットフォームでは、このようなネイティブ (カスタム) アプリケーションが絶大な人気を集めていますが、そこに入り込む余地はモバイル Web アプリケーションにも大いにあります。モバイルは十分に発展しました。その発展に伴っているのが、モバイル Web です。

この記事は、iPhone と Android に対応したブラウザー・ベースのアプリケーションを開発する方法を説明する 2 回シリーズの第 1 回です。このシリーズでは、開発者が独自のモバイル Web アプリケーションの開発をスムーズに始められるように支援することを目的としています。モバイル Web アプリケーションは、モバイル機器に Web サイトをレンダリングするだけではありません。それ以上のことを実現できます。そこでこのシリーズでは、モバイル Web 開発を魅力ある分野にしているコア技術と手法をいくつか取り上げて説明します。

現在、Web はプラットフォームとして好んで使われています。それは、従来からアプリケーション開発者やシステム管理者を悩ませてきた問題の多くを Web が解決してくれるからです。こうした Web によるソリューションとしては、以下のような例があります。

  • Web アプリケーションはデプロイするのが簡単です。Web アプリケーションをサーバーにインストールまたはコピーし、クライアントにブラウザーでその正しい URL を指定させるだけでデプロイすることができます。
  • Web アプリケーションはハイパフォーマンス・データ・センター内のサーバー・ファームにも柔軟に対応し、簡単に手に入る Web サイト管理ツールで保守することができます。
  • Web アプリケーションはデータ・ストレージを一元化することによって、災害復旧計画を単純化します。
  • HTML、CSS (Cascading Style Sheets)、JavaScript、そしてグラフィック画像を組み合わせることにより、(本格的な没入型のゲーム・エクスペリエンスには及ばない) ネイティブ SDK のエクスペリエンスや (ゲームやキオスクのエクスペリエンスを保証していない) 大半のアプリケーションのエクスペリエンスに比べ、遥かに優れたユーザー・インターフェース・エクスペリエンスを実現します。
  • 大多数のアプリケーションには、ユーザーに一連の日常的な操作を手引きする、使いやすい UI 要素が必要です。

Web アプリケーション分散モデルでとりわけ魅力的な側面は、ソフトウェアをサブスクリプション指向のサービスに変換できることです。これはまさに Win-Win の結果をもたらしてくれますが、それがどのようにして実現されるのかをここで簡単に説明します。

Web デプロイメント・モデルでは、顧客が試用版のサービスを試してみてから購入することができるので、最小限のリスクとコストでそのサービスを購入できるようになります。顧客が試用版を気に入った場合、そのサービスを使い続けるにはクレジット・カード (または PayPal) で取引すればよいだけです。このモデルは、ソフトウェア・ベンダーにとってメリットがありますが、その理由は、システムのアップグレードが単純化されるためサポートのコストが減るからであり、最終的には顧客に転嫁されるコストも最小限になります。それだけではありません。SaaS (Software as a Service) モデルを使用した場合、顧客は事前に多額の投資を行わなくても、ソフトウェアの恩恵を受けることができます。したがって、投資に対する収益は漠然とした先の時点ではなく、投資したその月に早速もたらされるというわけです。

素晴らしいことのように聞こえますが、Web でメリットがあることは、モバイルでも同じくメリットがあるのでしょうか。その答えは、iPhone が登場するまでは概して「ノー」でした。

その理由は、これまでモバイル Web のブラウザー・エクスペリエンスが物足りなかったからに他なりません。しかし現在、事態はすっかり変わっています。それは、iPhone を通して一般大衆のモバイル世界に影響を与えた、WebKit として知られる技術のおかげでです

iPhone は登場してからわずか数年のうちに一気に世界第 1 のモバイル Web クライアントの地位にのぼりつめました。なぜでしょうか?それは、WebKit と信頼性の高いインターネット接続により、Web がモバイルでも有効に機能するようになったからです。その有効性は、他のあらゆるブラウザーを遥かに凌いでいます。この事実に気付いた他のモバイル市場は、WebKit を使用するようになっているか、様子を眺めているか、そうでなければこの技術を採用しない口実を作っています。

では、WebKit とは一体何なのでしょうか。


WebKit と HTML5

WebKit は、iPhone の Mobile Safari ブラウザーを駆動するブラウザー・エンジンであると同時に、Android のブラウザーを背後で支える技術でもあります。WebKit はこの 2 つ以外のモバイル環境にも使われていますが、この記事では iPhone および Android プラットフォームに焦点を絞ります。

WebKit は KDE (K Desktop Environment) に端を発するオープンソース・プロジェクトです。WebKit プロジェクトは、モバイル機器を対象とした最近の Web アプリケーションに生命を吹き込みました。機器の機能とデザインは極めて重要なものの、モバイル・ユーザーが楽しむのはコンテンツです。インターネットでアクセスできるコンテンツのうち、モバイル・ユーザーがアクセスできるのはそのわずかな部分だけだとしたら、そのユーザー・エクスペリエンスは平凡なものにしかなりません。

私たちの多くは、どこにいても変わらない生活を送りたいと思うものです。例えば自宅ではラップトップで Web サイトを利用しているとしたら、電車に乗っているときにも同じコンテンツが利用できることを期待します。コンテンツは、キラー・アプリケーションです。私たちはどこにいようと、何をしていようと、目的のデータにアクセス可能であることを求めます。WebKit は iPhone や Android プラットフォームで、リッチなコンテンツをレンダリングできるようにします。

注目に値する点は、WebKit はデスクトップにおいても、Safari ブラウザー (Mac OS X プラットフォームのデフォルト・ブラウザー) で使用されていることです。話題にしているのが WebKit のデスクトップ・バージョンであろうと、iPhone または Android のブラウザー・エンジンとしての WebKit であろうと、HTML および CSS の機能のサポートという点で WebKit が最先端をいっていることに違いはありません。実際 WebKit は、他のブラウザーではまだ採用されていない CSS スタイル、つまり HTML5 仕様で現在検討中の機能をサポートします。

HTML5 仕様は、さまざまなブラウザー・ベースの技術を対象とする技術ドラフトを集めたものです。これらの技術には、クライアント・サイドの SQL 対応ストレージ、遷移、変換、翻訳などが含まれます。HTML5 への取り組みはこれまで長い間進められてきました。まだ完成には至っていないとは言え、その機能セットが主要なブラウザー・プラットフォームによってサポートされた暁には、まだ登場したばかりの頃の素朴な Web アプリケーションは遠い過去の記憶となることでしょう。そして開発されるアプリケーションは、Web アプリケーションが優勢となり、その対象は従来のデスクトップ・ブラウザーにとどまらず、モバイルの領域にまで広がることでしょう。モバイルは後から検討する対象ではなく、最初に検討する対象となるはずです。


モバイル Web アプリケーションの考慮事項

Web 開発技術を使用する場合、現代のアプリケーション開発者にはいくつかの選択肢が用意されています。まず、厳密にサーバー上の HTML、CSS、JavaScript ファイルとしてアプリケーションを作成するという方法があります。もちろん HTML コンテンツは静的 HTML ファイルとすることも、PHP や ASP.NET、そして Java サーブレットなどのさまざまなサーバー・サイド技術のいずれかから動的に生成することもできます。これらの技術はまとめて HTML という言葉に要約できますが、HTML 自体はこの記事ではそれほど重要でありません。最も重要なことは、WebKit ベースのブラウザーはモバイル機器で、HTML を解釈してレンダリングできるという点です。

ユーザーがモバイル機器 (すなわち、iPhone または Android) で Web アプリケーションにアクセスするには、ブラウザー・アプリケーションを開き、目的とするサーバーの URL (http://yourcompanyname.com/applicationurl) を入力します。

個々のモバイル Web アプリケーションは、汎用的な Web サイトから極めてプラットフォームに特化されたモバイル Web アプリケーションに至るまでのどこかに当てはまります。

汎用サイトのレンダリング

WebKit のレンダリング・エンジンは、iPhone および Android プラットフォームで目にする極めて直観的な UI と結合され、実質的にあらゆる HTML ベースの Web サイトをモバイル機器上で表示することができます。これまでのモバイル・ブラウザー・エクスペリエンスでは、コンテンツがラップされていたり、あるいはまったく表示されなかったりしましたが、それとは異なり、Web ページはモバイル機器上で正しくレンダリングされます。ページのロード時は、ページ全体が見えるようにコンテンツは大抵ズームアウトされます。そのためコンテンツが非常に小さく、場合によっては読み取れないまでのスケールで表示される場合もあります (図 1 を参照)。しかし、ページをスクロール、パン、ピンチ、ズームすることで、コンテンツの隅々まで簡単にアクセスできるようになっています。デフォルトでは、ブラウザーは幅 (論理サイズ) 980 ピクセルのビューポートを使用します。

図 1. ロード時に完全にズームアウトされた Web ページ
大抵はページ全体が見えるように、たとえ非常に小さな表示になるとしても、コンテンツがズームアウトされます。

ページ全体にアクセスできるようになったことは、従来のモバイル Web エクスペリエンスに比べて大きな進歩ですが、モバイル・エクスペリエンスを改善するためにできることは他にもまだあります。

モバイル・フレンドリーな Web ページ

汎用 Web ページをモバイル・フレンドリーなものにするには、いくつかの領域で Web アプリケーションに変更を加えられます。

ページは WebKit で正しくレンダリングされるものの、ラップトップまたはデスクトップ・コンピューターなどのマウス操作中心の機器と、iPhone や Android スマートフォンのようにタッチ操作を中心とした機器との間にはいくつかの違いがあります。主な違いを挙げると、「クリック可能」な領域の物理サイズ、「ホバー・スタイル」の有無、そしてまったく異なるイベント・シーケンスです。以下に、モバイル・ユーザーが表示することになる Web サイトを設計する際に考慮すべき点を簡単にまとめます。

  • iPhone/Android ブラウザーは、通常のモバイル・ブラウザーより遥かに読みやすいように画面をレンダリングします。したがって、モバイル向け専用にコンテンツを少なくしたサイトを作成する必要はありません。
  • 指はマウス・ポインターのサイズを上回ります。クリック可能なナビゲーションを設計するときには、この点に注意して、リンク同士を近付け過ぎないようにしてください。そうでないと、ユーザーが 1 つのリンクをクリックすると、隣のリンクまでクリックしてしまうことになります。
  • ホバー・スタイルは使用できません。指を使ってマウス・ポインターのように「ホバー」することはできないためです。
  • マウス・ボタンの押下、マウスの移動などのイベントは、タッチ操作をベースとした機器では全く異なります。これらのイベントのいくつかはモバイル機器でも発生しますが、デスクトップ・ブラウザーで目にするシーケンスと同じであるとは限りません。

以上の点についての詳細は、『iPhone in Action』(「参考文献」を参照) を参照してください。ここからは、WebKit で不可能なことではなく、可能なことのほうに重点を置きます。

Web サイトを iPhone や Android のユーザーにとって使いやすくする上で、最も明白な課題となるのは画面サイズへの対処です。これらのモバイル機器の画面サイズのデファクト・スタンダードは、320x480 です。ユーザーが Web コンテンツを横長の画面で表示した場合、このサイズは 480x320 となることにも注意してください。図 1 で目にしたとおり、WebKit はデスクトップ指向の Web ページを正しくレンダリングしますが、コンテンツをすんなり読むにはテキストが小さすぎるため、ピンチ操作とズーム操作を何度も繰り返さなければなりません。この問題については、どのように対処すればいいでしょうか。

最も単純に、しかもデスクトップに影響しないようにモバイル・ユーザーに対応する方法は、特殊なメタタグ、viewport を使用することです。

メタタグとは、HTML 文書の head 要素のなかに置かれる HTML タグのことです。viewport タグの単純な使用例として <meta name="viewport" content="width=device-width" /> というメタタグを HTML ページに追加すると、そのページはモバイル機器に合わせた適切なスケールに調整されます (図 2 を参照)。このタグをサポートしないブラウザーは、単にこのタグを無視するだけです。

図 2. モバイル機器に合わせて適切にスケールが調整されたページ
このメタタグを HTML ページに追加すると、モバイル機器に合わせて適切にスケールが調整されたページが表示されます。

場合によっては、ウィンドウのスケールを特定の値にあらかじめ設定しておくほうが望ましいこともあります (図 3 を参照)。

図 3. スケールが事前に設定されたウィンドウ
ウィンドウのスケールを特定の値に事前に設定したほうが望ましい場合もあります。

特定のスケールを設定するには、viewport メタタグの content 属性を明示的な値に設定します (例えば、<meta name="viewport" content="width=device-width, initial-scale=1.0 user-scalable=yes" />)。initial-scale の値を変更することで、画面を必要に応じてズームインしたり、ズームアウトしたりすることもできます。iPhone および Android プラットフォームの場合、この値を 1.0 から 1.3 までの間に設定すると適切です。viewport メタタグは最小スケールと最大スケールもサポートします。この 2 つのスケール設定を使用すれば、ユーザーがページをレンダリングできる範囲を制限することができます。

iPhone のデザインは、iPhone が登場したときから 320x480 というレイアウトのままですが、Android ではさまざまなメーカーがさまざまなユーザー層をターゲットとした機器を発表するにつれ、物理特性がより多様になっていくはずです。したがって Android のようなモバイル機器をターゲットとしてアプリケーションを開発する際には、画面のサイズ、デザイン、そして解像度に見込まれる多様性を念頭に置く必要があります。

これまでは、Android 搭載機器の間に物理的な仕様の違いはあっても、Android のソフトウェアは機器にインストールされているブラウザーの設定を通じて、ページのレンダリングを細かく制御していました。Android プラットフォームは安定している一方で、かなり流動的でもあるため、SDK のレベルとメーカーによっては、特定の機器での設定が開発環境での設定と異なってくる可能性もあります。図 4 のスクリーン・ショットは、Android Emulator V1.6 から撮ったブラウザー・アプリケーションの設定ページです。この設定画面でユーザーは、ブラウザーでの表示が事前定義されたズーム・レベル (Far、Near、Medium) になるように機器を構成したり、表示するページが画面に収まるようにサイズを自動調整する設定にしたりすることができます。

図 4. Android Emulator の設定ページ
この図には、Android Emulator V1.6 から撮ったブラウザー・アプリケーションの設定ページのスクリーン・ショットが示されています。

モバイルの世界で常に変わらないことは、変化し続けていることに他なりません。つまりモバイルの世界の全体像は多少なりとも確実に変わっているということです。例えば、Sprint 社の Hero のブラウザーの設定にはページ・レンダリングに関して全く異なるオプションのセットがあります。Hero は Android V1.5 をベースに、HTC が提供する山ほどの機能拡張を加えて作成されています。幸い、これらの設定が Web ページに設定されているとしても、viewport メタタグの内容で上書きされます。

今までのところ、ズーム操作を行わなければ小さくて読みにくいとは言え、WebKit は通常の Web ページをかなり首尾よくレンダリングすることがわかりました。次に制御の範囲をユーザーのエクスペリエンスに拡大し、viewport メタタグを使用して機器上でのページの表示を制御しました。その結果、ページは読みやすく、簡単にナビゲートできるようになっています。けれどもさらに改善を進め、サイトをモバイル・アプリケーションのようなルック・アンド・フィールにするとしたら、どうすればよいでしょうか。

モバイル用アプリケーション

ここで、モバイル・ユーザーをターゲットとした場合の設計ストラテジーについて考えてみましょう。簡単な事例研究として、Google の E メール・サービス、GMail のログイン・ページを検討します。

まず、図 5 のデスクトップ・ブラウザー・エクスペリエンスを見てください。

図 5. デスクトップ・ブラウザー
デスクトップ・ブラウザー・エクスペリエンスを示す図です。

このデスクトップのホーム画面には、左側に情報を提供するためのコンテンツが表示され、右側にサインインするための領域があります。このデスクトップのビューを、図 6 に示す iPhone でのモバイル用のビューと見比べてください。

図 6. iPhone でのモバイル用のビュー
iPhone から撮った、モバイル用のビューを示すスクリーン・ショットです。

図 6 の画面がターゲットとしているのは、明らかにモバイル・ユーザーです。ユーザーはアプリケーションを進めるために必要な情報を直接入力できるようになっていて、ピンチやズーム、スクロールなどの操作は必要ありません。

次に、メッセージを読む際のモバイル GMail アプリケーションの機能に注目してください。アプリケーションが使用できる画面面積は限られているため、メッセージを読むためのウィンドウに、ボタンやナビゲーションを表示するためのスペースはほとんどありません。ナビゲーション専用のスペースが少しでもあると、コンテンツを読むためのスペースが小さくなってしまいます。それと同時に、複数のフレームを表示したり、div 要素をスクロールしたりするなどの手段もできるだけ避けなければなりません。モバイル GMail はこの問題を、ページのスクロールが停止すると必ず単純なフローティング・メニューを表示するという方法で解決します。このメニューには「Archive」、「Delete」、「More」という 3 つのボタンがあり、「More」ボタンを選択すると他のメニュー項目が表示されるようになっています (図 7 を参照)。

図 7. フローティング・メニュー
「More」ボタンを選択すると、他のメニュー項目が表示されます。

これは、モバイル用に作成されたアプリケーションです。

もう 1 つ忘れてはならない点は、iPhone や Android プラットフォームで使われているような非常に有能なブラウザーを実行しているユーザーにとって、モバイル・エクスペリエンスのレベルを下げないようにしなければならないことです。その点に関しては、GMail がページの一番下に表示するオプションを見てください。

図 8. ユーザーに用意されたオプション
ユーザーに用意されたオプションを示す図です。

ユーザーがより強力なデスクトップ・バージョンの機能を選択して使えるようにしてください。可能であればいつでも、ユーザーが選択できるようにすることが重要です。

次に、Web 技術を使用しながらも、まるでモバイル機器のネイティブ・アプリケーションのように見えるアプリケーションを作成するとしましょう。

特定のプラットフォーム専用のコンテンツ

次のステップでは、特定のプラットフォーム専用のコンテンツを作成します。そのために行う作業は、ページのルック・アンド・フィールが汎用 Web サイトのようではなく、ターゲット・プラットフォームにネイティブのルック・アンド・フィールに近くなるようにページのフォーマットを設定することです。では、ここで言うネイティブとは何を意味するのでしょうか。

Web ページのルック・アンド・フィールを特定のプラットフォームのネイティブ・アプリケーションのようにする方法について詳しく掘り下げる前に、iPhone と Android のプラットフォームとしての視覚的な違いを簡単に調べてみましょう。ブラウザーをベースにした iPhone と Android の強力な関係はひとまず脇においておくことにします。

iPhone には独特のルック・アンド・フィールが備わっています。誰かに iPhone の画面のスクリーン・ショットを見せた場合、その相手が文明社会から離れて暮らしているのでない限り、その画像を iPhone の画面であると特定できる可能性はかなり高いはずです。一方、同じ相手に Android 搭載機器の画面のスクリーン・ショットを見せた場合には、結果は違ってくるでしょう。それはなぜかと言えば、考えられる理由がいくつかあります。第一の理由は、iPhone のほうが市場に出てからの期間が長く、その熱狂的ファンの数は決して少なくないからです。あの限られた機能の初代の iPhone にかなりの金額を払おうと何時間も行列を作った人々を覚えていますか? iPhone を持っているかどうかにかかわらず、Apple が創り出した商品は現在の市場で憧れの的となっています。それでは、Android についてはどうでしょうか。

Android は比較的新しく、多くの点で iPhone に対抗しています。それは多かれ少なかれ、Android がオープンソース・コミュニティーを信奉しているからです。Android を使用する機器は多数あると思いますが (電話やその他のアプライアンス・タイプの機器)、ここでは説明をできるだけ単純にするため、携帯電話に話題を絞ります。

Android 対応機器の数は、やがて世界中の iPhone を超えることになるでしょう。その理由は、目下、複数のメーカーが Android ベースの機器を生産中で、これらの機器が世界各地の通信事業者のネットワークで使えるようになるからです。Android 市場に参加している団体の数が多いということは、当然ルック・アンド・フィールもいくつかに分かれてきます。その一例は、前述の HTC による SenseUI インターフェースです。この魅力的なルック・アンド・フィールは、コアとなる Android SDK にはないものであり、すべての Android 搭載機器と互換するわけでもありません。そこで、Motorola、Google、Verizon はチームを組んで新しい Android 機器を作成することにしました。それが、DROID です。DROID は 2.0 プラットフォームで動作する最初の商用 Android 機器です。

Android の多様な表示を iPhone の一貫した表示と見比べてみてください。iPhone は Apple のとっておきの商品です。iPhone の表示は時間とともに進化していくかもしれませんが、その初期段階から Android に表れていたような、多岐にわたる表示に悩まされるとは考えられません。

では、ネイティブのルック・アンド・フィールとしては何を目標にすればよいのでしょうか。

Web 2.0 が登場する以前は、これは実に難しい問題だったはずです。複数のクライアント・ブラウザー (モバイルと非モバイル) をサポートする初期の試みでは、以下をはじめとする多種多様な技術が使用されました。

  • 完全なパラレル・サイト
  • userAgent に基づいてコンテンツを動的に生成する
  • プロキシー・サーバーを使ってコンテンツを機器に抽出する。RIM は機器上での E メールのレンダリングに、この手法を広範かつ効果的に使用しています。

以上の手法は、十分な資金のあるチームでは容認できるかもしれませんが、それ以外のチームにとっては、時間も、才能も、そしてこのような機能と引き換えにする資金もありません。さらにここまで見てきたように、これまでのモバイル Web は力不足だったので、これらの手法を採用するだけの資金があったとしても、その時代に戻りたいとは思いません。

幸い、かつてのモバイル Web に戻る必要はありません。WebKit と CSS の時代では、スタイルシートとメディア・クエリーを使うことによって、クライアント・ブラウザー間の違いに簡単に対応することができます。前に紹介したとおり、メディア・クエリーとは、クライアントに関する情報を取得する手法のことです。従来、ブラウザーはそのブラウザー自体を識別する userAgent ストリングをサーバーに送信し、サーバーはこのストリングから、そのブラウザーを搭載している機器に送信するコンテンツを判断していました (前述のとおりです)。メディア・クエリーでは、ブラウザーがそれ自体に備わった機能を基準にコンテンツを決定します。例えば、スマートフォンをターゲットとしたスタイルシートを取得するとしたら、メディア・クエリーは <link rel="stylesheet" type="text/css" href="smartphone.css" media="only screen and (max-device-width: 480px)" /> となります。一方、デスクトップ・コンピューターをターゲットとしたメディア・クエリーは、<link rel="stylesheet" type="text/css" href="smartphone.css" media="only screen and (min-device-width: 481px)" /> になります。

Internet Explorer V6

この記事を執筆している時点では、Internet Explorer V6 が市場の 20 から 30 パーセントを占めていますが、IE V6 への対応はこの記事の範囲外です。

メディア・クエリーについての詳細は、ドラフト仕様を参照してください (「参考文献」を参照)。

ここからはネットワーク・ステータスを表示するサンプル・アプリケーションのコンテキストで、この手法を適用する例を説明します。


ネットワーク監視アプリケーション

このアプリケーションの目的は、複数のサーバーを監視することです。独立しているソフトウェア開発者は、自分が複数のサーバーで複数のアプリケーションをサポートしていると気付くことがよくあります。また、今まで長い間ソフトウェア開発に携わっていれば、サーバーのタイプも、アプリケーションのタイプもさまざまに変化しているはずです。つまりは、監視する必要のあるすべてのアプリケーションのすべての側面を簡単にモニターできる単一のツールは存在しそうにありません。そこで活躍するのが、Network Monitor (netmon) モバイル・アプリケーションです。これは包括的なアプリケーションとしてではなく、モバイル機器で柔軟に使える便利なアプリケーションとして設計されています。

netmon アプリケーションには監視対象とするサーバーのリストが含まれ、それぞれのエントリーが KPI (Key Performance Indicator) を表示します。KPI はこれまで長いこと、MBA の学生にとってビジネスの正常性に関する重要な側面を測定する上で不可欠な要素となってきましたが、Web アプリケーションのホスティングの世界での重要な KPI としては以下の指標が考えられます。

  • 最近の時間枠内でのトランザクションの数:
    • 注文数
    • カタログのリクエスト数
    • E メール・メッセージの数
    • ページ・ビューの数
  • 最後のトランザクションからの経過時間:
    • 注文
    • EDI 文書
    • ビジネス・パートナーのメッセージ
    • ベンダーから FTP で送信されるファイル
  • データベースが使用可能かどうか
  • 最後にバックアップが行われたと認識されている日付
  • 注文ごとの平均金額
  • 残りのディスク・スペース
  • 過去 1 時間、1 日、1 ヶ月に転送された帯域幅

上記の項目や任意の数の操作データが、特定のシステムまたはアプリケーションの正常性に関する実態を明らかにするのに役立ちます。休暇シーズンの間、私たちはサイトで行われた注文の数を実際に調べ、その合計数が 1 時間ごとに着実に伸びていなければ詳細を調べることにしました。

アプリケーションのニーズと必要なリソースはそれぞれに異なるため、netmon アプリケーションは柔軟にアプリケーションごとの詳細に対応しなければなりません。この柔軟性の要件に対応するために最初に取り掛かるのは、最も基本的なデータ構造で特定のシステムの正常性を表すことです。第 2 回では、このデータがどこから提供されるのか、そしてどのようにデータを更新するのかを説明しますが、とりあえずは以下の情報に注目します。

  • サイトの名前
  • サイトの URL (ホーム・ページ)
  • 更新を取得するための URL
  • ステータス: OK かどうか
  • 要約: 状態に関する簡単な説明。この説明は「OK」という内容か、または最も優先される問題を説明するテキスト・ストリングとなります。
  • 項目: サイトに関する現行の運用統計または KPI を伝えるために使用する名前と値のペアの集合です。

サンプル・アプリケーションでは、上記の項目をナビゲートしやすい方法でリストにし、各項目を目立たせるために CSS、jQuery、そして WebKit の機能を利用します。前述のとおり、目標とするのは、このアプリケーションを iPhone と Android、さらに Safari のデスクトップ・バージョンで動作させることです。


アプリケーションの構築

最近の Web ページは、宣言型で作成し、構成とコンテンツだけを指定するようになっています。位置決めとフォーマット設定はすべて CSS (Cascading Style Sheet) によって行い、さらに JavaScript の力を借りることもよくあります。実際のところ、JavaScript ライブラリーは非常によく使われるようになっており、JavaScript ライブラリーを使うことは例外的というよりはむしろ標準的になりつつあります。この記事のサンプル・アプリケーションで使用する JavaScript フレームワークは、人気の高い jQuery です。サンプル・アプリケーションは iPhone と Android だけでなく、デスクトップでもレンダリングすることになります。どこでレンダリングするにしても HTML コンテンツはまったく同じです。違うのは、選択されるスタイルシートです。注意しておく点として、このサンプル・アプリケーションの見栄えについては、それほど重視しませんでした。事実、アプリケーションのスタイルシートの構成を強調するために、背景色は極めて誇張されています。アプリケーションの視覚的な部分については、第 2 回で多少手を加えて魅力的なものにします。リスト 1 に、このアプリケーションの HTML を記載します。

リスト 1. アプリケーションの HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta name="viewport" content="width=device-width" />
<link rel="stylesheet" href="netmon.css" type="text/css" />
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="netmon.js"></script>

<script type="text/javascript">
   if (navigator.userAgent.indexOf('iPhone') != -1) {
      document.write('<link rel="stylesheet" href="iphone.css" 
type="text/css" />');
   } else if (navigator.userAgent.indexOf('Android') != -1) {
      document.write('<link rel="stylesheet" href="android.css" 
type="text/css" />');
   } else {
      document.write('<link rel="stylesheet" href="desktop.css" 
type="text/css" />');
   }

function setupTestData() {
   try {
      netmon.initialize();
      if (netmon.resources.length > 0) {
         jQuery.each(netmon.resources,function (index, value) {
            $("#mainContent").append(netmon.render(index,value));
         });
         $(".serverentry").click (function() {$(this).find(".serveritems").toggle();});
         $(".serveritems").hide();
      }
   } catch (e) {
      alert(e);
   }
}
   
</script>
   
<title>My Network Resources</title>
</head>
<body onload="setupTestData();">
<div id="mainContainer">
   <div id="header">
      <h1>My Servers</h1>
   </div>
   <div id="mainContent">
   </div>
   <a href="q.php">My User Agent</a>
</div> 
</body>
</html>

上記の HTML にざっと目をとおすと、以下のいくつかの点に気付きます。

  • 外部でロードされる JavaScript ファイルが 2 つあります。1 つは jQuery ライブラリーのファイル、もう 1 つはアプリケーションで使用するヘルパー関数のファイルです。
  • viewport メタデータを使用して、コンテンツのレンダリング・スケールを調整しています。
  • 主要なスタイルシート、netmon.css がロードされています。
  • userAgent を問い合わせて、iPhone 用、Android 用、デスクトップ用の 3 つの追加スタイルシートのうち、どれをロードするかを判断しています。
  • ページがロードされると、jQuery と netmon.js ファイル内のヘルパー関数を利用してデータが表示されます。
  • ページの残りには、いくつかの div タグが含まれています。
  • 最後に、userAgent ストリングを表示するページへのリンクがあります。このリンクは便宜上、説明のために配置されているだけです。アプリケーション自体にはまったく関係ありません。

スタイルシートの詳細と、すべての作業が行われる netmon.js ファイルについて説明する前に、現時点でのアプリケーションの形を見てください。上記で説明したように、このアプリケーションでは、サポートされる 3 つのプラットフォームのそれぞれをターゲットとする 3 つの異なるスタイルシートを使用しています。開発プロセスに役立つように、各スタイルシートに設定されている背景色は異なります。図 9 に、背景色が青色に設定された Safari ブラウザーのデスクトップ・バージョンを示します。

図 9. デスクトップ上の Safari ブラウザーに表示されたアプリケーション
このスクリーン・ショットには、背景色が青色に設定された Safari ブラウザーのデスクトップ・バージョンが示されています。

図 10 は、背景色が赤色に設定された Android ブラウザーでレンダリングされたアプリケーションです。

図 10. Android ブラウザーでのアプリケーション
このスクリーン・ショットには、背景色が赤色に設定された Android ブラウザーでレンダリングされたアプリケーションが示されています。

図 11 は、背景色が緑色に設定された iPhone ブラウザーでレンダリングされたアプリケーションです。

図 11. iPhone ブラウザーでのアプリケーション
このスクリーン・ショットには、背景色が緑色に設定された iPhone ブラウザーでレンダリングされたアプリケーションが示されています。

主要なスタイルシートは、netmon.js という名前のファイルに含まれています (リスト 2 を参照)。

リスト 2. 主要なスタイルシート
body {
   color: #888888;
   font-family: Helvetica;
   font-size:14px;
   margin: 0px;
   padding: 0;
}
.details {
   margin: 0px;
   padding: 0px;
   background-color: white;
   border: solid;
   border-width: 1px;

   -webkit-border-top-left-radius: 8px;
   -webkit-border-top-right-radius: 8px;
   -webkit-border-bottom-left-radius: 8px;
   -webkit-border-bottom-right-radius: 8px;
}
.OK {
   color: #000000;
}
.BAD {
   color: #ff0000;
}
.odd {
   background-image: -webkit-gradient(linear, left top, right bottom,from(#ccc) 
,to(#999));
}
.even {
   background-image: -webkit-gradient(linear, left top, right bottom,from(#999) 
,to(#ccc)); 
}
.serverentry a {
   float: right;
   color: #ffffff;
}
.serveritems{
   color: #000;
}

#header h1 {
   margin: 0;
   padding: 0;
   text-align: center;
   color: #000;
}

プラットフォームごとのスタイルシートを使用することで、以下の 3 つの主要な目的を果たすことができます。

  1. スタイルシートによる影響がひと目でわかるようにカラー・スキームを変更するとともに、userAgent に基づいて特定のプラットフォームをターゲットにしたスタイルシートを使用することがいかに簡単であるかを示します。
  2. デスクトップとモバイル・プラットフォームのそれぞれに応じてフォント・サイズを調整します。
  3. WebKit 特有の機能を使用します。これは、デスクトップ上の WebKit 以外に対応したブラウザー (例えば、Firefox) をターゲットとしている場合は重要です。

一例として、iphone.css ファイルをリスト 3 に記載します。

リスト 3. iphone.css ファイル
body {
   background-color: #00ff00;
}
.serverentry {
   -webkit-border-top-left-radius: 8px;
   -webkit-border-top-right-radius: 8px;
   -webkit-border-bottom-left-radius: 8px;
   -webkit-border-bottom-right-radius: 8px;
}
.name {
   font-size: 2em;
}
.summary{
   font-size: 1.5em;
}
.serverentry a {
   font-size: 1.5em;
}

このファイルでは、body タグの背景色が緑色 (#00ff00) に設定されていること、そしてモバイル機器でエントリーを読みやすくするためにフォント・サイズが調整されていることがわかります。

いよいよここで、netmon.js ファイルに目を向けます。このファイルには、エントリーのリストと、エントリーをレンダリングすることを目的とした関数が含まれています (リスト 4 を参照)。ここではリストを簡潔にするために一部のデータを省略していますが、このファイルの完全なコピーは「ダウンロード」から入手することができます。

リスト 4. netmon.js
var netmon = {
   initialize : function () {
   },
   resources : 
   [
      {
         name : 'msiservices.com',
         homeurl : 'http://msiservices.com',
         pingurl : 'http://msiservices.com/netmon.php',
         status : 'OK',
         summary : 'OK',
         items : 
         [
          {name : 'DiskSpace', value : '22.13 GB'},
          {name : 'Database Up?', value : 'Yes'}
         ]
      },
      {
         name : 'server 2',
         homeurl : 'http://someurl',
         pingurl : 'http://someurl/netmon.jsp',
         status : 'OK',
         summary : 'OK',
         items : 
         [
          {name : 'DiskSpace', value : '100.8 GB'},
          {name : 'Database Up?', value : 'Yes'}
         ]
      },
// additional entries clipped for brevity

   ],
   render : function(index,itm) {
      try {
         var ret = "";
         ret += "<div class='serverentry " + itm.status + " " + (index % 2 == 0 ? 
'even' : 'odd') + "'>";
         ret += "<span class='name'>" + itm.name + 
"</span>&nbsp;&nbsp;<a target='_blank' href='" + itm.homeurl + 
"'>Show</a><br />";
         if (itm.status != "OK") {
            ret += "<span class='summary'>-" + itm.summary + 
"</span><br />";
         }
         
         ret += "<div class='serveritems'>"; 
         jQuery.each(itm.items,function (j,itemdetail) {
            ret += ">>" + itemdetail.name + "=" + itemdetail.value + 
"<br />";
         });
         ret += "</div>";      
         ret += "</div>";
         return ret;
      } catch (e) {
            return "<div class='error'>Error rendering item [" + itm.name + "] 
" + e + "</div>";
      }
   }
};

サーバー・エントリーの状態が OK ではない場合、その状態は赤色で示されます。これは、CSS ファイルでのクラス定義のおかげです。さらに、ステータスが OK でない場合は、要約フィールドを表示し、その問題が一目でわかるようにしてあります。図 9 から図 11 で示されている問題は、サーバー 4 のディスク・スペースが残り少ないことです。エントリーをタップすると、詳細を確認することができます (図 12 を参照)

図 12. サーバー 4 の詳細
このスクリーン・ショットには、エントリーをタップすると表示されるサーバー 4 の詳細が示されています。

各エントリーの右側にある「Show」リンクをタップすると、そのサーバーのホーム・ページが立ち上がります。この機能が重宝する理由は 2 つあります。1 つは、対象とするすべてのサーバーの URL を覚えるのは面倒なこと、そしてもう 1 つは、モバイル機器で長々とした URL を入力するのは、非常に面倒であることです。これは、どんなに優れたキーボードであっても変わりありません。

netmon はモバイル機器で快適に動作するようになりました。これで、サーバーをサポートしやくなったはずです。

第 2 回では、このサンプル・アプリケーションを充実させてリアルタイムのデータを要求できるようにするとともに、モバイル・アプリケーションを構築する上でのサーバー・サイドの検討事項について説明します。

今回の記事を締めくくる前に、このアプリケーションをアプリケーション・ストアからダウンロードできるようにするためには何が必要なのかを簡単に説明しておきます。


Web アプリケーションをモバイル機器にダウンロードできるようにするには

想像してみてください。このネットワーク監視アプリケーションが完成し、完成品を友人に見せたとします。その友人は、他の人もこのアプリケーションを使ってネットワークでのリソースを監視できるように、アプリケーションを売ったらどうだと勧めてきました。Web アプリケーションを売ることはできるのでしょうか。確かに、従来のサブスクリプション方式や、あるいは SaaS モデルによって Web アプリケーションを販売することはできます。しかし自分で作った「Web アプリケーション」をパッケージ化して、iTunes App Store や Google Marketplace などのアプリケーション市場で販売したいとしたら、どうすればよいのでしょうか。それには、アプリケーションをネイティブ・アプリケーションとしてコンパイルしなければなりません。幸いにも、そのためのソリューションがあります。

主要なモバイル・プラットフォームにはそれぞれに、ブラウザーをビューやフォームあるいはアクティビティーに統合する手段があります。この手段はプラットフォームごとに多少異なる言葉で呼ばれていますが、いずれも同じような仕組みです。ブラウザー・コントロールをネイティブ・アプリケーションのなかに配置すれば、ネイティブ・アプリケーションがブラウザー・コントロールと対話できるようになります。最も単純なモデルでは、ブラウザー・コントロールは単純に Web にアクセスしてコンテンツを取得するだけの場合もあります。あるいは、ネイティブ・アプリケーションがリンク・リクエストをインターセプトして独自のコンテンツを提供し、レンダリングのためだけにブラウザーのビューを利用するという場合もあります。ここで忘れてはならないのは、アプリケーションのコンテンツのソースが何であるかに関わらず、HTML と CSS がネイティブ・ウィジェットに代わる有望な手段となることです。一部のアプリケーションは、この 2 つの手法の組み合わせとなるでしょう。例えば、アプリケーションがそのコンテンツのほとんどを Web から取得する一方、アプリケーションの「ネイティブ・サイド」が Bluetooth によってローカル・リソースにアクセスするなどです。

このようなアプリケーション・アーキテクチャー専用のツールが、市場にはいくつか出回っています。その代表的なものとしては、PhoneGap と Appcelerator の 2 つがあります (「参考文献」を参照)。


まとめ

この記事では WebKit ベースの iPhone Web アプリケーションおよび Android Web アプリケーションを紹介しました。第 2 回では今回取り上げたサンプル・アプリケーションを拡張し、Web の世界を変える Ajax 技術を使用してリアルタイムのページ更新機能を組み込みます。


ダウンロード

内容ファイル名サイズ
Network app source codeos-androidiphone1-browserwars1sourcecode.zip23KB

参考文献

学ぶために

製品や技術を入手するために

  • Android SDK をダウンロードしてください。このサイトでは、API リファレンスや Android に関する最新ニュースも調べられます。
  • Android はオープンソースなので、Android Open Source Project からソース・コードを入手できます。
  • PhoneGap は、JavaScript で素早く簡単にモバイル・アプリケーションを構築するためのオープンソースの開発ツールです。
  • Web 技術を使用してネイティブのモバイルおよびデスクトップ・アプリケーションを作成、テスト、配布するための Appcelerator について調べてください。
  • IBM ソフトウェアの試用版を使用して、次のオープンソース開発プロジェクトを革新してください。ダウンロード、あるいは DVD で入手できます。
  • IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を試してみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source
ArticleID=461826
ArticleTitle=Android と iPhone のブラウザー戦争: 第 1 回 WebKit による救いの手
publish-date=12082009