• ログインログイン
  • 新規登録新規登録

MENU

「UIKitを使いこなそう(iOS7編)」 ーiOSアプリの正しいユーザインターフェイス構築のためにー(1)

連載UIKitを使いこなそう(iOS7編)

iOSアプリ作りの必修科目ともいえるUIKit。ゲームアプリにせよユーティリティーにせよユーザに対してわかりやすい操作性をキープするため、Xcodeを用いてユーザーインターフェースを勉強していきましょう。

第1回 「導入編」

■ UIKitはiOSアプリ作りの必修科目

iOSアプリ作りはプログラマに多くの夢を与えてくれるとても楽しい作業です。個人での制作であっても、世界中のiOSユーザに対して未知の体験やサービスを提供できる可能性を秘めており、大変魅力ある分野だと思います。その魅力に気づいた人は手持ちのMacintoshにXcodeをインストールして、既にアプリ作りに夢中になっていることでしょう。もしこれから作りたいという方がいらしたら、是非エンジニアインターンの「初めての言語がObjective-Cでも大丈夫! Xcode5ではじめてのiOS7プログラミング」をご覧になってください。

さて既に何本かのiOSアプリを作ってみた方、どんな画面デザインにされましたか? ゲームアプリにせよユーティリティーにせよユーザに対してわかりやすい操作性をキープするためにいろんな工夫をされたことと思います。先ほど未知の体験と言いましたが、この分野ではまだ誰も味わったことのない操作感をユーザに提供できるかもしれません。なんといってもまだスマホ自体の歴史が浅いのです。

でもいくら未知の体験と言っても、あまりにもユニーク過ぎる画面構成にしてしまうと、ユーザは操作方法がわからなくて大いに戸惑い、思い通りの結果が得られず、App Storeのレビュー欄で不満を表明するかもしれません。そうなってしまってはアプリの評価がガタ落ちになり、その後誰もダウンロードしてくれなくなります。

実はApple社はそういったアプリが巷にあふれずに済むように仕掛けを作ってくれています。統合開発環境の「Xcode」で普通にアプリを作り始めると、自然にUIKitというフレームワークのもとでわかりやすいユーザインターフェイスが構築されるようになっているのです。ですからユニークさを追求し過ぎずに素直にアプリを作っていけば大丈夫なのです。

しかし開発者の中には当然アーティスト肌の人がいて、ユーザインターフェイスに個性、独自性を求めたいということもあるでしょう。ただしその個性をユーザインターフェイスに求めることには大きなリスクが潜んでいます。多くの一般の人にとってのわかりやすいインターフェイスというのは膨大なユーザテストの中から統計的に導かれるものであって、アートの精神から導かれるものではないからです。ほとんどの場合使いやすいから感動する、のではなく、あまりにも自然に使えてインターフェイスの存在にすら気づかない、というのがユーザインターフェイスデザインの目指すべきゴールなのです。ここにはアートの精神は入りづらいわけです。もちろん自らの存在を隠すアート、というのも存在するとは思いますが。

そんなわけで、良いユーザインターフェイスのために、おそらく膨大なユーザテストをしているはずのApple社が用意したUIKitの上でアプリを作っていきましょう。UIKitの「UI」はユーザインターフェイスの頭文字です。そしてUIkitはiOS7の多くの機能の中でユーザが直接触れる部分を開発するための重要なフレームワークなのです。

なお、Apple社の研究成果として、一般のアプリ開発者に公開されている「iOSヒューマンインターフェイスガイドライン」があります。これはiOSアプリデザイナーとプログラマにとってのバイブルとも言えるような資料です。iOS機器に限らず一般的なタッチデバイスにも汎用的に利用できるノウハウが満載されていて、これを利用しない手はありません。是非目を通してみてください。

iOSヒューマンインターフェイスガイドライン

UIKitそのものが到達点ではなく、Apple社としてはユーザの満足度を向上させるためにインターフェイスガイドラインを作成し、そこから逆算してUIKitを構築しているはずです。つまりユーザインターフェイスのことで迷ったらこのガイドラインに答えが書いてある、と考えれば良いわけです。

■ 全てはストーリーボード上に

ではUIKit練習用にプロジェクトを新規作成しましょう。まずはテンプレート選びです。

 新規プロジェクト作成時のテンプレート選択画面 図. 新規プロジェクト作成時のテンプレート選択画面。「Single View Application」を選択。

ここでのポイントはSingle View Applicationを選択することです。UIKitの基礎を学ぶにはこれが一番です。他にMaster-Detail Application、Page-Based Application、Tabbed ApplicationなどでもUIKitの様々な機能を使うことができます。ステップアップの目標にしましょう。

プロジェクトナビゲータ画面 図. プロジェクトナビゲータ画面。Main.storyboardファイルが自動生成されている。

