あっ どうも子へびです。
なぜだか突然スクワットにハマってしまい毎朝コーヒーを沸かしている間スクワット中の子へびです。その結果毎日腹ただしいくらいの筋肉痛に襲われ歩き方がぎこちないところが難点です。でも筋肉痛になるってことは効いてるのかな?
UIとの連携はあの後珍しくトントン拍子で進んで、segmentの表示もうまくいき読込ボタンを押すと全ての値をUI側に表示することができました。そこで疑問が・・・
子へび
もしdataを編集したくなったら読込ボタンのあとは値を変更してまた登録ボタンを押したくなるよね?作り手側としてはもう一度読込ボタンを押してもらって読込ボタンにアップデートのコードをセットする方が楽チンだけど。登録ボタンは新規登録、読込ボタンは編集・更新っと分けたいけど人の心理としては普通登録ボタンが全てだよな〜。これどうやってボタン操作区分けするのかな?
っと思いMaster松陰に相談したところ
Master松陰
子へびこれはUIを作る時の鉄則ですがけっしてユーザーを信じるべからずなのです。あるとかないとかじゃなく、できるかできないかなんです。ユーザーは何をするかわからないっと言うのが前提です。全てのパターンに対応できるようにすべき。よくユーザーがそんな使い方するとは思わなかった。って言うエンジニアもいるけど、そんな時は君の想像力が足りないだけでしょ?っと言ってあげます。モンキーテストをクリアするぐらいでないとダメです。
子へび
なるほど。モンキーマジックか・・・。
最近また新しいアプリをリリースしたMaster松陰は自分のコードしかり常に完璧なコードを作りあげるをモットーにされてらっしゃるので子へびもそれを常とし、作ってみたいなっと思います。使いづらいものはやっぱり使わなくなっちゃうもんね。相変わらず厳しいMaster松陰ですがUIの構成が初めての子へびに指示書をくれました。その一部がこちら
実際のアプリはもっと複雑になるとのことですが、一番基本の形を指示してくれてるとのこと。
子へび
しかしこの指示書何だかやること多くないかな?すでに行数はかなりあるのにさらに行数が増えそうだ。
すでに行数が増え続けiPhoneでは全体のコードの見通しが悪くなってきて一度紙に落として見ていかないと構造がわかりずらくなっている子へびです。指示書通りにできるかな?