そもそも、ケータイの通信速度が速くなったら、アドレス帳とか、端末に置くべきか。。。

　さっきＮＨＫニュースを見ていたら、「ケータイの盗難でも、アドレス帳が消すことができる」という話をしていたんですけど、今後、通信速度が、３．９Ｇとか、すっげー早くなったら、そもそも、アドレス帳とか、端末においておいたほうがいいか？っていう議論もありえますよね。会社なんかのケータイの場合。

　ケータイ起動時に、サーバー（これはキャリアが用意するサーバーか、会社のサーバーかっていう話はあるけど）からダウンロード、ケータイ終了時に更新箇所だけアップロードして、削除ってすれば。。。

　さらには、単純に起動させるんじゃなくって、指紋認証してＯＫならダウンロードとか、あるカードを読み取ったら（これはＱＲでもfelicaでもなんでもいいけど）ダウンロードとすれば、たんに、そのケータイを盗んでも、ダウンロードできない。

　で、こうすれば、よく使う人だけをダウンロードして、それ以外は、サーバーにおいておいて、必要なときだけ検索するとかすれば、かなり多くの人でもできるし、会社で、アドレス帳を管理して、ある人の電話番号が変わったら、その人を登録しているアドレス帳に、いっせいに電話番号を変えるとかもできそう。

　なーんて考えると、アドレス帳も、メールも含めてぜーんぶサーバで管理できるし、
　そうなると端末のアプリは極論でいえばブラウザだけでよくなるかもしんないし、
　そーすると、ソフトはサーバー側にあるので、修正も簡単だし。。
　（さすがにそこまでする必要はなく、プログラムは、アプリで提供してもいいと思うけど、
　　理論上はできそう）


　なんてなってくると、メールもアドレス帳も、スケジュールも、掲示板とか、全部をまとめて、グループウエアとして提供して、起動時に、必要データを取り出してくればいい。
　グループウエアの提供とかは、プロジェクト管理と絡めて、ありそうだ。。

---

　さらには、ケータイから、運賃の精算書とかを書くと、会社の経理にＰＤＦ形式で、その清算書が届く（はんこも、それなりにシャチハタっぽく押してあって　＾＾）とか、そーいう世界にもなってくると思うけど、いいたいことは、そういうアプリの想像っていう話じゃなくって、ケータイの回線が早くなると、いままで、端末においておくのが当たり前と思っていたデータやアプリも、サーバにあったほうが便利ってことがあり得るかもしれない。。っていうこと。

　いままで、当然に端末に置くべきと思っていたデータ（デジカメで撮った写真とか）もサーバーにおいておいたほうがいいんじゃないか、ストリームでながしたほうがいいんじゃないか？などと、疑ってかかったほうが、面白いものがつくれるかもしんない。。

　ってことが、いいたかったこと。。

著作権を厳守した場合、YouTubeは、現在の人気を保てるかの方がリスクかも、グーグルにとって

このニュース
YouTube買収は「クレイジー」――ドットコム長者がコメント
http://headlines.yahoo.co.jp/hl?a=20061011-00000013-zdn_n-sci

では、アメリカのグーグルの問題点として、
（以下斜体は、上記ニュースより引用）

　Googleが今後1度でも著作権侵害で「御用」となるようなことがあれば、多くの株主訴訟につながると見る。Googleが、著作権に関するリスクをどう認識しているか、米証券取引委員会（SEC）に対してどう説明するかも見もの。また、両社が最近、各レーベルと急いで提携にこぎ着けたのは、デジタル権利管理（DRM）を気にしている現れであると見る。また、Google Video上でビデオクリップを販売する一方で、YouTube上で同じコンテンツが無料で配信される矛盾をどう解決するのかも見ものである、としている。

　と書いている。

　ウィリアムのいたずらは、さらにその問題に付け加えて、
　その先の話のほうが気になる。

　で、その先の話っていうのは。。。

　じゃあ、ＹＯＵ　ＴＵＢＥが著作権を守ったと仮にしたら、
　　　今の人気はあるか？

　っていう問題。

　ＹＯＵ　ＴＵＢＥが有名になった、「はいだしょうこ」さんの問題だって、あの画像を取り締まってしまったら。。。
　その他、いろんな画像、全部著作権違反をしているのを取り締まって、締め出してしまったら。。
　たぶん、日本からのアクセスは、激減するわけで、そうなったとき、ＹＯＵ　ＴＵＢＥは、どれだけの価値になるか。。というリスクは、みんな考えていないと思う。

---

　で、実はこれ、グーグルだけの話じゃなくって、ＹＯＵ　ＴＵＢＥに触発された、他の動画投稿サイトにも言える話。

　著作権を守る動画投稿サイトなんていうのも出たけど。。うーん。。。どーなんでしょーねー。。。どのくらい知名度が上がったか。。（＾＾；）
　意外と、始める前のほうが、知名度高かったりして（＾＾；）

