はじめに
前回の記事では、
「全部見せること」が親切ではない。
そんなことを書きました。
内部ではたくさんの情報を持っていても、
利用者がその時に必要としている情報だけを見せればいい。
そう考えるようになって、
画面は少しずつ整理されていきました。
ただ、
そうすると今度は、
別のものが増えてきました。
検索している。
フィルタを選んでいる。
一部を開いている。
案内を表示している。
画面を作り込めば作り込むほど、
データそのものではない「状態」が増えていったのです。
最初は、あまり区別していませんでした
タイトル名がある。
画像がある。
所持状態がある。
お気に入りがある。
検索文字がある。
フィルタがある。
どれも、
アプリが今持っている情報です。
なので最初は、
そこまで深く考えていませんでした。
状態は状態。
必要なら持っておけばいい。
そのくらいの感覚でした。
でも、
機能が増えてくると、
少しずつ違和感が出てきました。
これ、本当に同じ「状態」なのか？
例えば、
あるゲームを「所持している」に変更したとします。
これは当然、
アプリを閉じても残っていてほしい。
次に起動した時、
「未所持」に戻っていたら困ります。
では、
検索欄に
ドラゴン
と入力していたことはどうでしょう。
あるいは、
一覧の一部を開いていたこと。
フィルタを一時的に選択していたこと。
これらも確かに「状態」です。
でも、
タイトルや所持状態とは、
何かが違う。
ここでようやく、
同じ「状態」という言葉でまとめているけれど、役割が全然違うのではないか。
と考えるようになりました。
データそのものと、データをどう見ているか
整理してみると、
思っていたより単純でした。
タイトル名。
画像。
分類。
所持状態。
お気に入り。
自由項目。
これらは、
利用者が登録したデータそのものです。
一方で、
検索している。
絞り込んでいる。
一部を展開している。
案内を表示している。
こちらは、
データそのものではありません。
今、そのデータをどう見ているのか。
そのための状態でした。
ここを分けて考えるだけで、
頭の中がかなり整理されました。
何でも保存すればいいわけではなかった
状態を残したいなら、
DBに保存すればいい。
技術的には、
それでも実現できます。
でも、
少し考えると変です。
検索欄を開いているかどうかまで、
タイトルやCollectionなどと同じように扱う必要があるのか。
画面の一部が開いていることまで、
永続的なデータとして管理する必要があるのか。
保存できる。
だから保存する。
ではなく、
そもそも、これは何のために存在する情報なのか。
そこを考える必要がありました。
画面には、画面の都合がある
前回の記事では、
内部に存在するデータを、
そのまま全部画面に出す必要はない。
という話を書きました。
今回考えていたことは、
その逆でもありました。
画面で必要になった情報を、
全部データ側に背負わせる必要もない。
画面には、
画面の都合があります。
検索したい。
絞り込みたい。
開いたり閉じたりしたい。
一時的に説明を出したい。
それは、
CollectionやFolderやTitleが持つべき情報ではありません。
画面を使いやすくするために、画面側が必要としている情報です。
この違いを意識するようになってから、
状態をどこに置くべきなのかを、
以前より考えるようになりました。
Composeを書いていると、状態だらけでした
Jetpack Composeで画面を書いていると、
当然ですが、
状態によって表示が変わります。
例えば、
if (isExpanded) {
// 展開した時だけ表示
}
これも状態です。
isExpanded が変われば、
画面も変わります。
でも、
よく考えると、
isExpanded はタイトルの情報ではありません。
Collectionの情報でもありません。
DBに保存しているデータの構造とも、
直接は関係ありません。
ただ、
今この画面をどう見せたいか。
そのために必要な状態です。
こういうものが、
画面を作り込むほど増えていきました。
そして増えていったからこそ、
無視できなくなりました。
「これは残したいのか？」と考えるようになりました
それからは、
状態が増えた時に、
少し考えるようになりました。
これは、
利用者が登録した情報なのか。
画面を作るためだけの情報なのか。
アプリを閉じても残したいのか。
今だけ分かればいいのか。
例えば、
お気に入りにしたことは残したい。
所持状態も残したい。
でも、
一時的に開いた説明まで、
必ず残す必要はない。
そう考えるだけでも、
状態の扱いがかなり分かりやすくなりました。
ところが、また綺麗には分かれませんでした
ここで、
「なるほど。DBの状態と画面の状態を分ければいいのか」
と思いました。
ただ、
実際に作っていると、
そんなに綺麗でもありませんでした。
例えば、
最後に使っていたフィルタ。
これは画面の状態です。
でも、
毎回アプリを開くたびにリセットされたら、
人によっては面倒かもしれません。
最後に開いていた画面。
これもデータそのものではありません。
でも、
アプリを閉じて、
もう一度開いた時に、
また最初から辿り直すのは面倒です。
だったら、
覚えておいた方が使いやすい。
つまり、
画面の状態だから保存しない、という話でもありませんでした。
結局、「誰のための状態なのか」でした
ここまで考えて、
ようやく自分の中で整理できました。
DBに入れるか。
ViewModelで持つか。
Compose側で持つか。
それを先に考えるのではなく、
まず、
この状態は何のために存在しているのか。
そこから考えればいい。
利用者が登録した情報なのか。
今の画面を成立させるための情報なのか。
次にアプリを開いた時にも、
覚えておくことで便利になる情報なのか。
同じ「状態」でも、
役割が違います。
役割が違うなら、
持たせ方も違って当然でした。
おわりに
最初の頃は、
状態管理について、
そこまで深く考えていませんでした。
必要になった状態を作って、
画面が動けばいい。
それで十分だと思っていました。
でも、
機能が増えて、
画面を整理して、
「何を見せるか」を考えるようになると、
今度は、
「その画面を作っている状態は何なのか」
を考える必要が出てきました。
データそのもの。
データをどう見せているか。
そして、
次に開いた時にも覚えておきたいこと。
同じアプリの中にある状態でも、
全部同じではありませんでした。
たぶん私は、
最初から状態管理を綺麗に設計できたわけではありません。
作って、
増えて、
少しごちゃごちゃして、
そこで初めて、
「これ、分けた方がいいんじゃないか？」
と気づきました。
個人開発をしていると、
こういうことがよくあります。
先に設計思想があって、
それに沿って作っているのではなく、
作り続けた結果、あとから設計思想に気づく。
今回の状態管理も、
そんな一つでした。
前回の記事
コレクション管理アプリで、「全部見せること」が親切ではないと気づいた話
シリーズ
このシリーズでは、個人開発しているコレクション管理アプリ SLX（StockLedgerX） の設計思想が、どのように変化していったのかを時系列でまとめています。
シリーズ一覧はこちらです。
▶ SLX開発録 〜設計思想ができるまで〜
次回は、
画面の状態を分けて考えるようになったあとに出てきた、
「では、その状態をどこまで覚えておくのか」
という話について書いてみようと思います。