夢とガラクタの集積場

ListView続き。
いまいち脈絡ないですが、色々ListViewについて調べているうちにわかったということで＾＾；

ListViewでクリックを検知する方法について説明します。

ListViewでクリックを検知するには、AdapterViewのOnItemClickListenerを使用します。

引数の説明はいまいちわかりにくいですが、下記ソースコードのJavaDocを参照してください。


＝＝＝＝＝
itemlist.setOnItemClickListener(new OnItemClickListener() {

    /**
     * ListViewのクリックされたイベントを検知する。
     *
     * @param targetListView クリックされたItemを保持するListView
     * @param clickedView クリックされたView
     * @param index ListView中のクリックされたインデックス
     * @param rowid クリックされたViewのrowid
     */
    public void onItemClick(AdapterView<?> targetListView,
            View clickedView, int index, long rowid)
    {
        //ListViewとして使用するためにキャスト
        ListView listView = (ListView) targetListView;

        //ListItemとして使用するためにキャスト
        ListItem clickedItem = (ListItem) listView.getItemAtPosition(index);
    }
});
＝＝＝＝＝

ちなみに、APIですと引数は下記のように記述されていました。
1.parent       The AdapterView where the click happened.
2.view       The view within the AdapterView that was clicked (this will be a view provided by the adapter)
3.position  The position of the view in the adapter.
4.id       The row id of the item that was clicked.

。。。結局実装してみるまでわからなったやん（汗

なんというか、つらつらと分析だけやっているの飽きました（爆

元々書きたかったことは電力不足な中、
再生可能エネルギー、燃料電池、スマートグリッドといった
次世代のエネルギー／インフラが台頭してくるのではないか、ということでありまして。

そんなわけで今後はAndroidだけでなく、
そういった次世代エネルギー関連の内容も語られる形になります。

ともあれ、こんな阿呆なブログにつきあって頂いたお礼として、
スマートグリッドの本をちょこちょこ読んで作ったまとめを。
多少バランスが取れていない面はありますが、それは今後ブラッシュアップしていきます。

てなわけで、「２．エネルギー戦略を見直す。」について書いていきます。
ようやくですが。

ちなみに電力の不足について書かれた記事はよりわかりやすいとこを見つけました。
＃以後、本ブログでも電力の現状を示す際には下記のブログの引用をさせていただきます。

東京電力の計画停電を考える
http://ameblo.jp/kazue-fujiwara/entry-10835236187.html

上記ブログ管理人のkazuさんはサマータイムで節電という１つの結論を出しています。
人／電力消費の『場所的な避難』ではなく、『時間的な避難』という形での対処とするものですね。

とはいえ、一応この一連の記事の目的は「２．エネルギー戦略を見直す。」について
今わかっていることを書いて、まとめておこうという目的のため、
エネルギー戦略に対する感想や考えみたいなものを書いていきます。

まず最初にそもそも発電の手段ってどんなのがあるか、を列挙します。
結果は下記の通り。

１．火力発電：燃料の持つ化学エネルギーを燃焼により熱に変換し、さらに運動エネルギーに変換する発電。
２．原子力発電：核反応により熱エネルギーを得る発電。運動エネルギーへの変換は、通常は蒸気タービンを用いる。
３．水力発電：水の位置エネルギーによる発電。
４．核融合発電：原子核の融合によってエネルギーを得る発電。
５．地熱発電：地熱による発電。
６．太陽熱発電：太陽光の熱エネルギーによる発電。
７．風力発電：風の運動エネルギーによる発電。
８．波力発電：波の運動エネルギーによる発電。
９．潮力発電：潮の干満の位置エネルギーによる発電。
１０．炉頂圧発電：高炉の高圧ガスでタービンを回す発電。
１１．冷熱発電：LNGの冷熱を利用し、中間熱媒体を液化、循環させて発電。
１２．海洋温度差発電：海面の温水と深海の冷水の温度差を利用する発電。
１３．人力発電：人間を動力源とする発電。燃料や電池の補給が難しい局面で重宝される。
１４．燃料電池発電：燃料の化学エネルギーを直接電力に変換する発電。部分出力でも発電効率が良い。
１５．太陽光発電：太陽光エネルギーを太陽電池で直接電力に変換する発電。自然エネルギーなので燃料の購入の必要がない。
１６．宇宙太陽光発電：宇宙空間で太陽光発電を行い、それによって得た電力を地上に送る。
１７．MHD発電：ファラデーの法則に基づきプラズマなどを用いて発電する。
１８．熱電発電：温泉水と河川水などの温度差を利用して熱電変換素子により発電する。
１９．振動発電：圧電素子と振動板を組み合わせることにより、音や振動のエネルギーを電気エネルギーに変換する発電。

・・・・なんか、思ったより一杯あるんですね。
まずは分類分けしよう。ただ時間も時間のため、分類分け等は次回以降に。

てなわけでその３。

全く解決策ではなく、『真夏の停電をいかに乗り切るか』についてまずまとめちゃいます。
備忘録としても。

まず、真夏の停電において障害となるのは下記の３つです。
１．照明が無い暗闇
２．猛暑による体力の消耗
３．猛暑による食べ物の急激な痛み

１．照明が無い暗闇

夜は真夏であろうと暗いです。
長期にわたって夜間の停電が続くことを考えると、下記の２条件を満たした照明器具が必要でしょう。
Ａ．LEDを使用している
→　LEDの長寿命は大きいです。使い続けるため、電灯みたいに途中で切れては困る。
Ｂ．充電式か、今持っている充電池で使用することが出来る
→　重要。
おそらく、夏季にも照明器具向けの乾電池は不足するはず。
不足している状況下で数日でワンセットの乾電池を消耗することは出来ない。
なので、Eneloop等の繰り返し使用できる充電池と、
そのサイズの充電池で使用可能な照明器具を入手する必要があります。

Ａ、Ｂを満たす照明だと、充電池が入手しやすい単３電池、単４電池で稼働する
LEDランタンが理想かな？
ただ、今は入手できないので、４月か５月を待ちますか。。。


２．猛暑による体力の消耗
真夏に冷房を使用せずに凌ぐとひたすら体力を消耗します。
なので、少しでも消耗を抑えるためには。。。
何がいいんだろ。
扇風機と、保冷剤を多めに用意しておくくらい、しかないのかな。
後は、水分を頻繁に摂取できるよう確保しておくくらいでしょうか。


３．猛暑による食べ物の急激な痛み
停電の間冷蔵庫も止まります。
ただ、今と違うのは猛暑であるため、３時間であっても冷蔵庫の停止が響きます。
であれば。。。こちらも大きめの保冷剤を用意するか、
ジップロックに水をためて凍らせたものを保冷剤代わりに使用するといった対処が必要となります。



まとめ

夏までに下記のグッズを買い込んでおこう。
今は混乱期だから、物流も一通り回復した４月下旬あたりに。
１．LEDランタン（単３電池、単４電池で使用可能なもの）
２．EneloopかEvolta充電型の充電可能な電池
３．扇風機
４．保冷剤
５．ジップロック

てなわけで続きです。

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

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

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

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

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

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

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

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

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

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

Ａ．３月中旬の総発電能力：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)