インターネット動画こそロングテール対応広告が狙える。だからGyaoがテレビと同じことしても。。

　Gyaoのような、インターネットで動画配信をして番組を流す場合、電波による動画配信、すなわちテレビとは、根本的に異なる特徴がある。
　それは、電波の希少性とよばれる、ある周波数には、同時に１つの番組しか流せないということだ。
　たとえば、ＴＢＳは、今スケートをやっているが、これ以外の番組は、ＴＢＳは、この時間には流せない。もちろん、地上デジタルの場合、１つのチャンネルが１３セグメントにわかれ、うち１セグメントは、ワンセグ放送、いまのケータイでみれる番組となり、のこり１２セグメントを、１番組を普通のテレビの画質で流して３番組ながそうと、ハイビジョンを１画像ながそうと、勝手、すなわち、地上デジタルなら、最大普通画像３番組＋ワンセグ１番組、１つのチャンネルで流そうと思えば流せる計算になるが、それでも、セグメントごとにみれば、１つの番組しか流せない。

　そーすると、テレビ局の場合、
　　ある時間には原則１つの番組しか流せないのだから、
　　会社が儲かるようにするには、
　　　　その時間にできるだけ多くの人に見てもらえる
　　　　＝多くの人に受けそうな番組を流すことになる。

　たとえ、それが教育的に意義があろうと、いや、たとえ低俗といわれようとも、一部の人にとって眉をしかめる番組だろうとも、多くの人に受ければ、そういう番組をながす。これが、テレビだ。そりゃーしょーがない。そーいう仕組みなんだから。。

---

　でも、インターネットの場合は違う。同時にいっぺんの放送が、それぞれの人に対して流せる。そうすると、多くの人に受ける番組を流すより、確実に見てくれる番組を、幅広く作って流すほうがいい。

　具体例を言おう。
　いま、ＴＢＳは、スケートが流れてる。
　これは、浅田姉妹や、安藤美姫さんに興味ありありな人が多いからだ。
　でも、東京の人みんなが興味あるわけじゃない。

　一方インターネットは、浅田さんの番組も、安藤さんの番組も、プロレスも、映画も。。。あげればきりないのでこの辺でやめるけど、同時に見れる。ということは、ＴＢＳを見れる人がかりに１００人だったとして、スケートファンが２０％なら、全員見れば視聴率２０％、これけっこうすごいけど、インナーネット配信会社は、１人１人にあった１００個の番組を流すことだって可能だ。そしたら、みんな見て。。。１００％になってしまう（＠＿＠！）

---

　ってことは、インターネット配信は、１人１人の好みに合った映像を、とにかく、たくさん作って流したほうがいいことになる。個性的なら個性的なほうがいいかもしれない。
　まさに、ロングテールの世界だ。

　こうなってくると、いろんな番組が大量にでるのだから、広告枠もいっぱいになる。。
　ってことは、広告を小口にして、もっと広告料を安くしてしまうことも可能ということだ。
　たくさん作るとなってくると、お金をかける大作よりも、安い制作費で、手軽に、個性的な番組を作っていったほうがいいことになる。

　たとえばこんなかんじ

・日比谷公園の野外パフォーマンスを撮っていく番組、
　で、そういうパフォーマーとか、インディーズバンドとかからＣＭをとる。
　１番組につき１５００円とか（ただし、ＭＰＥＧかなんかでＣＭは入稿）

・小劇団がやっている演劇の内容を放送する番組で、
　いろんな劇団から広告をとる

・ＪＡＶＡとか、Ｗｏｒｄとか、フリーソフトの使いかたとかを、専門学校の
　授業を撮って流す。そして、その専門学校のＣＭをながす。
　→情報系にかぎらず資格関係とか、いろいろ

・最近のネットの話題の話など、なんでもいいから、ちょっとした人に話してもらって
　（それが重要なのではない、以下のＣＭが重要）
　ブログの紹介として、ブロガーからＣＭをとる、１回５００円
　（定型フォーマットがあって、文章だけを送る）

などなど。。
安い番組を大量に作って、安い広告費で大量の広告をとり、大量に流す。
まさに、ロングテールの番組＆広告戦略こそ、テレビと競合しても生き残れる、インターネット動画配信の戦略だと思うのだ。。

---

　でも、最近のＧｙａｏって、そういう方向じゃなく、番組的には、バラエティっぽいテレビ番組という感じがする。。。

本家にも書いたけど、罰ゲームで、グラビアアイドルが、アリを食べさせられるって、まるで、テレビのバラエティ番組を痛くしたような番組で。。。
　で、ＣＭも、大手からとってますよねー。

　こういう感じだと、まさにテレビとおなじ。。となれば、インターネットでみるより、テレビのほうが、見やすい（めんどくさくない）から、テレビに負けちゃうと思うんですよ。。。