プロジェクトナビゲータ画面で大事なのが、Main.storyboardです。プロジェクト設定のGenaralタブ画面を見ると、デフォルトでMain.storyboardファイルを用いてユーザインターフェイスを構築する設定になっています。

プロジェクト設定のGeneralタブ画面

図. プロジェクト設定のGeneralタブ画面。Main InterfaceでMain.storyboardが選択されている。

このMain.storyboard自体がUIStoryboardクラスに関連したファイル、つまりUIKitフレームワークの部品になっています。クラス名がUI〜のものはUIKitフレームワークの中で定義されているのです。ではこのStoryboardファイルを見てみましょう。

ストーリーボード画面 図. ストーリーボード画面。デフォルトで一枚のView Controllerとその上に一枚のViewが配置されている。

Storyboard画面には一枚のView Controllerがあります。これはUIViewControllerクラスに関連した部品です。さらにUIViewController上には必ず最低1つのViewというUIViewクラスの部品が乗っています。

上図の左側の部分をドキュメント・アウトラインといいますが、このドキュメント・アウトラインでは、パーツの重なりが上下逆になっているので注意が必要です。現在はベースになっている部分がView Controller(UIViewControllerパーツ)、その上にView(UIViewパーツ)が乗っている状態、と考えれば良いでしょう。

ここまでに「UIStoryboard」「UIViewController」「UIView」といったUI〜のクラス名が出てきましたが、その他にもプロジェクトナビゲータからAppDelegate.hを見てみると、「UIResponder」「UIApplicationDelegate」「UIWindow」といったキーワードがどんどん出てきます。つまりここまでSingle View Applicationで作業を進めていくと自然にUIKitを駆使していることになるのです。

さて、いっぺんにたくさん覚えるのは大変ですよね。ではUIKitのどのクラスから調べていけばいいのでしょうか。ヒントはObject libraryにあります。

画面右下がオブジェクト・ライブラリ。一つ選択するとそのクラス名と機能の簡単な説明が表示される

図. 画面右下がオブジェクト・ライブラリ。一つ選択するとそのクラス名と機能の簡単な説明が表示される。

ここには主にUIkitのパーツが並んでいます。この中の一つを選択すると、そのクラス名と簡単な説明が表示されます。View ControllerはUIViewControllerクラスのパーツだというのがわかります。そしてこのObject Libraryの一覧では、UIKitの中でも主にUIViewクラスのサブクラスのパーツがピックアップされています。まずはこのUIViewクラスのサブクラス群から取り掛かりましょう。

ではUIViewクラスのサブクラス群で全体ではどのくらいあるのでしょう。さらにUIKitの全体像はどのようになっているのでしょうか。ここでは素晴らしいサイトがあるので紹介しておきます。

iOS アプリの画面開発の基礎を理解する – A Day In The Life

この記事を読むとUIKitの主要クラスについて、全体イメージを理解できるようになると思います。さらに中盤以降の「ビューの種類」の箇所でUIViewサブクラス一覧が紹介されていますが、機能ごとに分類されておりとてもわかりやすくなっています。ここをしっかり見て全体を把握しておきましょう。

もしUIkitのクラス全てを把握したくなったら、Apple社の公式ドキュメントを見ておきましょう。

UIKit Framework Reference: Introdunction

このページの下半分がUIKitの全クラスを階層構造で示した図になっています。かなりのクラスがありますね。この階層構造はクラスの継承関係を表しています。例えば「UIButton」クラスは、

NSObject → UIResponder → UIView → UIControl → UIButton

という継承をしているわけです。NSObjectはObjective-Cのルートクラスです。UIButtonは上位4つすべてのクラスの属性を引き継いでいます。つまり、UIViewクラスの機能を知ると、その下に沢山ぶら下がっているサブクラスでもその機能が使えることがわかり、クラスの理解が進みます。

この連載では今後これらのUI〜クラスを一つずつ紹介していきたいと思います。

まずは次回、「UILabel」クラスです。文字列を表示する単純な機能を持ったクラスですが、ここでは文字表示についてしっかり学んでいきましょう。

■ 付録その1:名著「UIKit詳解リファレンス」について

数年前からiOSアプリを開発している人にとっては、UIKitの参考書といえば「iPhoneプログラミングUIKit詳解リファレンス」でしょう。

iPhoneプログラミングUIKit詳解リファレン

iPhoneプログラミングUIKit詳解リファレンス

この書籍は当時限られた英語情報しか手に入らなかった日本人プログラマにとって、救世主とも呼べるような素晴らしいリファレンスでした。網羅性が高く、困った時のUIKit詳解リファレンス頼み、という使い方がされていたようです。Amazonレビューでも非常に高い評価がなされています。

