# 【20/12/08(火)】1,2限目
###### tags: `卒業制作`

### 優先度 高

- [x] グループ参加

- 招待されたユーザが正式にメンバーとして参加される処理のこと
- group-state内のno-joinテーブルから該当レコードを削除。joinテーブルにレコードを追加すればよい

- [x] 吹き出しバグ

- 個人間チャット、グループチャット、共にメッセージのはみ出しが発生
- ついでに左文字詰めも実装しておく。現状は中央揃えになってる

- [x] グループログ

- メンバー参加、招待、除外などのグループ内アクションをチャット画面内に表示
- group-messageにログ投稿すればよい

- [x] 招待キャンセル(招待ユーザの除外)

- 参加中のユーザの除外は実装済みだが、招待中のユーザのキャンセル機能はない
- no-joinとmember内の該当レコードを削除するだけでいい

- [x] Latestテーブルの不備

- グループ内でメッセージを送信した場合、自分からメッセージを送信した場合は問題なくLatestフィールドに更新が入るが、自分以外の参加者はLatestフィールドに更新を入れていないので、追加するべきである。
- Latestフィールドに更新が入っていない場合、最新メッセージ画面が反映されなくなる。

- [x] グループ設定画面の不具合

- **招待できるユーザ表示機能で、招待中のユーザがいるのに、招待可能ユーザにまた表示されてしまう不具合**を発見
- 現在も開発を続けているが、わかったことはDBへアクセスする処理は、非同期処理として扱われており、全件データを取得する前に、その次の処理へ移動してしまっていることが判明した。
- 上記が原因でうまく実装できていない範囲
- GroupChatActivity
- 除外されたユーザを判断する処理部
- GroupSettingActivity
- 招待可能ユーザを判断する処理部

- [x] 除外されたユーザ

- 除外されたメンバーは、現状はそのグループにアクセスする手段がなくなる（ユーザ一覧画面からグループが表示されなくなるのを確認）
- 現在は、除外された旨のメッセージを表示する機能までは出来たが、誰に除外されたかについてはまだ。
- 開発メンバー各所から「誰に除外されたかわかると、逆恨みされることがある」と言われた。
- 逆恨みを意識するならば、除外された後、在籍する誰かから個別チャットで除外したユーザを問えば、どちらにせよ逆恨みされるような気もするが、一旦はこの「誰から除外されたか」については、開発を止めることにした。

### 優先度 中

- [x] 招待キャンセルユーザ名を表示

- 招待、除外するユーザ名をダイアログを表示する機能は既に実装しているが、招待をキャンセルするユーザの名前をダイアログに表示する機能はまだない

- [x] チャット内写真送信

- 個人間チャット、グループチャット内で写真の投稿を行う

- [x] グループログ出力タイミング
- 新たにグループ名変更、トピック変更時にもログ出力

- [x] 被りの除外

- RecycleViewの仕様上、描画されない範囲にスクロールしたあと、範囲内に入ると初期状態に戻る。
- この仕様のせいで、さっき変更を加えたものが初期化されることがある。
- 連続で追加後に保存ボタンを押すと、押した分だけ同じユーザを追加してしまう。
- 追加する時に内部的に、既に同じユーザが存在していた時は、追加しない処理が必要だ。
- ベストは、範囲外に行っても描画がリセットされないのがいい。もしかしたらプロパティとかメソッド指定とかで解決できるかもしれない

### 優先度 低

- [ ] 公式グループ

- 未定

- [ ] 公式グループ参加

- 上記機能を実装した場合に欲しくなる機能
- QRコードで参加できるようにする。誰かから招待されて参加するタイプではない
- もしくは、検索画面から公式を絞って検索できるようにするか

## 進捗

> [name=前田裕輝]
> - 前から悩みの種だった、招待可能ユーザの抽出処理を完成。
> - Firebaseへのアクセスは確かに、非同期で実行されるが、ブレイクポイントで挙動をよく観察すると、[挙動の理屈](https://hackmd.io/9DwDVbnkSVaeil-fvt4qPQ#%E6%8C%99%E5%8B%95%E3%81%AE%E8%A9%B3%E7%B4%B0)がわかってきた。

> [name=栗林幸暉]
> - None

> [name=武田鼓太朗]
> - None

## 挙動の詳細

- Firebaseへのアクセス処理はそれ以外の処理と比べて非常に遅い（データ件数問わず）
- Firebase以外の処理がすべて完了後、Firebaseへの応答がある。
- 複数、Firebaseへアクセス処理があった場合、データの件数問わず、上から読み込まれる。
- Firebaseへのアクセスリスナー内にある処理(例えば、ifとかforとか)も同様に、Firebase以外の処理すべてが完了後、アクセスリスナー内にある処理が実行される。
- リスナー内にある処理はしっかり、非同期挙動に対応して動ける。
- 問題は、Firebaseから取得したデータを**その後なんらかの形で利用する処理でつまづくことになる**だろう。
- 裏を返せば、取得したデータを元に何かする処理を**しなければいいということになる**
- 私は、取得したデータをもとに何かする。この処理を一切なくすことに決めた。

## 非同期処理

- Kotlinで非同期問題に直面した場合、解決方法はコルーチンというものを使うことになるだろう。（セオリーでは）
- コルーチンとは、同期処理のある部分を切り離し、切り離した部分を別のスレッドで動かし、マルチスレッドを可能とする（マルチスレッド・非同期処理）ものと、ある部分のデータ取得、もしくはループ処理完了まで、そのスレッド内の処理を待機する(async・await)がある。
- もし、Firebaseでデータを全件取得後、そのデータを利用したいなら、このコルーチンというものを使ってみてはどうだろうか。