2006年02月11日

RクラスとMクラス

Rクラス

 Rクラスはシステムリソースを利用するためのクラスになります。SymbianはマイクロカーネルOSですから、システムリソースはサーバアプリケーション(ネットワーク上でのサーバではないことに注意してください)から提供されます。そして、このRクラスがシステムリソースを操作/利用する際のインターフェースになります。従って、通常のクラスとは異なり生成と破棄の方法が異なります。

タイマを使ったサンプル

 ここでサンプルを見てみましょう(RTimerTest.zip)。

ビルド方法:RTimerTest.zipを展開していただくと、次のようなディレクトリ構造になっています。


この中のgroupディレクトリに移動して、
> bldmake bldfiles
> abld build [wins|winscw] udeb

とコマンドを発行してください。winsとwinscwはダウンロードしたSDKにあわせて選択してください。

その後は[スタート]→[全てのプログラム]→[Series60 Developer Tool]から[Emulator (Debug)]を選択してください。

エミュレータを起動した後は


のアイコンを探して、プログラムを起動します。

 このサンプルを起動すると、次のような画面になります。
次に、「オプション」のメニューから「カウント」を選びます。


 すると、次の画面のように右上で5回、カウントを行います。


タイマを使ったサンプルの解説
サンプル1では、Rクラス(つまりOSのサービス)を利用しています。実際に利用している箇所はCRTimerTestContainerクラスのcountというメンバ関数です。
#include
void CRTimerTestContainer::count(){
RTimer timer;
if (KErrNone == timer.CreateLocal())
{
TRequestStatus status;
const TTimeIntervalMicroSeconds32 KTimerInterval = 1000000;
// 一秒間隔でラベルの書き換え
TBuf<8> text;
for( int i = 0 ; i < 5 ; i++ )
{
_LIT(KCount, "Count:%d");
text.Format(KCount, i+1);
CEikonEnv::Static()->InfoMsg(text);
// 文字列のセットと書き込み

timer.After(status, KTimerInterval); // タイマーを開始し
User::WaitForRequest(status); // タイマーの終了を待つ
}
timer.Close(); // timerリソースのクローズ(1)
}
}
ここで重要な点は、RクラスはClose()関数(コメント(1)で書いてある箇所など)で、必ず終了処理を行う必要がある点です。通常のデストラクタ以外に処理が必要です。

Mクラス

 Mクラスは「純粋仮想関数のみを提供するクラス」であり、APIなどに関数等の名前解決を提供するクラスになります。換言すれば、Javaのインターフェースとほぼ同じ役割を持ちます。Mクラスに関しては、後の連載で出てくるサンプルで確認していきたいと思います。
posted by シンビアン at 09:15| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

Mach

読み方 : マーク
別名 : Machマイクロカーネル, マークマイクロカーネル, Mach micro-kernel
分野 : OS

 カーネギーメロン大学のRichard Rashid教授らのグループが米国防総省の援助を受けて開発したマイクロカーネル型のOS。1985年に最初のバージョンが公開され、その後、改良が進められると同時に、商用・非商用を含め多くのOSの基盤部分として採用された。

 Mach自体は、従来のOSの中核部分を抜き出して再構成したようなソフトウェアになっており、その上で動作する多くのサブシステムをあわせて、OSとしての機能を発揮するようになっている。

 また、複数のCPUを動作させるマルチプロセッサ機能や、ネットワーク上に分散したコンピュータが連携するための機能、巨大なメモリ空間のサポートなどが盛り込まれている。

 それまでのUNIX系OSのカーネルは、多くの機能を抱え込んで複雑になりすぎ、また、機種依存コードとそうでないものが混在していたため、他機種への移植に莫大な労力が必要だった。

 これに対し、MachはOSとして必要最低限の機能だけを提供し、また、ハードウェアの設計に依存する部分を自身の内部に隠蔽した。このような設計は、従来の「複雑な」OS基盤(モノリシックカーネル)と区別して「マイクロカーネル」と呼ばれる。

 Machを基盤に採用したOSは、サブシステムを追加することでOSの機能を拡張することができ、また、最小限の労力で他機種へ移植できる。ただし、マイクロカーネルと上位層の通信にかかるオーバーヘッドのせいで、処理速度が向上させにくいという欠点もある。

 当初のMachはまだ多くの機能を自身の中に抱え込んでおり、事実上モノリシックカーネルだったが、バージョンアップするたびに機能を外部に出し、そのたびにパフォーマンスが下がっていった。このため、いったん外に出した機能をカーネル空間に戻したり、ライブラリでエミュレートしたりすることを余儀なくされた。

 こうしたマイクロカーネルの欠点はいまだ克服されておらず、実用性やパフォーマンスを重視する多くのOSはモノリシックカーネルを採用している。

 Machを採用しているOSには、IBM社のOS/2やOSFのOSF/1、Apple社のMac OS X、NeXT社のNEXTSTEPとOPENSTEPなどがある。
posted by シンビアン at 08:35| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

マイクロカーネル 【micro-kernel】

