|
Unofficial "CLDC 1.1 + MIDP 2.0" API Reference. (日本語版) |
|||||||||
| 前のパッケージ 次のパッケージ | フレームあり フレームなし | |||||||||
参照先:
説明
| インタフェースの概要 | |
|---|---|
| Control | Control オブジェクトは、いくつかのメディア処理機能を制御するために使用します。 |
| Controllable | Controllable は Player のようなオブジェクトから Control を入手するためのインタフェースを提供します。 |
| Player | Player は時間ベースのメディア・データのレンダリングを制御します。 |
| PlayerListener | PlayerListener は Player で発生した非同期イベントを受け取るためのインタフェースです。 |
| クラスの概要 | |
|---|---|
| Manager | Manager は、マルチメディア処理のための Player といった、システム依存のリソースへのアクセス・ポイントです。 |
| 例外の概要 | |
|---|---|
| MediaException | MediaException はメソッドで予期していないエラー状況が起こったことを示します。 |
MIDP 2.0 メディア API は、モバイル・メディア API(JSR-135)仕様の直接のビルディング・ブロック(部分構造)互換です。 このビルディング・ブロックの使用は、完全なマルチメディア API への上方互換性(=下位互換性)を維持したまま、仕様にサウンドのサポートを含むことを目指す J2METM プロファイルのために意図されたものです。 そのような仕様の例は MIDP 2.0(JSR-118)です。 J2METM 適用範囲のデバイスを横断する同じ方針の API を用い、これら2つの操作を共通の API で、サウンドおよびマルチメディア・コンテンツの作成をシームレスに開発可能にします。
J2METM デバイスは高度なオーディオとビデオ・レンダリング能力がある PDA や Web タブレットからシンプルな音源を持つ携帯電話にまで及びます。 様々な構成とマルチメディア処理能力に順応するために API には高い抽象度が求められます。 MMAPI Expert Group の作業目標は、この広い応用分野を扱うことであり、作業の結果2つの API セットの提案をしました:
- モバイル・メディア API(JSR 135)
- MIDP 2.0 メディア API
前者の API は、例えばパワフルな携帯電話、PDA およびセットトップ・ボックスを含む、高度なサウンドとマルチメディア能力を備えた J2METM デバイスのためを意図しています。 後者の API は、マルチメディア API の直接の互換性を持つサブセットであり、大量販売用のモバイル機器のようにリソースに制約のあるデバイスを意図しています。 その上、サウンドのサポートを必要とするその他の J2METM プロファイルにこのサブセット API を採用することができます。 以下では、背景のより詳細な説明とビルディング・ブロック API の要求事項を挙げます。
J2METM デバイスによってはリソースに大きな制約があります。 デバイスが最大限のマルチメディア・タイプをサポートすることは、いくつかの携帯電話におけるビデオのように不可能かもしれません。 このため、全てのデバイスが、カスタム・プロトコルと Content Type のサポートする拡張性などのような、マルチメディア API の完全な汎用性をサポートすることが必要というわけではありません。
提案されたビルディング・ブロック・サブセット API は、上記の制約条件を満たすように設計されています。 この提案されたビルディング・ブロックは MIDP 2.0 Expert Group による要求事項一式を履行します。 これらの要求事項は:
- 低負荷のオーディオ再生
- 寛容なプロトコルとコンテンツ・フォーマット
- 音源のサポート
- 一般的なメディア・フロー制御のサポート:
スタート、ストップなど。- メディア指定のタイプによる制御のサポート:
ボリュームなど。- 能力の問い合わせのサポート
このサブセットは以下の点で完全なモバイル・メディア API と異なります:
- オーディオ専用です。
コントロールが指定するビデオまたはグラフィックスを全て除きます。- カスタム
DataSourceを経由するカスタム・プロトコルをサポートしません。javax.microedition.media.protocolパッケージ(DataSource)は省かれます。MIDP 2.0 で使用するビルディング・ブロックのサブセットは完全なモバイル・メディア API の真部分集合であり、完全に上方互換性があることに注目することが大切です。 完全なモバイル・メディア API の機能性を得るために、MIDP 2.0 に1つ要求されるのは、その API からの追加クラスとメソッドを実装するだけである必要があります。
提案されたオーディオ・ビルディング・ブロック・システムは3つのメイン・パーツからなります。
Managerはオーディオ・リソースの最上位コントローラです。 アプリケーションはPlayerの要求およびサポートする Content Type およびプロトコルのプロパティの問い合わせのためにManagerを使用します。 また、マネージャは単純な音を演奏するメソッドを含みます。
Playerはマルチメディア・コンテンツの再生を行います。 アプリケーションはロケータ文字列をManagerに与えることによってPlayerを入手します。
ControlはPlayerが持っているかもしれない全ての異なる制御を実装するために使用するインタフェースです。 アプリケーションは、それがサポートする制御についてPlayerに問い合わせを行い、次に特定のControl、例えばボリュームをコントロールするVolumeControlを求めることができます。
createPlayerメソッドは API への最上位エントリポイントです:Player Manager.createPlayer(String url)
urlはデータの内容とプロトコルを完全に指定します。<protocol>:<content location>
ManagerはURLを解析し、データのプレゼンテーションをハンドリングするために Content Type を認識し、Playerを作成します。 アプリケーションが使用するためのPlayerを結果として返します。createPlayerによって作成された接続は、Generic Connection フレームワークの規則と方針に従います。
Playerはデータ・フローとプレゼンテーションを制御する一般的なメソッドを提供します。例えば:Player.realize()
Player.prefetch()
Player.start()細かい粒度の制御は API の重要な特徴です; このため、各
Playerは併せてgetControlsとgetControlメソッドをタイプ特有の制御のために提供します。Control[] Player.getControls()
Control Player.getControl(int controlType)異なるタイプのメディアが対応する
Playerは異なるタイプのコントロールを提供するため、getControlsとgetControlメソッドは特定のメディア・タイプに特有のフィーチャを提供することができます。
ゲームと他のオーディオ・アプリケーションにとって、音源は重要です。 非常に小さなデバイスでは、その能力がサポートする唯一のマルチメディア表現である傾向があるため、それは特に重要です。 最も簡単な表現では、音源は単一のブザーか何らかの簡単なモノラル音源にまで限定されます。
Managerクラスは、この単純表現の単音音源を扱う最上位メソッドを提供します:Manager.playTone(int note, int duration, int volume)実装は、最も早く反応する音波生成を行うために、音源ハードウェア・デバイスを直接割り当てることができます。
またさらに、API はトーン・シーケンスを編成するために
Playerの特定のタイプを作成する手段を提供します。Player p = Manager.createPlayer(Manager.TONE_DEVICE_LOCATOR)作成された
Playerは、トーン・シーケンスをプログラムするために使用できるControlの特別なタイプであるToneControlを提供します。 これは多少パワフルなデバイスのためにより高度なアプリケーションを書くことを可能にします。
このセクションでは、私達が4つの共通するシナリオでどのように API を使用することができるかをデモンストレーションします。
シナリオ1:単音生成
try { Manager.playTone(ToneControl.C4, 5000 /* ms */, 100 /* 最大音量 */); } catch (MediaException e) { }シナリオ2:ループのある簡単なメディア再生
MIDP 2.0 では、デバイスがサンプリング・オーディオをサポートする場合に限り、wav フォーマットが不可欠である点に注目してください。
try { Player p = Manager.createPlayer("http://webserver/music.wav"); p.setLoopCount(5); p.start(); } catch (IOException ioe) { } catch (MediaException me) { }シナリオ3: JAR に格納されたメディアの再生
MIDP 2.0 では、デバイスがサンプリング・オーディオをサポートする場合に限り、wav フォーマットが不可欠である点に注目してください。
try { InputStream is = getClass().getResourceAsStream("music.wav"); Player p = Manager.createPlayer(is, "audio/X-wav"); p.start(); } catch (IOException ioe) { } catch (MediaException me) { }シナリオ4:トーン・シーケンスの生成
/** * "メリーさんの羊"は、"ABAC"構造です。 * "A"セクションのブロック・リピートを使用します。 */ byte tempo = 30; // テンポ 120 byte d = 8; // 八分音符 byte C4 = ToneControl.C4; // (ト音記号オクターブ4ド) byte D4 = (byte)(C4 + 2); // (ト音記号オクターブ4レ) byte E4 = (byte)(C4 + 4); // (ト音記号オクターブ4ミ) byte G4 = (byte)(C4 + 7); // (ト音記号オクターブ4ソ) byte rest = ToneControl.SILENCE; // 休符 byte[] mySequence = { ToneControl.VERSION, 1, // バージョン 1 ToneControl.TEMPO, tempo, // テンポ設定 ToneControl.BLOCK_START, 0, // "A"セクション定義開始 E4,d, D4,d, C4,d, E4,d, // "A"セクションの内容 E4,d, E4,d, E4,d, rest,d, ToneControl.BLOCK_END, 0, // "A"セクション定義終了 ToneControl.PLAY_BLOCK, 0, // "A"セクション再生 D4,d, D4,d, D4,d, rest,d, // "B"セクション再生 E4,d, G4,d, G4,d, rest,d, ToneControl.PLAY_BLOCK, 0, // "A"セクション・リピート D4,d, D4,d, E4,d, D4,d, C4,d // "C"セクション再生 }; try{ Player p = Manager.createPlayer(Manager.TONE_DEVICE_LOCATOR); p.realize(); ToneControl c = (ToneControl)p.getControl("ToneControl"); c.setSequence(mySequence); p.start(); } catch (IOException ioe) { } catch (MediaException me) { }
|
Unofficial "CLDC 1.1 + MIDP 2.0" API Reference. (日本語版) |
|||||||||
| 前のパッケージ 次のパッケージ | フレームあり フレームなし | |||||||||
| 公式仕様書原文の著作権表記等(※): Mobile Information Device Profile Specification ("Specification") Version: 2.0 Status: FCS Release: November 5, 2002 Copyright 2002 Sun Microsystems, Inc. and Motorola, Inc. All rights reserved. | ※ただしこの API リファレンスは英語仕様を一語一句正確に翻訳したものではなく、一度私が英語の仕様原文を読んだ上で元の意味と構造をなるべく保つように書き起こしたものです。このため一部は完全に異なる説明となっています。また CLDC 1.1 部分は同仕様の範囲外であるため、まったく参考とはしていません。 ※仕様書のライセンス上、問題は無いと考えておりますが、万が一問題があるとお考えの関係者の方がいらっしゃいましたらメールにて連絡をいただけると幸いに存じます(第一言語に日本語、第二言語に英語を希望しますが、返信は基本的に日本語で行います)。 |
