Dojo Mobile による軽量モバイル Web アプリケーションの開発

最適化およびパフォーマンスに関する考察

Dojo Mobile は、モバイル Web アプリケーションを作成するための Dojo ベースのウィジェット群です。Dojo Mobile を使えば軽量でパフォーマンスのよいモバイル Web アプリケーションを開発できます。この記事では、Dojo Mobile 自体がパフォーマンスの問題にどのように対処しているかを理解し、Dojo Mobile ベースのアプリケーションをできる限り小さく、効率のよいものにする方法を学びます。

Yoshiroh Kamiyama (kami@jp.ibm.com), ソフトウェア開発エンジニア, IBM

Photo of Yoshiroh Kamiyama神山淑朗はソフトウェア開発研究所のアドバイザリー・ソフトウェア開発エンジニアです。Rational Portfolio Manager、Lotus iNotes、Mobile MashupなどいくつかのDojoベースの開発プロジェクトを経て、2011年からはWebSphere Feature Pack for Web 2.0 and Mobileの開発に従事しています。Dojo Mobileのコントリビューターであり、Dojoツールキットのコミッターとして活動しています。



2011年 12月 09日

はじめに

IBM のモバイルテクノロジー・プレビューをダウンロード

IBM モバイルテクノロジー・プレビューをダウンロードして、エンタープライズ向けモバイルアプリケーション開発に挑戦してみてください。サンプルとして RESTful な通知サービスや、ハイブリッドなモバイルアプリケーションを開発するオープンソースフレームワークである PhoneGap、軽量版 WebSphere Application Server ランタイム、そしてこれらを動作させるためのソースコードサンプルが含まれています。

今日の市場に出回るスマートフォンはデスクトップ用とほとんど変わらない非常に高機能なWebブラウザを備えています。それらのモバイル Web ブラウザは、HTML5、CSS3、JavaScript、DOM 操作、Ajax といった最新の Web 技術のほとんどを扱うことができます。

Dojo Toolkit はデスクトップWebアプリケーション開発のためのツールキットとして進化してきたものですが、モバイル Web ブラウザでも基本的には動作しますし、既に非常に多くの有用なウィジェットを備えています。では、なぜ改めてモバイル向けの Dojo Mobile が必要だったのでしょうか。それにはいくつかの理由が存在します。

  1. 入力デバイスの違い: ほとんどのモバイル・デバイスにはマウスや物理的なキーボードがありません。その代わりに指による操作が可能なタッチ・スクリーンを備えます。デスクトップ向けに開発されたユーザー・インターフェイスで特に問題になるのは、ドラッグ & ドロップ操作、マウスのホバー・アクション、キーボード・ショートカット、キーボード・ナビゲーション (タブ・キーや矢印キーによる操作) などです。モバイル向けの UI ウィジェットは、タッチ操作に対応していることが望まれます。
  2. 小さい画面への対応: モバイル・デバイスは画面が小さく、さらにそのタッチ・スクリーンを指で操作します。そのため、UI をモバイル向けに適切にデザインすることが非常に重要です。また、タブレット・デバイスはスマートフォンよりもかなり大きい画面を持ちます。そのため、モバイル Web アプリケーションは画面サイズや画面の向き (縦向き・横向き) に適した UI に変形する機能が求められる場合もあります。
  3. パフォーマンスの問題: モバイル・デバイスの CPU の処理能力は急速に向上しつつありますが、それでもデスクトップ PC には劣ります。さらに、ネットワークの通信速度も低いことが多く、デスクトップに比べて極端に遅いこともあります。したがって、モバイル Web アプリケーションはフットプリントが非常に小さく、パフォーマンスに優れたものであることが求められます。

IBM WebSphere Application Server フィーチャーパック for Web 2.0 & モバイルの入手

IBM WebSphere Application Server フィーチャーパック for Web 2.0 & モバイルにはモバイル向けリッチインターネット・アプリケーション (RIA) の開発を手助けする IBM Dojo 1.7 ツールキットや、Dojo をベースとしたダイアグラム作成用コンポーネントが含まれています。Rational 開発ツールと併せて利用することでフィーチャーパックはデスクトップブラウザ向けに作成された WebSphere アプリケーションをモバイルデバイス用に変換するための手助けをしてくれます。

Dojo Mobileは、モバイル Web アプリケーションを作成するための Dojo ベースのウィジェット群であり、前述の問題に対処すべく dojox.mobile として Dojo 1.5 から導入されました。ただし、入力デバイスと画面サイズの問題に関しては、必ずしもモバイル向けにはじめから作り直す必要はなく、従来の延長で既存のウィジェットをモバイル向けに改良していくことで解決できるはずです。しかし、パフォーマンスの問題に関しては、その方法では解決しないことは明らかです。したがって、Dojo Mobile が取り組む最も重要かつ困難な課題の一つはパフォーマンス、特にコード・サイズの最小化であると言うことができます。


画像を使用しないUIウィジェット

Dojo Mobile の興味深い特徴の一つは、UI ウィジェットの構築に画像を使用していないことです。モバイル・デバイス向けのブラウザの主流である WebKit ベースのブラウザは、CSS3 をサポートしています。CSS3 の機能である背景のグラデーション、角の丸い矩形、DOM エレメントの回転や変形などを活用することで、ある程度のグラフィカルな表現が画像を使わずに実現できます。図 1 は Dojo Mobile が提供する UI 部品の一部です。これらのウィジェットは画像を使用せず、代わりに <div> などの DOM エレメントに CSS のスタイルを適用することで UI を実現しています。画像を多用すると、合計ダウンロード・サイズや、サーバーへの HTTP リクエストの回数が増加し、パフォーマンス劣化の原因となります。Dojo Mobile は CSS3 の表現力を最大限活用することで、それを回避しています。

図 1. 画像を使用しない Dojo Mobile ウィジェット
画像を使用しない Dojo Mobile ウィジェット

一方、ユーザー・アプリケーションは画像を使用するかもしれません。図 2 は Dojo Mobile のテスト・ファイルとして提供されている例です。ご覧の通り、タブ・バーのボタン、リスト・アイテムのアイコン、アイコン・コンテナのアイコンなどは画像です。画像を多用し過ぎるとそれだけパフォーマンスに影響しますが、それはユーザー・アプリケーションの選択です。Dojo Mobile 自体は画像を使用しませんし、ユーザー・アプリケーションに画像の使用に関して強制することもありません。さらに、後述するように、Dojo Mobile は「DOM ボタン」や「CSS スプライト」といった、画像の使用の必要性やサーバーへのリクエスト回数を減らすことを可能にするいくつかの便利な仕組みを提供しています。