OSの中核部分(カーネル)に最も汎用性の高く機能だけを持たせることでカーネルを小型化する手法。また、そのような手法によって設計されたカーネル。カーネギーメロン大学のグループが開発したMach(マーク)マイクロカーネルがもっとも有名な例。

 マイクロカーネルでは、ファイルシステムや仮想記憶処理などの機能は外部モジュールとして独立しており、カーネル自身は割り込み処理やプロセス間交信などの限られた機能しか持たない。カーネルに出された処理要求の多くは、カーネル内部からプロセス間交信によって外部モジュールを呼び出すことで行われることになる。こうした構造にすることで、カーネル内処理を並列実行することができ、効率を上げることができる。また、機能がモジュールの形で整理されているため、開発効率も上がり、移植や機能追加も容易になる。

 しかし、頻繁に発生するプロセス間通信のオーバーヘッドが大きく、また、CPUの動作モードをカーネルモードとユーザモードで頻繁に切り替える必要があるため、処理速度を向上させにくいという欠点がある。ただし、最新の研究開発の成果によれば、徹底的に機能を絞ってプロセス間通信の効率を向上させることにより、こうしたパフォーマンス上の欠点は克服できるという報告もある。

 マイクロカーネル登場以前の、カーネル自体に様々な機能を実装していく手法を「モノリシックカーネル」という。マイクロカーネルが登場した頃には、モノリシックカーネルは複雑すぎていずれ開発が困難になり、すべてのOSがマイクロカーネルを使うようになるという主張もあったが、LinuxのようなモノリシックカーネルOSの隆盛を見る限り、現在までのところそうした予想は現実とはなっていないようである。

 前述のMachはApple社のMac OS X(とその原型のNEXTSTEP)でコア部分に採用されているほか、当初のWindows NT(NTカーネル)もマイクロカーネル設計であった(現在は様々な機能が追加されてモノリシックカーネルに近くなっている)。
posted by シンビアン at 08:33| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

マイクロカーネル

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: ナビゲーション, 検索

マイクロカーネルとはオペレーティングシステムの設計思想、及びそのようなOSのカーネル部の名称である。OSが担う各種機能のうち、必要最小限のみをカーネル空間に残し、残りをユーザーレベルに移すことで全体の設計が簡素化でき、結果的に性能も向上できるという考え方。カーネル本体が小規模な機能に限定されるので「マイクロカーネル」と呼ばれるが、必ずしも小さなOSを構成するとは限らない。

マイクロカーネルの出現に伴い、従来型のOSを「モノリシックカーネル」と呼ぶようになった。

特徴

純粋なマイクロカーネルでは、まずカーネル空間で提供される機能を、メモリ空間の仮想化、プロセス制御、プロセス間通信に限定し、割り込みなども全て通信にマップする。その上でファイルシステムやデバイスドライバといった準カーネル機能をそれらのアプリケーションとして実装し、ユーザー空間で動作させる。場合によってはそれらの機能セットをサーバと呼ばれる単位で複数動作させる。

このような形態を持つ事のメリットは、

* OS開発効率の向上(機能拡張、デバッグなどを容易に行える)
* システム全体を止めずにカーネル以外のOSのアップデートを行うことができる
* 必要な機能のみを提供するアプリケーションに特化したOSを構築することが容易になる

などである。また一般にマイクロカーネルでは資源の抽象度が高く、マルチプロセッサ対応やネットワーク透過の通信が自然に実装できるため、大規模な資源利用には有利である。


反面あらゆる場所でプロセス間通信を利用する為、機能相互のオーバーヘッドが大きく、モノリシックカーネルと同等の機能を実装した場合、数パーセントから数倍のロスが出る場合がある。特にコンテキストスイッチのコストを避けるため、必要な機能をカーネル空間に移し、見た目上モノリシックカーネルのように動作させる場合もある(co-location)。

歴史

マイクロカーネルは「UNIXの再設計」という観点から始まっている。

UNIXはファイルという概念でリソースを統一し、ファイルを扱う小さなプロセスをパイプでつないで相互通信させることにより、コンパクトかつ高機能なOS設計に成功した。しかしその後の利用環境の変化に伴い、必ずしもファイルとして扱えないリソースが増加している。例えばネットワーク通信はソケットという概念で行われるが、ソケットはファイルではない。結果的に、後付けで似て非なるコードがOSを肥大化させるという事態が発生したといえる。

OSがたくさんのコードから成る事の直接的な問題点は、

* カーネル自体が占めるメモリ領域(カーネル空間のフットプリント)が大きくなる
* 移植性やメンテナンスに不利

といったものである。さらに、計算機資源の増大に伴いマルチプロセッサや仮想メモリといった、UNIX開発時に想定していなかった概念が出現しており、それらを含めたOS概念のリファインが必要と考えられた。


そこで、「大規模な資源」と「高速な通信」を念頭において「相互通信するプロセスによる協調動作」というUNIXの発展理念に至ったのがマイクロカーネルである。UNIXではファイルを中心概念としていたが、マイクロカーネルではプロセスと通信に主眼を移し、割り込みやI/Oといったあらゆる資源が徹底的に抽象化されている。

なお、この時古くなった計算機資源の再利用も考慮されていた。つまり、移植性が高くコンパクトなOSを使えば、旧式のシステムであってもネットワーク上に接続して資源として活用する事ができるという考え方である。


実際に実装されたMachでは、当初の予想通りコード量の削減には成功した。抽象度が高く、見通しの良いマイクロカーネルはトレンドとしては妥当であり、この時は将来有望な物と見なされている。

しかし問題はマイクロカーネルのパフォーマンス問題が予想以上に大きかった事である。初期のMachは純粋なマイクロカーネルではなく、BSDサーバとの複合カーネルだったがそれでも25%ほどのロスがあり、さらにこれを完全なマイクロカーネルに移行した場合、機能によっては数倍遅くなるという結果が出ている。さらに言えば、マルチプロセッサが浸透するという技術予測が外れた事も大きい。

一方メンテナンス性の面では、典型的なモノリシックカーネル実装であるLinuxの成功により、カーネルの複雑さは心配されたほど大きな問題ではない事が明らかになった。


こうして、一時は「全てのOSはマイクロカーネルに移行する」と考えられていたが、90年代中ごろにはそのような見方は下火になっている。

