フォトアルバムから画像取得のライブラリ化を試作(将来の仕上げ編)

フォトライブラリから画像取得の独自ライブラリを試作した話の補足です。試作したソースコードを、最後に仕上げるときの考慮点について少し書きます。

　

当ブログの投稿に何度も書きましたが、ライブラリ化する際に大事な考慮点があります。複数のアプリで使えることに加え、似たような機能と交換可能に作ることです。将来の仕上げでは、それらの点も考慮しなければなりません。

複数アプリで使える点は、独立したクラスとして作ったことで実現しました。似たような機能と交換可能な点は、現状よりも深く考えて決める必要があるでしょう。

　

まず、似たような機能を考えてみます。やはり写真を取得する機能でしょう。真っ先に思い浮かんだのが、フォトライブラリ以外から取得する機能です。iPad内からの取得だけでなく、インターネット経由で取得する機能も考えられます。これらの機能に変えたり、切り替えて使う状況も考慮しておくのがベストです。

今回試作したクラスは、UIViewのサブクラスとして作りました。画面に表示する機能も含まれているため、画面上の操作や反応もクラス内で記述し、その部分はアプリと無関係に作れるので、アプリからの独立性が高いと言えます。そのため試作クラス側では、アプリを気にせずに、表示内容や操作方法の変更が可能です。

逆にアプリに関係する点は、最低限の内容になっています。画面に表示するサイズ、画像を選択中かの問い合わせ、画像の取得ぐらいです。このような形なので、別な機能と交換するのも容易になっています。

そもそも私がライブラリ化する際には、画面に表示して操作する機能の場合、UIViewのサブクラスを選択しています。その最大の理由は、ライブラリ化した側に表示や操作を作れるからなのです。もう１つ、表示サイズを可変にしているのも、交換しやすいようにと考えてのことです。今回の試作クラスも同じ方法を選んだため、予想どおり結果になったというわけです。

　

というわけで、似た機能との交換可能性を上げるためには、メソッドを整えるのがキモとなります。順番に見ていきましょう。

初期化では、画面上の表示サイズを指定しているだけですから、問題ありません。もちろん最小サイズの違いはありますが、大きく使う分には同じに使えます。もし小さいサイズで使う場合は、画面上のレイアウトで対応するしかないでしょう。

取得画像のデフォルトサイズ設定メソッドでは、縦横の大きさを指定しています。この大きさの意味、つまり指定した大きさの値が、どのように使われるのかは、交換可能な機能を実現するためのAPIに依存します。できれば最大サイズを指定しているという意味にしたいのですが、それが可能とは限りません。仕方がないので、最大サイズに近い画像を得られるように、それぞれの実現方法で工夫するしかないでしょう。

最大サイズ以外の指定方法を考えてみても、代わりとなる値の種類は思い付きませんでした。現実的な選択肢としては、現状のサイズ指定がベストだと思います。

続いて、画像の取得メソッドは２種類を用意しています。デフォルトのサイズ設定で画像を取得するメソッドは、そのままで構わないでしょう。もう１つのサイズ指定による画像取得メソッドも、サイズ指定の方法が現状でベストとなれば、こちらも同じで構わないはずです。

取得が失敗した際にnilを返す方法も、そのまま別なクラスで使えます。ただし、失敗した理由をユーザーに伝える方法は、何かしら用意しなければなりません。クラス内にUIViewを持ってますから、メッセージ欄に表示するのが現実的だと思います。

取得関係では他に、画像情報を取得するメソッドも試作クラスで作りました。これはPhotosフレームワークに依存するデータ型なので、似た機能と交換可能にはなりません。また画像情報からUIImageを得る変換メソッドも同様です。これら２つのメソッドは、今回の試作クラス独自の拡張機能という位置付けにして、可能な限り使わない方針に決めます。特別な理由がない限り使わないメソッドという扱いです。

最後は、画像が選択中かどうか問い合わせるメソッドです。こちらは、Bool型で返す形式なので、何も問題はないでしょう。

　

以上は試作クラスで用意したメソッドですが、他に必要となる共通メソッドはないか、そもそもメソッドを考える前に、他に必要な共通機能があるかも検討しなければなりません。

おそらく必要な機能としては、交換可能な似たクラスの内容により、それぞれで出てくると予想します。たとえば、インターネット経由で画像を取得するクラスなら、通信状況を表示する機能が必要でしょう。ただし、共通の機能ではないため、今回の検討からは外れます。

交換可能なクラスで共通する機能となると、残念ながら思い付きませんでした。とりあえずは、現状のままで構わないと判断しました。

　

今回のような検討(似たような別機能への交換可能性を考慮して作る検討)は、試作している途中のどこかで必ず行います。

使用するAPIの仕様が十分に見えていて、どのように作るのかが見通せる場合は、最初の全体設計の段階で検討できます。できるだけ早めに、検討したほうが良いでしょう。

しかし、初めて使用するAPIの場合は、詳細を知らない段階なので、検討しても後から変更する可能性が高まります。試しに作りながら、APIの仕様が大まかに見えてきた段階で、検討するのが効率的です。

実際には、中心となるメソッドを決める場合に、できるだけ汎用的な形式を選ぶようにしています。また、UIViewのサブクラスで作るなど、アプリから独立した形になる工夫も採用しています。そのため、メソッドの選択を大きく間違うことはありません。

全体として、気付いたら修正するという流れで構わないと思います。

　

似た機能と交換可能に作るという考え方は、変更への柔軟性を高めるための重要な点だと思います。ここで紹介したような検討を、作る際に試してみてはいかがでしょう。