HOME > 開発者向けBLOG > Sencha Blog >  Ext JS on Tap

Technology Note 開発者向けBLOG

Sencha Blog

Ext JS on Tap

こんにちは、ゼノフィnakamuraです。

この記事は、US Sencha社ブログ Ext JS on Tap を翻訳したものです。

イントロダクション

extjs-on-tap-heroExt JSがタッチ対応デバイスのサポートを追加する予定であることを今年のSenchaConで発表しました。タッチインターフェースについて考えると、多くの人はまずスマホを想像して、その次にタブレットを想像します。このデバイスでタッチインターフェースが生まれた(もしくは生まれ変わった)かもしれませんが、実はタッチ入力はどんどん広まってきました。中型のノートパソコンやいくつか新しいデスクトップモデルのパソコンもタッチ画面をもっています。

もしこのタッチ機能の急増をBYOD(個人のデバイスのご利用)と合わせると、多くの開発者は自分のExt JSアプリケーションのタッチエクスペリエンスを最適化しようとしている理由を簡単に理解できます。

さて、このサポート態勢がどのように進んでいるのかご覧ください!

Sencha-Coreパッケージ

タッチ対応デバイスのサポートは今まではSencha Touchだけでした。Ext JSにタッチジェスチャーを利用可能にするために、Sencha TouchとExt JSの二つのフレームワークのコアを併合してsencha-core パッケージを作りました。

sencha-core パッケージには予想通りの項目がいくつか含まれています:クラスシステム、動的ローダー、機能検出、ユーティリティ(例えばXTemplates)など。これらのサブシステムと統一された事については言いたいことは沢山がありますが、この記事ではタッチイベントに関係する具体的なコードに焦点を当てます。

ジェスチャーとイベント正規化

ブラウザはネイティブタッチイベントをクリックのような別のイベントに変換しますが、変換中に約300ミリ秒の遅れが発生します。タッチ入力についてこのようなことは、あまり知られていません。そして、この遅れが原因で単純な操作も緩慢になり、ユーザーエクスペリエンスに悪影響を与えます。

ネイティブタッチイベントをより高いレベルの統合的なイベント(または「ジェスチャー」)に変換する能力はSencha Touchからsencha-coreパッケージに移動した主な部分の一つです。この拡張システムは「touchstart に続く touchend」のようなタッチイベントの系列を「tap」ジェスチャーに変換し、どのイベントも同じように実行されます。

tapジェスチャーは意味的にclick イベントと同じですが、実は(適切な場合)Ext JSは次のようにリスナーをclickイベントに変換します:

1
2
3
listeners: {
    click: onClick
}

(デバイスによっては)下のように変換されます。

1
2
3
listeners: {
    tap: onClick
}

次のようなイベントに関しても同じような変換を行います:

  • mousedowntouchstart
  • mousemovetouchmove
  • mouseuptouchend
  • dblclickdoubletap

もちろんジェスチャーイベント(pinchのような)に直接リッスンすることも一般的です。この場合、ユーザーが利用しているデバイスによって、この操作はユーザーが開始できないケースもあるということを忘れないで下さい。

注1: イベントリスナーを設定するために、フレームワークAPIを常に利用して、フレームワークにデバイス対応を任せましょう。

注2: シンプルなものに対しては、従来のマウスイベントを選択し、ジェスチャーの最適な変換をする処理を、フレームワークに任せてください。

グローバルイベントの委譲

Sencha Touch 2.0でジェスチャーシステムをサポートするには、イベントリスナーを管理する新しい戦略を導入して、DOM-レベルにアタッチされるリスナーの数を大きく削減しました。バブリングしたイベントをドキュメントルートだけでリッスンして、ジェスチャーがあるか確認し、そのわずかなリスナーからユーザーコードへ必要だけ委譲するという考えでした。

ユーザーコードがフレームワークAPIを回って、イベントリスナーをセットする以外、この仕組みの効果は検出不可能になります。DOM要素に直接アタッチするリスナーに依存しないでユーザーコードの目的を理解する能力は、マウスとタッチイベントの両方をサポートするデバイスに対して、イベントを正規化することに大きな役割を果たすでしょう。

すべてのタッチイベントやジェスチャーリスナーはこのように扱われています。すべてのイベントリスナーに対してこのアプローチをとるか現在検討中なので、この機能について是非フィードバックを下さい。

注3: イベントリスナーを設定する時には常にフレームワークAPIを利用して、フレームワークに誰がどのイベントをリッスンしているか整理させましょう。

慣性スクロール

モバイルブラウザの意外な欠陥の一つは、ブラウザ内のスクロールする領域の扱いです。ネイティブアプリケーションと違って、これらの領域は「慣性」を処理しないので、十分なユーザーエクスペリエンスを提供できません。言い換えると、ネイティブブラウザのスクロール動作はマウスを使用するデスクトップブラウザでは最適かもしれませんが、モバイルデバイスの場合ではそうではありません。そのような慣性スクロールは、タッチ対応に依存する機能としてとても需要があります。

次のautoScrollの構成はコンポーネントがスクロールを利用可能にするための通常の方法です:

1
2
3
4
Ext.create('Ext.panel.Panel', {
    autoScroll: true,
    ...
});

デスクトップブラウザでは、お察しの通りoverflowスタイルがセットされます。ところが、モバイルデバイスでは、慣性スクロールを有効にするために必要なスクロール要素を生成します。

タブレットでExt JSを利用するときは?

sencha-coreを介してExt JSに追加のデバイス対応が導入され、多くの開発者はExt JSとSencha Touchのどちらをどのケースで使用すればよいのかと悩んでいます。答えは単純ですが、適用するにはある考えが必要です:各フレームワークは独自の機能とデバイス対応があるので、開発者自身が自分のアプリケーションの要件に基づいて、その機能とデバイス対応の中から選択するしかありません。

場合によっては、二つのアプリケーションを作成する必要があるかもしれません:Ext JSのアプリケーションとSencha Touchモバイルアプリケーション。この現実はフォームファクタを考えると、そこまで意外ではないかもしれません:ユーザーエクスペリエンスを高めるために、これらのデバイス間で異なるインターフェイスを設計することは一般的です。

27インチのデスクトップ画面とiPhoneを標的とするアプリケーション場合、複数のインターフェイスを作らないといけませんが、27インチのデスクトップ画面とiPhoneを含むそれらの中間にあるデバイスも標的にしてしまうと、少し曖昧になってしまいます。タブレットとラップトップに、Sencha Touchのアプリケーションをアップサイズするべきか、またはExt JSアプリケーションをダウンサイズするべきか?

全てに万能な解決がないため、Ext JS内でタッチ対応と相互に排他的な機能のセットから重大な項目を取り外します。もしかしたらあなたのアプリケーションにはExt JSだけのある機能が必要かもしれないし、既にExt JSアプリケーションを持っているかもしれません。この新しいタッチイベントの対応で、あなたのExt JSアプリケーションはタブレット向けに準備されています!

PAGETOP