ただし、以上の問題はマイクロカーネルに利点がないという事は意味しない。実際にNeXTSTEP/Mac OS XやBeOSはマルチプロセッサ対応やCPU移行時の高い移植性など、マイクロカーネルOSであることの利点を活かしている。またLinuxのモジュール機構などは実質マイクロカーネル的な概念であり、利点は利点としてとりいれる傾向があるといえる。

一方マイクロカーネルも性能面での解析が進み、現在第二世代といわれる新しい実装が出現してきている

代表的な実装例とその特徴

* OS-9
o 6809のために設計された、最初の商用マイクロカーネルOS、当時はマイクロカーネルという用語は無く、有用性も理解されておらず、マイコン用途にしてはオーバースペックであった。
* Mach
o カーネギーメロン大学によってもっとも初期に開発され、マイクロカーネルの代名詞ともなったもの。Mac OS XやNEXTSTEP、MkLinuxで使用されている
* L4
o 第二世代マイクロカーネル。高速なメッセージ通信の実装によって、マイクロカーネルの欠点と言われた「メッセージ通信の多さによる非効率性」に対処することを目的にあげており、各種の実装上の工夫によってモノリシックカーネルに遜色ないパフォーマンスを出している。
* Hurd
o GNU によって UNIX 代替をめざし開発されたカーネル。トレンドにあわせ設計がたびたび変更されたため、アナウンス以来長らく登場が待望されていたが、近年動作可能なものが発表された
* Windows NT
o Machをベースにマイクロソフト独自実装のマイクロカーネルを利用。しかし、WindowsNT 4.0以降、パフォーマンス重視の為、各種ドライバをカーネルモードで動作させるようになり、すでにマイクロカーネルの範疇を逸脱しているという考え方もある。(カーネル参照)
* BeOS
o 独自のマイクロカーネル実装。優れたマルチプロセッササポートや、PowerPCからx86への移植の早さはマイクロカーネルの当初の理想を体現した物といえる。現在各種のフリー実装が進んでいるが、ここでもマイクロカーネルの利点が発揮されている。
posted by シンビアン at 08:31| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

Cクラス

 Cクラスは、Tクラス以外の一般のクラスになります。Cクラスは、後に述べる「クリーンアップスタック」の関係から、必ずCBaseクラスを継承しなくてはいけないという制約があります。繰り返しになりますが、携帯などの組み込み環境では「メモリの確保が、もっともリソース不足によるエラーを起こしやすい」点に注意してください。

 CBase クラスは大きく次の二つの機能を提供します。

* ゼロ初期化
* 仮想デストラクタ

 上記の二点は、どちらも後述する「クリーンアップスタック」に関係してきます。長くなりますので、詳細は「コンストラクション(Cクラス)」で見ていきます。
posted by シンビアン at 08:23| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

Tクラス

Series60でのデフォルトのスタックサイズは8KBです。大きなオブジェクトをスタック上に積むのは危険な行為になります。従って、これから利用するクラスのサイズを大まかでも知っておく必要があります。そこで、出てくるのがTクラスになります。Tクラスはスタックに積んでも安全な比較的小さなサイズで、大きさは概ね256bytes以下を目安にします。

 クラス自体の大きさ以外にも、他のオブジェクトを所有しない(つまりhas-aポインタを持たない)クラスである制約があります。これは、携帯などの組み込み環境は「メモリの確保が最もリソース不足によるエラーを起こしやすい」ためです。また、他のオブジェクトを所有しないので、デストラクタが不要になります。

 int型などの組み込みのデータ型は、Tが頭につくようにtypedefされています。以下に、簡単に組み込みのデータ型について触れていきますが、文字列の扱いが特殊であることに注意してください。

基本データ型

 基本データ型はデータサイズが小さいので先頭に「T」が付く型名が使われています。下記のようにtypedefされています。こちらはこれ以上の解説は不要かと思います。

typedef signed int TInt;
typedef unsigned int TUint;
typedef signed char TInt8;
typedef unsigned char TU in t8 ;
typedef short int TInt16;
typedef unsigned short int TUin t16;
typedef long int TInt32;
typedef unsigned lon g int TUin t32;

文字列

 文字列は、char型のポインタを使用しません。基本的に、文字コードがUnicodeになるためです。そこで、char型のポインタを使用するその代わりに「_L」マクロや「_LIT」マクロなどを使用します。ここでは例として「_LIT」マクロの使用方法を次に示します。

_LIT(KHelloWorld, "Hello World!");

 この場合、KhelloWorldが文字列を表す変数(TlitCの型)になり、宣言と初期化が行われます。変数が必要ない場合、例えば引数にそのまま渡したい場合は_Lマクロを使用します。以降のサンプルで_Lマクロを使用したものが出てきますので、そちらのコードも合わせて確認してみてください。

補足:LITマクロに比べて_Lマクロの方は若干効率が悪くなっております。基本的には_LITマクロを使用するほうが良いかと思います。

浮動小数点

 浮動小数点を表す型にはTFloatやTRealなどの型があります。

typedef float TReal32;
typedef double TReal;

 ただしこれらの型に関しては注意が必要です。組み込み環境のアーキテクチャでは、基本的には浮動小数点のサポートを行いません。浮動小数点を含む計算はハードウェアではなく、ソフトウェアで実行する形になります。つまり、浮動小数点の計算が整数の計算などとは異なり非常に時間がかかることになります。

 実際、弊社で作成している組み込み環境向けの3DグラフィックスエンジンであるMascotCapsule(*1)では、小数を表す必要がある場合、高速に動作させる必要性から浮動小数点ではなく(勝手にある桁に小数点があるものと仮定した)、固定小数点を採用しています。

 このようなことから、浮動小数点を含む計算は極力回避するというのが原則になると思います。

