Swift: アウトレットを含めたプロパティで Optional “?” を積極的に使う

Swiftの特徴として、クラス名のみで示す型では、nil値を許さないことです。一方、?や!でnil値を許す変数の定義などができます。それぞれ、OptionalとUnwrapped Optionalと呼ばれています。

var myLabel1: UILabel = UILabel(frame: ...) // nilを許さないので何か入力しないといけない
var myLabel2: UILabel?
var myLabel3: UILabel!

ここで、アウトレットについて考えてみます。アウトレットは、Interface Builderで線を引くなどして参照先のオブジェクトが指定されていれば、ストーリーボードのロード時などに自動的に参照先が設定されます。しかしながら、オブジェクト生成直後では値が確定しないので、OptionalかUnwrapped Optionalのどちらかにしないといけません。

ここで、Appleのドキュメントでは、Unwrapped Optionalにすべきと書かれており、Xcodeでアシスタントエディタで、Interface Builderのオブジェクトからctrl+ドラッグでコード上にドロップしたときに作られるプロパティは、自動的にUnwrapped Optionalになります。もし、アウトレットをOptionalで定義すると、Optional Binding、つまり、

if let aLabel = myLabel2 {
    x = aLabel.text
}

のように、ifで囲う必要があります。そうなると、Objective-Cで作られたプログラムを移植するようなときに、流れが変わってしまい、作業効率が悪くなるということもあると思います。こうした点を総合して、AppleはUnwrap Optionalをアウトレットの推奨形態にしていると思われます。

しかしながら、Optionalか、Unwrap Optionalかは、仕組みの上ではどちらでも構わないのではないでしょうか。つまり、nil値を許せばいいのです。また、nil値になる状態での不要な処理を避けるという意味では、明示的にOptional Bindingを記述することになるので、不都合はなく、むしろ好都合かもしれません。余分に記述するのが目障りということもあるかもしれませんが、予防的な措置であれば、むしろ歓迎すべきです。これらの点は、個人的な嗜好ではありますが、むしろ評価すべきです。そもそも、Swfitは安全な言語ということが謳い文句だったはずです。であれば、Optionalをもっと積極的に使うべきではないでしょうか。

Optionalにしたら、面倒と思うかもしれません。たとえば、以下はいずれも、エラーになります。tagというプロパティはないとエラーでは記述されています。

myLabel2.tag = 3
let m = myLabel2.tag

しかしながら、若干の誤差を許していただければ、基本的には非常に緩いルールでこれらのエラーは逃れられます。それは、Optionalなプロパティが左辺にあるときには、単に、変数名に?をつけるだけでいいのです。右辺で利用するときには原則としてバインディングを行います。

myLabel2?.text = "aaa";
if let label = myLabel2 {
     let m = label.text
}

これだけのことでいいのです。これだけのことで、より安全になるのであれば、手間をかける価値はあるのではないでしょうか? アウトレットを含めたプロパティは、Optionalで定義する〜このルールでも構わないと考えます。

実は深刻な“カミFileMaker問題”

(2015/2/12 0:28更新:Facebookでの杉原さんの意見も反映させました。2015/2/13 17:00更新:Facebookでの日高さんの意見も反映させました。ありがとうございます。)

ネ申ExcelはExcelだけの問題か?

Excel方眼紙や罫線優先のワークシートなどなど、Excelで作った文書のうち、見栄えを整えることを主眼として作ってしまったことにより後からデータの活用ができなくなってしまった文書などを「ネ申Excel」と総称されています。三重大学の奥村先生の論文にまとめられています。良し悪しの問題は難しいのですが、例えばネ申Excelな記入用紙はWebフォームにすれば、即座に一覧が作られるなど、より利便性が高い代替え手法が明らかに存在するような場合があります。そのようにExcelにこだわる余り、自身の効率化を損なうのはもちろん、入力をするなどの利用者の利便性を著しく損なう状態になるのは避けるべきだと言えるかと思います。

