andanteandantediary0210今日も特になにもしていない。起きてちょっと勉強しようとしたんだけど、なんかそわそわしちゃって落ちつかないから結局昼寝してやりすごした。いえばCombineについてちょっと調べたけど、結局Apple的にもSwiftUIにはViewModelを載せるのがいいと考えているっぽい?でもそしたら結局ヒープの確保が毎回発生するからイケてないんじゃないかなあ。measure!"なんですが。それを避けるためにSwiftUIはViewをstructにしたんじゃないのか?やっぱWWDCをちゃんと観ないとだめかなあ(それはそう)。アプリデザインを考えてみたけど、そういえばアプリのデザインを自分でやったことなかったなと思う。Webは素人なりに何度かやったことあって、たとえばこの日記も自分で(ふねさんの影響とかかなり受けてるけど)デザインしたんだけど、アプリだと一度に見せられる情報にかなりの制約があるから、機能の優先度を先に詰めておかないと画面遷移とかぜんぜん決められないなと思った。いま機能のリストを書いている。こんなのもっと後で考えるべきことかもしれないよな。必要な画面コンポーネントと不可分だから、特に今回のようにUIの制約がきつそうなケースでは先に不安要素を取り除いておきたい......。明日はかしこまったランチに行きます。23:55:41https://ofni.necocen.info/35830209仕事をした日だと「仕事は××だった」みたいに書き出せるのだが、そうでない日はなかなかそうもいかなくて困る。今日は昼過ぎに起きて録画していたアニメを観た。今期は「映像研には手を出すな!」を観ている。キャラクターが非常に魅力的な作品だし、いま自分も(アニメ制作ほどクリエイティヴではないにせよ)ものを作ろうとしているので、共感する部分も多い。昨夜悩んでいたこと、すなわちアクセストークン認証はビジネスロジックなのか単なる実装詳細なのかという問題については、少なくともアプリはログイン時にアクセストークンを要求し保存する必要があるし、それにトークン自動更新はビジネスロジックに含まれて然るべき、という観点からドメイン層にねじ込まれることになった。結果として結局DIを簡単に書く方法が要請され、それに伴ってコードが整理された。トークン更新機構が実装できたのでよかった。試作二号機の役割、つまり本格的なプロジェクト構成とアーキテクチャ的な問題の洗い出しは完了したのではないかと思う。この先、UI的な限界の探究を二号機で継続するか三号機が作られるかはまだ決めていない。このまま二号機で作ってもいいような気はする。エンティティさえ共通ならばどうにでもなるのがこういうアーキテクチャの強みだけど、だとしてもわざわざ乗り換えるのも面倒だし。明日はいろいろ用事があるから休暇、のつもりだったのだけど、用事はだいたい消滅したので単に四連休を楽しむ人みたいになってしまった。まあ四連休はありがたいのだが。明日はUIのお絵描きをがんばろうかな。03:07:01https://ofni.necocen.info/35820208今日はなんだっけなあ。ひさびさだったので首回りがスースーして参った。最近はそうでもなかったのだけど。夜はコードを書いていた。アプリ側のアーキテクチャはだいたい固まったのでサーバー側できちんとしたエラーを返すコードを書いたんだけど、じゃあアプリはこれを受けて誰が動くべきなのか?というところで悩んでいる。リソースが存在しないとかアクセス権限がないとか、そういうのは特に考えるところはないのだけど、アクセストークンが切れている場合に自動で更新しにいく、みたいな手続きはビジネスロジックの一部なのか、それともネットワーク固有の問題としていいのか。後者だと共通化は楽になるんだけど、論理的には前者であるべきのような気がする。前者をとると、ほぼすべてのUseCaseはそのためのRepositoryに依存する必要があって、注入が面倒なんだよな。DI機能を実装すべきなんだろうか。あれってモジュールをまたいでも使える実装なんだっけ?使えるか。