posted by シンビアン at 08:23| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

仮想関数について

純粋仮想関数

基本クラスでは,単に主要なメンバ関数と変数を宣言し,必要なものは派生クラスで用意することが多い.すなわち,基本クラスのオブジェクトに対する操作は行わず,これを継承した派生クラスのオブジェクトに対して操作を行うことが多い.

この場合には,基本クラスには仮想関数を使用するための名前だけで実態のないメンバ関数を用意しておけばよいことになる.このとき,純粋仮想関数を使用する.

純粋仮想関数とは,関数定義を持たず,次のような形式をしている.

virtual 型名 関数名(引数リスト) = 0;

この定義では,関数本体が 0 に等しいと定義している.すなわち,関数本体が存在しないことを表す.

このような関数を持つクラスを継承する派生クラスでは,実体のない関数を呼ぶことができないため,必ずその関数を再定義しなおさなければならない.

少なくとも 1 つの純粋仮想関数を含んでいるクラスを 抽象クラス と呼ぶ.抽象クラスは,本体のない関数を含んでいるため,そのクラスのオブジェクトを作成できない.抽象クラスへのポインタは作成でき,実行時のポリモーフィズムは実現できる.

class date {
int y, /* year */
m, /* month */
d; /* day */
public:
virtual bool leapyear() = 0; /* 純粋仮想関数 */
int getyear() { return y; }
};

class seireki: public date {
public:
bool leapyear() { /* 閏年 */
return (getyear() % 400 == 0)
|| (getyear() % 4 == 0) && (getyear() % 100 != 0);
} /* 純粋仮想関数を持つクラスを継承しているクラスでは,
必ず再定義する */
};

class heisei: public date {
public:
bool leapyear() { /* 閏年 */
return ((getyear() + 1988) % 400 == 0)
|| ((getyear() + 1988) % 4 == 0)
&& ((getyear()+ 1988) % 100 != 0);
} /* 純粋仮想関数を持つクラスを継承しているクラスでは,
必ず再定義する */
};

上の例では, leapyear は基本クラス date の中で純粋仮想関数として定義されている.よってクラス date は抽象クラスとなりそのオブジェクトは作成できない.

西暦のクラスと平成のクラスを date の派生クラスとして定義しており,それぞれで閏年かどうかを判定する関数 leapyear を再定義している.

よって,

int main()
{
date *p;
heisei nen;
seireki year;

...
date = &nen;
if (date->leapyear()) {
...
}
date = &year;
if (date->leapyear()) {
...
}
}

のように記述できる.
posted by シンビアン at 08:14| Comment(0) | TrackBack(0) | Symbian OS C++ 実践開発技法 | このブログの読者になる | 更新情報をチェックする

もっとも重要な部分を一気に

前回までは、大まかなGUIアプリケーションの構造を見てきました。今回はSeries60に特有のコードコンベンションや、ANCI C++にはない例外処理の方法、文字列の扱い、さらには2フェーズコンストラクションについて見ていきます。盛りだくさんで少々長くなっておりますがお付き合い下さい。

今回は「論より証拠」ということで、いくつかサンプルコードを用意しております。適宜サンプルコードをダウンロードして、解説と照らし合わせて読んでいただけると幸いです。
携帯上のアプリケーションという特殊な環境

 コードコンベンションの話をする前に、まずは携帯電話というアプリケーションの実行環境の特殊性について見てみましょう。

 昨今の携帯電話は、大きなヒープサイズなどのリソースを持った端末が出てきています。それでも通常のPC環境に比較して、かなり貧弱なリソースしかもっていないのが実情です。例えば、スタックサイズを見ると、Series60はデフォルトでは8KBという、今の感覚からみれば非常に小さいスタックサイズしか持っていません。

注:ただし、このスタックサイズはプロジェクトの設定ファイルで変更が可能です。

 さらに、通常のPCとは異なり、携帯電話は一度電源を投入すれば少なくとも数カ月、長ければ年単位で再起動されることなく動作することが求められます。

 一見、コードコンベンションとは無関係な話のように思えますが、実はSeries60のコードコンベンションはこのような貧弱で、利用条件の厳しい環境を意識したものになっているのです。

クラス(型)名に対するコードコンベンション

Series60ではクラス名や型名に対して4つのアルファベット(T,C,R,M)が先頭につきます。大まかな各々のアルファベットの意味は次の通りです。

Tクラス
サイズの小さいクラスで、スタック上にメモリを確保しても問題のない大きさ
Cクラス
Tクラスよりもサイズの大きなクラス、スタック上に積むのではなく、ヒープ上に確保しなくてはいけない大きさのクラス。このクラスは必ずCBaseクラスを継承する
Rクラス
OSのサービス(システムリソース)を利用するためのクラス。初期化と破棄の方法が通常のクラスとは異なる
Mクラス
純粋仮想関数を提供するインターフェース

 続いて、この各々について見て行きたいと思います。
posted by シンビアン at 08:10| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

Series60 GUIアプリケーションの構造

Documentクラス

 Documentクラスは、アプリケーションの扱うデータ(ファイル等)の管理を行うためのクラスです。したがって、このクラスに記述される処理の多くはファイル関連ということになるかと思います。ここでは、ファイル関連の処理は後の連載に回し、ContainerクラスとAppUiクラスから Documentクラスのポインタを取得する方法を紹介しましょう。

CSample1Document* doc = static_cast(
iEikonEnv->EikAppUi()->Document());

または、もっと単純に

CSample1Document* doc = static_cast(Document());

となります。

最後に、ちょっとしたデバックのヒント

 今回抜き出したHandleCommandL関数の中で

