BREWで複数画面を効率的に開発するフレームワークのまとめ：その１

　いままで、「BREWで複数画面を効率的に開発するフレームワーク」を書いて、５回目まできて、その５回目で「画面の切り替え方法などについて説明するのと、複数画面を行うときの修正箇所のポイント」と書いたことについて。
　ここで１回、全体方針と、５回までのまとめと、６回以降の予告です。

---

●ウィザードでつくってくれるソースと、複数画面の場合の問題点

　ＢＲＥＷの場合、ウィザードでソースをあらかじめ作ってくれるが、これは、１画面用のソースになっている（ように見える）。つまり、こんなかんじ

アプリ
　｜
各コントロール

でも、実際には、複数画面になる。なので、こんな感じ

アプリ
　｜
画面
　｜
コントロール

　そこで、問題になるのは、以下の３点
（１）複数画面を、どう表現し、どう切りかえるか
（２）画面内の項目（コントロール）を、どう制御するのか
（３）画面間（ひいては項目間）に関連するデータをどうするか

（１）が、いままで説明してきた１～５回目まで、（２）がこれ移行に説明する、コントロールの操作方法、（３）が、ＢＲＥＷ版カオル姫方式になる。
　
　で、今回のまとめは、いままでやってきたところということで、（１）の方法についてだ。

---

●複数画面を、どう表現するか

　複数画面あるばあい、これを１画面１クラスとして、表現した。
　ＣというかＢＲＥＷにおけるクラス表現は、

　１クラスにつき、１つのクラス用構造体を持ち、
　そのクラスのメソッドを
　　　クラス名_メソッド名（クラス用構造体 *引数１,その他引数。。）

　で表現することによってあらわす。

　で、その際必要なメソッドは、クラスの生成と、消滅にあたるものと、イベント処理。
　そこで、クラスをgamen1とすると、
　typedef struct _Gamen1
{
いろいろな要素（６回以降で説明）
　} Gamen1;

gamen1_InitAppData　生成
gamen1_FreeAppData　消滅
gamen1_HandleEvent　イベント処理
と表現した。ただし、名前はおかしいので、この機能をするものであったら、名前は変えるべきである（こぴぺが楽なので、こうしただけ）

　で、その中身については、第４回で、それにともなう、元のアプリの書き換えは、第３回に書いたので、くわしくは、そちらへ

---

●複数画面を、どう切り替えるか

　そして、画面切り替えに関しては、３つの状態が問題になる

（１）一番初めに表示する画面
（２）２番目以降、最後の画面のひとつ前まで
（３）最後の画面

画面が１つの場合は、つまり、ウィザードで生成されるものの場合は、
・initAppDataで、画面部品のインスタンスを生成し
・HandleEventのStartで、Redrawし、
・FreeAppDataで画面インスタンスを開放する。

　しかし、別に、画面部品を生成するのは、initAppData内でなくても、そのあとでも、生成してRedrawすれば、表示される。その性質を利用し、ここでは、生成とRedrawをまとめて、こんなふうにした。

