class _NewsState extends State<News> with AutomaticKeepAliveClientMixin
@override
bool get wantKeepAlive => true;
出現如下問題
build提示如下
Widget build(BuildContext context)
package:lzdres/article/list_view.dart
Describes the part of the user interface represented by this widget.
The framework calls this method in a number of different situations:
After calling [initState].
After calling [didUpdateWidget].
After receiving a call to [setState].
After a dependency of this [State] object changes (e.g., an [InheritedWidget] referenced by the previous [build] changes).
After calling [deactivate] and then reinserting the [State] object into the tree at another location.
The framework replaces the subtree below this widget with the widget returned by this method, either by updating the existing subtree or by removing the subtree and inflating a new subtree, depending on whether the widget returned by this method can update the root of the existing subtree, as determined by calling [Widget.canUpdate].
Typically implementations return a newly created constellation of widgets that are configured with information from this widget's constructor, the given [BuildContext], and the internal state of this [State] object.
The given [BuildContext] contains information about the location in the tree at which this widget is being built. For example, the context provides the set of inherited widgets for this location in the tree. The [BuildContext] argument is always the same as the [context] property of this [State] object and will remain the same for the lifetime of this object. The [BuildContext] argument is provided redundantly here so that this method matches the signature for a [WidgetBuilder].
Design discussion
Why is the [build] method on [State], and not [StatefulWidget]?
Putting a Widget build(BuildContext context) method on [State] rather than putting a Widget build(BuildContext context, State state) method on [StatefulWidget] gives developers more flexibility when subclassing [StatefulWidget].
For example, [AnimatedWidget] is a subclass of [StatefulWidget] that introduces an abstract Widget build(BuildContext context) method for its subclasses to implement. If [StatefulWidget] already had a [build] method that took a [State] argument, [AnimatedWidget] would be forced to provide its [State] object to subclasses even though its [State] object is an internal implementation detail of [AnimatedWidget].
Conceptually, [StatelessWidget] could also be implemented as a subclass of [StatefulWidget] in a similar manner. If the [build] method were on [StatefulWidget] rather than [State], that would not be possible anymore.
Putting the [build] function on [State] rather than [StatefulWidget] also helps avoid a category of bugs related to closures implicitly capturing this. If you defined a closure in a [build] function on a [StatefulWidget], that closure would implicitly capture this, which is the current widget instance, and would have the (immutable) fields of that instance in scope:
class MyButton extends StatefulWidget {
...
final Color color;
@override
Widget build(BuildContext context, MyButtonState state) {
... () { print("color: $color"); } ...
}
}
For example, suppose the parent builds MyButton with color being blue, the $color in the print function refers to blue, as expected. Now, suppose the parent rebuilds MyButton with green. The closure created by the first build still implicitly refers to the original widget and the $color still prints blue even through the widget has been updated to green.
In contrast, with the [build] function on the [State] object, closures created during [build] implicitly capture the [State] instance instead of the widget instance:
class MyButtonState extends State<MyButton> {
...
@override
Widget build(BuildContext context) {
... () { print("color: ${widget.color}"); } ...
}
}
Now when the parent rebuilds MyButton with green, the closure created by the first build still refers to [State] object, which is preserved across rebuilds, but the framework has updated that [State] object's [widget] property to refer to the new MyButton instance and ${widget.color} prints green, as expected.
See also:
[StatefulWidget], which contains the discussion on performance considerations.
Copied from State.
This method overrides a method annotated as @mustCallSuper in 'AutomaticKeepAliveClientMixin', but doesn't invoke the overridden method.dart(must_call_super)
有沒有大佬告知一下怎么解決，這個是為什么
uj5u.com熱心網友回復：
添加AutomaticKeepAliveClientMixin，并實作對應的方法bool get wantKeepAlive => true;，同時build方法實作父方法 super.build(context);class _Page1State extends State<Page1> with AutomaticKeepAliveClientMixin {
@override
void initState() {
super.initState();
print("Page 1 init");
}
@override
Widget build(BuildContext context) {
super.build(context);
return Text("Page 1");
}
@override
bool get wantKeepAlive => true;
}
uj5u.com熱心網友回復：
不好意思，沒有用過flutter，還有就是為啥會邀請我呢，嘿嘿uj5u.com熱心網友回復：
你發出來的代碼是沒有問題的
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/94175.html
標籤：Android