CONTENT
ここから
この章で学ぶこと
この章では、ログインとユーザーごとのデータについて学びます。
最初に覚えることは、これだけです。
ログイン = 誰が使っているかを確認する仕組み
ユーザーID = その人を見分けるための番号
Todoアプリで考えると、ログインがない場合は、誰のTodoなのか分かりません。
レポートを書く
買い物に行く
英単語を覚える
これが、自分のTodoなのか、別の人のTodoなのか分からない状態になります。
だから、ログインが必要になります。
10-1. なぜログインが必要なのか
ログインが必要な理由は、誰のデータかを分けるためです。
例えば、Todoアプリを2人が使うとします。
Aさん
Bさん
AさんのTodoです。
レポートを書く
英単語を覚える
BさんのTodoです。
買い物に行く
バイトのシフトを確認する
この2人のTodoが混ざると困ります。
ログインがない場合
ログインがないと、アプリは誰が使っているのか分かりません。
誰が使っているか分からない
↓
誰のTodoか分からない
↓
全員のTodoが混ざる可能性がある
例えば、Aさんがアプリを開いたのに、BさんのTodoが見えてしまうと問題です。
ログインがある場合
ログインがあると、アプリは今使っている人を判断できます。
Aさんがログイン
↓
AさんのTodoだけ表示
Bさんがログイン
↓
BさんのTodoだけ表示
これにより、ユーザーごとのデータを安全に分けられます。
ログインが必要になるアプリ
次のようなアプリでは、ログインが必要になることが多いです。
Todoアプリ
メモアプリ
予約アプリ
チャットアプリ
SNSアプリ
学習記録アプリ
家計簿アプリ
在庫管理アプリ
共通点は、自分専用のデータがあることです。
自分だけのデータがある
↓
ログインが必要
10-2. 誰のデータかを区別する
データベースには、たくさんのユーザーのデータが保存されます。
そのため、データには「誰のものか」を示す情報が必要です。
Todoアプリなら、user_id を使います。
user_id = 誰のTodoかを示す情報
user_idがない場合
Todoテーブルがこのようになっているとします。
| id | title | is_done |
|---|---|---|
| 1 | レポートを書く | false |
| 2 | 買い物に行く | false |
| 3 | 英単語を覚える | true |
この表だけでは、どのTodoが誰のものか分かりません。
user_idがある場合
user_id を追加すると、誰のTodoか分かります。
| id | user_id | title | is_done |
|---|---|---|---|
| 1 | user_a | レポートを書く | false |
| 2 | user_b | 買い物に行く | false |
| 3 | user_a | 英単語を覚える | true |
この場合、user_a のTodoは次の2つです。
レポートを書く
英単語を覚える
user_b のTodoは次の1つです。
買い物に行く
このように、user_id があるとデータを分けられます。
10-3. 自分のTodoだけ表示する仕組み
自分のTodoだけ表示するには、ログインしているユーザーの user_id を使います。
流れはこうです。
1. ユーザーがログインする
2. アプリがuser_idを取得する
3. データベースに問い合わせる
4. user_idが一致するTodoだけ取得する
5. 画面に表示する
表示のイメージ
データベースに、このようなTodoがあるとします。
| id | user_id | title |
|---|---|---|
| 1 | user_a | レポートを書く |
| 2 | user_b | 買い物に行く |
| 3 | user_a | 英単語を覚える |
Aさんがログインしている場合は、user_a のデータだけ表示します。
□ レポートを書く
☑ 英単語を覚える
Bさんがログインしている場合は、user_b のデータだけ表示します。
□ 買い物に行く
考え方はフィルター
自分のTodoだけ表示する仕組みは、フィルターに近いです。
全部のTodo
↓
user_idが自分と同じものだけ選ぶ
↓
画面に表示する
例えば、Aさんなら、
user_id = user_a のTodoだけください
とデータベースに聞きます。
10-4. ユーザーIDの考え方
ユーザーIDは、ユーザーを見分けるための番号や文字列です。
名前ではなく、IDで管理します。
なぜ名前ではなくIDを使うのか
同じ名前の人がいる可能性があるからです。
山田太郎
山田太郎
名前だけでは、どちらの山田太郎さんか分かりません。
だから、ユーザーIDを使います。
user_001：山田太郎
user_002：山田太郎
これなら、同じ名前でも別のユーザーとして区別できます。
ユーザーIDは自分で覚えなくてよい
ユーザーIDは、基本的にアプリやログインサービスが自動で作ります。
ユーザーが覚える必要はありません。
ユーザーは、メールアドレスやパスワードでログインします。
アプリ側では、ログインした人のIDを使います。
メールアドレスでログイン
↓
ログインサービスがuser_idを返す
↓
アプリはuser_idを使ってデータを分ける
Todoテーブルの例
ログイン対応のTodoテーブルは、最初はこの形で考えると分かりやすいです。
| カラム名 | 意味 |
|---|---|
id | Todoを見分けるID |
user_id | 誰のTodoか |
title | タスク名 |
is_done | 完了状態 |
created_at | 作成日時 |
この中で特に大事なのが、user_id です。
user_idがあるから、自分のTodoだけ表示できる
Firebase・Supabase・その他サービスの事例
Flutterでログインやユーザーごとのデータを扱うときは、自分で全部作るのではなく、外部サービスを使うことが多いです。
代表例はこちらです。
| サービス | 特徴 | 向いている例 |
|---|---|---|
| Firebase | Googleが提供するBaaS。認証、Firestore、Storageなどを使える | チャット、学習アプリ、リアルタイム性のあるアプリ |
| Supabase | PostgreSQLベース。Auth、Database、Storageを使える | 業務アプリ、予約管理、Todo、管理画面 |
| AWS Amplify | AWSと連携しやすい。認証、データ、ストレージ、関数などを扱える | 企業向け・AWSを使う案件 |
| Appwrite | 認証、データベース、ストレージなどを扱えるBaaS | 自分で管理しやすいBaaSを使いたい場合 |
Firebaseは、Flutter向けの公式ドキュメントが用意されており、Firebaseの各機能をFlutterアプリから使うためのプラグインが提供されています。Flutter公式ドキュメントでも、Firebaseは認証、リアルタイムデータベース、Cloud Firestore、ストレージなどを提供するBaaSとして紹介されています。
Supabaseは、Flutter向けのクイックスタートが用意されており、supabase_flutter を使ってFlutterアプリからSupabaseに接続できます。Supabase公式のFlutterチュートリアルでは、ユーザー認証、プロフィール情報の保存、プロフィール写真のアップロードを扱うユーザー管理アプリの例が紹介されています。
AWS Amplifyは、Flutterアプリをクラウドに接続するためのドキュメントが用意されており、データモデリング、認証、ストレージ、サーバーレス関数などを扱えます。
Appwriteは、Flutter向けのクイックスタートが用意されており、認証、ユーザー管理、ファイル保存などをFlutterアプリに追加できます。
Firebaseで考える場合
Firebaseを使う場合は、ログインには主に Firebase Authentication を使います。
データ保存には、Cloud Firestore を使うことが多いです。
考え方はこうです。
Firebase Authentication
↓
誰がログインしているかを確認する
Cloud Firestore
↓
ユーザーごとのTodoを保存する
Todoを保存するときは、ログイン中のユーザーIDを一緒に保存します。
user_id
title
is_done
created_at
Firebaseのイメージ
ログイン
↓
Firebase Authentication
↓
uidを取得
↓
FirestoreにTodoを保存
↓
uidが一致するTodoだけ表示
Firebaseでは、ユーザーIDを uid と呼ぶことがあります。
uid = Firebaseが作るユーザーID
Supabaseで考える場合
Supabaseを使う場合は、ログインには Supabase Auth を使います。
データ保存には、Supabase Databaseを使います。
Supabaseのデータベースは、PostgreSQLという種類のデータベースです。
考え方はこうです。
Supabase Auth
↓
誰がログインしているかを確認する
Supabase Database
↓
ユーザーごとのTodoを保存する
Supabaseのイメージ
ログイン
↓
Supabase Auth
↓
user.idを取得
↓
todosテーブルに保存
↓
user_idが一致するTodoだけ表示
Supabaseでは、ログイン中のユーザー情報から id を取得し、そのIDを user_id として使います。
他のサービスで考える場合
FirebaseやSupabase以外にも、ログインやデータ保存を助けてくれるサービスがあります。
例えば、AWS AmplifyやAppwriteです。
どのサービスを使っても、考え方はほぼ同じです。
ログインする
↓
ユーザーIDを取得する
↓
データにユーザーIDを付ける
↓
自分のデータだけ読み込む
サービス名や書き方は変わります。
でも、基本の考え方は変わりません。
よくある勘違い
メールアドレスでデータを分ければよい？
メールアドレスで分けることもできますが、基本はユーザーIDで分ける方が安全です。
メールアドレスは変更されることがあります。
ユーザーIDは、ログインサービス側で一意に管理されます。
メールアドレス = 人が見る情報
ユーザーID = アプリが見分ける情報
ログインすれば自動で自分のTodoだけになる？
ログインしただけでは、自動でTodoが分かれるわけではありません。
Todoデータに user_id を保存し、自分の user_id と一致するデータだけ読み込む必要があります。
ログイン
↓
user_idを取得
↓
user_idでTodoを絞り込む
全員のTodoをアプリ側で取ってから分ければよい？
基本的にはおすすめしません。
他の人のデータまでアプリに持ってくるのは危険です。
データベースに問い合わせる時点で、自分のデータだけ取得する方が安全です。
悪い例
↓
全員のTodoを取得してからアプリ側で分ける
良い例
↓
最初から自分のTodoだけ取得する
インストールや準備について
この章では、まだ実装作業はしません。
ただし、ログイン機能を作る場合は、次のような準備が必要になります。
Flutter SDK
Visual Studio Code
Firebase または Supabase
認証機能
データベース機能
参考URLです。
Flutter公式インストール
https://docs.flutter.dev/install
Firebase for Flutter
https://firebase.google.com/docs/flutter
Firebase Flutter setup
https://firebase.google.com/docs/flutter/setup
Supabase Flutter Quickstart
https://supabase.com/docs/guides/getting-started/quickstarts/flutter
AWS Amplify Flutter
https://docs.amplify.aws/flutter/
Appwrite Flutter Quickstart
https://appwrite.io/docs/quick-starts/flutter
この章では、まず次の考え方が分かればOKです。
ログインする
↓
ユーザーIDを取得する
↓
データにuser_idを付ける
↓
自分のデータだけ表示する
10-5. この章のまとめ
この章では、ログインとユーザーごとのデータについて学びました。
ログインは、誰がアプリを使っているかを確認するために必要です。
ユーザーごとのデータを分けるには、user_id を使います。
Todoアプリなら、Todoテーブルに user_id を入れます。
id
user_id
title
is_done
created_at
自分のTodoだけ表示する流れは、次の通りです。
ログインする
↓
自分のuser_idを取得する
↓
user_idが一致するTodoだけ読み込む
↓
画面に表示する
Firebase、Supabase、AWS Amplify、Appwriteなど、使うサービスは違っても、基本の考え方は同じです。
誰のデータかを分ける
↓
自分のデータだけ表示する
この考え方が分かると、Todoアプリだけでなく、メモアプリ、予約アプリ、学習記録アプリ、業務管理アプリにも応用できます。