AppBar action needs a key to see its own Scaffold

[This is an instance of a general issue and it could equally well be titled: 'Patterns for referring (using .of) to widgets introduced in the same build function']

Apps commonly have a single widget that contains a Scaffold and an AppBar. It's inconvenient that the AppBar's actions can't refer to the Scaffold directly. This can be overcome by providing the Scaffold with a key as in the example below.

It would be convenient if Scaffold.of(context) would return the Scaffold contained by context if there was no Scaffold ancestor.

Creating a GlobalKey to refer to the Scaffold can be fraught, see #4579.

import 'package:flutter/material.dart';

class Home extends StatelessWidget {

  // The AppBar's action needs this key to find its own Scaffold.
  final GlobalKey<ScaffoldState> _scaffoldKey = new GlobalKey<ScaffoldState>();

  @override
  Widget build(BuildContext context) {
    return new Scaffold(
      key: _scaffoldKey,
      appBar: new AppBar(
        title: new Text('Home'),
        actions: <Widget>[
          new IconButton(
            icon: Icons.shopping_cart,
            onPressed: () {
              // Scaffold.of(context) == null because our context contains
              // Scaffold. So we have to give the Scaffold a GlobalKey
              // and use it here.
              _scaffoldKey.currentState.showSnackBar(new SnackBar(
                content: new Text('$_scaffoldKey')
              ));
            }
          )
        ]
      ),
      body: new Center(child: new Text('Click the shopping cart'))
    );
  }
}

void main() {
  runApp(new MaterialApp(home: new Home()));
}

I'm running into the same issue. The workaround works but I'd still prefer snackbar can find its own scaffold without a global key.

One workaround is to put a Builder widget in the tree and use its context instead.

something like:

  @override
  Widget build(BuildContext context) {
    return new Scaffold(
      key: _scaffoldKey,
      appBar: new Builder(
        builder: (BuildContext context) { // <-- new widget inserted here
          return new AppBar(
            title: new Text('Home'),
            actions: <Widget>[
              new IconButton(
                icon: Icons.shopping_cart,
                onPressed: () {
                  // here "context" is from the Builder closure, so it's under the Scaffold
                  Scaffold.of(context).showSnackBar(new SnackBar(
                    content: new Text('$_scaffoldKey')
                  ));
                }
              )
            ]
          );
        },
      ),
      body: new Center(child: new Text('Click the shopping cart'))
    );
  }

This is a general issue, not really specific to AppBar. GlobalKey and Builder are the current state of the art solutions. If GlobalKey and Builder are not sufficient, please reopen this bug with more information explaining why.

This is in fact an AppBar issue because the type of Scaffold's AppBar is AppBar, not Widget. The suggested workaround doesn't compile.

Hopefully the "great Scrollable refactor" will eliminate this issue.

Still a problem but likely a trivial fix now.

I'm closing the original issue, since we're not planning to do anything about it.

I've opened a new issue, #9349, which covers the problem this issue had morphed into (the type of Scaffold's appBar property is AppBar not Widget).

Update dart in engine to version 8d9d68751a505426eb5f59a9d29f103fde6b…

Hi, I dit it, work for me :)

@override
Widget build(BuildContext context) {
  return new Scaffold(
    appBar: new AppBar(
      title: new Text('Demo')
    ),
    body: new Builder(
      // Create an inner BuildContext so that the onPressed methods
      // can refer to the Scaffold with Scaffold.of().
      builder: (BuildContext context) {
        return new Center(
          child: new RaisedButton(
            child: new Text('SHOW A SNACKBAR'),
            onPressed: () {
              Scaffold.of(context).showSnackBar(new SnackBar(
                content: new Text('Hello!'),
              ));
            },
          ),
        );
      },
    ),
  );
}

@Hixie

@Hixie Putting builder on appBar triggers this error.

Can you post your actual code? (Maybe file a new bug.)

In general appBar needs the widget to implement PreferredSizeWidget (e.g. it could be a PreferredSize widget or an AppBar), but exactly what you do to work around that depends on what you're trying to do.

Here's how I solved showing a ShackBar via AppBar, hopefully this is the correct use of PreferredSizeWidget.

appBar: PreferredSize(
  preferredSize: Size.fromHeight(kToolbarHeight),
  child: Builder(
    builder: (context) => AppBar(...),
  ),
),

Another alternative is to wrap things inside AppBar with a Builder each. This works for me:

    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
        actions: <Widget>[
          Builder(builder: (context) {
            return IconButton(
              icon: Icon(Icons.edit),
              onPressed: () {
                try{
                  print(Scaffold.of(context));
                } catch (e) {
                  print(e);
                }
              },
            );
          }),
        ],
      ),

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

AppBar action needs a key to see its own Scaffold #4581

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

AppBar action needs a key to see its own Scaffold #4581

Description

Activity

vy0592 commented on Oct 14, 2016

Hixie commented on Oct 14, 2016

Hixie commented on Oct 14, 2016

Hixie commented on Dec 29, 2016

HansMuller commented on Jan 6, 2017

abarth commented on Feb 10, 2017

HansMuller commented on Apr 12, 2017

fabiomotiws commented on Sep 13, 2018

kszyrvercobrador commented on Sep 18, 2018

Hixie commented on Oct 2, 2018

eddiegroves commented on Dec 10, 2018

gazialankus commented on Dec 31, 2018

github-actions commented on Aug 31, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions