PreloadJSはこれまでブラウザごとの違いやくせをうまく扱うため、コードがあちこち複雑になってしまいました。新たなリリースでは、この複雑さをなくすため、内部的な仕組みを改めています(「New Architecture in PreloadJS: Individual Loaders」参照)。今PreloadJSを使って書かれているハイレベルなコードの99%が、新たなバージョンになっても問題ないことを目指しました。

大きな変更のひとつは、ローダーの構成を変えたことです。これまでのバージョンは、内部的にXMLHttpRequest(XHR)とHTMLタグベースのふたつのローダーを用いていました。新しいPreloadJSでは、コンテンツごとにその形式に応じたローダを使います。たとえば、ImageLoaderはイメージファイル、TextLoaderならテキストファイルというように、それぞれは特定のコンテンツだけを読込みます。そのため、内部的な仕組みはとても簡潔になりました。そのため、クラスファイルの数は増え(図001)、EaselJSのようにパッケージディレクトリを設けることになりました。けれど、メンテナンスの手間が少し増すだけでしょう。

図001■PreloadJS 0.6.0のクラス

この新たな仕組みでは、LoadQueueクラスでなく、個別のローダーが使えます(「PreloadJS 0.6.0: ImageLoaderクラス」参照)。

var loader = new createjs.ImageLoader(loaderObject); loader.on(“complete”, handleImageLoaded);

こうして、LoadQueueクラスは面倒な仕事を引受けてもらえます。すると、PreloadJSはほかのことに力が回せるのです。

• LoadQueueが使うローダーをいちいち定めなくて済みます。それぞれのローダーが、必要に応じてそのコンテンツを扱うかどうか決めればよいからです。
• ローダーは、ロードすべき内容の一部のコンテンツを読込むこともできます。特別なロードのために追加のプラグインローダーを用いることもできます。SoundJSは、カスタムオーディオローダーを加えて、FlashとWeb Audioがサポートできるよう仕組みを改めました。
• プロジェクトで使わないローダーがあれば、コンパクト化する(min版)PreloadJSから除いてしまうこともできます(GitHubでビルドします)。そうすれば、ダウンロードは速くなり、ライブラリに必要なものだけが含まれます。

あと、よく使われそうなクラスが、XHRRequestとTagRequestです。前者は、基本的なXHRベースの読込みを行います。後者は、HTMLでスクリプトやイメージなどを読込みます。これらのクラスは単独でも、組合わせてカスタムローダーでも使えます。

この再設計によって、メンテナンスしやすくなり、数の多い処理を速め、新たな使い途が広がり、HTMLオーディオなどのブラウザ特有の問題が減ることを期待します。

作成者: 野中文雄
作成日: 2014年12月16日