　とはいえ、Ｇｙａｏが、上記のような、ロングテール番組、ロングテール広告戦略になるとも、ちょっと思えず。。
　このまま、こんな、テレビを痛くした様な番組ばかりが流れるっていうようだと。。

　やっぱ、Ｇｙａｏは。。。ねえ。。（＾＾；）

Javaの画面表示－その５：マルチウィンドウと再描画

　シリーズJavaの画面表示のつづきです。前回は、複数画面ですが、同時に２つ以上開かないケースについて、行いました。
　今回は、同時に２つ開き、さらに、内容の書き換えがあるケースについて考えます。

---

■仕様
　前回は画面２が出た後で、画面１を消していたが、消さないで、両方出ているようにする。
　ただし、画面１も画面２も、１つしか出さない（画面１で「打ち終わった」を何回クリックされても、画面２は、ひとつしか出ない）
　画面１で、「打ち終わった」がクリックされるたび、正解率を１足していく。

---

■アプリ全体である画面を１個（Ｎ個）しか立ち上げないという場合

　このように、アプリ全体で、ある画面を１個（もしくは２個、３個、何個でもいいけど、ときかく、決まった数しか立ち上げない）という場合、どうするかというと、

　アプリ全体の領域に、画面の個数、あるいは画面の実体を保持しておく

　という方法を使います。

　ここで、アプリ全体の領域ですが、今やっているこの方式では、アプリ全体領域として、mapという変数を取っています。これはアプリで１つで、かつ、全画面で、同じものを参照するようにしています。ということで、ここに入れましょう。

　たとえば第一画面で、いままで、gamen1クラスのgamen1_HandleEvent（内部）クラスで

	if ( o.equals(b2)== true)	
	{	//	打ち終わった！
		//	共通領域への値設定
		map.put("username","ウィリアムのいたずら");
		map.put("sei_ritu","50");
		map.put("byo","20");

		//	第二画面表示
		gamen2 g2 = new gamen2();
		g2.map	=	map;
		g2.initAppData();

		//	消す
		freeAppData();
	}

と書いていたところを、ハッシュマップから第二画面(gamen2)をとってきて、
なかったら、生成して、ハッシュマップにセットするようにします。

こんかなんじ

	//	第二画面表示
	gamen2 g2 = (gamen2)map.get("gamen2");
	if ( g2 == null )
	{
		g2	=	new gamen2();
		map.put("gamen2",g2);
		g2.map	=	map;
		g2.initAppData();
	}

もちろん、第一画面も、アプリ開始時に、mainメソッドの中で

	public static void main(String[] args) 
	{
		HashMap map= new HashMap();
		
		gamen1 g = new gamen1();

		//	画面１を設定
		map.put("gamen1",g);

		g.map	=	map;
		g.initAppData();
	}

なかんじで、セットされています

　なお、１個ではなく、２個、３個と立ち上げられる場合は、画面の個数をハッシュマップに入れておき、画面自体は、gamen1_1,gamen1_2。。。のように、枝番をつけて保存すればＯＫです（画面の個数が、規定数以上のときは生成しない。画面自体を入れておかないと、後述する値の変更で困る）

　それと、いままでfreeAppData();していた部分は、当然削除します。そうしないと、画面消えちゃいますから（＾＾；）

---

■値の変更を、直接書いてしまうと問題がある。

