夢とガラクタの集積場

てなわけで続きです。

電力不足が深刻になっていて、
それが急場の発電所の建設だけではどうやら解決しないだろう。
ただ、原子力発電の今後は絶望的だろう、というのが前回までの内容。

今回の地震は間違いなく戦後最大のインパクトを日本に与えた災害でしょう。
被害の大きさだけでなく、日本の社会への影響も。

多分、今のままでは東日本のエネルギー不足は解消しません。
ということは、おそらく取るべき策は下記の２つのうちいずれかではないかなぁ、
と考えています。
１．東電地域にある都市／設備／人口を日本各地に分散させる。
２．エネルギー戦略を見直す。

１．東電地域にある都市／設備／人口を日本各地に分散させる。

電力を使用する存在自体を地方に移動させてしまおう、という解決方法。
ただ、これについては個々の組織が自発的にやるとは思えないため、
多分ごく一部しか実現しないはず。
＃取引先が関東にあるままだと移動できませんしね。

２．エネルギー戦略を見直す。
根本解決につながる可能性ですが、５年１０年単位の時間がかかります。

１は多分実現しない、２は５年１０年かかる。。。
あれ？てことは５年間くらいの夏は今行われている計画停電をはるかに
上回る規模の計画停電が実施され続ける、ということですよね。

本当は２について書きたかったんですが、
まずは真夏の停電を乗り切るために必要なものを列挙しておく必要がありそうです。
ではまずそれをその３に。

てなわけで、思ったことのまとめ開始。

まず前提として、東京電力の発表によると、現状で東電区域において電力が不足しています。

Ａ．３月中旬の総発電能力：3350万KW
Ｂ．３月中旬の総必要電力：4700万KW（節電＋計画停電でＡにあわせている）

Ａについては４月前半までに
検査中だったり、フル稼働していない火力発電所をフル稼働状態に
持っていくことで4000万KWまで供給能力を持っていく予定のようです。

４月になれば暖房はほぼ使用されなくなる関係上、4000万KWあれば
必要な量はほぼ確保できる模様。
なので、４末時点では下記のように重要と供給はつりあいます。

Ｃ．４月末時点の総発電能力：4000万KW
Ｄ．４月末時点の総必要電力：4000万KW

ですが、このページや、このページを見ていると、
夏季に必要となる電力量は6000万KW～6400万KW程にもなる模様。
＃暖房と違って、冷房は電力で行う他ないから、という話なのでしょうか。

東電側も数か月で動作開始可能なガスタービン発電所（出力30万KW級）をいくつか
建設する予定のようですが、それでも4800万KW程までしか行かないようです。

ということは、下記のように最大1600万KWのギャップが出る。
夏の猛暑の中、計画停電突入、ということになってしまうわけです。

E．夏季の総発電能力：4800万KW
F．夏季の総必要電力：6000～6400万KW

かつ、今回の福島原発の事故によって、
今後原子力発電所を新設／修理することは極めて困難な状況になっていると思います。
世論／国際情勢的に。

もしかすると今停止している原発を再開することすら無理かもしれない。

てことは、おそらく上記の1600万KWを
今までとは違う手段を持って埋める必要がありそうです。

そのために何が出来るか、を考えた結果を書いていこうと思います。

東北関東大震災により被害を受けられた皆さんに心よりお見舞い申しあげます。

東北関東大震災では私自身も直接被災地区ではないにしろ、
停電やモノ不足による影響をかなり受けました。

幸い、動くのが早かった＆そもそも１人暮らしであまりモノを必要としない関係上、
生活必需品については困ることはありませんでした。
ただ、おかずのバリエーションは減ってたかな。そのくらいでした。

なんですが、電力不足によって街から明かりが消え、
物流が麻痺している都市を見ていると物思う所がありました。
とまぁ、ただそれはまた違う話題になるので、次の投稿で。

