Q&A
トーストとスナックバーについてのソースが見つかりましたが、読み返してみると、アプリがアクティブかどうか？を軸に話しているように感じました。
https://developer.android.com/guide/topics/ui/notifiers/toasts?hl=ja
わからないこと、回答してほしいこと
AndroidアプリをKotlinで開発する際、DB接続やIO処理のような一般的に重い処理は非同期で行うような設計思想になっていると思うのですが、仮にinsertが失敗したとか、DBにおいて重複禁止項目のバリデーションエラーに引っかかったなどは、どのようにユーザーに伝えるのが一般的なのかわからないのですが、
こういったアプリの基本的な処理についてのサンプル(入門)プログラムなどは公式から提供されていないのでしょうか？
補足、前提
(そもそもDBサーバーに接続に行くのがスマホからだと微妙でAPIサーバーを立てろみたいな意見もありそうですが、すでに利用しているソフトウェアについて、モバイル対応とかもあるとは思うので。。。)
関連してUIのトーストについて
以前自分は、トーストは非推奨で、スナックバーを利用すべきというのを見た記憶があり、今回質問の際に再検索してみたところ、以下の内容がヒットしました。
https://developer.android.com/reference/android/widget/Toast
内容からして私が以前確認した、トーストは非推奨というのは誤訳かなにかを確認しただけなのかなと思うのですが、特に理由なくトーストを利用してよいのでしょうか？
質問内容のおさらい
非同期処理の実行結果に対してUIに伝えるためのサンプルなどはあるでしょうか？
ユーザーエクスペリエンスのために、UIを思うように動かせないような処理(例えばポップアップによる選択)なども極力してはいけないという認識ですが、
サーバーとの処理はどのくらいかかるかわからず、画面遷移や応答の確認を待たず、即アプリを終了するなどのユーザー操作が考えられますが。
こういうアーキテクチャというか、スマホアプリの設計をする上で必須レベルの情報ってどこで参照すればよいのでしょう？
お詫び
※話したいことが多すぎてまとまりがないと感じるかもしれませんが、これでも一つの議題に絞ってそれ以外の内容は省いているつもりです。
恐縮ですがよろしくお願いします。
回答1件
0
ベストアンサー
仮にinsertが失敗したとか、DBにおいて重複禁止項目のバリデーションエラーに引っかかったなどは、どのようにユーザーに伝えるのが一般的なのか
その insert がアプリ/ユーザにとってどのような意味を持つのか、バリデーションエラーに引っかかるとアプリ/ユーザにとってどのような影響があるのかに因りますから、一般化は余り意味は無いと思います。(アプリの仕様としての UI デザイン側から決まっているかもしれませんが。)
コード的に見れば単に非同期処理からの UI の更新方法は…というだけで、それは既にサンプルとしてあるのではないでしょうか。
投稿2024/08/24 15:15
編集2024/08/24 15:17
総合スコア13168
ああ、そこら辺を省いていたら曖昧でしたか。
普通に業務アプリを想像して貰ったら大丈夫かと思います。
(一般化は意味ないってどゆことだ？ユーザーが例えば保存だとか投稿を押したのになんの通知もなく、データが捨てられるなんて動作あるのか？それ以外しかないなら、もうそれが一般的だと思うのだが。。。)
サンプルとしてあるというのはどういう意味でしょうか？
AndroidStudioのサンプルにあるということですか？
コード的な話というより、ユーザーにどう伝えるのか？という話です。
Webアプリ(SAPベースでは無い一般的なもの)や、WindowsFormアプリは直列的(同期的)にそこら辺を行って来ました、
awaitのイメージでIO処理(実際にはリクエスト？)を同期させるのは、Androidアプリ開発における考え方と一貫性がないのでは？という話です。
第1にどこかにそんな内容が書かれてた気が？ということと
第2にそもそも同期させるのであれば、非同期処理を強制させる理由がないことです(技術スタックの話もあるのでここに触れなくて大丈夫です)。
調べてもどこに書いてたか分からなかったのですが、ユーザー操作を中断させるようなのは控えるべきというのはマテリアルデザインの方にありました(強制するのは控えるべき)
https://m3.material.io/components/dialogs/
以下のリンクにてUIに処理を伝えるコードに関しては説明されているので良いのですが、ユーザー操作に対する注釈(fragmentの移動など)についての説明がされておらず、質問した次第です。
https://developer.android.com/topic/architecture/ui-layer/events?hl=ja#handle-viewmodel-events
この返信で元の質問と重複した内容があったかもしれないのですが、恐らく元の質問が伝わってないか、私がなにか根本的に誤解をしてるって感じだと思ってます。
要するに私が知りたいのは、
非同期処理のプロセスで、トーストなどを表示する(非同期処理をしている間ユーザーは画面移動や入力内容の破棄などを自由に行える)のが正しいのか、
非同期処理が完了する(Deferredの完了)まで(今回の場合はDBの通信終了)プログレスバーなどでユーザー操作を待機させるのが正しいのか、
そのサンプルはないのかという内容です。
恐らくは私が汲み取れてない部分が多いとは思います。
ユーザに強制しないのが良いというのは同感ですが、それが特定の具体的動作("DBへの保存時” 等) に UI としてどう表現されるのかは、1つ々々コードサンプルまで書くのは大変過ぎるのではと思います。
前提はともかく単純に「DB に insert する処理をする場合『裏で行って結果が出たらトーストで表示』 / 『裏か表かはともかくプログレスバーを表示して終わるまでユーザ操作を止める』 のどっちが正しい？」という質問だったとしたら、私なら *ユーザ操作を止める* という点は止めないほうが正しいと思いますのでトーストのほうを選びます。
が、アプリを起動したらまず DB に insert するのでそれが終わるまで他にそのアプリで出来ることは無いのであれば、プログレスバーのほうが正しいでしょう。
結局前提が出てきてしまいますので、 DB insert 時ならコレ！ という具体例は出て来難いのではないでしょうか。
例えばアカウント登録などそれが成功しないと先へ進めないようにするべき場面ではユーザー操作を止めるしかないです。プログレスバーというか通信中の表示を出すなど。
一方でメモアプリとかでタグの追加とかお気に入りのON/OFFみたいな場合は楽観的なUI更新で良い場合もあるかと思います。表示だけ先に更新して、実際の処理が失敗したらトーストでエラーを出すだけとか。
ケースバイケースなので、具体的な場面をある程度想定したら一般的な正解は出せそうな感じがします。
あとはGoogleの公式サンプルなどをダウンロードしていじってみるくらいしかないですかね。
https://developer.android.com/samples?hl=ja
ここからリンクされているArchitectureが良さげです。
https://github.com/android/architecture-samples/tree/main
ありがとうございました
あなたの回答
tips
プレビュー