同じような問題は他のソフトウエアにも、サービスにも存在します。ここで、データベースソフトの話をしたいのですが、そうなると、AccessかFileMakerかということになります。自分自身の問題でもあるので、馴染みの深いFileMakerを取り上げ、「カミFileMaker問題」として扱います。あえて、カタカナの「カミ」にしたのは、大昔「ファイルメーカー」と呼んでいたFileMakerへのトリビュートです。FileMakerのレイアウト機能は、帳票を高い自由度で作成できることから、従来の紙ベースで行われてきた業務をそのままデータベース化できる強い動機付けになっています。同じような仕様がAccessにもあることはありますが、プロの開発者からデータベース利用者までがみんなしてテーブルを定義してレイアウトをいじるというのはFileMaker市場の大きな特徴だけに、「カミFileMaker問題」が浮き彫りになると考えられます。

「カミFileMaker問題」とは?

ここで問題の定義として、紙の帳票類をそのままデータベース化してしまうことで発生する問題とします。もちろん、帳票をそのままデータベース化するだけでも、例えば、共有ができることや、印刷を省きパソコンやタブレットで閲覧することでの即時性などのメリットは発生します。最初の帳票ができたとき、「これはいい!」と誰もが思います。だけど、いくつも帳票を作るに従って問題が顕在化します。

紙が画面に変わっただけ?

帳票をデータベース化すると、どうしても従来のワークフローが結果的に踏襲されることになります。むしろ、ワークフローは出来上がっているのだから、それを電子化すればよりスムーズという、あまり根拠のない理屈を信じて突き進みます。その結果、まず、電子化されているのに「転記」という作業や、帳票の生成や破棄、あるいはステータス更新という動作に「手作業」が入ってしまいます。今までは紙だったので、それはやって当たり前でした。しかしながら、電子化するときに、そこでの自動化を深く考えなかったとしたら、同じことを端末を操作してやらないといけません。パソコンを扱うのが弱いとか、ストレスが高い人は、そこでまずはつまずくことになります。

紙にはなかったリンク情報はどうなった?

それでも仕事をみんなでがんばってこなしたとします。そして、さまざまな帳票レコードが、1つのエンティティに対して複数積み重なることにより、新たな問題が発生します。ある帳票と別の帳票が結びついている場合はよくあります。1対1や1対多ということもあるでしょうし、多対多もあります。紙で作業していると、その結びつきを人間がやっていることがあります。業務上の常識から、誰もが自動的に異なる2枚の帳票に関係がある、関係ないということを判定できるのです。この作業をパソコンの画面上で人間が行うのは非常に面倒です。紙のファイルを何冊か机に並べて対応するものを開けて突き合せるような手軽さは、今のパソコンやタブレットではまだまだ無理です。

もちろん、相手の文書IDを記録するなどすればいいのは当然ですが、気付いた時には遅かったということもあります。また、そのような「リンク」の重要性が、問題が発生しても気付かない、あるいは気付かないふりをするということあるでしょう。かくして、対応する文書の手がかりをかなり強引に引っ張り出すことになります。「同一顧客で、この帳票より前のもののうち、最新のもの」などといったリレーションシップを組むなどします。それでも、運用は可能かもしれませんが、対応が取れなくなる可能性が0ではなく、小さいながらも0%よりも大きくなります。また、業務で発生するイレギュラーなケースを忘れていると、ミスにつながります。ビジネスロジックでほぼ解決できるものでも、より単純な解決法があるのなら、単純な方が安定しているのは言うまでもありません。

矛盾する2つのフィールドの関係

さらにこんな例もあります。紙の帳票から、別の帳票に転記するとき、人間が転記するといいように解釈していたのですが、それを電子化すると、機械的に転記できないような場合が発生します。つまり、それぞれの帳票のスキーマに、論理的な不一致が発生してしまうのです。もっとも身近な例では、入力帳票が「氏名」で、それに対応する別の帳票が、姓名別々のフィールドのような場合です。こうしたスキーマの不一致は、紙の帳票をそのままデータベース化すると、気が付いたら行っていたということになります。また、転記なのか参照なのか、ここの考え所を全部転記することにしてしまったことで、かえって手作業が増えることもあります。

この問題は、突き詰めると、データベースのスキーマを検討するときに必ず必要となるその業務ドメインのモデル化が不正確なのです。フィールドとテーブルを定義すれば良いというのはFileMakerの機能のことで、設計者は他に考えないといけないことはたくさんあります。データ間の連携はもちろんだし、これについてはリレーションシップで定義することになります。しかしながら、FileMakerの機能に見えないこととして、あるデータは転記して見えるようにするのか、参照して見えるようにするのかということを考える必要があります。これは、FileMakerのテーブル設計のダイアログボックスでは明示化されていないものの、極めて重要な設計上の決まりごとになります。

