調査メモ

Androidアプリ「通話履歴カウンタ」をバージョンアップ（version 2.0）しました。



Android Marketにてダウンロードできます。
https://market.android.com/details?id=jp.ise.calllogcounter

通話履歴カウンタ（CallLogCounter）は、ケータイの通話履歴を分析し、あなたの交友関係の現状や推移を可視化するアプリです。

今回のバージョンアップでは、通話時間・回数ランキングの表示件数を（5件・10件・15件から）選択できるようにしました。トップ画面にて、端末のmenuボタンを押すと、「ランキング表示件数」というボタンが出てきます。それを押すとプルダウンで表示件数が選択できます。

また、2回目以降の起動を早くするために、設計を見直し、処理を改善しました。通話回数の多い人なら、改善の効果を実感いただけると思います。

さらに、英語表記にも対応し、日本語が読めないユーザーにも使えるようになりました。

ぜひ、ご利用ください。

だいぶ前から予告が出ていましたが、Chrome Webストアがついにリニューアルされました。

https://chrome.google.com/webstore/category/home?hl=ja

見た目がずいぶん変わって、見やすくはないけど、前よりはおしゃれな感じになりました。
でも、残念ながらデベロッパーダッシュボードは特に変化なしです。

ちなみに、私が作った「為替情報チェッカー」は、「FX」か「為替」で検索すると出てきます。
拡張機能＞ニュースと天気から探すと、小さすぎてなかなか見つかりませんでした。

以前と比べると、だいぶ上の方に表示されるようになりましが、相変わらずダウンロード数は伸びないですね。

残念。

◆chrome 拡張機能「為替情報チェッカー」
https://chrome.google.com/webstore/detail/pkjcjjfljpnhamedehdkjpbhppeikjab?hl=ja&hc=search&hcp=main



chrome拡張機能「為替情報チェッカー」を更新しました。上記URLから無料でダウンロードできます。

◆更新内容
ウィジェットの色を選択・保存する機能を追加しました。前回のバージョンは、ブログパーツをコピペしただけでしたが、それでは芸がないので、少し拡張機能らしい機能を実装しました。

----------

そもそも、「為替情報チェッカー」とは何ですかという人のために、概要を説明します。

◆「為替情報チェッカー」の基本機能
URLボックスの右に出てくる「FX」のアイコンをクリックすると、主要な為替レートがポップアップで表示されます。



◆特徴
1．今見ているサイトから移動することなく、ワンクリックで為替レートがチェックできます。
2．日本語で唯一の為替情報アプリです。chromeウェブストア内において、「為替」で検索すると、これしかヒットしません。（2011年8月21日現在）
3．日本円を軸に比較ができます。（海外のものだと、米ドルを基準にいくらと表示されるものが多く、円に換算して考えるのが面倒です。）

◆情報源
大和証券のブログパーツ（http://www.daiwa.jp/study/blogpart/index.html）を拝借して作成しています。
試しに作ってみたところ（基本的にコピーして貼っただけですが）、思いのほか便利だったので、早速公開しました。

◆ソースコードと作り方について
わざわざ公開するほどのものではありませんが、あえて隠す必要もないので、ソースコードは下記のURLに配置しました。
https://github.com/Akira-Isegawa/chrome-extension-fx

なお、作り方は下記のブログ記事にて紹介しています。
http://a-i-a.blog.so-net.ne.jp/2011-08-25

◆注意事項
為替はだいたい20分Delayなので、取引をする際は、実際の取引価格を必ず確認してください。為替情報チェッカーの機能、および、表示される情報について、一切責任を負う事はできませんので、ご自身の責任において、ご利用ください。

先日、Androidアプリ「通話履歴カウンタ」をリリースしましたが、このアプリは、他のAndroidアプリと比べて、画面のデザインがだいぶ違うことにお気づきいただけたでしょうか？

実は、このアプリはAndroidの標準的なUI（ユーザーインターフェース）部品をほとんど使わず、HTML+CSS+JavaScriptにより実装しました。
目的は、Webの標準的なUIの実装に用いられるHTML+CSS+JavaScriptで、実用に耐えうるAndroidアプリが作れるかを検証したかったためです。
これができれば、Androidの画面をほとんどそのままiPhoneやWindows Phoneなどにも使えるので、多機種への対応を考えた場合は効率的なはずでした。

