2010年8月アーカイブ

Melrose (コードネームです) Toolkit の情報が Adobe Labs に公開されました。(Melrose@Labs

Melrose は、AIR アプリの配布や課金と、アプリ開発者をつなげるサービスです。Melrose SDK をアプリケーションに組み込むと、Melrose ポータルを通じて、複数のアプリストアに AIR アプリを配布できるようになります。

いまのところ、Intel AppUp Center と Adobe AIR Marketplace の 2 つのアプリストアがサポートされています。今後、他の国も含め、ストアの数は増える予定だそうです。Melrose を利用できる開発者/ストアは、世界 47 の国に限定されますが、日本はその中に含まれています。

Melrose では、無償/有償どちらのアプリも配布できます。有償の場合、売り上げの 70% を受け取ることができます。配布状況を管理するための情報も Melrose ポータル経由で提供されます。いまのところ登録費は無償です。

Melrose SDK がサポートされるのは、Adobe AIR 1.5.3 以降のランタイムをターゲットとした、Flex Builder 3, Flash Builder 4, Flash Pro CS5 で開発されたアプリです。Flex SDK は 3.5.1 と 4.1 のどちらかです。

SDK のダウンロードはこちらからどうぞ。(Melrose Toolkit@Labs Downloads

 

8/31 日の 6 時 (5 時半開場) より、iPhone, iPad それから Android をターゲットにした開発事例のセミナーがあります。場所は、大崎のゲートシティホールです。

無料ですが、事前登録が必要です。詳細はこちらのサイトをご覧ください。(BE READY 5 for the new Web market

セッションは 3 つで、

  • Yahoo! Japan から、iPhone サイトのリニューアルからのノウハウや、Android 対応の際の注意点など
  • Phone Book チームから、企画/設計/開発それぞれの段階で最適なワークフローを発見した経緯について (アニメーターなども参加していて面白いです)
  • 楽天から、マルチデバイス向けアプリの事例から学んだこと、アクセス解析により更に先に進もうとしていること

についての紹介がある予定です。

Twitter 用に、ハッシュタグ:http://twitter.com/cs5wp/#adobeready が用意されています。#adobeready をつけてセミナー開始までにつぶやくと、抽選で 1 名に Adobe CS5 Web Premium が当たるそうです。まだ、競争率は低そうなので、チャンスかも?

つぶやく内容は、セミナーにて何を学びたいか、または Web 制作社/制作者としてマルチデバイスに関して困っていること、知りたいこと、などが良いようです。

Flash Player 10.1 と AIR 2 から、セキュリティ関連の新しい機能が追加されました。他のドメインから読み込むファイルの種類を制限できる機能です。

セキュリティドメイン

新機能の前に、セキュリティドメインについて確認です。

セキュリティドメインは、Flash Player に読み込んだ SWF ファイルを管理するための機能です。同じセキュリティドメイン内のリソースには自由にアクセスできますが、他のセキュリティドメイン内のリソースには (通常) 勝手にアクセスできないようになっています。

基本的には、SWF ファイルの置かれているサーバーのドメインごとに、セキュリティドメインが作られます。例えば、最初に読み込まれた SWF ファイルと、その SWF ファイルが読み込んだ SWF ファイルが、それぞれ別のサーバーから読み込まれた場合、2 つのセキュリティドメインがつくられます。そして、2 つの SWF ファイルは、それぞれ対応するセキュリティドメイン内に置かれます。

"基本的に" と書いたのは、外部ドメインのファイルを、ファイルを要求した SWF のセキュリティドメインに読み込む手段があるからです。以下の 2 つの API が提供されています。

1 つ目は、LoaderContext.securityDomain 属性に、読み込む側のセキュリティドメインである SecurityDomain.currentDomain を設定してから Loader.load() メソッドを呼ぶ、というものです。これで、外部ドメインのファイルでも、load() を呼んだ SWF と同じセキュリティドメインに読み込まれます。下はそのサンプルです。

var ld:Loader = new Loader();
var lc:LoaderContext = new LoaderContext();
// 読み込む側のセキュリティドメインを指定
lc.securityDomain = SecurityDomain.currentDomain;
// 第2引数にLoaderContextを指定
ld.load(new URLRequest("http://not.my.domain.jp/foo.swf"), lc);
 

かなり遅くなってしまいましたが、Flash Player 10.1 からセキュリティ上の理由で変更された仕様関連の情報です。変更は全部で 4 つあります。

まず、以下の 3 つは、既存のコードに影響が出る可能性のある変更です。

リダイレクトされた URL の切り捨て

1 つ目は、SWF ファイルやイメージを読み込んだ後に、読み込んだファイルの URL がドメイン名までしか見えなくなる、というものです。

この影響を受ける属性は、AS 3 では LoaderInfo.url と Sound.url それから AS 1 / AS 2 では MovieClip._url です。これらの属性値が、例えば、http://sample.jp/xxx/yyy/my.swf のはずなのに http://sample.jp/ になっている、という場合が起こりえます。

この状況が起きるのは、以下の 3 つの条件すべてが揃った場合です。

  1. ファイルの読み込み中に HTTP リダイレクトが発生
  2. ファイルを要求した SWF のドメインと、読み込まれたファイルのドメインが異なる
  3. ファイルを要求した SWF が、読み込まれたファイルへのアクセス許可を持たない

リダイレクトが発生した場合、リダイレクト後のURL 情報を見せない、というのが新しいセキュリティポリシーのようです。

URL 情報が一部隠されているかどうか、を知らせるため、AS 3 には新しい属性が追加されています。LoaderInfo.isURLInaccessible と Sound.isURLInaccessible の 2 つです 。AS 1 / AS 2 には、状況を示す属性の追加はありません。

リダイレクトされて (条件 1 を満たす) 他のドメインからファイルを読み込んだんだけど (条件 2 を満たす) URL が知りたい!というときは、ファイルへのアクセス権を与えます ( 条件 3 を満たさなくなる)。 設定方法は、読み込むファイルのフォーマットによって異なります。

読み込んだファイルが SWF の場合は、読み込まれた SWF が Security.allowDomain (AS 3) または System.security.allowDomain (AS 1 / AS 2) を実行します。これにより、ファイルを要求した SWF にアクセス権を与えます。

読み込むファイルがイメージやサウンドの場合は、サーバー上のポリシーファイルを使ってアクセス許可を設定します。その際、読み込む側の SWF が AS 3 の場合には、LoaderContext.checkPolicyFile や SoundLoaderContext.checkPolicyFile の値を true にして、確実にポリシーファイルが読み込まれているようにするのが良いでしょう。

なお、この変更は AIR 2 のアプリケーションコンテンツには影響しません。Flash Player 10.1 上で実行される全ての SWF ファイルと、AIR 2 の非アプリケーションコンテンツが影響を受けます。

今回の変更は大きく 2 点です。

まず、Mac 版に、ハードウェアを利用した H.264 ビデオの再生機能が追加されました。この機能は、OS X 10.6.3 以降の Apple Video Decode Acceleration framework がサポートされる Mac 上で利用可能です。より詳しい機種情報は、以前の記事をご参照ください。

それから、セキュリティ関連の修正が行われました。

修正された問題は 6 つで、重要度は非常に高いため、すみやかに最新版へのアップデートが推奨されています。対象となるのは、全てのプラットフォーム (Android 版を除く) の Flash Player 10.1.53.64 以前の全てのバージョンと、Adobe AIR 2.0.2.12610 以前の全てのバージョンです。

Flash Player 10 のサポートされない環境 (Windows 98, Windows ME, OSX 10.1-10.3, RHEL 3 & 4) 用に、Flash Player 9.0.280 もあわせて公開されています。

ダウンロードページは、

です。

デバッグ版とスタンドアローン版は、Flash Player Support Center からダウンロードできます。Flash CS3 Professional と Flex 3 用に、Flash Player 9.0.280 も同じページにあります。

今回は、外部 SWF ファイルを読み込んだ際の、未処理エラーの扱いについての話です。

外部 SWF ファイルの未処理エラー

Loader オブジェクトを使って、外部の SWF ファイルを読み込んだ場合を想定します。このとき、読み込まれた側の SWF ファイル内で未処理のエラーが発生すると、SWF ファイルの階層内でイベントフローが発生します。

例えば、foo.swf が bar.swf を読み込んだとします。その状態で bar.swf 内で未処理のエラーが発生した場合、UncaughtErrorEvent イベントは、それぞれの SWF ファイルの Loader と LoaderInfo オブジェクト間で、以下の順にディスパッチされます。

  1. foo.swf の LoaderInfo (キャプチャフェーズ)
  2. foo.swf 内の Loader (キャプチャフェーズ)
  3. bar.swf の LoaderInfo (ターゲットフェーズ)
  4. foo.swf 内の Loader (バブリングフェーズ)
  5. foo.swf の LoaderInfo (バブリングフェーズ)

これにより、読み込んだ側の SWF ファイル (foo.swf) 内でも、読み込まれた側 (bar.swf) の未処理のエラーイベントを受け取ることができます。

(AS1/2 の SWF ファイルを読み込んだ場合は、UncaughtErrorEvent が発生しません。また、HTMLLoader 内に読み込んだ HTML コンテンツ内での JavaScript エラーも、イベントとして通知されません)

なので、未処理エラーの処理方針として、とりあえずエラーが受け取れればよい、という場合であれば、LoaderInfo にイベントハンドラーを追加するだけで OK ということになります。どの SWF で未処理のエラーが発生しても、最終的にバブリングフェーズで LoaderInfo に通知されるからです。(上のステップ 5)

一方、発生元の SWF ごとに受け取る箇所を分けたい、という場合には、

  • 外部 SWF ファイルを読み込む Loader オブジェクトに UncaughtErrorEvent 用イベントハンドラーを追加
  • そのハンドラー内で stopPropagation() を呼ぶ

とすると、自身の未処理エラーは LoaderInfo、読み込んだ SWF ファイルの未処理エラーはそれぞれの SWF ファイルが読み込まれている Loader、という分け方ができます。

下は、Loader オブジェクトで未処理のエラーを受け取る場合のサンプルです。

ようやく、Flash Player 10.1 の新機能の話です。

前回までは、実行時エラーには、同期/非同期の 2 種類があること、それぞれ catch ブロックまたはイベントハンドラーを使って処理すること、という話でした。

Flash Player 10.1 と AIR 2 からは、「実行時エラーが発生したが catch ブロックにもイベントハンドラーにも渡されなかった」 という状況が起きると、UncaughtErrorEvent が生成されます。これにより、処理されなかったエラーの情報が通知されるため、エラー処理をこまごまと記述しなくても、とりあえずどんなエラーが起きたのかを知ることができます。

とはいえ、同期エラーが起きた場合であれば、スクリプトの実行が途中で終わってしまっている可能性があります。また、非同期エラーだった場合も、エラーの原因となったりソースにアクセスできるとは限りません。

つまり、グローバルエラーハンドラーは、状況を知るのには役立ちますが、それで問題が解決できるかというと、それはまた別の話なのです。アプリケーションが不安定になるようなエラーに対しては、やはり明示的なエラー処理の記述が必要そうです。(あたりまえですが)

UncaughtErrorEvent ハンドラーの追加

さて、UncaughtErrorEvent は、以下の 2 つのオブジェクトからディスパッチされます。

  • LoaderInfo.uncaughtErrorEvents
    SWF 自身のコードによる未処理のエラーを通知
  • Loader.uncaughtErrorEvents
    Loader に読み込んだ SWF 内のコードによる未処理のエラーを通知

どちらのオブジェクトも UncaughtErrorEvents オブジェクトです。UncaughtErrorEvents は EventDispatcher のサブクラスで UncaughtErrorEvent ディスパッチ専用のクラスです。(ディスパッチする側とされる側の違いが、名前の最後の s の有無だけなのです。ややこしい)

良く考えたら、タイトルは 「Flash Player 10.1 と AIR 2 の...」 にすべきでした。

という話は置いておいて、

非同期で行われる処理の場合 (ネットワーク経由のダウンロードとか)、エラーの通知も非同期に行われます。その際、エラーの発生はイベントという手段で通知されます。そのため、非同期エラーの処理は、非同期処理を行うクラスにイベントハンドラーを追加する、という形になります。

非同期エラーを通知するイベントは、以下の 2 種類に分けることができます。

  1. ErrorEvent のサブクラスによる通知
    エラーの種類ごとに提供されるイベントクラスを使用。AsyncErrorEvent、IOErrorEvent など。(一覧はこの 記事の最後にあります)
  2. ステータス通知イベントの属性値による通知
    NetStatusEvent や StatusEvent の属性値を使用。info.level もしくは level 属性の値が error になる。

ネットワーク関連のクラスは、両方の手段を使います。

それぞれ簡単な例を挙げておきます。

ErrorEvent のサブクラスによる通知の例

まず、ErrorEvent の例から。

引き続き、実行時エラーの処理に関する話題です。前回は、同期エラーを捕まえる方法についてでした。

デバッグ用プレーヤーと通常のプレーヤーでの動作の違い

最初に、ちょっと話題が逸れますが、デバッグ用の実行環境を使う際の注意点す。

Flash Professional や Flash Builder をインストールすると、デバッグ用の実行環境が付いてきます。(単独でも入手できます) Flash が表示されている領域で、右クリックしてコンテキストメニューに 「デバッガー」という項目が表示されたら、デバッグプレーヤーがインストールされている状態です。

デバッグプレーヤーでは、エラーが発生した際、通常の実行環境よりも多くの情報を取得することができます。具体的には、以下の 2 点です。

  • Error.getStackTrace() メソッドで、エラーが発生時の呼び出しスタックを取得できる。この属性は同期エラーの場合のみ利用可能。
  • Error.message 属性に、詳細な情報が設定される。通常のプレーヤーでは、大抵は Error.errorID と Error.name 属性の組み合わせの短いテキスト。

他の Error の属性に関しては、どちらの実行環境でも同じになります。

throw 文

では、以下、話を戻して、

スクリプトから、明示的にエラーの発生を通知するには、throw 文を使います。

var myError = new ApplicationError("エラー発生");
throw myError;
 

上のスクリプトが try ブロックで囲まれていた場合、後続の catch ブロックに throw されたオブジェクトが渡されます。下は、その例です。

Flash Player 10.1 から、グローバルエラーハンドラーの機能が追加されました。これにより、未処理のエラーを一括して扱うことが可能になります。

従来は、明示的に処理ロジックの記述されていない Error または ErrorEvent が実行時に発生した場合、その情報を知ることはできませんでした。(デバッグプレーヤーでは、ダイアログボックスが開いてエラーメッセージが表示される) ですが、起こり得る全てのエラーに対して、処理を記述するというのはなかなか面倒かつ困難です。

そこで、Flash Player 10.1 からは、未処理のエラーをまとめて処理できるよう、新しい機能が追加されたというわけです。

実行時エラー処理について

グローバルエラー処理の話の前に、普通のエラー処理についておさらいです。

まず、ここでエラーと言っているのは、実行時に起こるエラーのことです。(例えば、ある URL から swf ファイルを読み込もうとしたら失敗したとか) コンパイル時のエラーではありません。(文法が違ったとか)

ActionScript 3 では、実行時エラーを 2 種類に分けて扱います。

  1. Error クラス (と、そのサブクラス):
    エラーの発生が、実行中のスクリプトから直接扱える場合。関数呼び出しにより起きる実行時エラーはこのタイプ。IOError, TypeError など。
  2. ErrorEvent クラス (と、そのサブクラス):
    エラーの発生が実行中のスクリプトと非同期になる場合。イベントハンドラーで結果を受け取る処理はこのタイプ。IOErrorEvent, SecurityErrorEvent など。StatusEvent などもこれに含める。

上の 2 種類は、それぞれエラー発生の通知のタイミングが、同期/非同期と異なるため、エラー処理の記述も異なります。同期型のエラーの場合は、try..catch..finally を使ってエラー処理を記述します。一方、非同期エラーの場合は、非同期処理を実行するオブジェクトにエラーイベント用のハンドラーを追加します。

(繰り返しになりますが、新しく追加されたグローバルエラーハンドラーは、上記のようなエラー処理の記述されていないエラーを扱うための手段です。同期/非同期どちらのタイプのエラーも扱えます)

try..catch..finally の使い方

さて、ここで、同期エラー処理の基本となる try..catch..finally の使い方について、すこし具体的にします。

try..catch..finally は、エラー発生時の処理を記述するための構文です。エラーが起きると、スクリプトの実行が中断されるため、エラーの起きる可能性のある範囲を try ブロックで囲みます。そして、エラーの起きたときの処理を catch ブロックの中に記述します。catch 文の横には、処理の対象となるエラーオブジェクトの型を宣言します。

2014年1月

Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
レンタルサーバー

月別 アーカイブ

Powered by Movable Type 4.261