図 2. ユーザー・アプリケーションの画像
Example images that are used from user applications

CSS スプライト

画像の使用が避けられない場合、パフォーマンスの低下を最小限にするために二つの対策が考えられます。一つは、色数を減らしたり圧縮率を高めるなどにより、画像ファイルのサイズを少しでも小さくすることです。もう一つは、複数の小さな画像ファイルを一つの大きな画像にまとめることにより、サーバーへの HTTP リクエスト回数を減らすことです。まとめられた大きな画像は CSS プロパティによってクリップし、調整することにより、小さな画像の一つとして使用することができます。この手法は CSS スプライトとして知られており、Dojo Mobile は CSS スプライトをサポートします。

リスト 1 は、個々のリスト・アイテムに対してそれぞれアイコン画像を指定する例です。図 3 はその結果を示します。この例では、画像を取得するのに HTTP リクエストが 3回発行されます。

リスト 1. 個別の画像を使うリスト・アイテム
<ul dojoType="dojox.mobile.RoundRectList">
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-1.png" moveTo="bar">General</li>
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-2.png" moveTo="bar">Photos</li>
  <li dojoType="dojox.mobile.ListItem" icon="i-icon-3.png" moveTo="bar">Store</li>
</ul>
図 3. リスト 1 の結果
Result of the list items with separate images

一方、リスト 2 は、各リスト・アイテムによって共有される、3つのアイコンを一つに結合した画像 (i-icon-all.png) を使用した例です。ListItem ウィジェットの iconPos プロパティにコンマ区切りの値 (top,left,width,height) を与えることにより、結合画像内の任意の矩形領域を再利用できます。図 4 が示すように、結果は同じですが、HTTPリクエストは結合画像に対する 1回で済みます。

リスト 2. 結合画像を使うリスト・アイテム
<ul dojoType="dojox.mobile.RoundRectList" iconBase="i-icon-all.png">
  <li dojoType="dojox.mobile.ListItem" iconPos="0,0,29,29" moveTo="bar">General</li>
  <li dojoType="dojox.mobile.ListItem" iconPos="0,29,29,29" moveTo="bar">Photos</li>
  <li dojoType="dojox.mobile.ListItem" iconPos="0,58,29,29" moveTo="bar">Store</li>
</ul>
図 4. リスト 2 の結果
Result of the list items with an aggregated image

CSS スプライトは、アイコン・コンテナのアイコン (図 5) や、タブ・バーのボタン (図 6) でも使用できます。

図 5. CSS スプライトを使ったアイコン・コンテナ
CSSスプライトを使ったアイコン・コンテナ
図 6. CSS スプライトを使ったタブ・バー
CSSスプライトを使ったタブ・バー

DOM ボタン

Dojo Mobile は、図 7 に示すように、シンプルなボタンやアイコン、リスト・アイテムのチェック・マークや矢印などを提供しています。それらは画像を使わずに <div> エレメントに CSS のスタイルを適用することで実現されており、それらを「DOM ボタン」と呼んでいます。

図 7. DOM ボタン
DOM ボタン

DOM ボタンは画像を使わずに CSS だけで実現されているため、ファイル・サイズが小さくなることを期待できます。表 1 に DomButtonGreenCircleArrow (図 7 の上から 4行目の左端) を例として DOM ボタンと画像のサイズの比較を示します。DOM ボタンの方が画像よりかなり小さいことがわかります。

表 1. DOM ボタンと画像のサイズ比較
ファイルサイズ
DomButtonGreenCircleArrow.css (ビルドして gzip で圧縮) 392 バイト
mblDomButtonGreenCircleArrow.png1,599 バイト

さらに、DOM ボタンはビルド・ツールによりテーマの CSS ファイルに統合することもできるため、追加の HTTP リクエストの発行を必要としないという利点があります。しかもその場合、DOM ボタンのフットプリントはさらに小さくなります。表 2 は CSS ファイルに統合されたときの DOM ボタンのサイズを示します。DomButtonGreenCircleArrow.css の追加によって、わずか 155バイトしか増加しないことがわかります。

表 2. CSS ファイルに統合された DOM ボタンのサイズ
ファイルサイズ
base.css (ビルドして gzip で圧縮) 2,844 バイト
base.css + DomButtonGreenCircleArrow.css (ビルドして gzip で圧縮) 2,999 バイト
サイズの差155 バイト

DOM ボタンの構造

DOM ボタンは CSS のスタイルが適用されたネストした <div> エレメントから構成されています。既に述べたように、CSS3 の表現力豊かな機能、すなわち、背景のグラデーション、角の丸い矩形、エレメントの回転や変形などを活用することで、さまざまなバリエーションの図形を実現できます。矩形の<div>エレメントの角の丸みを調整することで円も描けます。図 8 に DOM ボタンの構造の例を示します。

図 8. DOM ボタンの構造
DOM ボタンの構造

DOM ボタンの使用方法

DOM ボタンの実体は単なる CSS スタイルの集まりです。それを表示するのに JavaScript は必要ありません。ネストした <div> エレメントを用意し、CSS スタイルを適用するだけで表示されます。リスト 3 に最小限のサンプル・コードを、図 9 にその結果を示します。

リスト 3. JavaScript なしで DOM ボタンを使用
<html>
  <head>
    <link href="themes/common/domButtons/DomButtonBlueCircleMinus.css" rel="stylesheet">
  </head>
  <body>
    <div class="mblDomButtonBlueCircleMinus">
      <div><div><div></div></div></div>
    </div>
  </body>
</html>
図 9. リスト 3 の結果
リスト 3 の結果

リスト 3 では、DOM ボタンのクラス名を持つルート・ノードを含めて 4階層にネストする DIV エレメントを用意しましたが、何階層の DIV エレメントが必要かは DOM ボタンによって異なります。必要な個数の DIV エレメントを自動的に生成するには、リスト 4 に示すように、Dojo Mobile の dojox.mobile.createDomButton() 関数を使います。