最終的には、実用的なアプリをリリースできましたが、そこに至るまでの過程はなかなか大変で、いろいろ思い通りに行かなかったので、その軌跡を一部記しておきたいと思います。

まず、最初はオープンソースで無料で使えるライブラリを流用することを考えました。iUIやTitaniumは昔、少しだけ使ったことがあるので、まだ使ったことがなかったjQTouchと、PhoneGapを使ってみることにしました。jQTouchは、画面のアニメーションをスマートフォンらしくしてくれるライブラリで、PhoneGapはJavaScriptからAndroidやiPhoneなどのAPIが呼び出せるライブラリです。

本や雑誌ではこれらのライブラリがすばらしいもののように紹介してありますが、自分の目的には適合しない部分が多々ありました。

【jQTouchの問題】
・jQTouchのアニメーションが重い。
　エミュレーター上ではサクサク動きますが、HT-03Aというかなり古い端末に入れてみると、アニメーションの動きが鈍すぎるうえに、画面がチラチラして、まともに動きませんでした。他方、iUIというライブラリであれば、HT-03Aでも一応スマートフォンらしいアニメーションが実現できました。ただし、Androidで1画面ごとに1つのWebViewを割り当てる作りにすれば、ページ遷移時のアニメーションは勝手に実現できるため、結局iUIも使わずに終わりました。


【PhoneGapの問題】
・PhoneGapの一部の機能のパフォーマンスがイマイチ。
　実機上で連絡先を20件ほど登録して、PhoneGap経由で連絡先を取得すると、10秒以上かかった挙げ句、2件しか表示されませんでした。エミュレータだと全部出てくるため、JavaScriptのコードが間違えているとも思えません。また、連絡先のAPIをJavaから直接呼ぶと、1秒もかからずにすべて表示されたことから、AndroidのAPI自体は悪くないようです。

・PhoneGapを使うと、画面側（JavaScript）と端末側（Java）でのコミュニケーションが面倒になる。
　PhoneGapには通話履歴データをとってくる機能はなかったので、PhoneGapを拡張して機能を追加しようと考えていました。一応、PhoneGapのソースをひもといて、なんとかその機能を拡張することはできましたが、JavaScriptでは呼び出しとCallBackメソッドを実装し、Java側では、DroidGapを継承してサービスを追加し、Pluginを継承して機能を実装するなどといった手順が必要で、なかなか面倒です。
　AndroidのWebViewにはそもそもJavaScriptとJavaをつなぐインターフェースがあるので、それを使った方がだいぶ楽でした。

・PhoneGap関連のJavaScriptのコードは、デバッグが難しい。
　普通のWeb画面で用いるJavaScriptであれば、Firebugなどを使えば比較的簡単にデバッグができますが、PhoneGap関連のJavaScriptはPCのブラウザでは動かないため、Androidのエミュレーターや実機上でテストをする必要があります。残念ながら、Androidのエミュレーターには、JavaScriptのデバッグをする機能はないため、どこでエラーになってどのように直せばよいかを特定するのが、なかなか難しい作業となってしまいます。


【HTML+CSS+JavaScriptの開発手法の問題】
・アプリをデプロイしても、うまく反映されないことがある。
　原因は不明ですが、アプリを消して、再度デプロイしても、最新の状態にならないことがたまにありました。実機でもエミュレーターでも同様の事象が発生し、おかげでデバッグの効率がだいぶ下がりました。ブラウザのキャッシュなどが残っているのが原因かと思って、消してから再実行しても結果は同じでした。
　この事象が発生した場合、エミュレーター起動の際に、Wipe User Dataを選択して、エミュレーターを初期化してしまうのが一番確実ですが、せっかく準備したテストデータも消えてしまうので、悲しい結果になってしまいます。実機の場合は、アプリとブラウザのキャッシュを消してから再起動するだけで、最新の状態が反映されるようです。

