【じっくりSw1ftUI68】実践（DB）編38〜第50章 SwiftUI Core DataとCloudKitストレージの概要
さてと、前回
で、
CoreDataの実践例
までは、約３週間かけてやったので、今回は
SwiftUI Core DataとCloudKitストレージの概要
を学んでく🕺ここ最近の傾向として、
概要
とつく章は、
操作なしで解説のみ
＝眠くなる🥱
と
大体、相場は決まってる🤣
ので、サクサクやっちゃってこう🕺
実は、去年
なんかで個人的には、やってんだけど、
ジュンク堂や丸善なんかで並んでる市販本
は数年単位で古い版の本が多く、
CloudKit👈今回からやる
SwiftData👈２章くらい後から出てくる
は載っていないところなので〜〜〜
今回もじっくりやってく🕺ま、大学とかで専門でやってるところでは、やってるかもしれないけど、
以降の導入編で書いたかもしれないけど、
オープンソース＝民主化されたテクノロジーを使って、
自分の作りたいアプリをサクッと作って、AppStoreに公開したい
だけな人が、
わざわざそのために、学校に通う＝コスパ悪過ぎ
👉そもそもオープンソースの理念に反してないか？
ってのがあるからね🧐ま、この国は最新の技術の理念が理解できず、
テクノロジー＝自分達のお金儲けの道具
としてしか見なしてないからね🧐
🙅オープンソース
＝お金が掛かると思っちゃだめ🙅♂️
オイラの今までの記事を見てもわかると思うけど、
知らない
だけで、知れば全然難しいコードやややこしい操作なんかをせずに、案外簡単なコードや操作で機能的にはアプリが作れることがわかると思う。
UIKitで開発したい人向けのマガジン
も含めてね。
知らないだけで、知れば誰でも
簡単にある程度の作りたいアプリが作れる
👉テクノロジーの民主化
だからね。
この程度の技能を身につけるのに、まずは触れもせずに、
学校に行かないといけない
って即断即決するのは、
完全に、ただの思い込みとか洗脳
余計なお金をかける前に、
まずはじっくり動かしながら触れてみよう
👉学校やオンラインスクールなんて
それでも必要であれば行けばいい
だけの話🕺
さてと、今回もオイラの学びなんざ関係ないって人は、
に全部載ってそうだから、そっち見れば良いんじゃね👀💦ま、いつまでアクセスできるか知らないけどね🤣
んだば、今回も
じっくり第50章を読んでく👓
（いよいよ残り19章くらいだねえ🧐）
概要としては、
まずCloudKitは、iCloud ストレージを使ったクラウドデータベースに、全ての端末や、ユーザー、アプリからのアクセスを可能にして、アプリ上のデータを格納する機能を提供してるってゆーてんね👀で、最初に
CoreDataと連携してデータベースを作成・管理する
CloudKitフレームワークを宣言して利用する必要がある
みたいなことが書いてんね🌱で、この章では、
CloudKitを作り上げるハイレベルな紹介と、
それに対応させるCoreDataも説明する
みたいなことが書いてる👓
👉すでに、概要だけな予感で、眠くなりそう😛
CloudKitってそもそも何？
Appleによって設けられた、格納、管理、取得やDBの構築を簡単にできるようにiCloudサーバーにアクセスする機能を提供するフレームワーク
みたいなことが書いてんね👀
具体的には、
バイナリファイルやビデオ、画像なんかも取り扱える。
ユーザーがプライベートなデータを格納するプラットフォームを提供していて、様々な端末からアクセスもできる。
開発者はやろうと思えば、そのデータを全てのユーザーがアクセスできるようにも公開もできる。
ってのが特徴みたいだね。
ここでポイント①：CoreDataとの大きな違い
CoreData：App自体に、データモデルを構築して、そのデータモデルにアクセスして、データの作成・取得・更新・削除する（CRUD）。👉Cloud上にない。
CloudKit：Appleが提供するiCloudてゆークラウドサーバー上にDBを構築してそこにアクセスして、データの作成・取得・更新・削除する（CRUD）。👉Cloud上にある。
てことみたいだね。
そら、クラウド上にないんだから、CoreDataだけだと、他のユーザーとデータを共有するなんてできないだろうし、もしそれができたら逆に、CloudKitの違いも無くなる。さらに個人情報なんてあってないようなものになるよねえ🧐ここまで読んだだけでも、
オイラは基本、CoreDataでいいかな
って感じかな🧐Storageサービスで全会員の情報をまとめたいみたいなアカウント情報を取り扱うアプリなんかを作りたいなら、CloudKitが良さそうな気もするけど、去年か一昨年だっけ？くらいから出てきたSwiftDataでどんなことが出来るかを知ってから、自分が作りたいアプリにどの
データベースフレームワークを追加するかは、
決めればいいかなあ
くらいにしか思ってないな🧐別に一時的な（例えば、クイズの集計を出す）データなんて、
UserDefault
で賄えたりもするから、前回の結果、前々回の結果なんかを残しておかなくてよければ、データモデルを追加してCoreDataフレームワークを追加することさえしなくていい場合も多いし、、、。要は、
作りたいアプリの目的と
組み込みたい機能（要件定義）による
だけだからね👀💦ま、こーゆーところで、最低限のフレームワークの基礎と実践くらいに触れる＝i0S17版のSwiftUIでできることを俯瞰することが大事ってことは分かると思う。
俯瞰もせずに、自分が使ってる本ではCoreDataしか載っていない
→モバイルデータベースは、CoreDataしか使えないと思い込む
→お客さんからアカウント情報をクラウド上で管理したいて要求があった
→そんなことはiOSだと出来ないと突っぱねるか機能選定を間違えて、一生懸命CoreDataでやろうとする
みたいなことになりかねないからねえ🧐
実際、日本の古い市販本しか知らずに、未だにUIKitを最新と思い込んでたり、Swiftは大したことができないとか豪語してる企業は多いし（昨春の就活で面談した企業で実体験済み。）
それも原因としては、
情報が少ない＋機能選定の段階で間違えてる
👉ちゃんと俯瞰的な理解が出来てないだけ
なんだけどね👀💦さてと、本題に戻って〜〜〜
CloudKitを学ぶ最初のステップ
まずは、
キーコンポーネントであること
実運用では、CoreDataと一緒に使うこと
を理解しようって書いてんね👀
CloudKitもCoreDataで用意した永続コンテナをCloudKitのエコシステム上で利用できる
ってことが非常に重要みたいで、
この知識がなくても、CloudKitの利用できなくはない。
CloudKitの高度な活用やサブスクリプションなんかで連携する時に非常に、CloudKitの基本理解が重要になってくる
みたいなことを書いてんね👀
CloudKitコンテナ
CloudKitを利用する上で、iCloud上に少なくともコンテナがひとつは必要（そらそうとしか思えないヤツ😛）。
CloudKit上にCKContainerクラスを設けないといけない。
そのコンテナが各アプリ間でデータを連携する。
CoreDataと連携する場合は、そのコンテナがオブジェクト管理モデルの役割を果たす。
ってことが書いてんね。
パブリック
全てのユーザーがアクセスして使えるデータベースとしても活用できる。
例えば、パブリックコンテナを利用して、地図アプリで、現在位置とそこの経路を他のユーザーを示す感じ。
プライベート
プライベートコンテナを利用して、各ユーザーが各ユーザーだけが使えるデータを格納管理できる。
ストレージの割り当て
パブリックでのデータと資格情報は、アプリのストレージ引用領域に格納
プライベートだと、ユーザーによって、ストレージ引用領域に対応👉ユーザーが不必要なストレージスペースを購入せずに、最小限の容量にする試行が必要
各アプリケーションに、1PBが無料で割り当てられているので、気にする必要性は低い。
CloudKitのレコード
パブリックかプライベートかに依らず、
CKRecordクラスに、
ディクショナリ型のレコードとして、
データは格納される
みたいな感じで書いてんね👀💦
CoreDataと連携したCloudKitを経由したデータは、
CoreDataモデルオブジェクトとしても管理できる
各レコードのID
CKRecordIDクラスで管理される
各レコードにIDが振られる
CloudKitリファレンス
データベース上の異なる各レコードの相関関係（リレーションシップ）は、CKReferenceクラスで構築できる。
レコード生成と各ターゲットを紐つけるリレーションシップを設けるため、CKReferenceインスタンスを作る。
CKReferenceオブジェクトは、キーと値のペアで構成される。
ひとつのレコードは、その他に対して、複数のリファレンスを有する。
ひとつが更新とか変更されたら、各ターゲットとして紐ついた他のレコードも更新・変更される
👉まあ、DBの基本的なリレーションシップと同じだね👀💦
レコード領域
プライベートでは、各レコードグループのリレーションのために、CKRecordZoneメカニズムを提供。
CKRecordZoneメカニズムなしだと、各レコードは初期設定された領域に格納される。
複数領域のレコードを同時に連携させるように、カスタム領域を設けられる。
CKRecordZoneIDで各レコードは、一意レコードとして、管理される。
パブリックの全てのレコードは、パブリックの初期領域とみなされる。
CoreDataの永続コンテナは、CloudKitのレコード領域として活用される。
前章でやったCoreDataの永続コンテナは、NSPersistentContainerインスタンスとして作成される。
CloudKitと連携したCoreDataは、その代わりに、NSPersistentCloudKitContainer クラスを使う。
CloudKitと連携したCoreDataコードを変更する場合、NSPersistentContainer を NSPersistentCloudKitContainer に置き換えるだけ済む。
CloudKitコンソール
・Appleが提供する下記URLからコンソールにアクセスして利用・管理。
・Xcodeの＜署名と機能＞画面からも利用できる。
ダッシュボードにアクセスするには、有効な Apple 開発者ログインとパスワードが必要。
ブラウザ ウィンドウに読み込まれると、チーム アカウントに関連付けられた CloudKit コンテナーへのアクセスが提供される。
1 つ以上のコンテナが作成されると、コンソールでは下記を行えるようになる。
データの表示
レコードの追加
更新
クエリ
削除
データベース スキーマの変更
サブスクリプションの表示
新しいセキュリティ ロールの構成
アプリケーションを App Store で公開する準備として、開発環境から本番環境にデータを移行するためのインターフェイスも提供される。
ログとテレメトリのオプションでは、1 秒あたりに実行される操作、平均データ要求サイズとエラー頻度、各トランザクションのログの詳細など、現在選択されているコンテナーによる CloudKit の使用状況の概要も提供。
CloudKit コンソールからデータにアクセスする場合、ダッシュボード インターフェースを使用してプライベート ユーザー データにアクセスできないので気をつける。
コンソールにログインするために使用した開発者アカウントに属するパブリック データベースとプライベート データベースに保存されているデータのみを表示・変更できる。
共有
CloudKit上のデータがプライベートの場合でも、sharing機能で他のユーザーと共有できる。
サブスクリプション
クラウド データベース内で変更が発生したときにユーザーに通知できる。
サブスクリプションは標準の iOS プッシュ通知インフラストラクチャで、
レコードの追加、更新、削除など、さまざまな基準のトリガーが設定できる。
通知は、述語を使って絞り込みもできる。
通知は、アラートやロック画面の通知エントリなどでユーザーに表示される。
まとめ
てな感じで、概念ばかりを一気に箇条書きで羅列したから、
かなり眠くなったけど🥱
要は、
CloudKitでクラウドサーバー上でデータ管理するから、
他のユーザーとのデータ連携やトリガーを使った通知なんかを設定できて、
よりWEBの旨みを活かしたアプリの構築ができる
ってことね🕺
ま、最近はどんな求人を見ていても、
CloudKitよりも
Laravel
でモバイルデータベース連携してる会社が多いなあと思ってるけど、ま、CloudKitは
Apple純正
だから、
SwiftUIとのユーティリティが確立されていて
使いやすいのかなあ🧐
って印象。触れた結果、不要かもしれないけど、
触れといて損はないよなあ🧐
と言いつつ、オイラは個人で趣味でアプリ開発をしたいだけだから、
そんなサブスクリプションでアカウント情報を管理するようなアプリをまず作りたいとは思わない。
👉個人情報の管理とかが大変だから。
個人レベルでお金目的でアプリ販売をやるなら、そんなところで余計な労力とかコストが大変（＝企業や組織が作ればいい）なアプリを作るより、
管理が簡単で、バグが少なく、
反社会性とか暴力要素のない
誰もが簡単に電車の待ち時間程度で使って、
また使おうって思うような
わかりやすいアプリを、AppStoreで有料アプリで公開した方がいい
と思うけどね🧐
あくまでも、個人でやるならば！
だけど。。。
企業とか実務で
アプリを使って、サブスクリプションまでゆくゆくは考えてるなら、CloudKitも有効な手段だから、知らないなら学んでおいて損はないんじゃない？
知らんけど🤣
SwiftUIと同じただのフレームワークだし笑😆
Apple公式
さてと、次回は
CloudKitの概要に触れたところで、実践例を紹介した
第51章 iOS 17 SwiftUI Core Data と CloudKit チュートリアル
を見てく🕺
記事公開後、
いつもはやってるけど、今回はXcodeすらほぼ開いてないので、今回も記事公開後の作業はなし😛
次回で実践例をやるけど、オイラのアプリでは特に使わんなあって感じなので、いつものまとめてるアプリには組み込まずに、プロジェクト単体での例だけに次回は止めるかな。
使わないものを無理に結合して、他に影響出て、それをわざわざ原因調査する時間の方が勿体無いし🤣
んだば、また次回〜〜〜〜