　ということで、著作権を厳密に守った場合、現在にくらべて、企業価値がどれくらいのものか、動画投稿サイトは、ビジネスとして成功するのか？
　というのは、正直、まだ未知数だし、結構、悲観的なような気がするんだけどな。。

Javaの画面表示－その３：画面部分を分けてみる

　シリーズJavaの画面表示、前回は、ＡＷＴを使って、よく本に載っている方法でやった場合と、そのときの問題点について書きました。
　よく本に書かれているのは、mainのところに書いてしまう方法なんだけど、このやり方だと、複数画面のときに困ると。。

　では、どうやったらいいのかについて、今日は書きます。

---

■概要
　ということで、BREWのように、２つの部分に分けます。
　ＢＲＥＷの場合、アプリ全体の関数と、各画面の関数にわかれますが、これも同じように、
・全体のクラスと
・各画面のクラスに分けます。

そして、全体のクラスでは、
・画面間に受け渡すハッシュマップの作成と
・はじめの画面表示
を行い、各画面のクラスで、画面表示と、イベント処理を行います。

　なお、ＢＲＥＷと異なり、ＪＡＶＡでは、メモリを解放する措置を、書く必要はありません
（システムがやります）

---

■全体のところ
　mainがあるところです。ここから、初めの画面を表示します。
　ソースは、こんなかんじ

import java.util.*;

public class test{


	/*
	 * 	メイン処理
	 */
	public static void main(String[] args) 
	{
		HashMap map= new HashMap();
		
		gamen1 g = new gamen1();
		g.map	=	map;
		g.initAppData();
	}
	
}

なお、画面の表示メソッドをinitAppDataってしている理由は、
ＢＲＥＷとあわせたからです。
　ふつうにJavaでくむときは、もっといい名前にしてください。

---

■各画面の処理
　今回は第一画面ということで、gamen1というクラスを作って
みました。で、ソースはこんなかんじです。

import java.awt.*;
import java.awt.event.*;
import java.util.*;

public class gamen1 {

	//	共通領域
	HashMap	map = null;
	
	//	画面項目項目
	Frame 		f;
	Button		b1;
	Button		b2;
	TextArea	t1;

	/*
	 * 	表示
	 */
	public void initAppData()
	{

		//	フレームを作成する
		f = new Frame("test");
		f.setSize(240,320);
		f.setLayout(null);

		//	アクションを作成する
		gamen1_HandleEvent al = new gamen1_HandleEvent();

		//	ラベル
		Label l1 = new Label("早うちの練習");
		l1.setLocation(10,30);
		l1.setSize(100,30);
		f.add(l1);

		Label l2 = new Label("これは、練習文です。");
		l2.setLocation(10,120);
		l2.setSize(150,30);
		f.add(l2);

		Label l3 = new Label("以下の文を打とう！");
		l3.setLocation(10,70);
		l3.setSize(100,30);
		f.add(l3);

		//	テキスト
		t1 = new TextArea();
		t1.setLocation(10,160);
		t1.setSize(150,80);
		f.add(t1);
		
		//	ボタン作成		
		b1 = new Button("挑戦する");
		b1.setLocation(120,70);
		b1.setSize(100,30);
		b1.addActionListener(al);
		f.add(b1);

		//	ボタン作成		
		b2 = new Button("打ち終わった!");
		b2.setLocation(10,250);
		b2.setSize(100,30);
		b2.addActionListener(al);
		f.add(b2);

		//	表示
		f.setVisible(true);

	}

	
	/*
	 * 	イベントリスナー
	 */
	private class gamen1_HandleEvent 
			implements ActionListener
	{

		/*
		 * 	ボタンが押されたときの処理
		 */
		public void actionPerformed(ActionEvent e)
		{

			Object o = e.getSource();

			if ( o.equals(b1)== true)
			{	//	挑戦する
				System.out.println("挑戦する");
				return;
			}

			if ( o.equals(b2)== true)	
			{	//	打ち終わった！
				System.exit(0);
			}
		}
	}
}

前回のmainが、initAppDataにきているだけで、それほどかわって
いませんが、画面部品（b1,b2など）が、メソッドの外に出ています。

おかげで、イベント処理Handle_Eventで、イベント発生箇所を聞くとき、

　　Object o = e.getSource();
　　if ( o.equals(b1) == true)

のように、オブジェクトを比較することで聞けるようになりました。

なお、initAppDataが表示処理、gamen1_HandleEventが、
イベント処理です。
ＢＲＥＷにあわせたため、こういう名前になってます。
本当にやるときは、もっと分かりやすい名前のほうがいいです。
なお、ＢＲＥＷにはFreeAppDataもあり、そこでメモリ解放しますが、
Ｊａｖａはシステム(JVM)がメモリ解放をやるので、書いていません。

---

　ということで、今回はここまで、
　次回のこのシリーズは、２つ目の画面を作って表示します。

BREWで画面間メモリ一括管理（その３－各画面での設定・取得）