・Androidのブラウザでは動作しないJavaScriptのライブラリが結構ある。
　グラフを表示させるライブラリは、JavaScriptでも多数あるのですが、見た目がかっこいいものに限って、Androidに入れてみると表示できないということが多々ありました。PCのブラウザやiPhoneのブラウザでは普通に動くのに、Androidのエミュレーターや実機に入れてみると動かないという不毛な検証作業を何度も繰り返しているうちに、もう新しいライブラリを探すのが嫌になって、すべて自分で実装することにしました。

・JavaScriptのエラーは、エラーレポートで送ってもらえない。
　アプリをリリースした後の話ですが、JavaScriptでエラーが起こっても、処理が停止するだけで、エラーレポートを送るかを尋ねるダイアログは出てきません。JavaScriptでも適切にエラーハンドリングをして、Java側にエラー発生を通知すれば、エラーレポートのダイアログを出せるかもしれませんが、予期せぬ例外が起こった際に、エラーハンドリングのコードがうまく最後まで動いてくれる保証はありません。


以上を総括すると、HTML+CSS+JavaScriptの開発手法の発想自体はすばらしいが、そのすばらしいアイディアを具体化するための開発環境や実装はまだ発展途上にあるということがわかりました。

上記で取り上げたライブラリについては、十分な検証ができないまま使うのを諦めてしまった部分もありますし、今はもう改善されている可能性もあるため、導入を検討されている方は、上記の点に注意しつつ、最新の状態で検証されることをおすすめします。

高校の頃、歴史の授業で、「1950年代後半、洗濯機・冷蔵庫・白黒テレビが『三種の神器』として宣伝され、普及し始めた。そして、1960年代、カー（自動車）・クーラー・カラーテレビの3Cが新三種の神器として普及していった。」と習ったと記憶しています。

高度成長期、明日は今日より良くなっているという希望に満ちた時代だったのでしょうか。不況の時代しか知らない我々の世代にとっては、具体的な感覚としては想像しづらいところです。

ところで、自分自身の生活環境を省みると、自分は3C（カー・クーラー・カラーテレビ）さえ持っていないことに気づきました。

最近、洗濯機が壊れてしまい、三種の神器も一種しか持ってないという状況になってしまいました。生活家電だけ見ると、1950年代後半の生活水準にあります。

別にお金に困っている訳でもないですし、蓄財に励んでケチっている訳でもないのですが、いつの間にかそうなっていました。

洗濯機がないのは結構面倒でしたが、手洗いでも、なんとかやっていけることが分かりました。これなら洗濯機さえ手に入らない貧困の時代が訪れてもなんとかなりそうです。

今回、期せずして擬似的な昭和生活を経験しましたが、そこから見えてきたのは、高度成長期のような明日への希望ではなく、もし日本が再び昭和中期の水準まで経済を衰退させた場合に、どうやって生き延びるかといったビジョンでした。

この経験が、将来訳に立たずに済むよう、日々努力をしようと決意を新たにしました。

Vectorにて「Excel VBA Framework」を公開しましたのでお知らせします。
下記のサイトから無料でダウンロードできます。

http://www.vector.co.jp/soft/winnt/business/se492956.html

ソースコードも公開しており、変更や有償での再配布も可能です（Apache License, version 2.0を採用）。

先日、「Excel VBA Framework構想」の記事で、そのコンセプトは記載しましたが、改めてその概要をご紹介します。



◆Excel VBA Frameworkとは?

ExcelVBAで開発を行う際に、よく使う機能をフレームワークとしてまとめたものです。

大まかに言うと、①開発の効率化と、②保守性・拡張性の向上がこのフレームワークの売りです。

①毎回必要となる機能を共通化し、一部のコードを自動で生成できるようにすることで、効率的に開発ができるようになります。
また、②ワークシートの入出力やメッセージ出力を集約し、変更の頻度が高いスキーマ定義やメッセージをコードから分離することで、保守性・拡張性を向上させます。


◆Excel VBA Frameworkの機能

このフレームワークが持つ機能は、下記の通りです。


【1. スキーマ定義】
行番号・列番号の定義を、VBAのコードに固定で持つのではなく、スキーマ定義のシートに記載された値を動的に取得するようにしました。
これにより、スキーマ変更時のコードへの影響が少なくなります。