データベースには、データベースに合った設計を

こうした問題は、昔からありますが、FileMakerは手軽だからこそ、陥る罠でもあるといえます。あえて、「カミFileMaker問題」として、問題を浮き彫りにすることで、より多くの方が意識できるようになればと考えました。もちろん、プロの方々もこうした失敗を重ねてきていて、いろいろなノウハウをお持ちでしょうし、長年使ってきた人も同様です。例えば、受託開発のとき、導入経験がないお客さんの要望をそのまま構築すると、「カミFileMaker問題」の宝庫です。プロや熟練者は、そこでしっかりとお客さんの要望を受け入れつつ、問題の発生を抑える手立てを考えないといけません。言われた通りにやればいいというのは間違いで、そのようなやり方を続けてきた結果使われないシステムを納品することになり、信用を落とすことになるのです。この問題を認識し、きちんと説明して方向付けをする必要があるのは、プロや熟練者の皆さんなのです。決して、素人を茶化すための問題定義ではないことは最後に強調したいと思います。

以下にまとめておきます。もちろん、みなさんの意見や表現の向上も大歓迎です。

「カミFileMaker問題」の発生

  • 帳票類をそのままFileMakerのデータベースで再現する電子化

「カミFileMaker問題」による起こりがちな結果

  • 一見すると効率化されたように見えるが、帳票作業とは異なる事務作業等が増えているなど、実は効率化されていない
  • 機械的に行えるデータの連携や解釈などが、データベースの仕様に含まれず、そうした作業も人間が行う必要がある
  • 2種類の帳票でスキーマが異なり、論理的には転記ができず、人間が解釈してつどつど修正しないといけなくなる
  • 紙が減ることの効率性だけに注目した結果、システム運用コストに気が回らず、気が付いたらかえってコスト高になってしまっていた
  • データベーススキーマの設計において正規化という点が考慮されず、データ解析に支障をきたしたり、あるいは解析自体が不可能な、品質の低いデータを蓄積してしまう。

「カミFileMaker問題」の本質

  • コンピュータ作業に最適なワークフローを検討し、転換しないために、結果的にさほどの効率化もされない
  • データ間のリンク構造を記録できないスキーマ上で、ビジネスデータが蓄積され、どうしようもなくなり、最悪はデータ活用に制限が出てきてしまう
  • データベースのスキーマを単に「紙にあった項目」のみで認識することで、ドメイン自体を表現するモデルの精度が低くなってしまう

iOS 8のデバイスの回転可能な方向の設定

iOSのネイティブアプリケーションを開発するとき、Xcodeのビルドするアプリケーションの設定のDeployment InfoにあるDevice Orientationにあるチェックボックスの設定が重要です。iOS 6以降、この設定がそのままInfo.plistファイルに設定され、アプリケーションはその設定に応じた動きをします。このDevice Orientationは、その方向にデバイスを向けたときに、画面が回転して、画面の上端が実際に上に見えるようになるということを示しています。通常、Upside Downつまり、ホームボタンが上に来る縦長の状態にしたときには、回転は行われないということになっています。つまり、Upside Downの方向にしたときには、写真は90度あるいは180度傾いて見える状態のままになるということです。

shot9897

前の図のDevice Orientationの設定は、iOS 7までは、iPhoneとiPadで別々でした。それぞれで回転可能な方向を決めることができました。iOS 8つまりXcode 6からは、その上のMain InterfaceがiPhoneとiPadで共通になっているので、Device Orientationも共通かと思ったら、Xcode 6.1.1で作ったプロジェクトでは、iPhoneとiPadのDevice Orientationの設定が、別々に定義された状態になっています。以下は、Infoをクリックして見たところで、Supported interface orientationが、iPhone向けの設定であり、General(前の図)で見えている設定です。それに加えて、Supported interface orientation (iPad)もあり、4つの方向がチェックされています。このiPadの設定はGeneralには見えていません。したがって、General側で設定をどう変更しようと、iPadの場合はこのInfoで見えている設定に従うために、すべての方向に回転ができるようになります。

shot9898