リスト 4. JavaScript で DOM ボタンを使用
<div id="btn1" class="mblDomButtonBlueCircleMinus"></div>
----
var node = dojo.byId("btn1");
dojox.mobile.createDomButton(node);

リスト 3 およびリスト 4 は、DOM ボタンの仕組みを説明するために紹介したもので、実際に使う場面はあまり多くないと思われます。その代わりに、Dojo Mobile のウィジェットのいくつかは次に示すように DOM ボタンをサポートしています。アイコン画像やボタン画像を置ける場所に、代わりに DOM ボタンを指定できます。

  • ListItem: icon、rightIcon、rightIcon2、arrowClass、checkClass プロパティ (図 10)
  • TabBarButton: icon1、icon2 プロパティ (図 11)
  • ToolBarButton: icon プロパティ (図 12)
  • TabBarButton: icon プロパティ (図 13)
図 10. ListItem (リスト)
list item
図 11. TabBarButton (タブ・バー)
tab bar button
図 12. ToolBarButton (ヘッダー)
tool bar button
図 13. TabBarButton (セグメンテッド・コントロール)
tab bar button

カスタム DOM ボタンの作成方法

カスタム DOM ボタンは容易に作成できます。次にいくつか注意点を示します。

  • DOM ボタンのクラス名は必ず "mblDomButton" で始めます。Dojo Mobile が DOM ボタンかどうかを判断するのに使用します。 (一方、DOM ボタンの CSS のファイル名や置く場所は任意です。)
  • DOM ボタンのルート・ノードには width と height を指定します。それらが DOM ボタン全体のサイズとなります。
  • <div> エレメントは横並びではなく、ネストしているので、DOM ボタンのルート・ノードではなく、直接の親ノードを基準にしてスタイルを適用します。
  • 特定の階層の <div> エレメントにスタイルを適用するために、CSS の子供セレクタ (>) を使用します。
  • CSS3 未対応のデスクトップ・ブラウザをサポートしたい場合は、画像および互換モード用 CSS ファイル (*-compat.css) を用意します。

リスト 5、リスト 6 にカスタム DOM ボタンの例を示します。図 14 はその結果です。

リスト 5. カスタム DOM ボタン (DomButtonMyCheck.css)
/* === Red Check Button ==*/
.mblDomButtonMyCheck {
  position: relative;
  width: 29px;
  height: 29px;
}
.mblDomButtonMyCheck > div {
  position: absolute;
  left: 0px;
  top: 8px;
  width: 16px;
  height: 6px;
  font-size: 1px;
  -webkit-transform: scaleX(0.7) rotate(135deg);
  border-width: 3px 4px 0px 0px;
  border-style: solid;
  border-color: red;
}
リスト 6. カスタム DOM ボタン (DomButtonMyCheck-compat.css)
/* === Red Check Button ==*/
.mblDomButtonMyCheck {
	background-image: url(compat/mblDomButtonMyCheck.png);
	background-repeat: no-repeat;
}
.mblDomButtonMyCheck > div {
	display: none;
}
図 14. カスタム DOM ボタン
custom DOM button

互換モジュール

Dojo Mobile は WebKit ベースのモバイル・ブラウザに最適化されていますが、WebKit 以外のデスクトップ・ブラウザもサポートします。しかし、デスクトップ・ブラウザをサポートするために、モバイル・デバイスにおけるパフォーマンスが犠牲になるのは望ましくありません。アプリケーションがモバイル・デバイスで実行される場合は、クロス・ブラウザのサポート・コードはロードされないことが望まれます。

条件コンパイル

一つの方法は、モバイルに不要なコードをビルド時に削除することを可能にする条件コンパイルです。Dojo は条件コンパイルを実現する手段として、プラグマと has() を提供しています。

プラグマは、リスト 7 に示すように、特定のコード・ブロックを除去あるいは挿入するために利用できる特別なディレクティブです。

リスト 7. プラグマの使用例
process: function(){
//>>excludeStart("marker1", kwArgs.noIE);
    if(dojo.isIE){
        ....
    }
//>>excludeEnd("marker1");
    ....
}

上の例では、次のように noIE=true オプションを指定してビルドすると、excludeStartexcludeEnd で囲まれた範囲のコード・ブロックがビルドから削除されます。

> build profile=myapp action=release noIE=true

同様にして、includeStart/includeEnd プラグマを使うと、条件を満たす場合のみそれらで囲まれた範囲のコード・ブロックがビルドに含まれます。

has() (あるいは dojo/has または has.js) は dojo-1.7 から導入された、機能の検出・確認の仕組みです。リスト 8 に示すように、現在の実行環境が特定の機能を備えているかを確認するのに使うことができます。

リスト 8. has() テストの例
process: function(){
    if(has("ie")){
        ....
    }
    ....
}

ビルド・プロファイルで、次に示すように staticHasFeatures オブジェクトを設定することで、has("ie") が 0 で置き換えられます。すると、コンパイラのオプティマイザがそのコード・ブロックを到達不能コードとみなし、ビルド結果から削除します。

staticHasFeatures: {
  'ie': 0
}

互換モジュール

条件コンパイルは特定のプラットフォームに最適化されたビルドを作ることを可能にします。しかしながら、そのビルドは他のプラットフォームでは動作しないという問題があります。他のプラットフォームをサポートするには、別のビルドを用意する必要があります。その問題を解決するために、Dojo Mobile は互換モジュール (compat) という別のアプローチを取っています。

互換モジュールには WebKit 以外のブラウザをサポートするためのコードが入っています。互換モジュールがロードされると、修正が必要なウィジェットのメソッドを上書きします。コードの上書きは元のウィジェットのクラス名を変えないため、ユーザー・アプリケーションのコードの書き方に影響を与えません。一方、元のクラスを継承してメソッドをオーバーライドする方法では、新しく定義したウィジェットのクラス名を使わなければならなくなります。互換モジュールはまた、元のスタイルシートへのパッチである *-compat.css を読み込みます。互換モードでは、CSS3 の代わり dojo.fx による JavaScript ベースのアニメーションや背景画像などの従来技術を使ってウィジェットの UI のレンダリングを行います。互換モジュールを使用するには、"dojox.mobile.compat" を dojo.require() あるいは require API を使ってロードします。