現在ではバージョンが古くなり、特にiOS7になってUIKitが大幅に変わったので、この書籍通りには行かない部分も増えてきました。しかし今でもその大半は有用であり、余裕があれば是非手元においておきたい名著です。ただし初心者の場合、バージョンの違いを自力で吸収できない場合もあるので注意が必要です。

■ 付録その2:Storyboardを使うか否か?

ところでこの「iPhoneプログラミングUIKit詳解リファレンス」を読んでいくと最初の方で衝撃を受ける提案がなされます。「Interface Builderと決別する」と宣言されてしまいます。Interface BuilderはStoryboard機能が搭載される以前の唯一のインターフェイス構築GUIツールだったのですが、著者の所友太氏は、UIKitを極めるにはこの便利なGUIツールを一切使わずすべてをコードで記述すべきだ、とおっしゃいます。当時Objective-Cド初心者だった筆者は少なからず衝撃を受け、それでも頑張って氏のおっしゃる通りプロジェクトからInterface Builderのすべての要素を排除して初めてのApp Storeアプリを構築したのです。書籍の詳細な記述のおかげでUIKitの良い勉強になりましたし、困った時には何度も助けられました。でもやはり大変でした。初心者にとってはやはりGUIツールは画面構築を直感的に行える強い味方なのです。

ただし、UIKitの詳細を知るには、すべてをコードで記述する方法を知っておかないと、特に細かいトラブルには対処できないと思います。販売できるレベルのアプリを作るには、GUIツールなしでもUIKitパーツを生成できる技術が必要です。そういう意味でこの書籍は中級者以上の必携の良書なのです。

さて、時代は既にiOS7です。今回はやはり進化したStoryboardを大前提としてUI構築法をご紹介しようと思い立ちました。が、やはり尊敬する所氏の主張も頭の片隅に残っています。

そして熟慮の末、今回はStoryboardフル活用で行くことにしました。理由として

  • Storyboard自体が進化している。
  • 単純にソースコードを書く量が減らせる。
  • 今後iOS機器の新製品がいきなり出ても、アプリ側が修正が少なくて済む。
  • 今後デザイナーのXcode利用が進みプログラマとの分業が明確になっていく。

などが挙げられます。

前回のiOS7へのアップデートでUIが大幅に変わり、すべてコードで記述されていたプログラムは大幅修正を余儀なくされました。こんな大幅なUIの変更は今後10年くらいないかもしれませんが、それでも画面サイズや縦横比の全く異なるデバイスがいつ新たに出現するかわからないのがAppleです。なかなか事前情報が手に入らず、新製品への対応は大変です。OSアップデートならば開発者は数カ月前からベータバージョンを入手してテストできますが、ハードウェアの新製品の場合は突然の発表なので、対応の緊急性が高く大変な作業になってしまいます。こういう場合はStoryboardでUIを管理していた方がはるかに楽になるはずです。特にAuto Layout機能をうまく利用すればほとんど手直しなしでいけるはずです(やや理想論ですが)。

でもStoryboardの全面活用はまだ開発現場でそれほど浸透していないようです。プログラマはみんなコードで画面を作るのが大好きです。すべてコードで表現できるからです。バグがあってもそれらはすべてコードの中に埋め込まれている、操作ミスが原因であることはない、GUIツールの不具合を考慮しなくて良い、ソースコードにすべてが書かれている、実に潔い世界です。こういう世界はプログラマに好まれます。ソースコードはバージョン管理システムとの相性もバッチリです。したがってGUIツールがかなり便利になっても利用がなかなか進まないのです。

そんな状況の中、筆者は著者の所氏に直接質問するチャンスを得ました。所氏は現在クックパッドのプログラマとして活躍されています。

「所さんはStoryboardは使われないのですか?」

「いや、Storyboardは大変合理的なツールだと思います。」

「えっ! そうですか! アプリ制作の現場ではあまり利用が進んでいないようですが。」

「そうですね。みんなコードで書きたがりますね。でも私は社内では利用推進派です。」

「それは素晴らしい! 職場で利用が広がるよう、応援してます!」

なんか我が意を得たり、その道の大家からお墨付きをもらったぞ、みたいな感じでちょっと興奮してしまいました。お恥ずかしい限りです。

そんなわけで名著「iPhoneプログラミングUIKit詳解リファレンス」の著者もお薦めするStoryboard、皆さんも迷わず是非フル活用していって下さい。

付録が長くなってしまいました。それでは所さんが「iOS7版UIKit詳解リファレンス」を出版されることを切に願いつつ(きっと出るに違いない!)、今回はここまでとさせていただきます。次回をお楽しみに。

オススメ記事一覧

もっと見る
完全無料!

1で登録完了!

エンジニアの仕事・年収や選考ノウハウ記事が読めるほか、
会員にはプログラミング講習やES・面接対策などリアルな無料サポートも充実。
ここだけの求人情報も多数。

今すぐ新規会員登録
Page Top