【2. データアクセスクラス(DAクラス)の自動生成】
各ワークシートのデータにアクセスする際に、Worksheetオブジェクトに直接アクセスするのではなく、データの入出力を管理するクラス(DAクラス)を作成し、そのクラスを通じてWorksheetにアクセスする方が保守性・拡張性が高まる上、入力チェックをする際にも便利です。
しかし、各ワークシートのスキーマに応じたDAクラスを準備するのはなかなか面倒くさいものです。
そこで、上記のスキーマ定義から、DAクラスを自動生成する仕組みを作成しました。


【3. 入力チェック(ゴミ処理)】
ユーザーは時にとんでもない値を入力しますが、ある程度のゴミは機械的に取り除いてから処理した方が親切な設計です。
そこで、上記のDAクラスの中に自動で入力チェック(ゴミ処理)を組み込みました。入力チェックは、まだ汎用的なものしか実装していませんが、容易に拡張可能です。


【4. メッセージユーティリティ】
ユーザーに表示するメッセージを、VBAのコードに固定で持つのではなく、「メッセージ一覧」のシートに記載された内容を利用するようにしました。
ユーザーメッセージを一カ所に集中させることで、実装と同時に統一的なメッセージ設計が簡単にできるようになります。
また、適切にメッセージ設計をすることで、エラー発生時の対応がとりやすくなります。


◆使い方

フレームワークはマクロ付きのブックで配布していますので、そのブックにモジュールやクラスを追加して開発してください。
フレームワークが提供するクラスには、頭に「FW_」という名前が付いているので、どこまでがフレームワークで、どこからが自分が書いたアプリかを区別するのは容易です。（Excel VBAではパッケージが作れないので、苦肉の策として共通のprefixを用いました。）

細かい使い方については、ダウンロードした際に一緒についてくるドキュメントをご参照ください。


◆今後実装予定の機能

【1. Javaへのインターフェース提供】
上記のスキーマ定義から、JavaのDAクラスを自動生成し、Apache POIを用いて、Javaから対象のワークシートにアクセスができるようにすることを予定しています。


【2. その他便利機能】
DAクラス高速化バージョン、DAクラスの単体テストクラスの生成、AccessDBへのデータ入出力を容易にするクラスなどなど。


◆その他

今後実装予定の機能がまだあるため、一旦ベータ版として公開しています。ベータ版のうちに「こんな機能も欲しい」といったご意見・ご要望をいただければ、実現の可能性は高いかもしれません。

ちなみに、早速仕事でも使ってみましたが、滑り出しは順調です。このフレームワークの使い方に慣れれば、だいぶ効率は上がると思います。

「フレームワークの使い方に慣れる」という部分が面倒と感じる人もいるかもしれませんが、なぜこういうコーディングスタイルにしているのかが分かれば、わりと簡単なので、そのあたりもあわせて、今後説明できればと思います。

最近、仕事でVBAのコードばかり書いています。

今携わっているプロジェクトは、大量の単純作業が膨大な種類存在しており、先月は、それらの作業を自動化するツールばかり作っていました。
全部で17種類のツールを作成しましたが、計1万行ちょっとのコードのうち、6割以上がVBA、3割がJava、1割がその他（シェル、バッチ、JavaScriptなど）という比率でした。
個人的にはJavaの方が好きですが、短期間でそれなりのGUIを持った小規模ツールを作るとなると、VBAにはかないません。

しかし、何個もツールを作っていると、毎度同じようなコードを書いていることに嫌気がさしてきます。単純作業を自動化するために、単純作業を繰り返す自分ってどうなんだろうと。

そこで、毎度必要となる機能はフレームワークに持たせて、それを拡張するだけでそれなりのツールが作れるようにできないかと考え始めました。

結果、「Excel VBA Framework」には、下記のような機能があるとよいという結論に至りました。


1. スキーマ定義

行番号・列番号の定義を、VBAのコードに固定で持つのではなく、スキーマ定義のシートに記載された値を動的に取得するようにします。
これにより、スキーマ変更時のコードへの影響が少なくなります。


