macOS版xibロード関数

...なんか管理が大変だったので、Hatenaから黙って引っ越しました。

macOSでもxibからロードする関数を立てておきたかったのと、swift3対応のため備忘。
システム上、高頻度の利用シーンがあり、3まで来てある程度Appleの設計もこなれて来たので、ライブラリとして書いてみた。

いつも思うが、Appleはxibに対して冷めたい。
設計者からすれば、もうnibみたいなレガシーシステムはデベロッパから切りたいので、何も考えずstoryboard使えということだとは思うが。
じゃないと、initWithNibnameコンストラクタ廃止して、NSArrayにxibから生成されたNSViewつめてインスタンス返すようなわかりにくいパスだけ残すなんて設計にしないと思う。

ただ、storyboardだとカスタムviewを単体で定義できないし、programableにviewController上のviewにバインドしたいときとか、特定の場所に特殊なviewを出したりしたいときにはやっぱりどうしてもまだ使う。
storyboardの中では結局xib使ってるんだけどね。。。複雑になり過ぎてユーザに開放できないわということだろう。
ドキュメンターに定評のあるAppleも説明コストのほうがかさむと判断したのかもしれない。
好意的に見ると、xib使わなきゃできないようなアプリケーションは、仕様が複雑になりすぎてるか、やりたいことを見失ってるから気づけ—ということかも知れない。
確かにiOSでiPad proをメインユースにとでも想定していないならそうかも知れない。
小さい画面であれもこれもできますと凝るほど、ユーザには負担がかかるんだよという、非常にわかりにくいメッセージだと考えると個人的には非常に納得できる。

で、Apple Developerより先に引っかかったのがこれ。


Load a UIView from nib in Swift


これはiOS向けのレポートだけど、いくつか比較した中では一番妥当に感じたので、ここからぱくってみる。
iOS版は数年前にObjCで書いたんだけど、iOSとmacOS、上物エンジンはさすがに若干違うので一部書き換えてある

assertはvendorが扱いを変えたり、個人の実験考察に誤りがあって棄却が必要になったとき、対応できるよう入れてあるモノ
ちなみに、何度か遭遇したけど何らかの条件下ではunsafePointerの順番ひっくり返るんだよなぁ。。。。
原因となり得る要素が多すぎて確信できる答えはまだ出てないけど。
たいていのレポートはfirstで決め打ち取り出ししているけど、なにか記述していない前提があるんだと思う

また無駄な処理を。。。といわれそうだけど、世界中に配るモノの一部なので一応保険に保険を掛けた構造といことで。
道具箱にframeworkとして入れておいてもいいんだけど、Categoryみたいにimportで切り分けられない。。。
一発間に冗長クラスを介在させるとかも考えたけど、それはそれでめんどくさいのでprox実装にしました。
あと、private gistをblogに貼ったら、robotがどう振る舞うかの実験もかねて。


-- 以下おもいつきの余談 --
それにしても、autoLayoutは複雑なCG座標系の概念でさえ、いかにも設計せず実装できまっす！みたいな顔をしているし、それを使ったstoryboardはXML生成の最適化処理にバグを持ってる気がして大いに気にくわないんだけど、コードで全部書くとパラメータがOOのあおりで意識しないところで書き換えられるなんてことは少ない反面、表示位置確認くらいの簡単なデバッグなんかに時間がかかるというジレンマ。。。
storyboardなりxibなりを書き換えたあとは、DerrivedDataごとclean(Xcode: Opt + ⇧ + ⌘ + k)が癖になってしまった。


概念上でもレイヤで完全に分離することで、利用者へ出しているIFをコントロールしたい、xibはもうカプセルに囲い込んで、xibのIFはstoryboardを通してしか使えないようにしたい現れなのかと。
余計な仮定はオッカムの剃刀でそぎ落とせ、KISSの法則も同じようなことだけど鉄則なので解らないでもない。
興味を持って考えるべきことはなるべく最小セットにとどめないと、思わぬ方向から要求が来たときに致命的な制約がかかるので。

ただ、やったらめったらそげばいいというモノではなくて、一貫性をもって取捨選択していく。
この一貫性というのが設計の本質といっていい(と私は考える）。

誰かをディスるわけではないが、よくS/Wに何百人月も投入して失敗するケースと、研究室やらベンチャーの少人数で高い生産性みたいな話があるけど、実はこれ当たり前の話。。。

だって、
関わる人たちの考えていることや意見の一貫性は、関わる人数が増加傾向にあるほど複雑化して損なわれる確率が高いのは想像にたやすい。
逆に少人数で、輪講なんかで同じ主張の本を読み、生活コンテキストやらイデオロギーやらフィロソフィーがある程度そろっていると、それぞれ違った課題を抱えていても、最初に思いつく解決アプローチは皆同じだったり、細かい設計まで言わなくても納得できる品質レンジに収まってたりして一貫性は保たれやすい
から

後者は私の仮説込みだけど、Blooksが人月の神話でとうの昔に言ってたことの受け売り(個人的にこう解釈している)です。

失敗経験則ではたいてい矛盾する２つ以上の課題を同時に解決しようとしてるんだけど、不思議なことに課題分析に工数を使うべきとの意見だけはついぞ出てこず、そして倒れるというアンチパターン。。。なぜだろう。

拙作 Smoker Insight! is Out

拙作アプリがローンチされました。

👉  にあるように、CoreDataとデータ構造に興味を持って設計を起こしたため、ベースがcoreData(実態はsqlite3)の割にはデータ量が少々蓄積してもリアルタイム演算は割と速い方だと思います。

以前にもネタにしましたが、ミソはパーセンタイルと4分位数あとKVS少々。逐次検索を一旦KVS構造に読み替えるシステムなんで、一旦準備が整えばフラグ調整や、新たな喫煙データが加わることで全データの平均値が変わって各データのプロパティ変更が必要になっても1,2,3qをピボットにして高速追従します。

これを軸にシステム全体のデータハンドリングが組まれているため、よくあるユーザに見えてるアイテムについてだけの実行ではなく、毎回データ全舐めをして、全データ系内で整合性を保ちながらも十分な速度で動きます。

 このアプリ、任意のタイミングでの全データグラフ化機能を搭載しているので、これは外せない必要仕様なわけです。

遅延評価であれもこれも必要になったとき計算、ではいざというときユーザーを待たせてしまいますから。

 IAPに至っては、かなりJBに対して挑戦的な実装になっていて、途中で仕様が複雑になりすぎたため、ここだけは真面目にUMLを書いて設計しました。

これも機会があればまた詳しくネタとして展開します。

ただ、今の実装はappleidのログインダイアログがしつこく出るので、少し仕様変更入れるかも。

 

とりあえず、いまはまだまだ全然宣伝できてないので、向こう２週間は個人開発者向け宣伝サイトに順次レビューを寄稿しつつ、AdMob, iTCとにらめっこの予定です。