タブつき撮影情報リストだよ

ファイルの整理に入る前に、ささっと撮影情報リストを作ってみました。

コントロールをEditFieldからListBoxに変更して、タブで内容を切り替えるようにしました。 今回の撮影情報リストの特徴は、タブの状態を共有プロパティを使って一元管理していることです。 共有プロパティというのは、Javaでいうところの静的変数ですね。 撮影情報は、複数のウインドウに表示する可能性があるので、どれかひとつのタブを切り替えたら、それ以外のタブも同時に切り替わるようにしようというわけです。

撮影情報リストのコンストラクタが呼び出されたら、共有プロパティの配列に、自分自身を登録するようにします。 タブが切り替えられたら、共有メソッドでその値を共有プロパティに保存してから、配列に登録されているインスタンスの全てに、リストを更新するように指示するわけです。 もしかしたら、撮影情報リストは、フローティングウインドウでひとつだけしか表示しないかもしれませんが、この仕組みはとても便利ですね。

REALbasicでは、抽象メソッド自体は扱えるものの、残念ながら抽象メソッドを明示的に宣言することができません。 なので、メソッドが増えると、どれが抽象メソッドかの判断がつきにくくなってしまいます。 でも、イベントを抽象メソッド的に使えることに気がつきました。 スーパークラスで、外部との窓口となるパブリックメソッドと、サブクラスとの窓口になるイベントを用意します。 後は、サブクラスを作成するだけで自動的にイベントが追加され、プライベートなメソッドと区別されるので、構造がとてもわかりやすくなります。

撮影情報は、TIFF、Exif、GPS、MakerNoteという4つに分類されますが、どれもIFDという同じ構造になっています。 そこで、IFDクラスを用意して、それぞれに対応する4つのインスタンスを作り、これにデータを格納します。 データ構造は同じでも、データの内容はそれぞれ異なるので、IFDAnalyzerクラスを用意して共通の処理を行い、それぞれに対応する4つのサブクラスを作り、そこで固有のデータの処理を行うわけです。 これまでも、データクラスの共用化はしていたわけですが、データ解析はひとつのクラスで力技でやっていたので、ずいぶんスッキリさせることができました。

オブジェクト指向プログラミングでは、データと処理でクラスを分けるというのが基本なんですが、その基本を知らなかったので、これまではずいぶん苦労していました。 PhotoMaster 1と比べると、PhotoMaster 2ではクラスの分化が進んでいたわけですが、それでもひとつひとつのクラスが巨大化していて、とても見苦しいコードになっていました。 PhotoMaster 3では、クラスをうまく分割することで、効率の良いコードにしていきたいですね。

要領が良くなると、負担が軽くなって、とても気持ち良くなりますね。

日本語で撮影情報表示

撮影情報が、日本語でより詳細に表示できるようになりましたよ。

といっても、できるようになったのは1週間ほど前の話で、それ以降は何かとバタバタしていたので、ほとんど手つかずでした。 オブジェクト指向プログラミングにおけるクラスの扱いにもだいぶ慣れてきて、かなりスッキリと記述できるようになりました。 というか、これまでがあまりにも力技過ぎて、我ながら呆れてしまいました。 逆に、この程度の技術力で良くここまで作り上げたものだと、妙に感心したりもしました。

メーカー独自の撮影情報であるMakerNoteの実装はまだなんですが、今は深追いはせずに、とりあえず次に移ろうと思います。 当面は、MakerNoteの情報ははなくても何とかなりますからね。 その代わり、GPS情報が取得できるようになったので、将来的には、ケータイカメラで撮った写真の場所をGoogleマップで表示する、なんてこともできそうです。 ただ、普通に撮っただけではGPS情報は組み込まれないので、どれだけ利用している人がいるのかはわかりませんが。

今のところ、取得可能な情報は、TIFF、Exif、GPSの3種類で、Interoperability、いわゆるExifR98拡張情報はまだ実装していません。 これは、RAWなどの拡張データ形式で記録された場合、互換性を保つためにサムネイル画像を別途THMファイルで提供するというものなんですが、基本的にPhotoMasterではRAWを扱わないので、ずっとこの拡張情報は扱ってきませんでした。 PhotoMaster 3では、もしかしたら、サムネイルの表示だけでも対応するかもしれません。

次は、これらの撮影情報を元に、自動的にファイルを整理する処理を実装していきます。 PhotoMaster 3では、この部分をマルチスレッド化することで、体感的な処理速度の向上を図るつもりです。 マルチスレッド化によって、最終的な処理時間は同じでも、処理が終わるまで何もできなくなることがなくなるので、待ち時間のイライラを減らすことができます。 マルチスレッド化は、何かとタイミングを取るのが難しいんですが、今時のソフトとしては避けては通れない道なので、気合いを入れて頑張ります。

7月中旬までには、ファイルの読み込みと一覧表示、そして詳細表示の骨格を完成させたいですね。