　シリーズ「BREWで画面間メモリ一括管理」（いわゆるＢＲＥＷ版カオル姫方式）の第三回目、今日は、各画面における、共通領域への値設定と取得の方法です。

---

■前回のまとめ
　その前に前回の内容をまとめておくと、
・共通領域の連想配列を保持しておくところ
　　　IKHMap　*pMap
　を、アプリの構造体に用意する

・アプリ_initAppData（はじめに来るところ）で、
　上記共通領域の連想配列pMapを、
　　IKHMAP_Create(pMe->pIShell,pMe->pIDisplay);
　で作成する

・アプリ_freeAppData（最後に来るところ）で、
　上記共通領域の連想配列pMapを、
　　IKHMAP_Release
　で開放する。そうすると、連想配列の各要素も、
　解放される

＊連想配列：あるキーを入れたら、それに対する値が帰ってくる配列
　perlでは、配列として存在するが、Javaでは、同じことをハッシュマップ
　（またはハッシュテーブル）で行う。Ｃではないので、IKHMapとして、
　今回、作っている。

---

■各画面での値の設定
　今回、gamen1でやっているので、そこで説明します。

●各画面の構造体(gamen1.h)
　これは、どっちでもいいんですけど、画面の構造体に、

// 共通領域
IKHMap *pMap;

　というかたちで、全体アプリの構造体の値を置いとけるところを
作っておきます。

●画面の初期化（gamen1_InitAppData）
　上記領域をとった場合、

// 共通領域を設定
pMe->pMap = poya->pMap;

　っていうかたちで、アプリ全体領域の共通領域
（ここではpoya->pMap）の”ポインタを”pMe->pMapに
セットします（つまり、実体は、アプリ全体領域の共通領域が
さしているところと同じです）

●値のセット
　今回は、gamen1_doJob2でやっています。

　IKHMAP_StrPut(pMe->pMap,"sei_ritu",sei_ritu);

　のように、IKHMAP_StrPutという関数を使います。
　引数は
　　第一引数＝共通領域のポインタ
　　第二引数＝キーワード
　　第三引数＝値の文字列
　です（この関数は、値が文字列のケースしか使えません）

　おなじキーワードがすでにあれば、そいつは削除して、
新規に、この値を設定します。
　なお、値の領域は、関数内で取得し、その後、引数の
「値の文字列」の内容をコピーします。
　つまり、引数の値の文字列に対しては、なにもしないので、
この引数のメモリー解放は、ユーザー側でやってください。

●注意
　pMe->pMapは、領域を取っているわけでないので、
gamen1_FreeAppDataで領域を開放「しない」でください。

なお、上記例のgamen1.cは、ここにあります。

---

■値の受け取り
　
　gamen2.cのgamen2_InitAppDataでやっています。

　　username = (char *)IKHMAP_Get(poya->pMap,"username");

　のように、値をIKHMAP_Get(で取得します。
　引数は
　　第一引数＝共通領域のポインタ
　　第二引数＝キーワード
　です。返り値が結果になります（NULLは”設定されていない”の意味）

　なお、返り値は、配列の値のポインタそのものを返します。
　なので、勝手に解放(FREEIF)とか、しないでください。
　また、値を書き換えると、それ以降、ずっと、そのキーワードの値は、
代わってしまうので、書き換えないでください。
（キーワードの値を変えたい場合は、IKHMAP_StrPutしてください）

　なお、このように、初期化でしか使わない場合は、画面の構造体に
共通領域のポインタを取らなくてもいいです（統一させるのであれば、
とってもいい）。

　また、要素がいらなくなったら、IKHMap_Removeをすれば、解放
されます。勝手にFREEIFしないでください。
　ただし、もし、解放しなくても、プログラムが終了するとき、
または、同じキーワードで新しい値が設定される（＝更新する）ときに、
値は解放されます。

---

と、こんな感じです。
これで、利用できるはずです。

次回は、具体的にIKHMapの中身について書きます
（なので、ただ、この関数を使う分には、今日までの範囲でできるはず）

AJAXはＶＩＥＷ、ＰＨＰはＣとＭって形で、ＭＶＣが特別なことを使わなくても分離できるってこと？

　きのうのマスカットのサーバーサイドのところを見て思った。
　そっか、（マスカットに限らず）AJAXを使えば、

　　　ＡＪＡＸ部分でビュー、
　　　ＰＨＰは、コントローラーとモデル

　にわけられる。。。

　で、サーバーサイドのＰＨＰを呼び出すときに渡す引数と
　ＰＨＰの表示内容をＸＭＬが、

　カオル姫方式なんかでいう、ビューとモデル間の受け渡し変数ってことね。

　つまり、こんなかんじ


あ、でも画面を切り替えるとき、ちょっといやらしい問題があるなあ。。
できることはできるけど、手法として確立するには、もちょっと考えたほうがいいなあ。。

こんど、キレイに出来そうだったら、そのとき、また書きます。