ID:78060さん

## SNSネイティブアプリ開発 ### 概要 悪口や意見を投稿し、反論を受けて「いいね」の数で実質的な勝敗が決まる議論型SNSネイティブアプリ。 他のアプリやサイトで蔓延る悪口やアンチコメントをこのアプリに限定したいと考え、作成に至った。 悪口を言われている人が見える範囲から隔離することで、傷つく人を減らすことができる。 見たい人だけがインストールし、見たくない人は避けることで、無意識に傷つくことを避けられる。 ### 開発期間 2024年 7月〜2025年2月 ### 役割 担当工程: 企画・要件定義・設計・コーディング・テスト ### 使用技術 ー Kotlin, Jetpack Compose, Coil, Dagger Hilt, Firebase Firestore, Cloud Storage, Firebase Authentication, Cloud Functions, Cloud Messaging, Jetpack Navigation ### メイン機能の使い方 |悪口を投稿する|悪口に反論する|討論を閲覧、コメントする| |---|---|---| |<img width="230" alt="VenTal GIF 2025年2月26日.gif" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3913183/60d31b91-3a44-4aab-8c19-8d2481845844.gif">|<img width="230" alt="VenTal GIF Feb 26 2025 (2) (1).gif" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3913183/cd7d5c58-f876-46c0-8bfc-852a22c7359e.gif">|<img width="230" alt="VenTal Video Feb 27 2025.gif" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3913183/2e6b095a-a08f-4854-bf2d-90e848f93d62.gif">| |まず下の＋ボタンを押して、作成画面へ。ストレスが溜まっていることや普通に悪口を記入して送信ボタンを押す|他人の悪口はボトムバーの左から2つ目の画面で閲覧可能。右にスライドでいいね。左にスライドで反論作成画面へ。記入して送信すればVSがスタート|VSはタイムラインに流れる。いいねは2人のうちどちらしかいいねできない。VSにメッセージを送れるのは参加者の2人のみ。コメントは全員できる。| ![]() ## 設計 #### 要件定義 #### モデリング ・ユースケース図 ・状態遷移図（未使用） ・アクティビティ図 ・ドメインモデル #### 基本設計 ・機能設計（画面遷移図と画面詳細） ・ER図（NoSQLに変更のため途中からyamlで設計） ・データフローダイアグラム #### 詳細設計 ・機能一覧 ・ロバストネス図 ・シーケンス図 #### インフラ構成図  ## 開発・実装内容 ### プッシュ通知機能 #### 概要 イベントに対してユーザーの通知設定がオンの場合端末にプッシュ通知を送信する #### 課題 ・通知先情報はサーバーのみが扱いたい ・通知情報の格納以外はサーバー側で行いたい。 ・ユーザーのプロフィール画像を通知に使いたい。　 #### 機能の実施方法 送信機能 1.通知を送りたいユーザーのFirestoreの通知コレクションに通知内容を格納 2.Cloud FunctionsにデプロイしたFunctionがコレクションへの追加を確認する。 3.Functionが通知先ユーザーの通知設定を確認する。 4.もし設定がONなら、通知の種類に応じて通知内容を補完して、通知設定に格納されているdevice token を使用してCloud Messagingからプッシュ通知を送信。 受信機能 1.受信すると表示する情報を指定。 2.指定された URL から画像を取得し Bitmap に変換。 3.HttpURLConnection を利用してネットワーク接続し、BitmapFactory.decodeStream(input) で画像をデコード。 4.通知を表示 #### 工夫した点 クライアント側で通知を送る処理をするとなると他ユーザーの端末情報や設定情報を扱うことになってしまうしそもそも責務があっていない。そこでCloud Functionを用いることで責務を分離することができた。 通知の種類を今後追加する予定があるため追加しやすい形で実装したかった。enumクラスで通知の種類を管理して、そこに追加すれば通知の種類を増やせるようにした。 ### フォロー機能 #### 概要 フォローという名のサブスクライブのような機能。 #### 課題 ・フォロー状態に応じてUI、メソッドの変更させなければいけない。 ・フォローしている人だけの投稿をページングでき、かつ新着順で表示する必要がある #### 機能の実施方法 フォロー機能 ・フォローは各ユーザーコレクションがフォローリストを保持。 ・フォロワーが誰かを知る機能は予定していないので、フォロワーはカウントのみ。 ・そのフォローリストをリアルタイムでリッスンして、状態に応じてUiを変更。 フォローしているユーザーの投稿のみ表示する ・フォローリストを10個ずつに分割し、開始日と終了日で絞って取得。（Firestoreではinに10個しかいれれないから） ・取得したものを一覧にしてソートする。 ・ページングは開始日と終了日をずらすことで実現。 #### 工夫した点 10個ずつをクエリのinに入れていくが、そのクエリの段階でソートしてしまうと全てを一つにした時にページングすることが難しくなってしまう。そこで投稿数を想定して、期間を絞って各クエリで取得しまとめた後にソートすることで期間をずらせばページングすることができるようになった。

## プロジェクト概要 ### 目的、背景 本プロジェクトでは、TODOリストアプリケーションを開発。目的は、タスク管理の効率化を目指すシンプルなアプリケーション開発を通じてCURDアプリケーションの作成手順を網羅すること。バックエンドはJava Spring Bootを使用し、データベースにはMariaDBを採用。フロントエンドはHTMLとCSSでシンプルなUIを実装し、直感的な操作を可能に。タスクの追加、削除、更新、一覧表示の機能を実装し、ユーザーが簡単にタスクを管理できるようにした。 ### 規模感、チーム構成、担当した役割 - **チーム構成**: 会社の研修なので一人で開発を行った。 - **担当した役割**: バックエンドの設計・実装、フロントエンドの実装、手動テストの実施 ### 使用技術や開発環境等 - **バックエンド**: Java (Spring Boot) - **データベース**: MariaDB - **フロントエンド**: HTML, CSS - **開発環境**: Eclipse, Git, - **テストツール**: 手動テスト（DBにデータ入力し、画面で実際に動作確認） --- ## 取り組んだ課題 ### どんな課題だったのか 1. **詳細設計**: 基本設計をもとに詳細設計を行いました。タスク管理に必要な項目（タスク名、期限）をどのようにデータベースで管理するかを検討し、効率的なテーブル設計を行った。 2. **コード実装**: Spring Bootを使用して、タスクのCRUD操作（作成、読み取り、更新、削除）を行うための機能を実装した。フロントエンドでは、HTMLとCSSでシンプルで直感的に操作できるユーザーインターフェースを構築。 3. **テスト実施**: 手動でDBにデータを入力し、画面で動作を確認する形でテストを行った。特に、タスクのCRUD操作が正しく機能するかどうかを重点的に確認。 ## 取り組みの成果 - **機能実装の完成**: タスクの追加、編集、削除、一覧表示機能を全て実装。タスク管理をシンプルに行えるシステムを提供し、ユーザーの利便性を向上。 - **ユーザビリティ向上**: シンプルで直感的なUIを実装し、ユーザーがストレスなくタスクを管理できる環境を提供。 - **手動テストの実施**: 単体テストや結合テストを手動でテストケースを作成し、DBにデータを入力した後、実際に画面で動作を確認。これにより、ユーザーインターフェースとバックエンドの連携を細かく確認。この経験から境界値などのテストの基本的な必要事項を学ぶことができた。 ---