iEikonEnv->InfoMsg(_L("test"));

という記述があります。この記述により、図4のスクリーンショットのような簡単なメッセージをエミュレータ画面右上に出すことが出来ます。

■ 図4

 iEikonEnvメンバはAppUiクラスの中で定義されているのですが、次のように書いても同一のデバックメッセージの出力ができます。

CEikonEnv::Static()->InfoMsg(_L("Test"));

 なお、CEikonEnvクラスはeikenv.hにて定義されていますので、必要に応じてインクルードしてください。

 次回は一般的なコードコンベンション、基本データ型および例外処理の考え方を概観していく予定です。
posted by シンビアン at 08:09| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

Series60 GUIアプリケーションの構造

AppUiクラス

 先述の通り、AppUiクラスはコントローラの役割を果たします。コントローラではユーザーのイベントを受け取り、それを処理するわけです。この「イベント通知用の関数」は「メニューのイベント用(HandleCommandL)」と「キー入力のイベント用(HandleKeyEventL)」の2つがあります。

TkeyResponse CSample1AppUi::HandleKeyEventL(
const TKeyEvent& /*aKeyEvent*/,TEventCode /*aType*/)
{
return EKeyWasNotConsumed;
}

void CSample1AppUi::HandleCommandL(TInt aCommand)
{
switch ( aCommand )
{
case EAknSoftkeyBack:
case EEikCmdExit:
{
Exit();
break;
}
case ESample1CmdAppTest:
{
iEikonEnv->InfoMsg(_L("test"));
break;
}
// TODO: Add Your command handling code here
default:
break;
}
}

HandleKeyEventLには、キーイベントの種類(aKeyType - 押し下げ、押し上げ)と操作されたボタン(aKeyEvent)が、HandleCommandLには選択されたメニューリソースで定義されたリソース IDが引数に渡されます。リソースについても以降の連載で触れる予定です。

Containerクラスでのイベントの処理

 Containerクラスにおいても、キーイベントの処理が可能です。イベント処理を可能にするためには、OfferKeyEventLをオーバーライドする必要があります。

TKeyResponse CSample1Container::OfferKeyEventL(
const TKeyEvent& aKeyEvent,TEventCode aType){
if( aType == EEventKeyDown)
iEikonEnv->InfoMsg(_L("Test"));
return EKeyWasNotConsumed;
}
posted by シンビアン at 08:03| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

Series60 GUIアプリケーションの構造

アプリケーションの起動シーケンス

 アプリケーションは、図2に記された起動シーケンスに沿って起動します。

■ 図2 出典:NRIラーニングネットワーク 「ノキア Series 60 C++開発入門コース」より

 図2に出てくる各関数は、実際にコードを確認することができます。以下の説明ではAppUIクラス、Containerクラスを中心に見ていきます。

注:起動シーケンスの最初のNewApplication関数は、正確にはAppクラスメンバではありません。最初にアプリケーション自身のインスタンスを生成するため、図2ではAppクラスのメンバであるかのように記述されています。

Containerクラス

 まずは、簡単にContainerクラスを概観してみましょう。

コンストラクション

 Containerクラスにおける初期化を担うメンバ関数はConstructLという関数になります。

void CSample1Container::ConstructL(const TRect& aRect)
{
CreateWindowL();

iLabel = new (ELeave) CEikLabel;
iLabel->SetContainerWindowL( *this );
iLabel->SetTextL( _L("Example View") );

iToDoLabel = new (ELeave) CEikLabel;
iToDoLabel->SetContainerWindowL( *this );
iToDoLabel->SetTextL( _L("Add Your controls\n here") );

SetRect(aRect);
ActivateL();
}

 このソースコードを読むに当たって、注意しなくてはいけない点がいくつかあります。列挙しますと、

1. 通常のC++コンストラクタは、一般に自身のインスタンス用のメモリ確保しか行わない。メンバの初期化は、ConstructLという関数で行う。このように、メモリの確保とメンバの初期化を2つに別けることを2フェーズコンストラクションと呼ぶ。

2. 文字列にはUnicodeを採用しているため、通常のダブルクオーテーション(“….”)文字列は使用しない。その代わり、変換用のマクロ(_Lマクロなど)が存在する。

3. 通常のANCI C++との例外処理機構の相違から、通常のnew演算子ではなく、new(ELeave)を使用する。

となります。以上の点に注意してください。以上で挙げた3点は、以降の連載で細かく触れて行きたいと思います。頭の片隅において置いてくだされば今回は結構です。

 上記のコードでは、アプリケーションの表示として二つのラベル

* iLabel
* iToDoLavel

の2つのインスタンスを生成して、各々が「Example View」と「Add Your contorols\n here」という文字列を貼り付けています。Series60ではUnicodeを採用していますので、例えば文字列を図3のように変更することもできます。

これは、単純に_Lマクロの中身を日本語に置き換え、再コンパイルするだけですので、是非お試しください。

描画されるコントロールの個数の管理

 Containerクラスは、自身の上で描画されるコントロールの個数とコントロールへのポインタをメンバー関数を通じて通知する必要があります。この処理を行うのがCountComponentControls関数とComponentControl関数です。

TInt CSample1Container::CountComponentControls() const
{
return 2; // return nbr of controls inside this container
}
CCoeControl* CSample1Container::ComponentControl(TInt aIndex) const
{
switch ( aIndex )
{
case 0:
return iLabel;
case 1:
return iToDoLabel;
default:
return NULL;
}
}

 CountComponentControls関数では、このContainer上で描画されるコントロールの総数(今回はラヴェルが2個)を返します。また、ComponentControl関数では、各々のコントロールのポインタを返却します。コントロールの個数や実体の変更を行う時は、合わせてこれらの関数の変更が必要になりますので、ご注意下さい。
