NewtonScript講座 online

第3回: ビューシステム(後)

 今年の2月号から始まった連載ですが、今回でいきなり最終回になってしまいました。実にあっけないです。中途半端になってしまいまして、大変申し訳ないです。

 さて、気を取り直して、前回の続きをやりましょう。電卓はちゃんと動きましたか?いろいろとわからない部分もあったと思います。今回だけでは説明しきれないとは思いますが...。こんなことならあんな構造にしなければ...。

 ま、気を取り直して(笑)、ビューの解説です。



ビューとは画面のパーツ

 ビューとはNewtonの画面上に見えるいろんなパーツです。ボタンとかもそうですし、アプリケーションのフレーム部分もそうです。文字やグラフィックを表示するものや、単なる枠線までいろいろなものがあります。

 前回作った電卓では、電卓のベースとなっているのがビュー、電卓のボタンもそれぞれビュー、結果の表示窓もビューだし、右下のクローズボタンもビューです。

 ビューは画面の表示単位であるだけでなく、いろいろな機能を持つことが出来ます。例えば、ボタンのビューはユーザーのタップをうけると、ハイライト表示して何か仕事をします。また、Namesなどに使われている文字入力フィールド(もちろんこれもビューです)は、ユーザーが書いたインクを認識して英数字に変換します。


ビューの階層構造

 階層構造とは、よく親子関係と言われるあれです。ビューは別のビューを自分の子供として持つことが出来ます。電卓の例では、アプリケーション・ビューであるcalcBaseが親ビューとなり、その他全部のボタンと表示窓のビューを子供として持っています。

 親ビューは子供ビューをいくつでも持てますが、子供ビューの親は一個だけです。子供ビューは別のビューの親となることもできます。これはつまり木構造です。

 こういう階層構造にはどういう意味があるのでしょうか?実はこれがNewtonScriptのオブジェクト指向的な構造なのです。この構造を使ってNewtonScriptは一つの継承を実現しています。

 C++などのクラス構造の親子関係で継承というと「子供は親の資産を継承できる」ということになります。すねかじり状態です。親が出来ること、知っていることは、子供も同じように利用できるわけです。

 NewtonScriptはC++などと違いクラスという明示的な概念はありません。もっとダイナミックであり、全ては直接オブジェクトとして存在するものです。ですのでC++的な継承の説明では実際にピンと来ないのでちょっと説明を変えましょう。

 NewtonScriptでは、子供が何かをしようとしたり何か情報を得ようとして、自分では処理できないときには、自分はそれを投げ出してしまって親に任せることが出来ます。親は子供が投げ出した仕事を引き受けて処理します。親もまた自分が出来ないことは、そのまた親に渡します。

 どうでしょう、ちょっと感じはつかめましたか?特に、子供から親に処理を投げる、というのは重要ですので覚えておいて下さい。後でまた出てきます。


ビューの裏にテンプレートあり

 今までビューが実際の仕事をしているように書いてきましたが、実際にはビューが全部処理をしているわけではありません。全てのビューにはその裏方としてテンプレートが存在しています。場合によってはプロトなどと呼ばれたりします。

 ボタンがボタンのふりをしていられるのも、protoTextButtonというものをテンプレートとして選んでいるからです。ボタンらしく表示しているのも、タップしたときに反転するのも、裏で全部protoTextButtonが処理しているのです。

 Newtonのシステムは最初からいろいろな便利なテンプレートを用意しています。これらを全部説明はとても出来ませんが、NTKのレイアウトのパレットで選べるものが組み込みのテンプレートです。何もしないプレーンなものから、月単位のカレンダーを表示するものまであります。


テンプレートを使った継承

 テンプレートはビューの裏方になりますが、実は、さらに別のテンプレートがまた裏方にいることもあります。というより、たいていのテンプレートはそういう多段階の構造になっています。

 これもNewtonScriptのもう一つの継承構造です。先ほどの親子継承に対してプロト継承と呼ばれています。雰囲気的には、こちらはC++で言うクラスの継承と似ている感じです。が、もちろんちょっと違います。

 このように二つの継承機能があったときに、ではどちらが優先されるのかと言えば、これはプロト継承が優先されるということに決まっています。ビューは、まず自分のテンプレートを順に見ていき、最後のテンプレートが処理できないときに初めて親に投げます。親も親で自分のテンプレートを利用します。