ここで、互換モジュールは compat.js_compat.js に分かれていることに注意してください。実装はすべて _compat.js に含まれており、compat.js は _compat.js を読み込むためのローダーです。compat.js は現在使用中のブラウザが WebKit ベース以外であるときに限り _compat.js をロードします。compat.js は非常に小さいコードであるため、常にビルドに含めておいてもモバイルでのパフォーマンスに大きな影響はありません。これにより、WebKit ベースのブラウザを使った場合は _compat がロードされないのでパフォーマンスに影響を与えることはありません。WebKit 以外のブラウザを使った場合は自動的に _compat がロードされ、Dojo Mobile は互換モードで動作します。表 3 に compat.js をビルドに含めた場合と含めない場合のサイズの比較を示します。両者の差は無視できるほど小さな 45バイトしかないことがわかります。

表 3. モバイル・ビルドのサイズ比較 (profile: mobile-all.profile.js, ビルドして gzip で圧縮)
説明サイズ
compat.js なしのモバイル・ビルド36,594 バイト
compat.js ありのモバイル・ビルド36,639 バイト
サイズの差45 バイト

パフォーマンス評価のヒント

前述のように、WebKit 以外のブラウザでは、Dojo Mobile は互換モードで動作し、画像や *-compat.css などの追加リソースがロードされます。したがって、もしモバイル・デバイスにロードされるファイルの種類や個数を評価したい場合は、Firefox や Internet Explorer などの WebKit 以外のブラウザを使うべきではありません。Google Chrome やデスクトップ版の Safari は WebKit ベースであるため、それらのデバッガの方がそのような目的のためにネットワークのトラフィックの監視をするツールとして適しています。


モジュールの依存関係

Dojo は数多くの便利な API を提供しますが、それらは比較的小さな JavaScript ファイルであるモジュールという単位で管理されています。数え切れないほど多くの便利なモジュールが存在しますが、それらを使い過ぎると最終的なコード・サイズが肥大化する結果になりかねません。Dojo Mobile はモジュールへの依存が最小限になるように注意深く実装されています。例えば、dojo.query や dijit._Templated など通常使われることの多い便利なモジュールを意図的に使用していません。また、Dojo Mobile のすべてのウィジェットは、dijit._Widget ではなく、dijit._WidgetBase を継承しています。dijit._WidgetBaseはdijit._Widget のベース・クラスであり、キーボード操作などのモバイルには不要のコードが含まれておらず、その分 dijit._Widget よりも軽量になっています。さらに、Dojo 1.6 までは必須モジュールであった dijit._base.manager は使用せず、そのサブセットである dijit.registry を直接使うことでも軽量化を図っています。

もちろん、ユーザー・アプリケーションが dojo.queryやdijit._Templated などを使うのはユーザー自身の選択です。しかし、 (特にモバイルの場合は) パフォーマンスの観点から使用する dojo/dijit モジュールは慎重に選択するべきです。例えば、もしアプリケーション内のたった 1カ所だけで dojo.query を使っているとしたら、恐らく dojo.query 全体の実装コードと比べて圧倒的に小さなコードでそれを置き換えることができるはずです。

リスト 9 に Dojo Mobile のベースが直接的・間接的に依存するモジュールの一覧を示します。典型的なデスクトップでのユース・ケースに比べると、dojo/dijit モジュールへの依存が非常に少ないことがわかります。dojo/_base 以下の dojo ベース・モジュールには 25個中 11個しか依存していませんし、dijit/_base 以下のモジュールへの依存はありません。リスト 9 に存在しないモジュールをユーザー・アプリケーションから使用すると、その分だけコード・サイズが増えることになります。そのようなモジュールを使用する場合は慎重に選択すべきです。

リスト 9. 依存モジュール
dijit/_Contained
dijit/_Container
dijit/_WidgetBase
dijit/main
dijit/registry
dojo/Evented
dojo/Stateful
dojo/_base/Deferred
dojo/_base/array
dojo/_base/config
dojo/_base/connect
dojo/_base/declare
dojo/_base/event
dojo/_base/kernel
dojo/_base/lang
dojo/_base/sniff
dojo/_base/unload
dojo/_base/window
dojo/aspect
dojo/dom
dojo/dom-attr
dojo/dom-class
dojo/dom-construct
dojo/dom-geometry
dojo/dom-prop
dojo/dom-style
dojo/domReady
dojo/has
dojo/keys
dojo/mouse
dojo/on
dojo/ready
dojo/topic

ビルド

アプリケーションのロード時間の最適化をするために、ビルドは重要なプロセスです。Dojo は、すべての JavaScript と CSS を少数のファイルに圧縮し、実行効率のよい、アプリケーションのリリース版を作ることができる強力なビルド・ツールを持っています。図 15 および図 16 は、ビルドしない (ソース・コード版) アプリケーションとビルドしたアプリケーションにおける転送ファイルの比較を示します。リクエスト発生回数および合計転送サイズの両方において非常に大きな差があることがわかります。以下では Dojo Mobile のビルドについて議論します。

図 15. リクエスト発生回数とダウンロード・サイズ (ビルドなし)
リクエスト発生回数とダウンロード・サイズ (ビルドなし)
図 16. リクエスト発生回数とダウンロード・サイズ (ビルドあり)
リクエスト発生回数とダウンロード・サイズ (ビルドあり)

customBaseビルド

Dojo のビルドには customBase というオプションがあります。スタンダード Dojo ビルドでは、ほぼすべての dojo ベース・モジュールをビルドに組み込みます。これは、ベース・モジュールは明示的に要求しなくても常に利用できることになっているためです。しかし、customBase オプションを true にしてビルドを行うと、実際に依存関係に含まれているベース・モジュールのみがビルドに組み込まれます。Dojo Mobile はベース・モジュールへの依存を最小化するようデザインされています。その効果を得るためには、customBase オプションの指定が重要です。リスト 10 はプロファイル・ファイルで customBase オプションを指定する例を示します。

