今回は、このところ眺めてみている iOS アプリ開発を意識したチップス集的な「同じような処理だけどこっちの方がいいよってやつ」の次の項目
レイアウト用の仮 View を使う
のところから読み進めていきますね。よろしくお願いします。————————————————————————————————————————
熊谷さんのやさしい Swift 勉強会 #291
00:00 開始
00:33 UILayoutGuide を使っていこう、という話
04:42 readableContentGuide もよく使われる
05:57 描画コストを削減可能
07:42 macOS は NSLayoutGuide
08:35 iOS と macOS は座標系が異なる
11:02 DOM (Document Object Model) と描画コスト
12:29 描画コストを気にするのは大切
13:52 UIBarButtonItem の多国語対応
16:21 システムが提供する選択肢を使うと効率的
18:20 用意されている systemItem
19:44 直接的な色ではなくシステム名を使う
20:06 色のダークモード対応も簡単に
20:40 名前を付けて使うの今どきの主流
23:34 AppKit と Cocoa
24:31 ところで _StringProcessing とは
25:54 独自の色名を定義するには
27:00 今回の所感と次回の展望
————————————————————————————————————————
Transcription & Summarize : 熊谷さんのやさしい Swift 勉強会 #291
では始めていきましょう。今日は引き続きブログのタイトルからで、こちらはiOSアプリを主に意識したTipsとなります。その中の今日のテーマは、「レイアウト用のUIViewを使う」というお話です。
例えば、レイアウト用のUIViewをインスタンス化して、バックグラウンドをクリア設定して、ImageViewのトップアンカーにレイアウトViewのトップアンカーを当ててアクティベートするという内容です。つまり、オートレイアウトをコードで書いたことがほとんどない場合、トップアンカーをImageViewに設定するのかといった点が少し分かりにくいかもしれませんが、最終的にはImageViewとレイアウトViewのトップアンカーを合わせるということになります。
これだけでは少し曖昧かもしれませんので、もう少し具体的に説明します。イメージビューに対してレイアウトビューを重ねて配置し、そのレイアウトビューを利用してUI要素を適切に配置するということです。具体的には、UI要素を配置するためにビューのアンカーやオートレイアウトガイドを活用することが推奨されています。
レイアウトガイドを使用することでビューの評価コストが高まることもなくなり、パフォーマンスも向上します。具体的には
UILayoutGuide
を作成して、必要なレイアウトに利用することができます。このガイドは、ビューと同じ四角い領域を持ちながら、ビューそのものを表示しないため、軽量で効率的です。アンカー設定のみで存在するため、UI要素を親ビューに直接配置する際のみに利用されます。オートレイアウトでよく利用されるのが、リータブルガイドです。例えば、幅が広い端末において、全画面を利用すると読みにくいので、幅を800ピクセルに制限したりする場合に便利です。このリータブルガイドを使うことで、簡単に好ましい配置が可能になります。
UIViewsを無理に活用するよりも、こうしたレイアウトガイドを使用することで、より効率的でわかりやすいレイアウト設定ができるようになります。また、昔話になりますが、iOS4の頃は白塗りのビューがあるほうが軽いと言われていましたが、現在もその経験は役立つポイントがありますね。 懐かしいですね。このレイアウトガイド、オートレイアウトならではの感じです。以前はオートリサイジングでしたね。そのときはビューを使わないとどうにもならなかった気がします。オートリサイジングは複雑で、うまくいかないことが多かったです。頑張ってFMを使いだしたんですよね。懐かしいですね。
このUIレイアウトガイドですが、iOS 9から導入されましたが、MacOSにはないんです。MacOSにはレイアウトガイドがないのは不思議ですよね。UIの合流もようやく最近ですね。微妙に違いがあったりします。レイアウトガイドの座標系はMSKの場合トップレフトですが、レイアウトガイドはトップレフトかボトムからです。UIもトップレフトなので、このあたりがうっかりすると混乱します。コアグラフィックを使っているときも、ややこしいことが起こりますね。座標系が統一されていれば良いのにと思います。
NSViewはバックグラウンドカラーが設定できなかったのでレイヤーを使って対応する必要がありましたね。いろいろと制約があったのを思い出します。でも、今は統一されていると良いですね。
NSレイアウトガイドですが、iOSはバージョン9から、macOSはバージョン10.11から使えるようになりました。バージョンが安定してきたので安心して使えるレベルですね。
JavaScriptのDOM(ドキュメントオブジェクトモデル)についても話しましたね。DOMで親ノードを持たないノードを作ることができますし、シェイプリングのようなノードをまとめて作る機能も便利です。これはドキュメントフラグメントを作って、それにノードを詰め込んでから最後に
appendChild
で実際に追加するやり方と似ていますね。評価コストを削減するためには、DOMの仕組みもよく考えられています。UIレイアウトも、例えば
addSubview
のときに評価コストがかかるなど注意が必要です。レイアウトガイドがあるなら、それを使えばいいでしょう。評価コストを考慮して追加するタイミングを遅らせるべきかどうかは一概には言えませんが、泣かないようにいろいろと努力する必要があります。UIレイアウトガイドを使うことで評価コストも気にせず使えるのはいいですね。既存のアンカーで済んでいるなら、それほど複雑なことはしていないかもしれませんが、恩恵を受けているのは確かです。 確かに、知っておくと便利かもしれないですね。次に進みましょうか。
とりあえず、
UIBarButtonItem
のラベルですね。UIBarButtonItem
、バーボタン、なるほど。バーボタンってどこで使うんでしたっけ。ナビゲーションバーですね。UIBarButtonItem
、ナビゲーションバーのボタンなどに使いますね。これのタイトルですかね。ラベルとタイトル、どちらが正しいかですが、タイトルのほうが正しいかもしれないです。とりあえず、
UIBarButtonItem
のタイトル、イメージ、プライマリアクション、メニューって感じで評価されるのかな。前にも言ったような気がしますが、この問題の幅広さには驚きますね。でも、知っている人ならすぐに答えられるのでしょうか。自分はまだピンとこないですが、
UIBarButtonItem
、プライマリアクション、メニュー、これは昔のストーリーボードでは使わなかった気がします。なんとなくですが。さて、システムアイテムを使うとローカライズが自動で行われます。こうした便利な機能は他にもありますね。例えば、既存のキーボードのエンターキーなどもそうです。どうカスタマイズするかは忘れちゃいましたけど、エンターキーも置き換えられるんですよね。そういった指定をするときには既存のものもカスタムも可能です。iOSのキーボードをいじっていた気がしますが、まあ、それはいいですね。
とにかく、システムが用意した既存のものを使うとローカライズが自動で行われ、その国に合わせた適切な表示がされます。このようなことはとても重要です。
文章はここまでですね。このようにすることで、一貫性が出ますし、翻訳が最近進んだおかげで、インターナショナリゼーションが進みました。アプリではグローバリゼーションと呼ばれたりしますが、このおかげで、変な日本語訳もそこまで気にならなくなりました。昔は違和感があって気になっていましたが、今では問題ないですね。
時々、変な日本語訳がありましたね。例えば、ブラウザの情報を更新するボタンのことです。昔、そこに「爽快」と表示されていて驚きました。リフレッシュをそう訳したのでしょうが、今ではそういったこともなくなりました。
今お話ししたように、システムが用意したものを使うと良い感じに表示されます。これが大事なんですね。
とりあえず、ここまでにします。次に進みましょう。次は、
UIColor
のホワイトやブラック、UIColorLabel
などについてです。これは変更したことがないですね。なかなか面白いですね。なるほど、まあ、いいでしょう。 確かに、今の状況では色の設定はないほうが自然な感じがしますね。UIカラーにはシステムで適されたものがいくつか存在していて、それによってダークモード対応やアクセシビリティにおけるハイコントラストなどが自動的に行われるのだと思います。最近ではダークモード対応などでアセット(たとえば
XCAssets
)を使うことが増えています。アセットにダークモード用の色を登録して名前を使うだけで、モードに合わせて適切な色に切り替えてくれる機能があります。こうして名前を先に付けてあげて使うことが推奨されています。これは昔からCSSなどでも行われてきた流儀で、カラーを名前で指定しておくことでサイトのリニューアルが簡単になり、統一感が保たれます。例えば、CSSでもあらかじめ色に名前を付けておくことで、テーマを変更する際に便利です。昔はカラーコードを検索して手動で書き換えることもありましたが、名前を付けておくことでそうした手間が省けます。システムに既に用意されているカラーを使うのも、ほぼ同じ感覚で便利です。
では、どんなカラーがあるのか気になってきますね。UIKit の他にも、macOSで使われる AppKit の
NSColor
や、アクセントカラーなどがあります。iOS4時代にはすでにテキストカラーなどが存在していたようですが、最近ではより多くの種類が増えてきています。例えば、アクセントカラーやポイントカラーはとても使いやすいです。また、
NSColor
は AppKit に定義されており、macOSを使用する際にも多くの color プリセットが利用できます。同時に、Foundation や Core Data なども含まれており、正則表現(Regular Expressions)もサポートされています。このように、システムが提供するカラーやその他の機能を活用するのは非常に便利です。さらに、独自の色を作りたい場合にはエクステンションを使って例えば以下のように定義することも多いです。
extension UIColor {
static let customColor = UIColor(red: 0.25, green: 0.5, blue: 0.75, alpha: 1.0)
}
こうすることで、アプリ全体で統一されたカラーを簡単に呼び出すことができます。基本的にはシステムが提供するものを使いましょうという話でした。田中亮我さんのブログにも同様のことが書かれていたかもしれません。
次回はシステムブルーについて話す予定です。今日はこれで終わりにします。お疲れ様でした。ありがとうございました。