2. データアクセスクラス（DAクラス）の自動生成

各ワークシートのデータにアクセスする際に、Worksheetオブジェクトに直接アクセスするのではなく、データの入出力を管理するクラス（DAクラス）を作成し、そのクラスを通じてWorksheetにアクセスする方が保守性・拡張性が高まる上、入力チェックをする際にも便利です。
しかし、各ワークシートのスキーマに応じたDAクラスを準備するのはなかなか面倒くさいものです。
そこで、上記のスキーマ定義から、DAクラスを自動生成する仕組みを実装します。


3. 入力チェック（ゴミ処理）

ユーザーは時にとんでもない値を入力します。それでいてアプリが動かないと、すぐに「バグだ！どうなってるんだ！」と苦情を言ってきます。
「入力値が悪いんだから、知らねーよ」と言い返したくなりますが、確かに、ある程度のゴミは機械的に取り除いてから処理した方が親切な設計であることは間違いありません。
そこで、上記のDAクラスの中に自動で入力チェック（ゴミ処理）を組み込みます。


4. メッセージユーティリティ

ユーザーに表示するメッセージを、VBAのコードに固定で持つのではなく、「メッセージ一覧」のシートに記載された内容を利用するようにします。
ユーザーメッセージを一カ所に集中させることで、実装と同時に統一的なメッセージ設計が簡単にできるようになります。また、適切にメッセージ設計をすることで、エラー発生時の対応がとりやすくなります。


5. Javaへのインターフェース提供

上記のスキーマ定義から、JavaのDAクラスを自動生成し、Apache POIを用いて、Javaから対象のワークシートにアクセスができるようにします。


6. その他便利機能

DAクラス高速化バージョン、DAクラスの単体テストクラスの生成、AccessDBへのデータ入出力を容易にするクラスなどなど、夢は膨らむ一方です。



上記の「Excel VBA Framework」の構想は、現在、寝る間を惜しんで実装中です。（もうすぐベータ版ができます。）
たぶん同じような状況で苦しんでいる人も居ると思いますので、近日中にオープンソースで公開する予定です。

Androidアプリ「通話履歴カウンタ」のダウンロード数が1000を超えました。
ご利用ありがとうございます。

この数に至るまで、1カ月ちょっとかかりました。
最初の500ダウンロード達成までに約20日かかっていたのと比べると、ゆっくりながらも徐々に成長しているようです。

今後とも、より多くの人に使っていただけるよう、
機能改善や追加を行いたいと思います。

Androidアプリ「通話履歴カウンタ」は、Androidマーケットにて無料でダウンロードできます。
https://market.android.com/details?id=jp.ise.calllogcounter

このブログの累計アクセス数（ページビュー）が、30万を突破しました。

たくさんのご利用ありがとうございます。

最初の10万アクセスを突破するのに約3年かかりましたが、
それから2年を待たずして、30万アクセスに到達しました。
ゆっくりと、しかし、着実に成長しているようです。

ネタはあっても、準備に時間がかかるため、
なかなか更新頻度は上がりませんが、
今後もボチボチ続けていきたいと思います。

Androidアプリ「通話履歴カウンタ」を更新しましたので、お知らせします。

下記サイトにて無料でダウンロードできます。
https://market.android.com/details?id=jp.ise.calllogcounter&feature=search_result
（※ダウンロード済みの人はUPDATEするだけでOKです。）

今回の更新のポイントは「高速化」です。

一日に50回以上通話をするヘビーユーザーを想定して、2万件以上の通話履歴データを準備し、開発・テストを行いました。

一部の重たい処理をバックグラウンド化する、データのI/Oを節約する、メモリの使用量を節約するなど、地道なチューニングを繰り返し、大幅な高速化に成功しました。

例えば、アプリを起動してから画面が表示されるまでの時間は約10分の1に、画面が表示されてから操作が行えるようになるまでの時間も約4分の1にまで改善しました。

電話をほとんどしない私のような人にとっては、あまり改善の成果は見えないかもしれませんが、電話の数が多い人なら、今回の改善の成果を実感いただけると思います。

ぜひ、お試しください。