【Dart/Flutter開発】背徳を感じつつも削除フラグを導入→しかもカッコ良くできたからヨシ!な話【個人開発】
こんにちは、たちつてとです。
出費記録アプリを作っています。
その中でちょっとかっこいいUIを作ってしまったので、
ほんのちょっとだけ嬉しくて記事にします。
今回は、削除フラグ(後述)を編集できる画面を作りました。
→出費のカテゴリの要/不要をユーザが操作できる、
ようになりました。
まずはほんの少しイントロというか、
プログラムとして何を作ったかを紹介します。
【Dart/Flutter開発】画面遷移とカレンダー機能を実装、実際の(自作)アプリと考え方を共に...【スマホアプリ】
や
【Dart/Flutter開発】表示制御と検索機能の実装、実際の(自作)アプリと考え方を共に...【スマホアプリ】
でも機能を実装してます。
イントロ.作戦決定までのあらすじ
下画像は、出費記録アプリ(自作)のドロップダウンです。
まあ、よくある「カテゴリ」というやつです。
「食費」とか「旅行」とかのイメージのやつです。
で、もちろんプログラムとして楽なのは、
この選択肢が固定としてあることですよね。
しかしまあ、やはり
よくある機能として
カテゴリが追加できたり
削除できたり...
があると思います。今回のテーマです。
とは言っても作るのめんどくさいですやんか。
上の左側の画面なんかは、出費の明細登録画面で、
要はこれと同じものを作ればよろしい。
ということではあるんですが...
やることが自明で
時間がかかるものほど、
やる気が失われるものは
ありません。
「やる気0、しかしやらねば」
(かつお金ももらえない)という状態は、
フラストレーション及びストレスになりかねません。
趣味のプログラミングでは、この状態を
全力を持って回避しなければなりません。
(皆さんも気をつけましょう)
したがって今回、
- データの用意はする
- 全部は画面に出さない←削除フラグを導入
- 削除フラグを操作できる画面があればよろしい
ということになります。
出費のカテゴリなんぞ高々10個ちょいあればええから、
データを増やさせる必要ないやろ。という背徳的作戦。
カテゴリ名は編集できるようにしとく(いつか)。
削除フラグとは
削除フラグというのは、論理削除するかどうかを決めるものです。
あ、ブラウザバックしないで...もう3行なので....
論理削除の対になるのは物理削除です。
論理削除のついでに、物理削除も知っておきましょう!
- 物理削除→記録媒体(スマホのストレージ、データベース)から削除
- 論理削除→記録媒体には存在。画面等には表示されない
物理削除
ポケモンとかの「最初から始める」は物理削除、
「お気の毒ですが冒険の書〜」も物理削除。
0%も物理削除。この世から「物理」的に消える状態。
論理削除
論理削除の例はあんまり浮かびませんね...
具体的には、
- 削除フラグ:0 →表示など、利用中
- 削除フラグ:1 →削除状態
です。要は、「sakujoFuragu」なる項目があって、
1(=true)ならば削除状態と「思いましょう。」
ということです。
「物理」/「論理」の気分は分かりませんか?
作戦決行
直上の画像が作ったものになります。
めっちゃ途中感ありますけどね。
赤/青色のボタンをタップしたら、
削除フラグが切り替わる。
本当はカテゴリのデータは14個くらいあるんですが、
最初にあげた画像では5個しか選択肢にありません。
これが削除フラグが立っている
→データは存在するけど使用されていないデータがある
という状態になります。
この見た目、我ながらすこ。
もちろんボタンの色と白文字の組み合わせもですが、
ちょっと上に小さくactive/non-activeが表示されているところとか、カテゴリ名の背景色が灰色でちょっと無骨なところとか。
ソースと必要な処理の記述
※後からの改修のしやすさのためにconstを仕込んでいます。
const _active = 'active';
const _act_color = Color.fromRGBO(240, 125, 125, 1.0);
const _nActive = 'non-active';
const _n_act_color = Color.fromRGBO(125, 125, 240, 1.0);
本体は以下。例の如く、ListVIewというのを利用してます。
ListView.builder(
// リストを生成
itemBuilder: (context, index) {
final cate = _cates[index];
final delFlg = _cates[index].delFlg;//一行のデータごとの削除フラグ
ElevatedButton(
child: (Text(
// テキストの設定
delFlg == 1 ? _nActive : _active,//Textを変更
style: new TextStyle(
color: Colors.white,
),
)),
style: ElevatedButton.styleFrom(
shadowColor: Colors.transparent,
primary: delFlg == 1 ? _n_act_color : _act_color,//色を変更
),
onPressed: () {
// 登録処理 人によって書き方はまちまち
Hive.openBox<Category>(_category).then((value) {
cate.delFlg = delFlg == 1 ? 0 : 1;//削除フラグ変更(更新処理)
value.put(_cates[index].id, cate);
setState(() {});//build実行で、画面リロード
});
},
),
変数とかは、ばりばり独自のものなのでやはり作戦だけお伝えします。
黄色のコメントのあたりを見ていただければ幸いです。
delFlgには、リスト一行一行のデータ(インスタンス)に、
「削除フラグ」(=0か1の値)のプロパティが用意
→格納してあります。
それでElevatedButtonのプロパティやTextの引数に、
(delFlg == 1 とか言った)削除フラグを判定基準にした
記述があることがわかると思います。
Textの引数を三項演算子
(bool? trueの場合の値:falseの場合の値)
にして、「trueの場合の値 」とかに
Stringを持ってくるのはいくつか過去にもやってました。
個人的に革新だったのは、Colorクラスも同様に
Stringと同じ要領でプロパティに当てはめるところでした。
まあ、わかっちゃったら当たり前なんですけど...
最後に、setState空打ち→build実行で画面再描画→完成!です。
今回の機能はこれ(=2種類)で十分なんですけど、
クラスのプロパティにColorなんて追加して、背景色を制御する。
→出費が1万を超えたら赤、5000円以上ならオレンジ...
なんてことも可能ですね。
最後に、DropDown作成処理に
List<Category> cates = [];
for (Category cate in cateBox.values) {
if(cate.delFlg == 0) {// 削除フラグが立っていないものだけを抽出
cates.add(cate);
}
}
削除フラグが立っていないデータだけを
取り出すことを条件づけて完了です。
これらの処理によって、
データはストレージに存在するけど使用はされていない
を実現することができます。
「論理」的な削除の気分、少しでもわかったでしょうか?
最後に選択肢の確認
はい、最後に画面です。
左側の画面のように、削除フラグが立っていないのは3つのデータだけ。
対して右側の画面でも、3つの項目だけが表示されています。
これにて、削除フラグの導入は完了です。
まとめ
今回、カテゴリの論理削除→削除フラグの操作を
ユーザができるようにしました。
これにて、各ユーザのカテゴリの使用/不使用に応じて、
カテゴリの表示/非表示をユーザーが操作できます。
これにて最初に述べた、当初の目的である
>やはりよくある機能として、
>このカテゴリが追加できたり削除できたり...
をなんとなく暗黒面に落ちたような気がしつつも
達成できたわけですな。
そろそろ、書籍も読んで理解も深めたいぜ...な季節。
|
|
|