　では、すでに画面が表示されている場合、つまり、ハッシュマップから画面が(nullでなく）取得できた場合は、どーしたらいいでしょうか。
　仕様では、このとき、正解率を１足して再描画しなければいけません。

　ということで、以下の赤字のところのように、直接、第二画面のラベルを書き換えても画面は、確かに書き換わります。それなので、仕様は満たすので、これでいいという考えも確かにあります。

	if ( o.equals(b2)== true)	
	{	//	打ち終わった！
		//	共通領域への値設定
		map.put("username","ウィリアムのいたずら");
		seikai ++;
		map.put("sei_ritu",new Integer(seikai).toString());
		map.put("byo","20");
				
		//	第二画面表示
		gamen2 g2 = (gamen2)map.get("gamen2");
		if ( g2 == null )
		{
			g2	=	new gamen2();
			map.put("gamen2",g2);
			g2.map	=	map;
			g2.initAppData();
		}
		else
		{
			String byo = (String)map.get("byo");
			g2.l2.setText("正解率"+　seikai + "%"　+"時間" + byo + "秒");
		}
		//	消す
//		freeAppData();	消さないで両方だす
	}

---

　でも、このやり方だと、第二画面を仕様変更されて、l2がなくなった場合（l1とまとめるとか）、第一画面がエラーになります。
　ということで、第二画面と、第一画面が、同時に修正を更新しないと、その間コンパイルエラーとなり、リンクできない（実機では動かないので、テストできない）っていうことになります。
　結合以降でも、仕様変更などが入ることは、現実的にあるわけで、そういうときに、修正が、同時にいくつかの画面に渡ってしまうと、今回は簡単だから２つ同時に修正というのはできるんだけど、複雑に入れ組んでくると、もう、どーしよう（＞＿＜！）っていうことになります。

　つまり、画面部品の追加削除が勝手に行われても、コンパイルエラーにならないさらに、影響は最小限にしたいというわけです。それには、どうすればいいか。。。

---

　実は、この続きをかいてあるのですが、それを貼り付けたら、恐ろしく長くなってしまった（＾＾；）ので、今日は、ここまでとします。

　どうしたらいいかは、次回のこのシリーズで書きます。

「東芝、ソニーへの賠償請求検討」って、他にも広がったら！？

ここのニュース
東芝、ソニーへの賠償請求検討＝電池回収でパソコン販売に影響も
http://headlines.yahoo.co.jp/hl?a=20061016-00000037-jij-bus_all

ひえー。東芝が請求したら、きっとほかのメーカーも請求するよね。。
そーしたら、ソニーは。。。。

ただ、この請求、どこまでが、範囲かって、問題ですよね。。間接的な影響といっても。。
・サポートセンターにかかってきた電話を受けた人件費？
・たしかに販売機会損失の問題
・ブランドの信用力低下の問題

　どこまでが範囲か。。。

　でも、これで、間接被害まで賠償するとか言うことになったら、急にテレビコマーシャルしたりして。。「以下の商品は発火のおそれがありますので、すぐにサポートセンタへ」とかいう（＾＾；）

　あと、こういう間接被害が認められると、とくに「販売機会の損失」まで認められちゃうと、中古品を扱っているおみせまで、範囲になっちゃうよね。そのパソコンのバッテリーを交換する期間、そのパソコンを販売する機会を損失したし、パソコンが対象かどうか調べる手間もかかった！とか言われたら。。。（＞＿＜！）

　うーん、もし、賠償が認められたら、ソニーは、たいへんそうだ。。。

BREWで複数画面を開発する場合の方法論（その１０：ＨＴＭＬとコントロールの混在－その１）

　シリーズ「BREWで画面間メモリ一括管理」（いわゆるＢＲＥＷ版カオル姫方式）が一段落して、今度カオル姫方式2ndにいく前に、ちょっと、複数画面の話で遣り残していることがあるので、そっちのほうを書きます。

　カオル姫方式2ndは、Javaのシリーズをやっているのですが、そっちのほうで、カオル姫方式2ndと同じことをやると思うので、それとの比較というかんじで、あとで書くと思います。
（そうすると、外部仕様的には共通で、内部仕様を変えればＯＫっていう感じが見えてくると思います）

　ということで、前やってたシリーズ「BREWで複数画面を（分割して開発可能な）開発する場合の方法論」の続きということになります。

　で、これからやるお題は、ＨＴＭＬとコントロールの混在です。

---

■利用場所
　ＢＲＥＷで、ITextCtlやIMenuCtl等、コントロールを貼り付けるような画面で、ある理由から（詳しくは聞くな、そーいう場合があるんだ、じゃなかった(^^;)あるかも知れないと思ったんだ）IMenuCtlのAEECLSID_SOFTKEYCTL（画面の下に出るソフトキー）が（技術的な理由以外の制約で）使えない場合がある。。かもしれない。。
＊技術的には、可能です。

　そのとき、IHtmlViewerのボタン(INPUT TYPE="submit")を使えば便利ジャン！

　というようなケースや、

　HTMLでINPUT type=textでやっていたんだけど、それだと、複数行が出来ない。
　複数行にしようとして、textareaにしても。。？？あれあれ？？
　ってなっちゃって、ITextCtlで複数行にしようと思ったり。。。
　でも、ボタンは使いたいなどというケース（今回は、これ）

　などなど。。。です。

---

■仕様
　第一画面を、以下のようにします。



　このとき、this is testまでが、IHTMLCTLを使ったもの（IHtmlViewerをつかいやすくしたもので、このシリーズの今までの回で、使っていたものです）、下の入力テキストが、ITextCtlです。

・はじめに「挑戦する」にフォーカスが来て、それを選択します
・次に入力エリアにフォーカスがうつって（上記のイメージは、そのときの様子）
　ここで、入力して「ＵＰキー」を押すと
・「打ち終わった！」にフォーカスが行くので、そこで選択すると
・第二画面に遷移します（それ以降はいままでと同じ）

---

■ソース
　今回は、この仕様変更で、修正の入ったソースを先に公開します。
　以下のソースです（これ以外は「BREWで画面間メモリ一括管理（その１－概要とサンプルソース）」の下のほうにあるソースと同じです）

　IHtmlCtl.c
　IHtmlCtl.h
　gamen1.c
　gamen1.h
　gamen1.htm

---

　次回から説明に入ります。