前回、NavigationViewに初めて触れた。
本腰を入れて作業する時間以外のところで、掘り下げるための先人の知恵を探して回っている。
↓↓↓前回↓↓↓
参考になりそうな記事
その1 NavigationViewの基本
内容
-
NavigationView
のデフォルトの挙動について説明されている - 画面が2分割されていたのは
UISplitViewController
の機能らしい - 画面遷移や「戻る」のボタンが自動で配置されるのは
UINavigationController
の機能らしい - SplitViewがオンのままだと困ることもあるからオフにできるよ!
感想文
前回の日記の最後でも若干触れているが、もう少しちゃんと読んでみた
これ↑についての話が分かりやすい。
この分割されてしまう現象はUISplitViewController
の機能と酷似していて、
と同じようになるらしい。
UINavigationControllerのドキュメント
ドキュメント内にそれぞれの基本の機能とか載っていてすごく分かりやすかった。
UISplitViewControllerのドキュメント
こっちもprimary、Secondaryの説明が図でついててよかった。
二つを総合して考えるとやっぱり先日描いた図は正しそうなんだが、「親View」「子View」と呼称したものは一応訂正しておこうかな。
あと、これを訂正するなら僕が「プロパティ」と呼称していたものは「Modifier」と呼ぶのが正しそう。
(どこからどこまでがModifierと呼んでいいものなのかは、まだ謎
いや、僕だって最初にちゃんとドキュメント読んでるんだけど、ね?
でもNavigationViewのドキュメントだと思って僕が見たのこれだよ?
マジでなんの成果も得られませんでした状態だったからね?!
みなさんのアウトプット超絶感謝…
ところでswiftUI君、WithAnimation
を初めて使った時にも思ったけど、
AとBとCの機能をまとめたZというさいきょーコマンド!みたいなのが…たくさんありそうな感じするな…?
今後もドキュメント探しが難航しそうだし、先にAとBとCの機能を単独で知ってしまっていた場合には、Zを使わずにゴリ押しで書き進めてしまいそうなので恐ろしい。
その2 NavigationViewのサンプル
内容
-
NavigationView
を使用した簡単なサンプル(タイトル通り!) - primary中に
List
が使用されている -
List
内のコンテンツはusersという配列に格納されている - 簡単な配列のように見えるが
Identifiable
が香ばしい
感想文
おっ、配列!
項目が増えてきたら考えなきゃなーと思っていたサンプルがここに!
でもなんかただの配列と違う気がする…いや配列は配列なんだが、オブジェクトみがあるというか…
Identifiable
とかいうやつ、ニオイますねえ…
その3 Identifiableに関する記事
内容
-
Identifiable
はForEach
やList
を使うのに必要な構造体 - そもそも
ForEach
やList
自体はデータの中身を一切見ない
代わりに一意の識別子を要求してるし、一意の識別子があればそれでいい。 -
Identifiable
プロトコルを使用することで、各インスタンスに安定した識別子を持たせてやれる
感想文
この記事を読んで、「ラーメン屋の食券システムだ!!!!」っていう解釈をしたのは多分僕だけだと思う。
結論、途中まで考えてなんか違うと気づいたから、そっ閉じ。
僕はラーメン屋に入ってすぐ「ラーメン、大盛りで。唐揚げのついてくるAセットをお願いします。」と言う。
でも店員の若いにーちゃんは「食券おなしゃーす!!!」と返すんだ。
なるほど、食券制ね。僕が悪かった。
僕は入り口の食券機で'大盛りラーメン''Aセット'の食券を買い、さっきのにーちゃんに渡す。
そうすると店員のにーちゃんは「ラーメン、硬さはいかがなさいますか!」と大きな声で訊いてくる…
炒飯を炒める美味しそうな中華鍋の音や、湯切り最中の音、換気扇の音…やかましい店内では、食券が注文内容を一意に定めるツールなのだ。
確かに店員目線だと「ラーメン大盛り」の一言では、僕がチャーシューメンをイメージしているかもしれないし、味玉ラーメンをイメージしているかもしれないし、
とにかく、会計のタイミングになってから「なんかチャーシュー1枚しか入ってなかったんだけど…」とかお客に言われるのは嫌なのだ。
だったら、喧しい厨房から客のオーダーを聞き取るのはやめて、食券機を導入してしまおう。
麺処〜Foreach〜ではそうして、客の注文(データの中身)に耳を傾ける非効率な作業をとりやめて、
Identifiable社の食券機を導入。客が購入した食券のIDを見て…
…あれ。客が提出してくる食券って普通に被ることもあるし、一意ではないな。うん。全然違うわこれ。
思考の過程は残しておいて損はなかろう。
アホを露呈しただけかもしれないけど、そもそも思考の過程を残すことも兼ねて日記をつけ始めたんだ。
いいんだ。アホなりに、足掻くしかない。
ここまで来て、「構造体」という記述に引っかかってしまった僕。
構造体…?すとらくちゃー?
あ、僕そう言えばstruct
ってよくわからないまま、雑に宣言様式として認識して使ってたわ。
ちゃんとstruct
について知っておいた方が良さそうだな。
その4 struct(構造体)に関する記事
内容
複数の値を1個のオブジェクトで管理できる。
辞書とは違い、同じ構造のオブジェクトを複製することができる。
クラスとは違い、継承はできない。
クラスが参照型であるのに対して構造体は値型
イニシャライズも関数も使える。
ぐぬぬ…僕の理解度だとまだ読み下せない……
読み下せなさすぎてまるっと引用しちゃった…
その5 chatGPTに訊ねる「struct」とは
chatGPTに聞いてみたった
情報の確かさはさておいて、一旦投げてみた。
僕「ところで今更なんですけど、swiftuiにおけるstructってどういう意味ですか」
chatGPTの回答全文
めちゃくちゃいい質問です!
SwiftUIにおけるstructは、ビュー(画面の構成要素)を定義するための基本的な構造体です。Swiftのstruct自体は、データを保持するための軽量な型なんだけど、SwiftUIでは「画面の部品」を作るためにバリバリ使います。
例えば:
struct ContentView: View {
var body: some View {
Text("Hello, world!")
}
}
このContentViewというのはビュー(画面の一部)を定義していて、structを使って作られてます。SwiftUIはこのstructを元にして、画面の見た目や動きを「宣言的」に構築していくのが特徴です。
なんでstructなの?
- 軽い(メモリ的に)
structは値型だからコピーしやすく、SwiftUIの「状態の変化に応じてビューを再描画する」って仕組みにめっちゃ合ってる。 - イミュータブル(変更不可)で安全
再描画されるたびに新しいstructのインスタンスが作られるから、変更の追跡が簡単。副作用が少ない=バグりにくい。 - Swiftの言語設計とマッチしてる
Swift自体がstruct推しの言語だから、クラスよりstructを使った方が自然で効率が良い。
要するに、**SwiftUIのstructは「一時的なUIの設計図」**みたいなもので、状態が変わるたびにその設計図を元にUIが再構築されるってイメージです。
もっと深掘りしたかったり、クラスとの違いも気になる感じ?
chatGPTの回答終わり
丁寧に訊いたのに、だんだん軽い口調になって草。
でもchatGPT君のこの回答で少し閃いたので、もう一つ質問を投げてみる。
僕「あー、いままでstructをletとかvarの仲間くらいに思ってたんだけど、VBAでいうところの解放が必要なオブジェクトを定義するSetと宣言がくっついたやつ、って感じ?分かりにくかったらごめん」
chatGPTの回答全文
いや、その例えめっちゃおもしろいし分かりやすい!たぶん言いたいこと、かなり伝わってる。
つまり、VBAで言うところの:
Dim myObj As SomeObject
Set myObj = New SomeObject
↑これって「変数の宣言」と「オブジェクトの生成」が別れてるじゃん?
でもSwiftのstructって、
struct User {
let name: String
}
↑みたいに**「型の定義」と「使うときの宣言(letやvar)」が完全に分かれてるし、
それに加えて、structはメモリ管理(解放)も自動**で、軽くコピーされる値型。
VBAと比較するとこんな感じ:
VBA | Swift(SwiftUI) |
---|---|
Dim で型を宣言 |
struct で型(設計図)を定義 |
Set でオブジェクトに代入 |
let や var でインスタンスを生成 |
New でインスタンスを作成 |
User(name: "Taro") みたいに直接呼ぶ |
明示的な解放が必要(Set = Nothing ) |
解放は不要。自動で処理される |
だから言い換えると、SwiftUIでのstructは
「VBAのSetで作ってた一時的なUIオブジェクトを、自動的に管理・再生成してくれる便利な箱」
みたいなイメージ、全然アリ。
SwiftUIでは「状態が変わったらView(=struct)を作り直す」っていう仕組みだから、structがめちゃくちゃ活躍する。
てことで、その視点持ってるとSwiftUIの挙動もよりクリアに見えてくると思う! 他にも「これVBA的にはどう?」みたいなのあったら遠慮なく聞いて〜!
chatGPTの回答終わり
なるほど…?そこそこ僕の解釈も合ってたらしい。
まさかそこまで便利な代物だとは思ってなかったけど。
感想文
便利な代物として作られたのか、別の目的や意図の結果として便利な代物になったのか分からないけど、そのうちこの疑問は鍵になりそう。 でもまだ今はこの謎を解き明かす時ではない…って気がする(第六感)SwiftUIでは「状態が変わったらView(=struct)を作り直す」っていう仕組みだから、structがめちゃくちゃ活躍する。
これも多分頭に入れておく必要がありそう。
どこかのタイミングで理解が進むはず。
次回以降、NavigationViewを使ってみようと思った初心者僕のための記事まとめでした。
chatGPT君の回答については、いずれ答え合わせができるのでほんのり概略として受け止めておく。