後、いまいち今までのデザインは見にくかったので変更しました。
すっきりして見やすくなったかと思います。

Androidアプリでリストを最後まで読んだら検知する方法

の続きです。

とりあえず、『リストを最後まで読んだら検知すること』は成功しました。
ともあれ、これだけでは全くわからないので、
使ったメソッドと、その動作についてまとめます。

『リストがスクロールしたこと』を検知することは前の投稿にも書いたとおり、http://developer.android.com/reference/android/widget/AbsListView.OnScrollListener.html
を使います。

使用するメソッドはonScrollです。

ただ、APIとして記述されている内容だけだとぶっちゃけわかりません（汗
英語力不足なんでしょうか。。。。

仕方がないので動作確認した結果、下記の動作となることがわかりました。

firstVisibleItem：一番上に表示されてるアイテムのインデックス
visibleItemCount：画面に表示されてるアイテム数
totalItemCount：リストに存在している全アイテム数

図に示すと下記のようになります。

なので、「firstVisibleItem + visibleItemCount == totalItemCount」の条件を
満たした場合のみOnScrollからイベントを発生させるようにすれば、
リストを最後までスクロールした場合に処理を行うことが可能となります。
差分がtotalの10%になったら発動、というようにすれば
「下の残りが少なくなったら随時追加読み込みを行う」という処理も
可能になります。

さて、とりあえず検知と、イベント発動が可能であることがわかったので、
後は読み込み処理を上手く共通化して扱うための手法、ですね。

作成が成功したらその３として投稿します。

もう１つ。
Androidアプリ内部で、HttpURLConnectionを用いてhttpsのBasic認証を行った場合
なぜか「１回目の通信のみがこける」という事象が発生中。

原因は不明ですが、１回目の通信はhttpsstatuscodeが-1なので、
そもそも外部にアクセスに行けずにこけている模様。

で、代わりになるようなものが無いか調べていたのですが、
DefaultHttpClientだと何とかなる可能性があります。
「https通信」「Basic認証」は各々実現している情報（下記２ページ）がありました。

・Android で HTTPS 通信をする
http://www.pshared.net/diary/20091123.html

・DefaultHttpClientでBasic認証使ったアクセスを行う
http://techbooster.jpn.org/application/3391/#more-3391

なので、「https通信」「Basic認証」の両立も可能？と考えたい所ではありますが、、、
とりあえず、試すまでにはちと間が空きそうです。

最近Androidエミュレータを用いてAndroidの通信内容を確認するために
ローカルプロキシを適用していたんですが、
よく通信に失敗するという状態になっていました。

で、確認してみたんですが、https通信の時だけこけている模様。
http通信は正常に中身が確認できていたので、
https通信だけピンポイントにこけているようでした。

で、なぜかな～と調べてみると、Androidのバグ情報が。
http://code.google.com/p/android/issues/detail?id=2690

どうやら、Androidのバグとして、プロキシを通したhttps通信は出来なかったようです。
尚、このバグはGingerbread、つまりAndroid2.3では解消している模様。

なので、Androidエミュレータのhttps通信の中身を確認したい場合、
Android2.3のエミュレータを使う必要がありそうです。

現在作成中のアプリで、
「リスト表示されたアイテム（ListView）を最後までスクロールしたら次を読み込む」
処理が必要になったのですが、
Web上を調べてみてもいまいち見つからなかったので
メモとしてここに残しておきます。

とりあえず、検知出来そうな手段は見つけました。

http://developer.android.com/reference/android/widget/AbsListView.OnScrollListener.html

が使えそうです。

このページにある下記のメソッドは、
スクロールした際にコールバックを返す、というメソッドのため、
最後までスクロールしたら次読み込む用にすれば実現できそうです。

とまぁ、とりあえずはテスト用のプログラムを組んで確認してみよう。。。

public abstract void onScroll
(AbsListView view, int firstVisibleItem, int visibleItemCount, int totalItemCount)