posted by シンビアン at 08:00| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

IDEのない環境でのビルド

第1回では紹介しませんでしたが、IDEのない環境でもSeries60用アプリケーションをビルドすることができます。この場合は、通常のテキストエディタを用いてソースを編集し、コンパイルをコマンドライン上で行う形になります。

 まずはコマンドプロンプト上のカレントディレクトリをプロジェクトのディレクトリの下にある Group ディレクトリに移動します。そこで、

> bldmake bldfiles と入力し、その後に

> abld build [wins|winscw] udeb と、コマンドを発行してください。

 この後、エミュレータの起動は[スタート]→[すべてのプログラム]→「Series60 Developer Tools]と進み、[Emulator(Debug)]を選択し起動します。

 上記のようにIDEなしの環境でもプログラムを作成することは可能です。もっとも、Forum NokiaのダウンロードサイトからSeries60用のCodeWarriorの期限付き評価版が入手できますので、IDEなしのビルドを実践する機会は多くないかもしれません。
posted by シンビアン at 07:48| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

Series60 GUIアプリケーションの構造

Series60上でのUIのアーキテクチャは大別すると、

* 従来のUIアーキテクチャ
もっともシンプルなもの
* Viewアーキテクチャ
アプリケーションが複数の表示の方法をサポートするときに用いる
* ダイアログベースのアーキテクチャ

に大別されます。

 今回は、もっともベーシックな「従来のUIアーキテクチャ」を見て行きたいと思います。第1回の例題で作成したアプリケーションは、この「従来のUI アーキテクチャ」を使用しています。このアプリケーションの構造に言及する前に、「モデル−ビュー−コントローラ」(MVC)について簡単に触れましょう。

MVCとは

 MVCの考え方自体は広範囲に用いられているもので、プログラムの(役割としての)構成要素を大まかに以下の3つに大別しています。

* モデル:アプリケーションで扱うべきデータを管理するオブジェクト(クラス)
* ビュー:ユーザーにデータを表示するオブジェクト(クラス)
* コントローラ:ユーザの入力の処理としての窓口になり、ビューとモデルの間の調整を行うオブジェクト(クラス)

 前回の連載で作成したスケルトンも、このMVCの考え方に基づいて作られています。それでは、前回のスケルトンのクラス構成を見てみましょう。

図1では、

* CSample1App(クラス名がApp で終わるもの。以下Appクラスと呼びます)
アプリケーションそれ自体を表すクラス
* CSample1AppUi(クラス名がAppUi で終わるもの。以下AppUiクラスと呼びます)
アプリケーションのコントローラとなるクラス
* CSample1AppContainer(クラス名がContainer で終わるもの。以下Containerクラスと呼びます)
アプリケーションのビューとなるクラス
* CSample1AppDocument(クラス名がDocument で終わるもの。以下Documentクラスと呼びます)
アプリケーションで処理するデータを管理するモデルとなるクラス

と、なります。

posted by シンビアン at 07:46| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

Symbian(Series 60)上でのC++によるアプリケーション開発

講習ではSymbian OS上の代表的なAPIであり、NOKIA社の端末などで採用されているSeries 60を用いたスタンドアロンアプリケーションを構築する際に必要となる知識を獲得する事を目的とします。Series 60用のSDK、開発環境の概要からスタンドアローンのアプリケーション開発で必要となるUI、グラフィックス処理、ファイル管理までを3日間のコースでみていきます。

 コース情報
講座スタイル :講習会
開催期間/開催日

:3日間

4/26(火)〜4/28(木)
6/1(水)〜6/3((金)
7/6(水)〜 7/8(金)
9/20(火)〜 9/22(木)
11/9(水)〜11/11(金)

開催時間 :10:00〜17:00
開催会場 :東京会場
受講料 :\189,000(税込み)                           

 ご提供対象

Symbian OS上でのアプリケーション開発に興味がある方

 カリキュラム

●Symbian と Series60
●Series 60 SDK(可能であれば05306「ふたたびSeries 60」の内容をあわせる)
●Symbian OS の基本
●メモリ管理
●ディスクリプタ
●アプリケーション構造の概要
●リソースファイルとローカライズファイル
●UIコントロール
●クライアント/サーバフレームワーク
●アクティブオブジェクトフレームワーク
●Series 60 UI概要
●グラフィックス
●データ永続性
  付録:05313展開(Symbianマシンへのアプリケーションのインストール方法)

 注意事項

C++言語の知識があることを 前提とした講座になります。
posted by シンビアン at 07:43| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

IDE上でのビルドとエミュレータでの実行

Application Wizardでプロジェクトを作成したので、後は適切なIDEを用いて開発やビルドを行います。

IDE上でのビルドとエミュレータでの実行

 Application Wizardでプロジェクトを作成したので、後は適切なIDEを用いて開発やビルドを行います。

Microsoft Visual C++ の場合

 先のApplication wizard でIDEを指定してプロジェクトファイルを作成した場合は指定したディレクトリにプロジェクトファイル(.dsw)が作成されていると思います。

 作成されていない場合(もしくは作成し忘れた場合)はコマンドプロンプト上で作業をします。

 まずはコマンドプロンプト上のカレントディレクトリをプロジェクトのディレクトリの下にある Group ディレクトリに移動します。そこで、

> bldmake bldfiles

と入力し、その後に

> abld makefile vc6

と入力します。これでプロジェクトファイルができあがります。

注)実際にプロジェクトファイルができあがるのは、
-----
[SDKをインストールしたディレクトリ]\ epoc32\BUILD
-----
の下に、プロジェクトが格納されているファイル構造を反映した形でディレクトリが作られ、その中にプロジェクトファイルが格納されます。

 ビルドした後、IDE上でエミュレータを起動する場合は、エミュレータの位置を聞かれます。エミュレータ本体は[スタート]→[すべてのプログラム]→ [Series60 Developer Tools]と進んで、「Emulator(Debug)」を選択すると起動しますが、今回はエミュレータの位置が重要なので、右クリックをしてプロパティを参照してみてください。