リスト 10. プロファイル・ファイルにおける customBase オプション
dependencies = {
  stripConsole: "normal",

  layers: [
    {
      name: "dojo.js",
      customBase: true,
      dependencies: [
        "dojox.mobile.parser",
        "dojox.mobile",
        "dojox.mobile.compat"
      ]
    },
  ....

Closure コンパイラ

Dojo のビルド・ツールからは 2種類のコンパイラ (=コンプレッサ) 、Shrinksafe と Google Closure コンパイラ、が利用できます。Shrinksafe は Dojo のデフォルトのコンパイラです。Closure コンパイラは Dojo バージョン 1.7 から同梱されるようになりました。表 4 は Closure と Shrinksafe のモバイル・ビルドのサイズの比較です。Closure の方がかなり圧縮率が高く、少なくともこの例では Shrinksafe よりも約 20% ほどコード・サイズが小さくなっていることがわかります。

表 4. Shrinksafe と Closure のモバイル・ビルドのサイズの比較
説明サイズ
モバイル・ビルド (Shrinksafe、gzip で圧縮) 44,826 バイト
モバイル・ビルド (Closure、gzip で圧縮) 36,639 バイト

Dojo Mobile は Closure を使ったビルドでテストされています。よりサイズの小さいビルドが得られるため、Closure の使用が推奨されます。

Dojo Mobile のビルド方法

Dojo Mobile は二つのサンプル・プロファイル・ファイル、mobile-all.profile.js および mobile.profile.js、を提供しており、それらは dojo/util/buildscripts/profiles フォルダにあります。それらのプロファイルを使って簡単にビルドを実行するには、dojox/mobile/build フォルダにあるシンプルなバッチ・ファイルを使います。

コマンド・ラインからバッチ・ファイルを実行できます。Windows の場合は build.bat を、Linux の場合は build.sh を使います。

リスト 11. ビルド用バッチ・ファイルの使い方
  > build
  Usage: build separate|single [webkit]
    separate  Create mobile.js that includes only dojox.mobile
    single    Create a single dojo.js layer that includes dojox.mobile
    webkit    Enable webkitMobile=true option (Loses PC browser support)

separate は mobile.profile.js を使用し、dojox.mobile ベースのモジュールだけを含む mobile.js を作成します。その mobile.js は dojo ベースや dijit ベースのモジュールを含みません。デスクトップ・ブラウザのサポートのために、_compat.js も作られます。また、dojo.js も作られますが、それは普通の dojo ベース・ビルドであって、customBase ビルドではありません。

"dojox.mobile ベース"にはすべての Dojo Mobile ウィジェットが含まれているわけではないことに注意してください。例えば、ScrollableView、Carousel、SpinWheel、フォーム・コントロールなどはそのベースには含まれません。もしそれらをビルドに含めたい場合は、プロファイル・ファイルの dependencies 配列にそれらを追加します。リスト 12 は、dojox.mobile ベースのビルドである mobile.js に取り込まれるすべてのモジュールを示します。

リスト 12. mobile.js に含まれるモジュール
dojox/main
dojox/mobile
dojox/mobile/EdgeToEdgeCategory
dojox/mobile/EdgeToEdgeList
dojox/mobile/Heading
dojox/mobile/ListItem
dojox/mobile/ProgressIndicator
dojox/mobile/RoundRect
dojox/mobile/RoundRectCategory
dojox/mobile/RoundRectList
dojox/mobile/Switch
dojox/mobile/ToolBarButton
dojox/mobile/TransitionEvent
dojox/mobile/View
dojox/mobile/ViewController
dojox/mobile/_ItemBase
dojox/mobile/_base
dojox/mobile/common
dojox/mobile/compat
dojox/mobile/sniff
dojox/mobile/transition
dojox/mobile/uacss

single は mobile-all.profile.js を使用し、dojox.mobile ベースとそれが依存するすべての dojo/dijit モジュールを含む一つの dojo.js レイヤーを作成します。デスクトップ・ブラウザのサポートのために、_compat.js も作られます。このビルドは customBase オプションを有効にします。したがって、ビルド結果の dojo.js には必要最小限の dojo/dijit モジュールだけが含まれます。リスト 13 は、single ビルドに取り込まれるすべてのモジュールを示します。

リスト 13. dojo.js に含まれるモジュール
dijit/_Contained
dijit/_Container
dijit/_WidgetBase
dijit/main
dijit/registry
dojo/Evented
dojo/Stateful
dojo/_base/Deferred
dojo/_base/array
dojo/_base/config
dojo/_base/connect
dojo/_base/declare
dojo/_base/event
dojo/_base/kernel
dojo/_base/lang
dojo/_base/sniff
dojo/_base/unload
dojo/_base/window
dojo/aspect
dojo/dom
dojo/dom-attr
dojo/dom-class
dojo/dom-construct
dojo/dom-geometry
dojo/dom-prop
dojo/dom-style
dojo/domReady
dojo/has
dojo/keys
dojo/mouse
dojo/on
dojo/ready
dojo/topic
dojox/main
dojox/mobile
dojox/mobile/EdgeToEdgeCategory
dojox/mobile/EdgeToEdgeList
dojox/mobile/Heading
dojox/mobile/ListItem
dojox/mobile/ProgressIndicator
dojox/mobile/RoundRect
dojox/mobile/RoundRectCategory
dojox/mobile/RoundRectList
dojox/mobile/Switch
dojox/mobile/ToolBarButton
dojox/mobile/TransitionEvent
dojox/mobile/View
dojox/mobile/ViewController
dojox/mobile/_ItemBase
dojox/mobile/_base
dojox/mobile/common
dojox/mobile/compat
dojox/mobile/parser
dojox/mobile/sniff
dojox/mobile/transition
dojox/mobile/uacss

webkit は、WebKit ベースのモバイル・ブラウザには不要なコードを取り除く webkitMobile=true ビルド・オプションを有効にします。例えば、Internet Explorer や Firefox に固有のコードはビルドから排除されます。このビルドは合計コード・サイズを減らしますが、ビルドされたモジュールはたとえ互換モジュール (compat.js) を使ったとしてもデスクトップ・ブラウザでは動作しません。

また、このオプションは Dojo 1.6 ではかなりの量のコードを削減する効果がありましたが、Dojo 1.7 ではコードの書き方がブラウザの種類による分岐から has() による機能の検出・確認に基づく分岐に移行しつつあることもあり、webkitMobile オプションは以前ほどのコード削減の効果はなくなっていることに注意してください。


CSS の結合

Dojo Mobileはthemes フォルダ以下に数多くの CSS ファイルを提供しています。ウィジェット毎に一つの CSS ファイルがあり、それらは 4つのテーマ (android, blackberry, custom, and iphone) それぞれに対して存在します。また、DOM ボタンや画面遷移のアニメーション用の CSS ファイルもあります。アプリケーションに必要な CSS を指定するのを助けるために、複数の CSS をまとめて読み込むためのエントリ・ポイント CSS ファイルがいくつか提供されています。

  • オールインワン・テーマ・ファイル (例:themes/iphone/iphone.css)
    すべての共通 CSS ファイルとテーマ CSS ファイルを含みます。
  • ベース・テーマ・ファイル (例:themes/iphone/base.css)
    dojox.mobile ベース・モジュールのテーマ CSS ファイルを含みます。
  • DOM ボタン (themes/common/domButtons.css)
    すべての DOM ボタンを含みます。
  • 画面遷移 (themes/common/transitions.css)
    すべての画面遷移アニメーションを含みます。

オールインワン・テーマ・ファイルを使えばすべての CSS が読み込まれるので最も簡単です。しかし、使っていない CSS ファイルまで含まれてしまい、不必要にフットプリントを増加させる場合があります。その場合は、ベース・テーマ・ファイルと、その他個別に必要な CSS を指定するという方法があります。

上記のエントリ・ポイント CSS ファイルは @import ディレクティブの集まりです。Dojo のビルドを実行することで、@import 文はインライン展開され、すべての参照先の CSS ファイルはエントリ・ポイント CSS ファイルに統合されます。したがって、ビルドされていればエントリ・ポイント CSS ファイルに対する HTTP リクエストは 1回しか発生しません。ただし、リスト 14 に示すように、<link> または @import を使ってアプリケーション内で CSS ファイルを列挙してしまうと、それぞれに対して HTTP リクエストが発生してしまいます。

リスト 14. HTML 内の link タグ (userApp.html)
<head>
  <link href="../themes/iphone/base.css" rel="stylesheet">
  <link href="../themes/iphone/TabBar.css" rel="stylesheet">
  <link href="../themes/common/SpinWheel.css" rel="stylesheet">
  <link href="../themes/common/domButtons/DomButtonBlueCircleArrow.css" rel="stylesheet">
  ....

HTTP リクエスト回数を減らすには、リスト 15 に示すように、@import ディレクティブを使って必要最小限の CSS を列挙した独自のエントリ・ポイント CSS ファイルを用意します。Dojo のビルドを行うと、列挙したファイルがインラインに展開された外部参照のない CSS ファイルになります。リスト 16 に示すようにアプリケーションから使うことができます。

リスト 15. 統合のための CSS ファイル (myStyles.css)
@import url("../themes/iphone/base.css");
@import url("../themes/iphone/TabBar.css");
@import url("../themes/common/SpinWheel.css");
@import url("../themes/common/domButtons/DomButtonBlueCircleArrow.css");
リスト 16. HTML内の単独の link タグ (userApp.html)
<link href="myStyles.css" rel="stylesheet">

以上のように、独自のエントリ・ポイント CSS ファイルを作成し、 Dojo のビルドを実行することにより、HTTP リクエストの回数を減らすことができます。


動的作成と遅延ロード

遅延ロードは、モジュールが初めて使われる時点でロードする技法であり、アプリケーションの起動時間のパフォーマンスを向上させます。Dojo Mobile 自体も内部的に遅延ロードの技法を使っていますが、ユーザー・アプリケーションも効果的な遅延ロードの活用を検討すべきです。

ビューの動的作成

_ItemBase クラスの url プロパティを使って、ビュー遷移の直前に新しいビューを動的に作成できます。リスト 17 は url プロパティの使用例を示します。ビューのコンテンツは HTML フラグメント (リスト 18) または JSON データ (リスト 19) のいずれかです。

リスト 17. url プロパティの例
<ul dojoType="dojox.mobile.RoundRectList">
  <li dojoType="dojox.mobile.ListItem" url="view1.html">
    External View #1 (sync)
  </li>
  <li dojoType="dojox.mobile.ListItem" url="view2.json" sync="false">
    External View #2 (async)
  </li>
</ul>
リスト 18. 動的ビュー用の HTML フラグメント (view1.html)
<div dojoType="dojox.mobile.View">
  <h1 dojoType="dojox.mobile.Heading" back="Home" moveTo="foo">view1.html</h1>
  <ul dojoType="dojox.mobile.EdgeToEdgeList">
    <li dojoType="dojox.mobile.ListItem">
      Jack Coleman
    </li>
    <li dojoType="dojox.mobile.ListItem">
      James Evans
    </li>
    <li dojoType="dojox.mobile.ListItem">
      Jason Griffin
    </li>
  </ul>
</div>
リスト 19. 動的ビュー用の JSON データ (view2.json)
{
  "dojox.mobile.View": {
    "dojox.mobile.Heading": {
      "@back": "Home",
      "@moveTo": "foo",
      "@label": "view1.json"
    },
    "dojox.mobile.EdgeToEdgeList": {
      "dojox.mobile.ListItem": [{
        "@label": "Jack Coleman"
      }, {
        "@label": "James Evans"
      }, {
        "@label": "Jason Griffin"
      }]
    }
  }
}

もう一つの方法は、ビューのコンテンツをプログラム的に取得し、それを対象のビューに挿入することです。リスト 20 に例を示します。

リスト 20. 既存のビューに対してコンテンツをロードし、遷移を行う例
<li dojoType="dojox.mobile.ListItem" moveTo="#" onclick="myAction2(this)">
  Load and Move (async)
</li>
----
function myAction2(li){
   var view2 = dijit.byId("view2"); // destination view
   var listItem = dijit.byNode(li);
   var prog = dojox.mobile.ProgressIndicator.getInstance();
   dojo.body().appendChild(prog.domNode);
   prog.start();
   view2.destroyDescendants();

   var url = "http://..."; // or var url = listItem.url;
   dojo.xhrGet({
       url: url,
       handleAs: "text",
       load: function(response, ioArgs){
           var container = view2.containerNode;
           container.innerHTML = response;
           dojo.parser.parse(container);
           prog.stop();
           listItem.transitionTo("view2");
       }
   });
}

詳細とより多くの例は dojox/mobile/tests/test_list-actions.html を参照してください

IconContainer による遅延ロード

IconContainer は複数のアイコンを持ち、それぞれがサブ・アプリケーションを表します。サブ・アプリケーションは一つまたは複数の Dojo ウィジェットから構成される場合があります。起動時にすべてのサブ・アプリケーションのコードをロードしてしまうと、メイン・アプリケーションの起動時間が遅くなってしまいます。起動時間のパフォーマンスを向上するために、IconItemlazy="true" パラメータを指定できます。すると、Dojo パーザーは IconItem 内のウィジェットのインスタンス化をスキップし、IconContainer はアイコンが初めて開かれたときにアイコンのコンテンツのモジュールを動的にロードし、インスタンス化します。

リスト 21 はアイコン・コンテンツを遅延ロードする例です。アイコン・コンテンツのモジュール (次の例では dijit.CalendarLite) を明示的に要求する必要がないことに注意してください。また、Dojo 1.7 では、遅延ロードは同期ローダー・モードでしかサポートされていないことにも注意してください。これは、遅延ロードは dojo.require を使って同期的に実行されるためです。

リスト 21. IconContainer の遅延ロードの例
<ul dojoType="dojox.mobile.IconContainer">
  <li dojoType="dojox.mobile.IconItem" label="Calendar" lazy="true">
    <div id="cal" dojoType="dijit.CalendarLite"></div>
  </li>
  ....
図 17. IconContainer
icon container

TabBar による遅延ロード

もし遅延ロードするタブ・パネルが必要な場合は、TabBar および "ビューの動的作成" で説明した手法を使うことができます。ただし、タブ・パネルの場合は最初に表示されるパネルに対して特別な対応が必要です。なぜなら、起動時にはビューの遷移がないためです。外部コンテンツを最初に表示されるパネルにロードするために、起動時にダミーのブランク・ビューから最初に表示されるパネルにプログラム的にビュー遷移を起こす必要があります。リスト 22 およびリスト 23 は同じ例を示します。前者は同期の例、後者は非同期の例です。

リスト 22. 遅延タブ・パネルの例 (同期モード)
  <script src="../../../dojo/dojo.js" djConfig="parseOnLoad: true"></script>
  <script language="JavaScript" type="text/javascript">
    dojo.require("dojox.mobile");
    dojo.require("dojox.mobile.parser");
    dojo.require("dojox.mobile.compat");
    dojo.require("dojox.mobile.TabBar");
    dojo.ready(function(){
      setTimeout(function(){
        dijit.byId("tab1").onClick();
      }, 0);
    });
  </script>
</head>
<body style="visibility:hidden;">
  <ul dojoType="dojox.mobile.TabBar" barType="segmentedControl">
    <li id="tab1" dojoType="dojox.mobile.TabBarButton" url="view1.html">New</li>
    <li id="tab2" dojoType="dojox.mobile.TabBarButton" url="view2.html">What's Hot</li>
    <li id="tab3" dojoType="dojox.mobile.TabBarButton" url="view3.html">Genius</li>
  </ul>

  <div id="blank" dojoType="dojox.mobile.View" selected="true"></div>
  <div id="view1" dojoType="dojox.mobile.View"></div>
  <div id="view2" dojoType="dojox.mobile.View"></div>
  <div id="view3" dojoType="dojox.mobile.View"></div>
</body>
リスト 23. 遅延タブ・パネルの例 (非同期モード)
  <script src="../../../dojo/dojo.js" djConfig="async: true, parseOnLoad: true"></script>
  <script language="JavaScript" type="text/javascript">
  require([
    "dojo/_base/kernel",
    "dijit/registry",
    "dojox/mobile",
    "dojox/mobile/compat",
    "dojox/mobile/parser",
    "dojox/mobile/TabBar"
  ], function(dojo, registry){
    dojo.ready(function(){
      setTimeout(function(){
        registry.byId("tab1").onClick();
      }, 0);
    });
  });
  </script>
</head>
<body style="visibility:hidden;">
  <ul dojoType="dojox.mobile.TabBar" barType="segmentedControl">
    <li id="tab1" dojoType="dojox.mobile.TabBarButton"
        url="view1.html" sync="false">New</li>
    <li id="tab2" dojoType="dojox.mobile.TabBarButton"
        url="view2.html" sync="false">What's Hot</li>
    <li id="tab3" dojoType="dojox.mobile.TabBarButton"
        url="view3.html" sync="false">Genius</li>
  </ul>

  <div id="blank" dojoType="dojox.mobile.View" selected="true"></div>
  <div id="view1" dojoType="dojox.mobile.View"></div>
  <div id="view2" dojoType="dojox.mobile.View"></div>
  <div id="view3" dojoType="dojox.mobile.View"></div>
</body>

モジュールの動的な要求

実行時にモジュールを動的に要求するのはよいアイデアです。それにより起動時間のパフォーマンスを向上できるためです。しかし、ここで一つ注意すべき問題があります。リスト 24 を見てください。Dojo モジュールをプログラム的にロードする例を示しています。このコードは確かに動作するのですが、もしリスト 24 をビルドすると、ビルド・ツールは自動的にその要求されているモジュールを拾い上げてビルドに取り込んでしまいます。したがって、そのモジュールは起動時に既にロードされているので、dojo.require が実行されても何もしません。

リスト 24. Dojo モジュールをプログラム的にロード (正しくない例)
myHandler: function(e){
  dojo.require("dijit.CalendarLite");
  var cal = new dijit.CalendarLite();
  ....
}

この問題を避けるために、リスト 25 に示すように、dojo.require の代わりに dojo["require"] と書くことができます。

リスト 25. Dojo モジュールをプログラム的にロード (正しい例)
myHandler: function(e){
  dojo["require"]("dijit.CalendarLite");
  var cal = new dijit.CalendarLite();
  ....
}

もしアプリケーションが非同期ローダーを使っている場合は、リスト 26 に示すように文法が異なります。しかし、コードをそのように書くとやはりビルド・ツールがモジュールを拾い上げてしまうので、これもよい例ではありません。

リスト 26. Dojo モジュールをプログラム的にロード (正しくない例)
myHandler: function(e){
  require(["dijit/CalendarLite"], lang.hitch(this, function(module){
    var cal = new module();
    ....
  }));
}

リスト 27 に示すように、クラス名を一旦変数に代入することで問題を回避することができます。

リスト 27. Dojo モジュールをプログラム的にロード (正しい例)
myHandler: function(e){
  var cls = "dijit/CalendarLite"; // assign to a variable so as not to be in the build
  require([cls], lang.hitch(this, function(module){
    var cal = new module();
    ....
  }));
}

非同期モード

Dojo 1.7 では、従来の Dojo ローダーに加えて、新しい AMD (Asynchronous Module Definition) ローダーが提供されています。Dojo Mobile のウィジェットは新しい AMD 書式で記述されています。任意の Dojo モジュールをロードするのに、従来の dojo.require (リスト 28) または新しい require API (リスト 29) のいずれかを使うことができます。

リスト 28. dojo.require の例 (従来書式)
<script src="../dojo/dojo.js" djConfig="parseOnLoad: true"></script>
<script language="JavaScript" type="text/javascript">
  dojo.require("dojox.mobile");
  dojo.require("dojox.mobile.parser");
  dojo.require("dojox.mobile.compat");
</script>
リスト 29. require の例 (AMD 書式)
<script src="../dojo/dojo.js" djConfig="async:true, parseOnLoad:true"></script>
<script language="JavaScript" type="text/javascript">
  require([
    "dojox/mobile",
    "dojox/mobile/parser",
    "dojox/mobile/compat"
  ]);
</script>

リスト 28 同期的にモジュールをロードします。一方、リスト 29 は非同期的にモジュールをロードします。 多数の JavaScript ファイルがロードされる状況では、非同期ロードの方が同期ロードよりもよいパフォーマンスを期待できますが、ビルドによって全モジュールが一つの JavaScript ファイルにまとめられている場合は、同期ロードと非同期ロードの間に大きな違いはないかもしれません。

しかし、それよりも注意すべき大きな違いがあります。図 18 は、リスト 28 のように記述された test_iPhone-Animation.html を開いたときのトランザクションを示します。一方、図 19 は、リスト 29 のように記述された test_iPhone-Animation-async.html を開いたときのトランザクションを示します。表 5 に示すように、同期モードでは 17個、合計 26KB もの余計なファイルがロードされていることがわかります。これは、同期モードは下位互換モードで動作し、互換性を保持するためにいくつかの必須モジュールをロードするためです。test_iPhone-Animation-async.html がそれらの追加モジュールなしで問題なく動作していることからもわかるように、それらはロードされても使われることはなく、ロードされる必要がないことは明らかです。したがって、たとえ使用するモジュールを注意深く選択し、customBase オプションを使ってビルドを最適化しても、dojo.require() を使ってしまうとその努力が台無しになります。アプリケーションのパフォーマンスを最適化するためには、dojo.require() ではなく、require API を使うべきです。

図 18. 同期ロード (test_iPhone-Animation.html)
Synchronous loading
図 19. 非同期ロード (test_iPhone-Animation-async.html)
Asynchronous loading
表 5. 同期モードと非同期モードでのリソースのダウンロードの比較
ファイルリクエスト回数合計サイズ
test_iPhone-Animation.html2369.15 KB
test_iPhone-Animation-async.html643.54 KB

なお、たとえ リスト 29 のような AMD 書式で記述しても、async:true (デフォルト値はfalse) を指定しなかった場合は、やはり下位互換モードで動作し、追加モジュールがロードされてしまうので注意してください。


dojox.mobile.parser

dojox.mobile.parserはdojo.parser の小さなサブセットです。純粋に合計コード・サイズを減らすだけのために開発されたものです。dojo.parser にないモバイル固有の拡張機能などは一切持っていないので、dojo.parser の代わりにdojox.mobile.parser を使わなければならない理由はありません。好きな方を選ぶことができます。dojo.parser のいくつかの高度な機能、例えば <script type="dojo/method"> や <script type="dojo/connect"> などは、dojox.mobile.parser にはありません。しかし、dojox.mobile.parser はより軽量です。

表 6 に示すように、dojox.mobile.parser のサイズは約 0.7KB (ビルドして gzip で圧縮) ですが、dojo.parser (とその依存モジュールのうち dojox.mobile ベースから要求されないもの) のサイズは 6.5KB です。もしアプリケーションにとって dojox.mobile.parser の能力が十分であれば、それを使うことでアプリケーションの合計コード・サイズを減らすことができます。

表 6. dojox.mobile.parser と dojo.parser のサイズ比較
説明サイズ
dojox.mobile.parser734 バイト
dojo.parser + 依存モジュール6,507 バイト

まとめ

この記事では、Dojo Mobile を使って軽量なモバイル Web アプリケーションを作る方法および、そのパフォーマンス最適化手法をアプリケーションに適用する方法を示しました。

参考文献

学ぶために

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

  • 最新の Dojo 1.7 は Dojo ツールキットダウンロードページからダウンロードできます。
  • IBM モバイルテクノロジー・プレビューをダウンロードして、エンタープライズ向けモバイルアプリケーション開発に挑戦してみてください。サンプルとして RESTful な通知サービスや、ハイブリッドなモバイルアプリケーションを開発するオープンソースフレームワークである PhoneGap、軽量版 WebSphere Application Server ランタイム、そしてこれらを動作させるためのソースコードサンプルが含まれています。
  • IBM WebSphere Application Server フィーチャーパック for Web 2.0 & モバイルにはモバイル向けリッチインターネット・アプリケーション (RIA) の開発を手助けする IBM Dojo 1.7 ツールキットや、Dojo をベースとしたダイアグラム作成用コンポーネントが含まれています。Rational 開発ツールと併せて利用することでフィーチャーパックはデスクトップブラウザ向けに作成された WebSphere アプリケーションをモバイルデバイス用に変換するための手助けをしてくれます。
  • IBM ソフトウェア評価版をダウンロードして導入したり、クラウドから利用したり、IBM SOA Sandbox を利用して SOA を効果的に利用する方法を学びましょう。

議論するために

  • developerWorks コミュニティーに参加しましょう。ブログやフォーラム、グループコミュニティー、wiki を通じて他の開発者とのコネクションを構築できます。

コメント

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=Web development, Open source
ArticleID=778803
ArticleTitle=Dojo Mobile による軽量モバイル Web アプリケーションの開発
publish-date=12092011