前のSTEPでは、単一画面の中で状態を持ち、入力に応じてUIが変わるところまでを扱ってきました。
しかし実際の業務アプリでは、
一覧 → 詳細 → 編集、あるいは
検索 → 結果 → 登録といったように、画面遷移を前提とした構造が必ず登場します。
このSTEPでは、Flutterにおける画面遷移の基本を押さえつつ、「なぜこの設計がWebや業務アプリと相性が良いのか」を整理していきます。
Navigatorの基本
Flutterの画面遷移は、
Navigator というスタック構造を使って管理されます。
考え方としてはとてもシンプルで、「画面をスタックに積む」「戻るときはスタックから外す」というモデルです。
Navigator.push を呼ぶと新しい画面が前面に表示され、
Navigator.pop を呼ぶと一つ前の画面に戻ります。
この構造は、Webの履歴スタックやモバイルOSの画面遷移とほぼ同じで、余計な概念を覚えなくても直感的に理解できます。
重要なのは、画面はただの "Widget" であるという点です。
特別なViewクラスやControllerが存在するわけではなく、これまで作ってきたWidgetをそのまま「次の画面」として扱えます。
画面間データ受け渡し
業務アプリでは、
画面遷移と同時にデータを渡すケースがほとんどです。
例えば、一覧画面で選択したIDを詳細画面に渡す、といった場面です。
Flutterでは、このデータ受け渡しを
コンストラクタ引数で行うのが基本になります。
画面遷移時に必要なデータを明示的に渡すため、「どの画面が何に依存しているのか」がコードから一目で分かります。
これは、グローバル変数や暗黙的な状態に頼りがちな設計と比べて、
保守性が非常に高い点です。
PHPやJavaScriptで「この画面、どこから値が来ているんだっけ？」となった経験がある人ほど、この明示性のありがたさを感じるはずです。
Web対応時の注意点
FlutterはモバイルだけでなくWebにも対応していますが、画面遷移に関して一つ意識しておきたい点があります。
それは、
URLと画面状態の関係です。
Navigator をそのまま使った場合、URLは変わらずに画面だけが切り替わります。
業務システムの管理画面や社内ツールであれば問題にならないことも多いですが、URL共有やリロード耐性が必要な場合は、ルーティング設計を一段階進める必要があります。
このシリーズではまず「仕事で使える最短距離」を優先し、このSTEPではあえて
シンプルなNavigator構成に留めます。
本格的なWebルーティングについては、後続ステップで整理する前提で問題ありません。
成果物：CRUD画面遷移構成
ここでは、
一覧 → 詳細 → 戻る、という
最小構成のCRUD風画面遷移を作ります。
ロジックを削ぎ落とし、「画面遷移の骨格」だけが見えるコードにしています。
lib/main.dart
import 'package:flutter/material.dart';
void main() {
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return const MaterialApp(
home: ListScreen(),
);
}
}
class ListScreen extends StatelessWidget {
const ListScreen({super.key});
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(title: const Text('一覧画面')),
body: ListView.builder(
itemCount: 5,
itemBuilder: (context, index) {
return ListTile(
title: Text('Item $index'),
onTap: () {
Navigator.push(
context,
MaterialPageRoute(
builder: (_) => DetailScreen(id: index),
),
);
},
);
},
),
);
}
}
class DetailScreen extends StatelessWidget {
final int id;
const DetailScreen({super.key, required this.id});
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(title: const Text('詳細画面')),
body: Center(
child: Column(
mainAxisSize: MainAxisSize.min,
children: [
Text('選択されたID: $id'),
const SizedBox(height: 16),
ElevatedButton(
onPressed: () => Navigator.pop(context),
child: const Text('戻る'),
),
],
),
),
);
}
}
このコードだけで、「一覧を選ぶ → 詳細を見る → 戻る」という業務アプリの基本動線が完成します。
画面が増えても、この構造をベースに積み上げていくだけで破綻しにくいのがFlutterの強みです。
このSTEPのまとめ
このSTEPでは、Flutterにおける画面遷移の基本を扱いました。
Navigatorの仕組みは驚くほど単純で、Widget設計の延長として自然に理解できます。
この時点で、
「単画面 + 状態管理」
「画面遷移 + データ受け渡し」
という、業務アプリに必要な最低限の構造はすでに揃っています。
次のSTEPでは、この画面構成を前提に、より実務に近い「状態のスコープ」や「画面を跨ぐ設計」を掘り下げていく予定です。
0 件のコメント:
コメントを投稿