■ 画面5

 後は実際にデバックセッションを開始すれば、エミュレータでの動作が確認できます。

■ 画面6

Metroworks CodeWarrior の場合

 基本的には同じ手順を踏みます。ただし、abld コマンドを入力する際のコマンドライン引数を、

> abld makefile cw_ide

とします。

バイナリの作成

 実機へのインストールのためには、ARM用にコンパイルする必要があります。このコンパイルを行うためにはビルド用のスクリプトを作成しておく必要があります。Groupディレクトリにおいて

> abld build [thumb|armi] urel

 とコマンドを発行します。thumbと指定した時はthumb用にビルドし、armiとした時は通常のARM用のバイナリを作成します。thumb用のビルドは、バイナリのサイズが小さくなりますが、実行速度が若干遅くなります。

 この後は、Series60のインストールファイルであるSISファイルを作成します。SISファイルはインストールスクリプトであるpackage ファイル(.pkg)の記述を元にmakesisコマンドで作成していきます。コマンドプロンプト上で

> cd パッケージファイルのあるディレクトリ
> makesis パッケージファイル.pkg

とコマンドを発行してください。

実機へのインストール

 エミュレータで実行を確認した後は、実機で確認することになるかと思います。現在、日本国内向けに出ている端末に関してはインストールに制限(インストールコントロール)がかかっています。ですから、いわゆる「勝手アプリ」というのはインストールできない設定になっております。

 実機へのインストール可能にするためには認証を受ける必要があります。認証は「SymbianSigned」が提供しています。認証プロセスはSymbianSignedのWebサイト(http://www.symbiansigned.com/)をご覧下さい。

 次回はより細かく、プログラムの中身に踏み込んで話を進めていきます。ご期待下さい。
posted by シンビアン at 07:41| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

SDKを用いたビルドの方法

 SDKをインストールすれば、後は実際に何か作ってみようというのは人間の心理だと思います。そこで、簡単にSDKを用いての開発の流れを見て行きましょう。

 アプリケーションの雛形(スケルトン)の作成はSDKに付属しているApplication Wizard(画面1)から行えます。

■ 画面1

 ここで「Series 60 Application Wizard」を選択し、「project name」に適当な名前を入れます(スナップショットでは「sample1」になっています)。その後に「create」のボタンを押すと、次の画面が現れます。

ここでは、いくつかのタブがありますが、各々を簡単に見ますと


■ 画面2
Generalタブ(画面2)

* アプリケーションのタイプ
* EIKONベースのUI(通常のもの)
* ダイアログベースのUI
* Viewアーキテクチャ(一つのアプリケーションが複数のView を持つときに便利)
* アプリケーションのタイトル
* アプリケーションの識別子(最終的にリリースする時は一意である必要がある。今回はサンプルとして動作を確認するので、デフォルトで入った値をそのまま使う)


Otherタブ

* 必要であればコピーライトとアプリケーションの著者を入力する。


■ 画面3
classesタブ(画面3)

アプリケーションの主要なクラスとそのファイル名。基本的にはModel-View-Controller (MVC)の考え方にのっとっている。各々のクラスを簡単に説明すると

* ……Appクラス:アプリケーションそれ自体を表すクラス
* ……AppUiクラス:コントローラとなるクラス
* ……Containerクラス:実際に描画対象となるコンポーネントのクラス
* ……Document クラス:アプリケーションが扱うデータ(ドキュメント)を管理するクラス。

と見ていただければよいかと思います。この部分の詳細は次回以降の回で細かく触れようと思います。



■ 画面4
Foldersタブ(画面4)

プロジェクトの各種ファイルを管理するディレクトリを指定します。ディレクトリ名と、どのような情報が格納されるのかをあわせて確認してください。

* Include:各クラスのヘッダファイルを格納するディレクトリ
* Source:ソースファイルを格納するディレクトリ
* Group:プロジェクトの設定ファイル(.mmpファイル)などを格納するディレクトリ
* Data:メニューのためのリソース、
* Aif:アプリケーションに関連図けられたビットマップなどが配置されます。
* Package:実機へのインストールファイルを作成するディレクトリ。インストール情報であるpkgファイルが格納されます。実機へのインストーラであるsisファイルを作成はこのpkgファイルから行われます。


IDE Optionsタブ

* Microsoft Visual C++ 6.0 のプロジェクトファイルなどIDEの設定ファイルをSeries 60 SDK のプロジェクト設定ファイル(.mmp)の内容から作成します。


 以上を設定することでアプリケーションのスケルトンを作成してくれます。あとは、ここからIDE(Microsoft Visual C++またはMetoroworks CodeWorrior)を立ち上げます。
posted by シンビアン at 07:37| Comment(0) | TrackBack(1) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

Series60とは?

プログラムというからには、スマートフォンには携帯電話メーカーが策定したAPIが搭載されてます。この APIのひとつである「Series60」は、Nokiaが策定したC++上でのAPIです。キャリアなどが制定したAPIと異なり、ヨーロッパでも日本でも同じバイナリがSeries60を搭載した端末上で動作します。Series60は、携帯電話向けのOS「Symbian OS」上で実装されたAPIです。今回の主題であり、先ほどの触れさせていただいた702NKもSeries60を搭載しています。

 Series60は、まさに「スマートフォンのためのAPIセット」ということができ、これまでの携帯電話では考えられないようなAPIが用意されています。主だったものを列挙していくと次のようになります。

* GUIに関連したAPI群
o 各種UIのコントロール
o グラフィックス

* ファイル入出力に関係したAPI群
o 通常のバイナリファイルの入出力
o 端末組み込みのデータベースへの入出力

* Symbian OS提供のサービスを利用するAPI群
o 通信に関連したAPI群
o IP v4 / v6
o 赤外線通信
o Bluetooth

* マルチメディア(音声、映像)を処理するためのAPI群

* アプリケーションエンジンAPI
o 端末の電話帳、カレンダーなどへアクセスするためのAPI

………


Series60とC++

 Series60は開発言語としてC++を採用しています。しかし、いわゆるANCIのC++ではないことにご注意下さい。以降の連載では、いくつかのサンプルプログラムが掲載されると思いますが、その中に出てくるコードに若干の違和感を覚える方が居るかもしれません。これは、Series60ではC+ +言語を組み込み端末向けにカスタマイズをしているためです。

 まずは目に付くところを2点挙げると、

* 実行時型情報を持たない
* try-catchによる例外処理はサポートしない(ただし、try-catch以外の方法での例外処理を提供)


となるでしょうか。

Series60の対象ハードウェア

 このSeries60が対象とするユーザインターフェース(UI)の物理的なデバイスとしては、

* 176×206ドットのカラー液晶
* 片手で操作をすることを前提とした物理的なUI


を想定しています。これらの制限はあくまでも現在のものです。したがって、例えば液晶のサイズなどもより大きいものをサポートする拡張がこれからなされるようです。

 もちろん、個性豊かなNokiaの端末ですから、上記以外の物理的なUIデバイスをもつ端末も存在しますし、そのためのAPIも存在します。例えば「Series80」(キーボードを持ったもので、640×200ドットの液晶画面を持ったもの)や「Series90」(ペン入力、640×320ドットの液晶画面)といったものもあります。一見すると「これが携帯電話?」と思うような端末が多数あります。興味がある方は探してみてはいかがでしょうか?

 Series60はSymbian OS v6.1以降のいくつかのバージョン上で実装されています。あくまでもSeries60はSymbian上でビルドされた「APIとUIのデザインのひとつ」ということになります。したがって、Series60以外にも、前述のSeries80やSeries90、Motorolaが開発した「UIQ」などのUIデザイン、APIが存在します。Series60に限っても、時を経るごとにいくつかのバージョンが出てきました。
posted by シンビアン at 07:34| Comment(0) | TrackBack(1) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

スマートフォンって何?

さて、この「スマートフォン」とは何なのでしょうか? ハードウェアの進化や省電力化によって、これまで PDAと呼ばれていた端末と同程度のことが携帯電話のサイズの端末で行えるようになってきました。日本国内の端末でも豊富な機能を組み込むものが出てきています。ただし「個別のツールの追加」というニュアンスが強く、「汎用的なPCやPDAに近い環境」とはなっていない状態であると思えます。

 これに対して、スマートフォンと呼ばれる端末は、PCやPDAに近い感覚で、PCとのデータの連携はもちろん、携帯電話に目的別のアプリケーションを自由にインストールしたり、もちろん自分でアプリケーションを作成することが可能です。恐らく、今回の連載をお読みの方の中には「アプリケーションを作成する」ことを職業としている方が多いのではないでしょうか?

 単にプログラムを作成するだけならば、例えば国内での携帯Java環境でも可能です。ただし、作成できるアプリケーションの自由度が大きく違います。このSeries60 の端末と他の国内で出ている端末の大きな違いのひとつは、まさに「プログラム作成の自由度の差」にあるといえます。

 もし、標準搭載のWebブラウザが気に入らなければ、例えばOperaのインストールパッケージをダウンロードし、携帯電話側にインストールすればよいのです。もちろん、その気になれば自分でWebブラウザを作ることも可能です。それだけではなく、電話帳をカスタマイズしたり、Bluetooth上で IPプロトコルを利用することも可能です。

 「何ができるのですか?」と聞かれれば、「おそらく想像できることは全てできます」というのが答えになると思います。しかも仮想マシンなどを介すのではなく、ネイティブのコードです。
posted by シンビアン at 07:30| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

Vodafone 702NK

2004年12月に「Vodafone 702NK」というNokiaの携帯端末が発売されました。もしかしたら、この連載をお読みの読者の中にも、すでにお持ちの方がいるかもしれません。この 702NKは、海外では「NOKIA 6630」という名称で発売されています。そして、この端末は一般に「スマートフォン」というカテゴリの携帯電話であるといわれています。
posted by シンビアン at 07:29| Comment(0) | TrackBack(0) | NOKIA SMARTPHONE HACKS | このブログの読者になる | 更新情報をチェックする

SDKの入手とインストール

SDKはNokiaの開発者向けサイト「Forum Nokia」(http://www.forum.nokia.com)から入手可能です。Forum Nokiaには、開発情報や多数のプログラム例も掲載されていますので、有益な情報が多数あるかと思います。是非一度ご覧下さい。

 SDKのインストールは簡単に行えるのですが、これ以外に

# Perlインタプリタ:Active Perl 5.18以降
# Java実行環境:Java2 Runtime Environment v.1.3.1以降

が必要になります。これらはインストール前に別途用意しておいてください。

 インストールを開始するにはダウンロードしたzipアーカイブに含まれるSetUp.exeを実行します。
posted by シンビアン at 07:26| Comment(0) | TrackBack(0) | Series60プログラミングテクニック | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。