CloudKit: N から 1 のレコードを参照してみました
CloudKit で relation の定義の仕方がわかったので、今度は、N のテーブルから 1 のテーブルを参照する方法を試してみました。
Apple 謹製のドキュメントはすごく素性がよくて（当たり前？）、その通りに作ればその通りに動きました。ただ、これ、実装するとなるとかなりキツイね。理由は手順を追うとわかります。
- まず、N テーブルのレコードを query して recordID を特定。
- 次に、そのレコードに定義してある Referene 型のフィールドの値を得る。
- それを手掛かりとして、1 のレコードが定まるので、フィールドの値を得る。
正直、CloudKit 使わないで、自 server に仕組みを素で書くのと、手間は大して変わりません。以前 4D 使ってプログラム書いている時とは雲泥の差。なんか、Python を CGI としてプログラムするのと大差ない。いや、SQLite3 なら、フィールドに色々制約をつけられるので、恩恵を受けられるけれども、CloudKit はそんな仕組みがないので、その面では厄介か。なんでこんなこと言うかといえば、CoreData の素晴らしさはどこ行ったんですか？と言うことを確認したい。
で、さらに、サーバーとやりとりする都合、1 で block を使い、さらに、3 のために block を使うという、block の中に block を書く形になるので、変態的な code になってしまう関係上、こんな仕組みやめて自 server で書いちゃった方がむしろ判読性？可読性？メンテナンス性？は高いんじゃないかと思いました。
と言いつつも、自 server を建てるとなると、それなりに費用がかかりますので、そんなお金はない当方としては、これを使うしかないなぁと。
あと、まだよくわかんないけど、簡単に重複したレコードを作れちゃうのは、そうならないような配慮も自分でしないとならないからなのでしょうか。RDB なら普通にある機能なんだけど、自分で実装するとなると・・・きついね。
ふぅぅぅぅ。
さて、次は、マスターにデータを一括して登録するにはどうするのか・・・ファイルアップロードして一括登録したかったんだけど、仕組みが・・・ない？ アプリから作る感じなのかなぁ・・・
CloudKit で relation はどうやって定義するのか
CloudKit を使って、1 : N の relation はどうやって表現するのか、とりあえず、設計においてどうするのか、理解を深めるため、主に Apple の document を中心に熟読してみました。
CoreDate との比較になりますが、CloudKit の場合、N : N という CoreData で便利だった手法は使えません。変わって、1 : N ( : 1) の表現になるようです。relation を形容するための field type として、Reference 型というのが用意されています。これを果たして 1 と N でどちらに定義するものか悩ましかったんですが、Apple 謹製 document によると N 側に規定し、1 側のレコードを参照するのがよいとのことです。発展的には、1 : N : 1 の関係を規定した場合、Reference 型のフィールドは N のテーブル（Record Type）に、1 のテーブルそれぞれ分 2 つ定義することになります。RDB 屋としては、自然に理解できました。でも、CoreData を知ってしまった今は、ちょっと、懐古主義という言葉を思い出しました（一貫性がないと言いますか、ま、あまり深く考えず、そういうものだと理解しました）。
ついでながら、便利に思ったことも記載しますと、1 側のレコードを削除したら、N 側のレコードも芋づる式に削除可能だそうで、一貫性を保つための（最低限の）仕組みは用意されているようです。
後日談ですが、その恩恵を受けるにはレコード生成時にその指定を忘れるなと。action:CKReferenceActionNone はだめ。
document によると、Dashboard で指定ができると書いてあるけれども、よくよく読むと、それは 、1 レコードずつ指定する方法なので、実質意味がないぞと。
生成時には、action:CKReferenceActionDeleteSelf だと。
設計まででまだ実際に cording していませんので、試したらまた記載します。
CloudKit を使ってみた
アプリのユーザーが作ったデータを共有すると色々都合が良いので、BaaS はどれがいいのか調べていたら、Apple 謹製の CloudKit があった。ちょっと試してみたらかなり素直な印象。Apple の公式ドキュメントが一番使える印象。Objective-C で例示してあるのもいいね。
レコードの保存、Query まではうまくいきました。残り疑問点は、relation と データの削除。
relation はかなり難しそうね。
UITableView を配置すると、上部に謎の空白ができてしまう時の対処方法
いつの頃からか、UITableView を画面上に配置すると、謎の空白ができてしまう現象が発生。これ、見た目がすごく悪いので、解決方法がないのか色々調べたのですね。
結局のところ、StoryBoard で、UITableView の配置順を下げると解消するのですが、これが一番簡単な解決方法だと言うことが判明。adjust scroll view insets の適用は、海藻の一番上のオブジェyくとなので、UITableView が一番上にあると意図せずこれが効いてしまうので効かないように順位を下げる、と言う長い長い説明終了。
愛宕吾国ハイキング縦走コース
脚がだいぶ仕上がってきたので、12 月にも行ったコースを走ってきました。
今日は気温が低く快晴で風も少なく走りやすい。R1 フーディの上にウインドブレーカーで丁度良い感じ。R1 フーディは走っている間とても快適でした。満点です。
岩間駅から 0740 に走り始めて福原駅に着いたのが 1025 だったので、3 時間を切ってゴール。相変わらず登りがきつすぎで走るのが困難。コースは 12 月に走ったのを随分覚えていて、地図なしでいけました。
次に行く時に備えて、2 つほど。1 つは、初めの展望台への登り斜面は、ぬかるんでいて滑りやすい。これは 12 月もそうだったのだけれど、ここのところ雨も降っていないと思うのになぜかぬるぬるで、転びそうになりました。「切り通し」（高尾山では「巻道」と言うが・・・）の矢印はないけれども、回り込んで走ったほうが安全か。
2 つ目は、吾国山を下山して、一般道に出て、前回 lost してしまったところ、今回は矢印を見落としませんでした。歩道を走っていると、つい、そのまま行ってしまいますが、左に矢印があり、車道を横切って曲がります。丁度カーブのところなので、何となく行ってみたい感じの道だから、次回はもう見落とさないだろう。
今回、タイムは良かったんですが、駅に着いたら、丁度、5 分前に電車が行ってしまい、30 分ほど待つことに・・・待っている間、汗を吸っている R1 は寒かったですね。
前回は宍戸駅前の踏切が工事中で遠回りして「いこいの家はなさと」に行ったのですが、今回は工事も終わっていて、普通にいけました。1.8km ほどなので、クールダウンには丁度よい距離でしょう。はなさとの食堂は美味しいものが多いと思いました。今回はカリカリたこ焼き食べました。お土産に買った「吉原殿中」というお菓子は甘すぎず、しつこくなく、すごく美味しかったです。
info.plist と NSUserDefaults
アプリ内のちょっとしたデータを保存するのに、CoreData に保存するほどでもないんだよなーということがあって、具体的には、観察地を入力する時のデフォルト地点を、前回の場所にしておきたかったんですね、毎回場所を変えてバードウオッチングする人は稀で、普段はホームグラウンドとしている地点を探鳥し、たまに遠征するだろう、自分みたいにと思って。
そんな時、NSUserDefault を使うとすごく便利なんですが、info.plist に思い違いをしていて、軽くハマりました。値の取り出しまではすんなり、というか、久しぶりだったので、こんなにめんどくさかったんだと思いながら作っていましたが、さて、値を更新しようとして、やり方がさっぱりわからず・・・それもそのはずで、初期値の設定は手動で、読み出しのみというのが info.plist の役割なので、更新できたら逆に困るというもの。
以前買った古い本を引っ張り出してきて、あ、NSUserDefault だったとようやく気付いた次第です。
info.plist ですが、使いにくいことの一つに、値を取り出す時に指定する key が見えているまんまなのか、接頭語を付けるのかわからない点があります。
Xcode で、info.plist を選んで、右クリックすると、コンテキストメニューには Show Raw Key/Value というメニューが見えるので、それを選ぶとプログラミング時に指定する実際の key が見えます。大抵、頭に CFBundle などの文字を付けてやることになりますが、知らないと、指定がうまくいかずハマりが深くなるので、知っていると便利ですね。
なお、info.plist に開発者が key を追加した場合、プログラムで指定する key は接頭語を必要とせず、マンマで大丈夫です。でも、付けようとする名前が予約されていると混乱の元になりますから、my とか、oreore とか、何らかの自分を主張する接頭語を自身でつけてやるのが良いんでしょうね。
CloudKit Storage
アプリ利用者のデータを統合すると集合知的な利用方法ができる。
今構築中の野鳥観察記録（Field Note）では、例えば有名な探鳥地に行くとして、遭遇できるであろう野鳥の種別とその期待値を出したり、日本各地における渡り鳥の初認日から、自宅周辺での初認日を予想したりと、ふだんの bird watching life が充実すること間違いない。
アプリ利用者のデータを集めるにはどうすればいいのかよく分からなかったで、mobile backend とかを色々調べたりしていたのだけれど、結局どれが生き残るかよく分からない混沌とした状況で、決め手にかけるなぁというのが正直なところ。
そんな中、CloudKit Storage というのが、Apple 謹製であったので、びっくりこきました、ってか、知ってる人からすると、そんなことも知らないの、ぷっっ 状態。
ちょっと色々調べてみることにしよう。