レイアウトとビューの関係

 さて、NTKでプログラムを作るときには、ビューのことをレイアウト(Layout)と呼んでいます。またユーザー・プロト(User Proto)というものもあります。これらはどういう関係にあるのでしょうか?

 NTKのレイアウトは一見ビューを作っているように思えますが、実際にはテンプレートを配置しているだけです。レイアウトというのはビューがどのテンプレートをどのように使うか、親子関係はどのようになるのかなどを記述した、いわばビューの設計図なのです。Newtonは実行時にその情報を元に、実際のビューを組み立てていきます。ビューというのは実行時にしか存在しないものです。

 ユーザー・プロトとは、一見レイアウトと似ています。実際ほとんど同じものですが、使う用途が異なります。ユーザー・プロトはレイアウトと違い、直接ビューの設計図となるわけではありません。その代わりに、他のレイアウト上に配置することが出来ます。つまり新しい種類のテンプレートをユーザーが作れると言うことです。

 例えば、システムが用意しているテンプレートには、テキストボタンもアイコンボタンも用意されていますが、テキストとアイコンを両方出してくれるボタンは用意されていません。

 そこでこのユーザー・プロトを使って、protoTextButtonを元にその横にアイコンを表示するように改造することが出来ます。こうしてprotoIconTextButtonなどとしておけば、いろいろなところで使い回すことが可能になるわけです。

 ビューやテンプレート、レイアウトなどの用語は、今までもそうでしたが、説明の時には非常に曖昧です。文脈をちゃんと読みとって適切な判断をして下さい。


ビューの名前付けについて

 前回の電卓では、レイアウトの最中にビューに名前を付けました。「calcBase」と「display」です。覚えていますか?

 ビューに名前を付ける理由の一つには、レイアウトの最中に便利であるからと言うのがあります。他のビューと区別が付いて分かりやすいし、特にブラウザーでは名前がないと判断に困るときがあります。

 しかしもう一つもっと重要な理由があります。それが「宣言」です。

 先ほどの親子継承の説明で思い出して欲しいのが、「子供は親に処理を渡せる」と言うことです。つまりビューは自分の祖先(親の親など)のどれかに対してして欲しいことがある場合、単純に親にお願いすればいいことになります。

 ところが、逆を考えてみましょう。親が子供もしくは子孫(子供の子供など)に何かして欲しいときにはどうしたらいいのでしょうか?実はNewtonScriptでは親は子供のことを管理していません。自分がどんな子供を持っているか知らないのです。親子継承は子から親への一方通行なのです。

 そこでこの宣言が登場します。親は宣言されている子供に関してだけは宣言された名前で参照することが出来るようになります。

 電卓の例では、表示窓が「display」として「calcBase」に宣言されていましたが、このおかげで親である「calcBase」が子供である「display」に対して表示しろなどと命令を出来るわけなのです。

 なお、前回の文中では「定義」という用語を使いましたが、「宣言」の方が適切ということで訂正します。ごめんなさい。


新説「ビュー構造は会社だ」

 ちょっといろいろ説明しすぎて混乱しているかもしれませんので、適当な与太話でもしましょう。

 ビューを社員や部課長、社長とします。ただしそれぞれ個人です。登場人物は社長「木戸」や部長「大村」、平社員「伊藤」など。

 平社員は仕事をもらうと自分のわかる範囲で仕事をします。わからないことは上司に回します。上司も自分の出来ることをやって、出来なくなるともっと上に回します。これが親子継承。

 平社員「伊藤」の仕事はユーザーサポートです。この仕事にはマニュアルがちゃんと用意されていて、それに従えば彼の仕事はこなせます。これがプロト継承。

 このユーザーサポートマニュアルに従えば、平社員「伊藤」と平社員「井上」は同じ仕事をします。ですが別の社員です。ちょっとづつ個性も違います。これは同じテンプレートを持つ別のビューに相当しますね。

 部長「大村」は自分の部下の名前など覚えていない不精ものです。ですから必要そうな社員にはあらかじめポケベルを持たせておいて、必要なときには鳴らして呼びつけ、仕事を頼みます。このポケベルが宣言。ちょっと苦しいか(笑)。

 まあおおかたこんな感じで考えていくと、前回の電卓などはワンマン社長の中小企業と言ったところでしょう。何しろ社員(ボタンと表示窓)は何もせず、ただ「僕、押されました」と社長(calcBase)に報告するだけです(DoCalcButton)。実際の計算や途中経過の保存、結果の表示に到るまで全部社長が実行指示しています。

 もっと大きなアプリケーションになるとこうはいきません。有能な部下をそろえて仕事は割り振り処理されていくことになります。

 どうでしょう?理解の助けになったでしょうか?混乱させただけだったりして(笑)。


次回予告じゃないお知らせ

 次回はありません。残念ながら今回で終了です。連載の機会を与えて下さったポケコンジャーナルにこの場を借りて感謝します。どうもありがとう。

 しかしスープの説明までは行きたかったですね。ビューまでは結構分かりやすいので、実際に触ってみると以外と作れるようなのですが、たいていみんなスープでつまずくようです。スープは何らかの状態を保存しておきたいときには必須なんですが...。

 というわけで、このまま中途半端で終わってしまうのも何とも気分が悪いので、この続きは自分のHomepageで公開することに決めました。URLは http://www.saryo.org/basuke/です。ご期待下さい。ではまたいつの日か。さようなら。


というわけで...

 このホームページ連載になったわけです。以上はほぼ原文のまま載せました。もちろんこれで終わりません。以後も続けますのでよろしく。


前に戻る 目次に戻る 次に進む