I’m creating mobile application with Flutter.
This application has two forms (screens).
For example:
class MainScreen extends StatelessWidget {
#override
Widget build(BuildContext context) {
return Scaffold(
appBar: AdvertAppBar(context),
body: Container(…),
),
);
}
}
And
class ListScreen extends StatelessWidget {
// This widget is the root of your application.
#override
Widget build(BuildContext context) {
return Scaffold(
appBar: AdvertAppBar(context),
body: Container(…),
),
);
}
}
As you could see I’m using shared appBar which instantiates from external class (AdvertAppBar).
Is there any way to know from appBar class what the class of parent object (MainScreen or ListScreen)?
Navigator 2.0 should be able to cater this use case. I suggest using the pages argument in the Navigator constructor. This should help keeping a list of Page objects in tab and be able to update the Screen as needed. This blog post has a complete sample that you can try out.
Related
I am trying to understand why the Flutter / Dart HotReload does not work if I reference the appBar: widget as opposed to defining the code inline. Why?
Here is the sample code:
class AppBarWidget extends StatelessWidget {
#override
Widget build(BuildContext context) {
return Scaffold(
appBar: appBar,
);
}
}
AppBar appBar = AppBar(
title: new Text("App Title"),
);
Notice appBar: appBar is a reference to the AppBar(...) widget definition.
In this case, if I change the title: property text, it will not hot reload even though both IDE (VSCode or AStudio) says it reloads. I need to rebuild to make it work.
But if I move the AppBar(...) widget definition into appBar: AppBar(...) and change the title, it Hot Reloads.
This happens because Flutter's hot-reload is "stateful". It preserves the state of all variables – including the variable you defined.
As such, while you can change the sources of a variable, it will keep its previous state.
In any cases, you shouldn't extract widgets as global variables – but instead, extract them as StatelessWidget and use const constructor.
This has the same performances benefits while being compatible with hot-reload.
class MyAppBar extends StatelessWidget implements PreferredSizeWidget {
const MyAppBar({Key key}) : super(key: key);
#override
Widget build(BuildContext context) {
return AppBar(
title: const Text('App title'),
);
}
#override
Size get preferredSize => const Size.fromHeight(kToolbarHeight);
}
I'm new to Flutter and confused about how InheritedWidget works with routes. I'm using an SQLite database with the sqflite library. Basically, what I'm trying to achieve is, when my app is launched, I want all widgets that don't require the database to show right away. For instance, the bottomNavigationBar of my Scaffold doesn't need the database but the body does. So I want the bottomNavigationBar to show right away, and a CircularProgressIndicator to be shown in the body. Once the database is open, I want the body to show content loaded from the database.
So, in my attempt to achieve this, I use FutureBuilder before my Scaffold to open the database. While the Future is not completed, I pass null for the drawer and a CircularProgressBar for the body, and the bottomNavigationBar as normal. When the Future completes, I wrap the drawer and body (called HomePage) both with their own InheritedWidget (called DataAccessor). This seems to work, as I can access the DataAccessor in my HomePage widget. But, when I use the Navigator in my drawer to navigate to my SettingsScreen, my DataAccessor is not accessible and returns null.
Here's some example code, not using a database but just a 5 second delayed Future:
import 'package:flutter/material.dart';
void main() => runApp(App());
class App extends StatelessWidget {
#override
Widget build(BuildContext context) {
return MaterialApp(
home: FutureBuilder(
future: Future.delayed(Duration(seconds: 5)),
builder: (context, snapshot) {
Widget drawer;
Widget body;
if (snapshot.connectionState == ConnectionState.done) {
drawer = DataAccessor(
child: Drawer(
child: ListView(
children: <Widget>[
ListTile(
title: Text("Settings"),
onTap: () => Navigator.push(context, MaterialPageRoute(builder: (context) => SettingsScreen()))
)
]
)
)
);
body = DataAccessor(child: HomePage());
}
else {
drawer = null;
body = Center(child: CircularProgressIndicator());
}
return Scaffold(
drawer: drawer,
body: body,
bottomNavigationBar: BottomNavigationBar(
items: <BottomNavigationBarItem>[
BottomNavigationBarItem(icon: Container(), title: Text("One")),
BottomNavigationBarItem(icon: Container(), title: Text("Two"))
]
)
);
}
)
);
}
}
class HomePage extends StatelessWidget {
#override
Widget build(BuildContext context) {
DataAccessor dataAccessor = DataAccessor.of(context); //dataAccessor IS NOT null here
print("HomePage: ${dataAccessor == null}");
return Text("HomePage");
}
}
class SettingsScreen extends StatelessWidget {
#override
Widget build(BuildContext context) {
DataAccessor dataAccessor = DataAccessor.of(context); //dataAccessor IS null here
print("SettingsScreen: ${dataAccessor == null}");
return Text("SettingsScreen");
}
}
class DataAccessor extends InheritedWidget {
DataAccessor({Key key, Widget child}) : super(key: key, child: child);
#override
bool updateShouldNotify(InheritedWidget oldWidget) => false;
static DataAccessor of(BuildContext context) => context.inheritFromWidgetOfExactType(DataAccessor);
}
It's possible I'm doing things wrong. Not sure how good of practice storing widgets in variables is. Or using the same InheritedWidget twice? I've also tried wrapping the entire Scaffold with my DataAccessor (and having the database as null while it is loading), but the issue still remains where I can't get my DataAccessor in my SettingsScreen.
I've read that a possible solution is to put my InheritedWidget before the MaterialApp but I don't want to resort to this. I don't want a whole new screen to show while my database is opening, I want my widgets that don't need the database to be shown. This should be possible somehow.
Thanks!
The solution in the last paragraph is what you need. The MaterialApp contains the Navigator which manages the routes, so for all of your routes to have access to the same InheritedWidget that has to be above the Navigator, i.e. above the MaterialApp.
Use Remi's method and you end up with a widget tree like this:
MyApp (has the static .of() returning MyAppState)
MyAppState, whose build returns _MyInherited(child: MaterialApp(...)) and whose initState starts loading the database, calling setState when loaded.
When building your home page you have access to MyAppState via .of, so can ascertain whether the database has loaded or not. If it has not, just build the database independent widgets; if it has, build all the widgets.
I simply cannot make heads or tails out of this. So, this is the main widget:
import 'package:flutter/material.dart';
void main() => runApp(MyApp());
class MyApp extends StatelessWidget {
#override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Anliegen Foo',
home: Home(),
);
}
}
while the Home widget is supposed to be a stateful one and defined thus:
class Home extends StatefulWidget {
#override
_HomeState createState() => _HomeState();
}
class _HomeState extends State<Home> {
int _currentIndex = 42;
#override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: Text("Foo - $_currentIndex"),
),
body: Text('bar baz'),
);
}
}
Similarly to how the official docs recommend you do this.
You would expect the AppBar title to be "Foo - 42". But it is "Foo - 0", i.e. while the variable is found it is found to be null (and thus seemingly automatically interpreted as 0).
The debugger says that the variable exists and is set to 42, both in the context of the class and the build function.
This also goes for anything else I try to declare - Lists, strings, whatever, all not initialized but at the same time initialized.
But when I then do set the variable inside the build method like this:
#override
Widget build(BuildContext context) {
_currentIndex = 42;
[...]
now it begins to work.
So, where am I going wrong here?
Yes, thank you guys, a mere rebuild/hot restart was indeed the answer. I was thrown by the fact that the debugger shows the variable just fine with the proper value while the Widget does rely on the old class definition from before the hot reload.
tl;dr: Restart or hot restart.
The Flutter documentation for InheritedWidget says
Base class for widgets that efficiently propagate information down the tree.
To obtain the nearest instance of a particular type of inherited widget from > a build context, use BuildContext.inheritFromWidgetOfExactType.
Inherited widgets, when referenced in this way, will cause the consumer
to rebuild when the inherited widget itself changes state.
Given that widgets in Flutter are immutable, and in the example code..
class FrogColor extends InheritedWidget {
const FrogColor({
Key key,
#required this.color,
#required Widget child,
}) : assert(color != null),
assert(child != null),
super(key: key, child: child);
final Color color;
static FrogColor of(BuildContext context) {
return context.inheritFromWidgetOfExactType(FrogColor);
}
#override
bool updateShouldNotify(FrogColor old) => color != old.color;
}
the color property is final so cannot be reassigned. Assuming this widget is right at the top of the tree, as in most examples, when will this ever be useful. For the widget to be replaced, a new instance will have to be created.
Presumably where this is done, a new instance of whatever is passed as child will be created too, causing that child's descendants to also rebuild, creating new instances of its childresn etc..
Ending up with the whole tree rebuilt anyway. So the selective updating applied by using inheritFromWidgetOfExactType is pointless, when the data of an instance of InheritedWidget will never change for that instance?
Edit:
This is the simplest example of what I don't understand that I can put together.
In this example, the only way to "change" the InheritedWidget/FrogColor which is near the root of the application is to have its parent (MyApp) rebuild. This causes it to rebuild its children and create a new instance of FrogColor and which gets passed a new child instance. I don't see any other way that the InheritedWidget/FrogColor
would change its state as in the documentation
... will cause the consumer to rebuild when the inherited widget itself changes state.
import 'package:flutter/material.dart';
import 'dart:math';
void main() {
runApp(MyApp());
}
class FrogColor extends InheritedWidget {
const FrogColor({
Key key,
#required this.color,
#required Widget child,
}) : assert(color != null),
assert(child != null),
super(key: key, child: child);
final Color color;
static FrogColor of(BuildContext context) {
return context.inheritFromWidgetOfExactType(FrogColor);
}
#override
bool updateShouldNotify(FrogColor old) => color != old.color;
}
class MyApp extends StatefulWidget {
// This widget is the root of your application.
MyAppState createState() => MyAppState();
}
class MyAppState extends State<MyApp>
{
#override
Widget build(BuildContext context) {
var random = Random(DateTime.now().millisecondsSinceEpoch);
return FrogColor(
color : Color.fromARGB(255,random.nextInt(255),random.nextInt(255),random.nextInt(255)),
child:MaterialApp(
title: 'Flutter Demo',
home: Column (
children: <Widget>[
WidgetA(),
Widget1(),
FlatButton(
child:Text("set state",style:TextStyle(color:Colors.white)),
onPressed:() => this.setState((){})
)
]
)
)
);
}
}
class WidgetA extends StatelessWidget {
#override
Widget build(BuildContext context) {
print("Ran Build ${this.runtimeType.toString()}");
return WidgetB();
}
}
class WidgetB extends StatelessWidget {
#override
Widget build(BuildContext context) {
print("Ran Build ${this.runtimeType.toString()}");
return Text("SomeText",style:TextStyle(color:FrogColor.of(context).color));
}
}
class Widget1 extends StatelessWidget {
#override
Widget build(BuildContext context) {
print("Ran Build ${this.runtimeType.toString()}");
return Widget2();
}
}
class Widget2 extends StatelessWidget {
#override
Widget build(BuildContext context) {
print("Ran Build ${this.runtimeType.toString()}");
return Text("SomeText",style:TextStyle(color:FrogColor.of(context).color));
}
}
Further, the output of this is
I/flutter (24881): Ran Build WidgetA
I/flutter (24881): Ran Build WidgetB
I/flutter (24881): Ran Build Widget1
I/flutter (24881): Ran Build Widget2
So all the child widgets are always rebuilt. Making the registration done in inheritFromWidgetOfExactType pointless also.
Edit2:
In response to #RémiRousselet answer in the comments, modifying the above example, something like
class MyAppState extends State<MyApp>
{
Widget child;
MyAppState()
{
child = MaterialApp(
title: 'Flutter Demo',
home: Column (
children: <Widget>[
WidgetA(),
Widget1(),
FlatButton(
child:Text("set state",style:TextStyle(color:Colors.white)),
onPressed:() => this.setState((){})
)
]
)
);
}
#override
Widget build(BuildContext context) {
var random = Random(DateTime.now().millisecondsSinceEpoch);
return FrogColor(
color : Color.fromARGB(255,random.nextInt(255),random.nextInt(255),random.nextInt(255)),
child: child
);
}
}
works by storing the tree that shouldn't be modified outside of the build function so that the same child tree is passed to the InhertedWidget on each rebuild. This does work only causing the rebuild of the widgets that have registered with inheritFromWidgetOfExactType to get rebuilt, but not the others.
Although #RémiRousselet says it is incorrect to store the subtree as part of the state, I do not believe there is any reason that this is not ok, and infact they do this in some google tutorial videos. Here She has a subtree created and held as part of the state. In her case 2 StatelessColorfulTile() widgets.
Presumably where this is done, a new instance of whatever is passed as a child will be created too, causing that child's descendants to also rebuild, creating new instances of its children etc..
Ending up with the whole tree rebuilt anyway.
That's where your confusion comes from
A widget rebuilding doesn't force its descendants to rebuild.
When a parent rebuild, the framework internally check if newChild == oldChild, in which case the child is not rebuilt.
As such, if the instance of a widget didn't change, or if it overrides
operator== then it is possible for a widget to not rebuild when its parent is updated.
This is also one of the reasons why AnimatedBuilder offer a child property:
AnimatedBuilder(
animation: animation,
builder: (context, child) {
return Container(child: child,);
},
child: Text('Hello world'),
);
This ensures that when for the whole duration of the animation, child is preserved and therefore not rebuilt. Leading to a much more optimized UI.
I have app with two screens, and I want to make push from 1st to second screen by pressing button.
Screen 1
import 'package:flutter/material.dart';
import './view/second_page.dart';
void main() => runApp(new MyApp());
class MyApp extends StatefulWidget {
#override
State<StatefulWidget> createState() {
return new MainScreen();
}
}
class MainScreen extends State<MyApp> {
#override
void initState() {
super.initState();
}
#override
Widget build(BuildContext context) {
return new MaterialApp(
home: new Scaffold(
appBar: new AppBar(
title: new Text("Title")
),
body: new Center(
child: new FlatButton(child: new Text("Second page"),
onPressed: () {
Navigator.push(context,
new MaterialPageRoute(
builder: (context) => new SecondPage()))
}
)
)
)
);
}
}
Screen 2
import 'package:flutter/material.dart';
class SecondPage extends StatefulWidget {
#override
State<StatefulWidget> createState() {
return new SecondPageState();
}
}
class SecondPageState extends State<SecondPage> {
#override
void initState() {
super.initState();
}
#override
Widget build(BuildContext context) {
return new Scaffold(
appBar: new AppBar(
title: new Text("Title"),
),
body: new Center(
child: new Text("Some text"),
),
);
}
}
Push not happening and I got this
The following assertion was thrown while handling a gesture: Navigator
operation requested with a context that does not include a Navigator.
The context used to push or pop routes from the Navigator must be that
of a widget that is a descendant of a Navigator widget.
Another exception was thrown: Navigator operation requested with a
context that does not include a Navigator.
What is wrong?
Think of the widgets in Flutter as a tree, with the context pointing to whichever node is being built with the build function. In your case, you have
MainScreen <------ context
--> MaterialApp
(--> Navigator built within MaterialApp)
--> Scaffold
--> App Bar
--> ...
--> Center
--> FlatButton
So when you're using the context to find the Navigator, you're using a context for the MainScreen which isn't under the navigator.
You can either make a new Stateless or Stateful Widget subclass to contain your Center + FlatButton, as the build function within those will point at that level instead, or you can use a Builder and define the builder callback (which has a context pointing at the Builder) to return the Center + FlatButton.
Just make the MaterialApp class in main method as this example
void main() => runApp(MaterialApp(home: FooClass(),));
it works fine for me,
I hope it will work with you
There are two main reasons why the route cannot be found.
1) The Route is defined below the context passed to Navigator.of(context) - scenario which #rmtmackenzie has explained
2) The Route is defined on the sibling branch e.g.
Root
-> Content (Routes e.g. Home/Profile/Basket/Search)
-> Navigation (we want to dispatch from here)
If we want to dispatch a route from the Navigation widget, we have to know the reference to the NavigatorState. Having a global reference is expensive, especially when you intend to move widget around the tree. https://docs.flutter.io/flutter/widgets/GlobalKey-class.html. Use it only where there is no way to get it from Navigator.of(context).
To use a GlobalKey inside the MaterialApp define navigatorKey
final navigatorKey = GlobalKey<NavigatorState>();
Widget build(BuildContext context) => MaterialApp {
navigatorKey: navigatorKey
onGenerateRoute : .....
};
Now anywhere in the app where you pass the navigatorKey you can now invoke
navigatorKey.currentState.push(....);
Just posted about it https://medium.com/#swav.kulinski/flutter-navigating-off-the-charts-e118562a36a5
There is an another very different work around about this issue, If you are using Alarm Manager (Android), and open back to your Application. If you haven't turned on the screen before navigation, the navigator will never work. Although this is a rare usage, I think It should be a worth to know.
Make sure the route table mentioned in the same context:
#override
Widget build(BuildContext context) {
return MaterialApp(
home: FutureBuilder(
future: _isUserLoggedIn(),
builder: (ctx, loginSnapshot) =>
loginSnapshot.connectionState == ConnectionState.waiting ?
SplashScreen() : loginSnapshot.data == true ? AppLandingScreen(): SignUpScreen()
),
routes: {
AppLandingScreen.routeName: (ctx) => AppLandingScreen(),
},
);
}
I faced this issue because I defined the route table in different build method.
Am a newbie and have spent two days trying to get over the Navigtor objet linking to a black a screen.
The issue causing this was dublicated dummy data. Find Bellow the two dummny data blocks:
**Problematic data **- duplicate assets/image:
_buildFoodItem('assets/plate1.png', 'Salmon bowl', '\$24'),
_buildFoodItem('assets/plate2.png', 'Spring bowl', '\$13'),
_buildFoodItem('assets/plate1.png', 'Salmon bowl', '\$24'),
_buildFoodItem('assets/plate5.png', 'Berry bowl', '\$34'),
**Solution **- after eliminating duplicated image argument:
_buildFoodItem('assets/plate1.png', 'Salmon bowl', '\$24'),
_buildFoodItem('assets/plate2.png', 'Spring bowl', '\$13'),
_buildFoodItem('assets/plate6.png', 'Avocado bowl', '\$34'),
I hope this helps someone,,,,,,,
If the navigator is not working, it can be due to many reasons but the major one is that the navigator not finds the context.
So, to solve this issue try to wrap your widget inside Builder because the builder has its own context...