Passing Data Between Screens

Passing Data Between Screens

Nearly every real-world Flutter app needs to pass information from one screen to another. A product listing page must send a product ID to the detail page; a login form must hand a user token to the home screen; a settings screen must return the user’s chosen theme back to the caller. Flutter gives you two clean mechanisms for this: passing data forward via constructor arguments when you push a route, and returning data backward via Navigator.pop() when you pop a route.

Passing Data Forward to a New Screen

When you push a new route with Navigator.push(), you create an instance of the destination widget directly. The cleanest way to send data is to add required constructor parameters to that widget. The caller fills them in at push time, and the destination reads them from widget.fieldName (in a StatefulWidget) or directly from constructor fields (in a StatelessWidget).

// 1. Define a simple data class
class Product {
  final int id;
  final String name;
  final double price;

  const Product({required this.id, required this.name, required this.price});
}

// 2. The destination screen accepts data via constructor
class ProductDetailScreen extends StatelessWidget {
  final Product product;

  const ProductDetailScreen({super.key, required this.product});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text(product.name)),
      body: Padding(
        padding: const EdgeInsets.all(16.0),
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: [
            Text('ID: ${product.id}'),
            Text('Price: \$${product.price.toStringAsFixed(2)}'),
          ],
        ),
      ),
    );
  }
}

// 3. The caller pushes the route and passes data
void _openProduct(BuildContext context, Product product) {
  Navigator.push(
    context,
    MaterialPageRoute(
      builder: (context) => ProductDetailScreen(product: product),
    ),
  );
}

This approach is type-safe: the Dart compiler enforces that all required fields are provided. There is no stringly-typed key lookup, no casting, and no risk of passing the wrong type.

Returning Data Back to the Calling Screen

Sometimes the new screen collects information (a selected date, a confirmation boolean, a form result) that the caller needs after the user navigates back. Navigator.pop() accepts an optional result value. On the calling side, Navigator.push() returns a Future that resolves with that result when the route is popped.

// Picker screen: pops with the chosen color string
class ColorPickerScreen extends StatelessWidget {
  const ColorPickerScreen({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Pick a Color')),
      body: Column(
        children: [
          ListTile(
            title: const Text('Red'),
            onTap: () => Navigator.pop(context, 'red'),
          ),
          ListTile(
            title: const Text('Green'),
            onTap: () => Navigator.pop(context, 'green'),
          ),
          ListTile(
            title: const Text('Blue'),
            onTap: () => Navigator.pop(context, 'blue'),
          ),
        ],
      ),
    );
  }
}

// Caller screen: awaits the Future returned by Navigator.push()
class HomeScreen extends StatefulWidget {
  const HomeScreen({super.key});

  @override
  State<HomeScreen> createState() => _HomeScreenState();
}

class _HomeScreenState extends State<HomeScreen> {
  String _selectedColor = 'none';

  Future<void> _openColorPicker() async {
    final String? result = await Navigator.push<String>(
      context,
      MaterialPageRoute(builder: (context) => const ColorPickerScreen()),
    );

    // result is null if the user pressed the system Back button
    // without calling Navigator.pop(context, value)
    if (result != null) {
      setState(() {
        _selectedColor = result;
      });
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Home')),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Text('Selected color: $_selectedColor'),
            const SizedBox(height: 16),
            ElevatedButton(
              onPressed: _openColorPicker,
              child: const Text('Pick a Color'),
            ),
          ],
        ),
      ),
    );
  }
}

Passing Data with Named Routes

When you use named routes (defined in MaterialApp.routes), you cannot pass constructor arguments directly. Instead, use Navigator.pushNamed() with the arguments parameter and retrieve them inside the destination with ModalRoute.of(context)!.settings.arguments.

// Sending data with pushNamed
Navigator.pushNamed(
  context,
  '/product-detail',
  arguments: product,   // any Object
);

// Receiving data inside the destination widget
@override
Widget build(BuildContext context) {
  final product =
      ModalRoute.of(context)!.settings.arguments as Product;

  return Scaffold(
    appBar: AppBar(title: Text(product.name)),
    body: Text('Price: \$${product.price}'),
  );
}

Summary

Flutter gives you straightforward, idiomatic patterns for screen-to-screen data flow:

• Forward: Add required constructor parameters to the destination widget and pass values when calling Navigator.push().
• Backward: Call Navigator.pop(context, result) in the destination; await Navigator.push() in the caller to receive the result.
• Named routes: Use the arguments parameter of pushNamed() and retrieve with ModalRoute.of(context)!.settings.arguments, casting to the expected type.
• Always guard against a null result when awaiting a pushed route — the user may navigate back without supplying one.