（１）一番初めに表示する画面
　アプリのinitAppDataで、画面番号（という領域をアプリの構造体の中に作っている）を０にしている。そこで、アプリのHandleEventで一番初め(Startが一番初めになる）に来るときは、画面番号０である。そこで

画面番号０のとき、一番初めの画面のinitAppDataを呼び出す。 　　ここで、初めの画面のインスタンスは生成し、Redrawされて、初期画面が表示される

（２）２番目以降、最後の画面のひとつ前まで
　２番目以降は、前に画面が出ている。そこで、その画面をクローズし、次の画面を生成する。
そこで

・現在表紙している画面のFreeAppDataを呼び出す。 　　→ここで、表示画面のインスタンスは消滅する ・その直後に次に表示したい画面のinitAppDataを呼ぶ 　　→ここで、画面のインスタンスは生成し、Redrawされて、画面が表示される 　　→必要なら、画面クリアをしておくこと

（３）最後の画面

　消滅した後、アプリを終了する必要があるので

・現在表紙している画面のFreeAppDataを呼び出す。 　　→ここで、表示画面のインスタンスは消滅する ・その後ISHELL_CloseAppletを呼ぶ(FALSEで）

　

---

ということで、画面切り替え法（前の画面Free、後の画面init)を説明したところで、第６回からは、個々の画面について、どのように、インスタンスをおいて、どのようにフォーカス制御するかについて書く予定ですが、第６回をいつやるかは未定です。

サイトを売ったらいくらになるかを「きっこのブログ」を例に、Gyaoで今夜１０時やるらしい

　「きっこのブログ」をみていたら、今夜１０時から、Gyaoのニュースで、きっこの日記を売ったら、いくらになるのかという話をやるらしい。

　「きっこのブログ」は、たしか、リンクフリーだが、引用は、手紙をださないといけないので、今回は、リンクのみ。くわしくは（つまり、サイトを売るとはどういうことかとか、Gyaoのどこをみるのかとか）は、以下の「きっこのブログ」のリンク先を参照してください（きっこのブログときっこの日記は、たしか同じ内容だと思った。バックアップ用だったかな？）

　ここ　http://kikko.cocolog-nifty.com/kikko/2006/03/post_6e98.html

---

　うーん、じゃあ、このウィリアムのいたずらの分家ブログを買う人。。っていったら、やっぱ、KDDIさんぐらいですかね。
　へんな情報を書き込まれないようにするため、BREWのパートナーにしか、みれないようにするとか（＾＾）

　そしたら、もう、書きまくりだけどね。

　ドキュメント●●ページの、あのサンプルコードは、●●の機種では、うごきません。
　たぶん、サンプルは●●の機種で確認を取ったと思われますが、●●の機種では、もうひとつのほうのロジックをとおり、なぜか、そっちでは、ドキュメントサンプル、ポインタが抜けてます（＾＾；）

　とか、そーいうネタを。。

　今は、かけません。

　なぜなら、そのドキュメント、confidencialって書いてあるから（＾＾；）

　でもまあ、KDDIさんは、買いたくても、私はだれだかわからないので、当然会うこともできないわけだ。ということで、買われる心配（？）はいまのところない。

　そのうち、手元にあるケータイも(開発が終わったら）取り上げられるので、そしたら、もう、BREW端末で調べることができないので、BREWネタはなくなる（DocomoのDoJaネタに変わる予定です）。
　なので、このサイトを買う意味はない。

　つーことで、当分だれも、このブログは買ってくれそうにもない。

---

　で、「私はだれだかわからないので、当然会うこともできない」でもひとつ、ついでの話題
　
　本家に書いたんだけど、こんなのがあるみたい（＠＿＠）

　日本ブログ協会

そこの設立趣旨


ブログに関する啓蒙、表彰、研究、調査、交流、支援、提言等を行うことを通じて、我が国におけるブログの普及促進を図る。


　交流しちゃうんですか（＠＿＠！）

　大丈夫ですか！！

　交流会とかに、きっこさんとか、出てきたら、命狙われませんかね（＾＾；）
　（って、出ない、でない！！）
　ちなみに、ウィリアムのいたずらも、出られません。
　なにいわれるか、わかんなさそーだ（＾＾）


　啓蒙って、もう十分、ブログしってるとおもうんですけど。。。

　たぶん、ブログの啓蒙より、PSEマークの啓蒙のほうが、必要だと思う。

---

P.S　と書いたが、本当は、ウィリアムのいたずらの連絡先は、このブログを全部（この記事じゃないよ、ブログ全部、８９０件くらいあるみたいだけど、全記事）を見ると書いてある。

　かつて、そこの連絡先を見て、連絡をくれた人が１人いる。

　でも、ふつう、探すやつはいないだろう。８９０件も（＾＾；）

抽象化をすると逆に開発・作業効率が悪くなること、その逃げ方をWebでＤＴＰを例に

　今日は、昨日の話の最後に、HTTPのPOSTでの通信等を使って、Ｗｅｂベースで作るＤＴＰや雑誌などの自動編集について全体的なアーキテクチャーを説明したほうがいいと思うのでと書いたことについでです。
　ただ、そんだと、読者に逃げられそうなので、汎用的な話題「抽象化をすると逆に開発・作業効率が悪くなる」もかねてみました。

---

　結局、この「Ｗｅｂベースで作るＤＴＰや雑誌などの自動編集」（別に雑誌じゃなくって、動的ホームページでも、レポートでも何でもいいんだけどね）のアーキテクチャはこんなかんじ。


文字、画像、線画（ドローイングソフトの出力）等の素材
　　→そのまま、公開できるところにおく

　　↓　ＨＴＴＰのgetあるいはpostでとってくる

小組サイト

　　↓ ＨＴＴＰ

レイアウト(AJAXでもいいし、サイトでもいい）

---

　で、どーして、３層になるかというと、

・素材の部分は、お客さんが提供するものなので、そのまま扱うしかない。
　統一的なフォーマットにしてくださいということは、いえない場合が結構ある。
　なぜなら、「お客様は神様」だからだ。うそだと思ったら、三波はるおに聞いてくれ。
　　（まあ、ほんとは、力関係なんだけどね）

　なので、そのまま、ＣＧＩプログラムでアクセスできるところにおく。

・レイアウトは、汎用的に作れることは、昨日の話で示した。


・ところが、小組は、汎用的ではない。競馬新聞と、FromAは似てないし、テレビ欄と天気予報も似ていない。これらは、「この欄を、何ページのどこに置く」というレイアウト情報までは共通するのだが、その中身がぜんぜん違うからだ。

　実は、この小組の違いが、見え方の違いを表している。

　そこで、小組は、
　　・それぞれをＷｅｂサイトにして、
　　・レイアウトからの要求に応じて
　　・素材を集めて、表示なり、要求にこたえるようにする
ってなかんじにした。
　で、ここは、個別につくり、インターフェースの枠組みだけを汎用的にしたわけだ。

---

　従来のＤＴＰソフトでは、ここを汎用的な文字枠とか、イメージ枠とか図の枠にした。
　そのため、図で天気図を作る。。ありえねー（＾＾）っていう話になった。

　そう、汎用的にすると、抽象度が上がってしまうので、作業効率が下がるのだ。
　そして、開発効率も下がる。なぜなら、抽象的な仕様なんて、決まらないから。

　そこで、この問題の逃げ手として、簡単に汎用化できるレイアウトと個別的な小組を切り離し、個別の小組は、簡単に切り替えられるよう、プラグインにするわけだ。
　で、プラグインといっても、事実上、Ｗｅｂベースの場合、呼び出しサイトを変えるだけのお話だ。

---

　で、レイアウトと小組のインターフェースの枠組みをどうしたらいいかなのだが、
　これは、

・表示用画面
・プログラム呼び出し
・印刷用の内容をテキスト？で
・自動編集用のデータをテキストで

　ということに、とりあえずしておく。
　具体的な引数は、レイアウトや小組の関係によって変わるかもしれないが、基本的には、ＨＴＴＰのＰＯＳＴで渡すと。。
　で、そのプログラムの書き方は、ＰＨＰの場合は、ここに示したと。

---

　あとは、小組のプラグインとは、レイアウトとは？なんだけど、これは、具体的な話の中で展開する。

　で、そのまえに、こんなのが、どんな風にいいのかについて、書くわけだが、それは、また話が大きく変わるので、今回はここまでとしよう。