ちなみに、iPhoneとiPadの両方の設定が必要なら、Generalのパネルに双方の設定ができるようにすべきです。もしかして、iPadのDevice Orientationの設定は間違えて紛れ込んでいるのでしょうか? ここで、iPad側の設定を削除したいなら、Supported interface orientation (iPad)の項目を選択し、項目名の右に見える、丸にマイナスの部分をクリックします。これで削除できます。

shot9899

ここで、まず、Info.plistに項目が存在するかどうかによって、どのように稼働するのかを見てみます。これを見る限り、既定の動作をさせるには、要するに、これらのInfo.plist項目はそもそもない方が素直な設定の気がします。既定の動作をさせないときに、項目を定義するというのが理にかなっているような気もします。

Supported interface orientation Supported interface orientation (iPad) 回転の動作動作
設定なし 設定なし iPhoneはUpside Down以外が可能、iPadはすべての方向へ可能、つまりデバイス既定の動作
設定あり、要素なし 設定あり、要素なし
設定あり、要素あり 設定なし iPhoneもiPadも、iPhone側の設定に従う
設定あり、要素あり 設定あり、要素あり iPhoneはiPhoneの設定に、iPadはiPadの設定に従う

Supported interface orientationにチェックが入れば、その方向で回転するというのが概略の説明ですが、正しくは1つの場合だけ回転しません。回転しない例が、iPhoneの場合のUpside Downです。つまり、このチェックを入れるだけでは、その方向に回転しないのです。つまり、デバイスの規定値の方が優先順位が高いとみていいでしょう。

では、iPhoneでもUpside Downを可能にするにはどうすればいいか? UIViewControllerにあるsupportedInterfaceOrientationsメソッドにヒントがあり、このメソッドをオーバーライドするのがポイントです。このメソッドは、UIViewControllerであらかじめ定義されており、ビットマスク値を返します。ホームボタンの位置が上下左右のそれぞれに対応する4ビット分のマスク値を返します。UIViewControllerに実装されているメソッドだと、iPadだと4つのビットがすべて1、iPhoneだとUpside Downを除く3つのビットが1になっています。実際に回転していい方向は、Info.plistの設定と、supportedInterfaceOrientationsメソッドの返り値をビットANDをして、残ったビットが回転をしてもいい方向になります。なので、Info.plistの設定で全部にチェックされていても、iPadでは全方向に回転は可能ですが、iPhoneでは、Upside Downはマスク設定で0になっていて、キャンセルされてしまうのです。

それでは、自分で定義しているUIViewControllerの継承クラスで、supportedInterfaceOrientationsメソッドを実装して、全部のビットが1になっている値を返せばいいではないかと考えるところです。しかしながら、この回転の判断は、いちばんルートにあるビューコントローラで判定されます。Single View Applicationで作ったようなプロジェクトだと、いきなり自分で定義しているビューコントローラのクラスがルートにあるので、そこでメソッドを組み込めばいいでしょう。以下のコードに追加されているメソッドを加えます。しかしながら、Master-Detail Applicationのテンプレートで作ったプロジェクトでは、例えば、MasterViewControllerやDetailViewControllerクラスにsupportedInterfaceOrientationsメソッドを作ってもうまくいきません。これらのクラスのオブジェクトはルートのビューコントローラではないからです。Master-Detail Applicationで作ったプロジェクトのストーリーボードファイルを見れば、ルートはUISplitViewControllerクラスのオブジェクトです。そこで、以下のような、UISplitViewControllerクラスを継承したMyRootViewControllerクラスを定義します。そして、メソッドにはsupportedInterfaceOrientationsだけを定義すれば良いでしょう。returnの後のenum型の値が、すべての方向のビット値が1に設定されたものです。返り値がIntなので、rawValueプロパティを使ったり、Int型に変換するなど、Swiftではちょっとややこしいですね。

shot9900

そして、ストーリーボードのUISplitViewControllerクラスのオブジェクトを選択します。右側のユーティリティエリア上部では左から3つ目のアイコンを選択して、アイデンティティインスペクタを表示して、Classのところで、前の図にあるMyRootViewControllerを選択します。

shot9901

こうしておけば、Master-Detail Applicationで作ったプロジェクトでも、iPhoneでUpside Downの方向でも回転ができるようになります。もちろん、プロジェクトのDeployment Infoの設定にあるDevice Orientationのチェックボックスは4つともオンにしておく必要があります。