Hilt化、ネットワーキング層の構築が完了しました。
今日は、これまでの基盤の上に、アプリを本格的なWebサービスへと進化させるための入口、**「ユーザー認証機能」**を設計します。
この記事では、実装に着手する前の「設計フェーズ」として、要件定義と基本設計を固めていきます。Qiitaの記事にすることも意識し、思考のプロセスを交えながら、分かりやすくまとめました。
1. なぜこの機能が必要か？（背景と目的）
これまでのアプリは、誰でも使える代わりに、データはスマホの中だけにある「スタンドアロン型」でした。
しかし、将来的に**「どの端末からでも同じデータを使える」クラウド同期機能**を実現するためには、まず「このメモは、誰のメモなのか？」を識別する仕組みが不可欠です。
そのための第一歩が、ユーザー認証機能の実装です。
2. 何を作るのか？（要件定義）
2-1. 機能要件（ユーザーが出来るようになること）
ユーザーストーリー:
- 新しい利用者として: 私は、メールアドレスとパスワードを使って新しいアカウントを作成し、アプリを使い始めたい。
- 既存の利用者として: 私は、登録したメールアドレスとパスワードでログインし、自分のメモ画面にアクセスしたい。
- アプリの利用者として: 一度ログインしたら、次にアプリを開いたときには自動的にログイン状態になっていてほしい。
機能一覧:
| 機能ID | 機能名 | 機能概要 |
|---|---|---|
| FE-011 | 新規登録機能 | ユーザーがメールアドレスとパスワードを入力し、新しいアカウントを作成できる。 |
| FE-012 | ログイン機能 | 登録済みのアカウント情報でログインできる。 |
| FE-013 | ログイン状態の永続化 | ログインに成功したら、そのユーザー情報を端末内に記憶する。アプリを再起動しても、ログイン状態が維持される。 |
| FE-014 | 画面分岐機能 | アプリ起動時にログイン状態を判定し、未ログインならログイン画面へ、ログイン済みならメモ一覧画面へ、ユーザーを振り分ける。 |
2-2. スコープ（今回はやらないこと）
- ログアウト機能
- パスワードリセット（忘れた場合）機能
- GoogleやX（旧Twitter）などを使ったSNSログイン機能
3. どうやって作るか？（基本設計）
3-1. 設計方針
- 既存のMVVMアーキテクチャ、Hilt、Navigation Composeを基盤として実装します。
- ログイン状態（ユーザーIDなど）の端末内への保存には、
SharedPreferencesの現代的な後継であるJetpack DataStoreを利用します。DataStoreは、非同期で安全にデータの読み書きができるため、今回の目的に最適です。
3-2. 新しい登場人物（コンポーネント設計）
今回の機能実装のために、以下の新しい専門家たち（コンポーネント）をチームに迎えます。
-
UI層:
-
LoginScreen.kt: ログインフォームを表示する**「受付画面」**。 -
RegisterScreen.kt: 新規登録フォームを表示する**「会員登録画面」**。 -
SplashScreen.kt: アプリ起動時に一瞬だけ表示され、行き先を振り分ける**「案内人」**。
-
-
ViewModel層:
-
AuthViewModel.kt: ログインと新規登録のロジックを担当する**「認証の専門家」**。
-
-
データ層:
-
UserRepository.kt: ユーザー情報のAPI通信と、ログイン状態の保存・読み出し（DataStore）を担当する**「顧客情報管理者」**。 -
DataStore: ログインしたユーザーのIDなどを保存しておくための**「小さな金庫」**。
-
3-3. 新しい画面の流れ（画面フロー）
この機能追加により、アプリ起動からの画面遷移の流れが以下のように変わります。
思考のポイント:
アプリ起動時にいきなりログイン画面や一覧画面を見せるのではなく、SplashScreenという「案内人」をワンクッション挟みます。
この案内人が、裏側で「お客様はログイン済みですか？」とUserRepositoryに静かに確認し、確認が取れてから適切な画面へスムーズにご案内します。これにより、ユーザーは画面のチラつきなどを感じることなく、快適な体験を得られます。
以上が、Day 3で実装する認証機能の要件定義と基本設計です。
この設計に致命的な漏れはなく、この後の詳細設計に進むための完璧な土台となります。準備ができたら、次のステップである詳細設計に進みましょう！