flutter开发之状态管理、路由管理、
2.3 状态管理
#2.3.1 简介
响应式的编程框架中都会有一个永恒的主题——“状态(State)管理”，无论是在 React/Vue（两者都是支持响应式编程的 Web 开发框架）还是 Flutter 中，他们讨论的问题和解决的思想都是一致的。所以，如果你对React/Vue的状态管理有了解，可以跳过本节。言归正传，我们想一个问题，StatefulWidget的状态应该被谁管理？Widget本身？父 Widget ？都会？还是另一个对象？答案是取决于实际情况！以下是管理状态的最常见的方法：
- Widget 管理自己的状态。
- Widget 管理子 Widget 状态。
- 混合管理（父 Widget 和子 Widget 都管理状态）。
如何决定使用哪种管理方法？下面是官方给出的一些原则可以帮助你做决定：
- 如果状态是用户数据，如复选框的选中状态、滑块的位置，则该状态最好由父 Widget 管理。
- 如果状态是有关界面外观效果的，例如颜色、动画，那么状态最好由 Widget 本身来管理。
- 如果某一个状态是不同 Widget 共享的则最好由它们共同的父 Widget 管理。
在 Widget 内部管理状态封装性会好一些，而在父 Widget 中管理会比较灵活。有些时候，如果不确定到底该怎么管理状态，那么推荐的首选是在父 Widget 中管理（灵活会显得更重要一些）。
接下来，我们将通过创建三个简单示例TapboxA、TapboxB和TapboxC来说明管理状态的不同方式。 这些例子功能是相似的 ——创建一个盒子，当点击它时，盒子背景会在绿色与灰色之间切换。状态 _active确定颜色：绿色为true ，灰色为false，如图2-8所示：
下面的例子将使用GestureDetector来识别点击事件，关于该GestureDetector的详细内容我们将在后面“事件处理”一章中介绍。
#2.3.2 Widget管理自身状态
我们实现一个TapboxA，在它对应的_TapboxAState 类:
- 管理TapboxA的状态。
- 定义
_active：确定盒子的当前颜色的布尔值。 - 定义
_handleTap()函数，该函数在点击该盒子时更新_active，并调用setState()更新UI。 - 实现widget的所有交互式行为。
// TapboxA 管理自身状态.
//------------------------- TapboxA ----------------------------------
class TapboxA extends StatefulWidget {
TapboxA({Key? key}) : super(key: key);
@override
_TapboxAState createState() => _TapboxAState();
}
class _TapboxAState extends State {
bool _active = false;
void _handleTap() {
setState(() {
_active = !_active;
});
}
Widget build(BuildContext context) {
return GestureDetector(
onTap: _handleTap,
child: Container(
child: Center(
child: Text(
_active ? 'Active' : 'Inactive',
style: TextStyle(fontSize: 32.0, color: Colors.white),
),
),
width: 200.0,
height: 200.0,
decoration: BoxDecoration(
color: _active ? Colors.lightGreen[700] : Colors.grey[600],
),
),
);
}
}
#2.3.3 父Widget管理子Widget的状态
对于父Widget来说，管理状态并告诉其子Widget何时更新通常是比较好的方式。 例如，IconButton是一个图标按钮，但它是一个无状态的Widget，因为我们认为父Widget需要知道该按钮是否被点击来采取相应的处理。
在以下示例中，TapboxB通过回调将其状态导出到其父组件，状态由父组件管理，因此它的父组件为StatefulWidget。但是由于TapboxB不管理任何状态，所以TapboxB为StatelessWidget。
ParentWidgetState 类:
- 为TapboxB 管理
_active状态。 - 实现
_handleTapboxChanged()，当盒子被点击时调用的方法。 - 当状态改变时，调用
setState()更新UI。
TapboxB 类:
- 继承
StatelessWidget类，因为所有状态都由其父组件处理。 - 当检测到点击时，它会通知父组件。
// ParentWidget 为 TapboxB 管理状态.
//------------------------ ParentWidget --------------------------------
class ParentWidget extends StatefulWidget {
@override
_ParentWidgetState createState() => _ParentWidgetState();
}
class _ParentWidgetState extends State {
bool _active = false;
void _handleTapboxChanged(bool newValue) {
setState(() {
_active = newValue;
});
}
@override
Widget build(BuildContext context) {
return Container(
child: TapboxB(
active: _active,
onChanged: _handleTapboxChanged,
),
);
}
}
//------------------------- TapboxB ----------------------------------
class TapboxB extends StatelessWidget {
TapboxB({Key? key, this.active: false, required this.onChanged})
: super(key: key);
final bool active;
final ValueChanged onChanged;
void _handleTap() {
onChanged(!active);
}
Widget build(BuildContext context) {
return GestureDetector(
onTap: _handleTap,
child: Container(
child: Center(
child: Text(
active ? 'Active' : 'Inactive',
style: TextStyle(fontSize: 32.0, color: Colors.white),
),
),
width: 200.0,
height: 200.0,
decoration: BoxDecoration(
color: active ? Colors.lightGreen[700] : Colors.grey[600],
),
),
);
}
}
#2.3.4 混合状态管理
对于一些组件来说，混合管理的方式会非常有用。在这种情况下，组件自身管理一些内部状态，而父组件管理一些其他外部状态。
在下面 TapboxC 示例中，手指按下时，盒子的周围会出现一个深绿色的边框，抬起时，边框消失。点击完成后，盒子的颜色改变。 TapboxC 将其_active状态导出到其父组件中，但在内部管理其_highlight状态。这个例子有两个状态对象_ParentWidgetState和_TapboxCState。
_ParentWidgetStateC类:
- 管理
_active状态。 - 实现
_handleTapboxChanged()，当盒子被点击时调用。 - 当点击盒子并且
_active状态改变时调用setState()更新UI。
_TapboxCState 对象:
- 管理
_highlight状态。 GestureDetector监听所有tap事件。当用户点下时，它添加高亮（深绿色边框）；当用户释放时，会移除高亮。- 当按下、抬起、或者取消点击时更新
_highlight状态，调用setState()更新UI。 - 当点击时，将状态的改变传递给父组件。
//---------------------------- ParentWidget ----------------------------
class ParentWidgetC extends StatefulWidget {
@override
_ParentWidgetCState createState() => _ParentWidgetCState();
}
class _ParentWidgetCState extends State {
bool _active = false;
void _handleTapboxChanged(bool newValue) {
setState(() {
_active = newValue;
});
}
@override
Widget build(BuildContext context) {
return Container(
child: TapboxC(
active: _active,
onChanged: _handleTapboxChanged,
),
);
}
}
//----------------------------- TapboxC ------------------------------
class TapboxC extends StatefulWidget {
TapboxC({Key? key, this.active: false, required this.onChanged})
: super(key: key);
final bool active;
final ValueChanged onChanged;
@override
_TapboxCState createState() => _TapboxCState();
}
class _TapboxCState extends State {
bool _highlight = false;
void _handleTapDown(TapDownDetails details) {
setState(() {
_highlight = true;
});
}
void _handleTapUp(TapUpDetails details) {
setState(() {
_highlight = false;
});
}
void _handleTapCancel() {
setState(() {
_highlight = false;
});
}
void _handleTap() {
widget.onChanged(!widget.active);
}
@override
Widget build(BuildContext context) {
// 在按下时添加绿色边框，当抬起时，取消高亮
return GestureDetector(
onTapDown: _handleTapDown, // 处理按下事件
onTapUp: _handleTapUp, // 处理抬起事件
onTap: _handleTap,
onTapCancel: _handleTapCancel,
child: Container(
child: Center(
child: Text(
widget.active ? 'Active' : 'Inactive',
style: TextStyle(fontSize: 32.0, color: Colors.white),
),
),
width: 200.0,
height: 200.0,
decoration: BoxDecoration(
color: widget.active ? Colors.lightGreen[700] : Colors.grey[600],
border: _highlight
? Border.all(
color: Colors.teal[700],
width: 10.0,
)
: null,
),
),
);
}
}
另一种实现可能会将高亮状态导出到父组件，但同时保持_active状态为内部状态，但如果你要将该TapBox 给其他人使用，可能没有什么意义。 开发人员只会关心该框是否处于 Active 状态，而不在乎高亮显示是如何管理的，所以应该让 TapBox 内部处理这些细节。
#2.3.5 全局状态管理
当应用中需要一些跨组件（包括跨路由）的状态需要同步时，上面介绍的方法便很难胜任了。比如，我们有一个设置页，里面可以设置应用的语言，我们为了让设置实时生效，我们期望在语言状态发生改变时，App中依赖应用语言的组件能够重新 build 一下，但这些依赖应用语言的组件和设置页并不在一起，所以这种情况用上面的方法很难管理。这时，正确的做法是通过一个全局状态管理器来处理这种相距较远的组件之间的通信。目前主要有两种办法：
- 实现一个全局的事件总线，将语言状态改变对应为一个事件，然后在APP中依赖应用语言的组件的
initState方法中订阅语言改变的事件。当用户在设置页切换语言后，我们发布语言改变事件，而订阅了此事件的组件就会收到通知，收到通知后调用setState(...)方法重新build一下自身即可。 - 使用一些专门用于状态管理的包，如 Provider、Redux，读者可以在 pub 上查看其详细信息。
2.4 路由管理
路由（Route）在移动开发中通常指页面（Page），这跟 Web 开发中单页应用的 Route 概念意义是相同的，Route 在 Android中 通常指一个 Activity，在 iOS 中指一个 ViewController。所谓路由管理，就是管理页面之间如何跳转，通常也可被称为导航管理。Flutter 中的路由管理和原生开发类似，无论是 Android 还是 iOS，导航管理都会维护一个路由栈，路由入栈（push）操作对应打开一个新页面，路由出栈（pop）操作对应页面关闭操作，而路由管理主要是指如何来管理路由栈。
#2.4.1 一个简单示例
我们在2.1节“计数器”示例的基础上，做如下修改：
-
创建一个新路由，命名“NewRoute”
class NewRoute extends StatelessWidget { @override Widget build(BuildContext context) { return Scaffold( appBar: AppBar( title: Text("New route"), ), body: Center( child: Text("This is new route"), ), ); } }新路由继承自
StatelessWidget，界面很简单，在页面中间显示一句"This is new route"。 -
在
_MyHomePageState.build方法中的Column的子widget中添加一个按钮（TextButton） :Column( mainAxisAlignment: MainAxisAlignment.center, children:[ ... //省略无关代码 TextButton( child: Text("open new route"), onPressed: () { //导航到新路由 Navigator.push( context, MaterialPageRoute(builder: (context) { return NewRoute(); }), ); }, ), ], ) 我们添加了一个打开新路由的按钮，点击该按钮后就会打开新的路由页面，效果如图 2-9 和 2-10 所示。
#2.4.2 MaterialPageRoute
MaterialPageRoute继承自PageRoute类，PageRoute类是一个抽象类，表示占有整个屏幕空间的一个模态路由页面，它还定义了路由构建及切换时过渡动画的相关接口及属性。MaterialPageRoute 是 Material组件库提供的组件，它可以针对不同平台，实现与平台页面切换动画风格一致的路由切换动画：
- 对于 Android，当打开新页面时，新的页面会从屏幕底部滑动到屏幕顶部；当关闭页面时，当前页面会从屏幕顶部滑动到屏幕底部后消失，同时上一个页面会显示到屏幕上。
- 对于 iOS，当打开页面时，新的页面会从屏幕右侧边缘一直滑动到屏幕左边，直到新页面全部显示到屏幕上，而上一个页面则会从当前屏幕滑动到屏幕左侧而消失；当关闭页面时，正好相反，当前页面会从屏幕右侧滑出，同时上一个页面会从屏幕左侧滑入。
下面我们介绍一下MaterialPageRoute 构造函数的各个参数的意义：
MaterialPageRoute({
WidgetBuilder builder,
RouteSettings settings,
bool maintainState = true,
bool fullscreenDialog = false,
})
builder是一个WidgetBuilder类型的回调函数，它的作用是构建路由页面的具体内容，返回值是一个widget。我们通常要实现此回调，返回新路由的实例。settings包含路由的配置信息，如路由名称、是否初始路由（首页）。maintainState：默认情况下，当入栈一个新路由时，原来的路由仍然会被保存在内存中，如果想在路由没用的时候释放其所占用的所有资源，可以设置maintainState为false。fullscreenDialog表示新的路由页面是否是一个全屏的模态对话框，在 iOS 中，如果fullscreenDialog为true，新页面将会从屏幕底部滑入（而不是水平方向）。
如果想自定义路由切换动画，可以自己继承 PageRoute 来实现，我们将在后面介绍动画时，实现一个自定义的路由组件。
#2.4.3 Navigator
Navigator是一个路由管理的组件，它提供了打开和退出路由页方法。Navigator通过一个栈来管理活动路由集合。通常当前屏幕显示的页面就是栈顶的路由。Navigator提供了一系列方法来管理路由栈，在此我们只介绍其最常用的两个方法：
#1. Future push(BuildContext context, Route route)
将给定的路由入栈（即打开新的页面），返回值是一个Future对象，用以接收新路由出栈（即关闭）时的返回数据。
#2. bool pop(BuildContext context, [ result ])
将栈顶路由出栈，result 为页面关闭时返回给上一个页面的数据。
Navigator 还有很多其他方法，如Navigator.replace、Navigator.popUntil等，详情请参考API文档或SDK 源码注释，在此不再赘述。下面我们还需要介绍一下路由相关的另一个概念“命名路由”。
#3. 实例方法
Navigator类中第一个参数为context的静态方法都对应一个Navigator的实例方法， 比如Navigator.push(BuildContext context, Route route)等价于Navigator.of(context).push(Route route) ，下面命名路由相关的方法也是一样的。
#2.4.4 路由传值
很多时候，在路由跳转时我们需要带一些参数，比如打开商品详情页时，我们需要带一个商品id，这样商品详情页才知道展示哪个商品信息；又比如我们在填写订单时需要选择收货地址，打开地址选择页并选择地址后，可以将用户选择的地址返回到订单页等等。下面我们通过一个简单的示例来演示新旧路由如何传参。
下面我们通过一个例子来演示：创建一个TipRoute路由，它接受一个提示文本参数，负责将传入它的文本显示在页面上，另外TipRoute中我们添加一个“返回”按钮，点击后在返回上一个路由的同时会带上一个返回参数，下面我们看一下实现代码。
TipRoute实现代码：
class TipRoute extends StatelessWidget {
TipRoute({
Key key,
required this.text, // 接收一个text参数
}) : super(key: key);
final String text;
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: Text("提示"),
),
body: Padding(
padding: EdgeInsets.all(18),
child: Center(
child: Column(
children: [
Text(text),
ElevatedButton(
onPressed: () => Navigator.pop(context, "我是返回值"),
child: Text("返回"),
)
],
),
),
),
);
}
}
下面是打开新路由TipRoute的代码：
class RouterTestRoute extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Center(
child: ElevatedButton(
onPressed: () async {
// 打开`TipRoute`，并等待返回结果
var result = await Navigator.push(
context,
MaterialPageRoute(
builder: (context) {
return TipRoute(
// 路由参数
text: "我是提示xxxx",
);
},
),
);
//输出`TipRoute`路由返回结果
print("路由返回值: $result");
},
child: Text("打开提示页"),
),
);
}
}
运行上面代码，点击RouterTestRoute页的“打开提示页”按钮，会打开TipRoute页，运行效果如图2-11所示下：
需要说明：
-
提示文案“我是提示xxxx”是通过
TipRoute的text参数传递给新路由页的。我们可以通过等待Navigator.push(…)返回的Future来获取新路由的返回数据。 -
在
TipRoute页中有两种方式可以返回到上一页；第一种方式是直接点击导航栏返回箭头，第二种方式是点击页面中的“返回”按钮。这两种返回方式的区别是前者不会返回数据给上一个路由，而后者会。下面是分别点击页面中的返回按钮和导航栏返回箭头后，RouterTestRoute页中print方法在控制台输出的内容：I/flutter (27896): 路由返回值: 我是返回值 I/flutter (27896): 路由返回值: null
上面介绍的是非命名路由的传值方式，命名路由的传值方式会有所不同，我们会在下面介绍命名路由时介绍。
#2.4.5 命名路由
所谓“命名路由”（Named Route）即有名字的路由，我们可以先给路由起一个名字，然后就可以通过路由名字直接打开新的路由了，这为路由管理带来了一种直观、简单的方式。
#1. 路由表
要想使用命名路由，我们必须先提供并注册一个路由表（routing table），这样应用程序才知道哪个名字与哪个路由组件相对应。其实注册路由表就是给路由起名字，路由表的定义如下：
Map routes;
它是一个Map，key为路由的名字，是个字符串；value是个builder回调函数，用于生成相应的路由widget。我们在通过路由名字打开新路由时，应用会根据路由名字在路由表中查找到对应的WidgetBuilder回调函数，然后调用该回调函数生成路由widget并返回。
#2. 注册路由表
路由表的注册方式很简单，我们回到之前“计数器”的示例，然后在MyApp类的build方法中找到MaterialApp，添加routes属性，代码如下：
MaterialApp(
title: 'Flutter Demo',
theme: ThemeData(
primarySwatch: Colors.blue,
),
//注册路由表
routes:{
"new_page":(context) => NewRoute(),
... // 省略其他路由注册信息
} ,
home: MyHomePage(title: 'Flutter Demo Home Page'),
);
现在我们就完成了路由表的注册。上面的代码中home路由并没有使用命名路由，如果我们也想将home注册为命名路由应该怎么做呢？其实很简单，直接看代码：
MaterialApp(
title: 'Flutter Demo',
initialRoute:"/", //名为"/"的路由作为应用的home(首页)
theme: ThemeData(
primarySwatch: Colors.blue,
),
//注册路由表
routes:{
"new_page":(context) => NewRoute(),
"/":(context) => MyHomePage(title: 'Flutter Demo Home Page'), //注册首页路由
}
);
可以看到，我们只需在路由表中注册一下MyHomePage路由，然后将其名字作为MaterialApp的initialRoute属性值即可，该属性决定应用的初始路由页是哪一个命名路由。
- 路由名称：
"/"是默认的初始路由（通过initialRoute指定）。
#3. 通过路由名打开新路由页
要通过路由名称来打开新路由，可以使用Navigator 的pushNamed方法：
Future pushNamed(BuildContext context, String routeName,{Object arguments})
Navigator 除了pushNamed方法，还有pushReplacementNamed等其他管理命名路由的方法，读者可以自行查看API文档。接下来我们通过路由名来打开新的路由页，修改TextButton的onPressed回调代码，改为：
onPressed: () {
Navigator.pushNamed(context, "new_page");
//Navigator.push(context,
// MaterialPageRoute(builder: (context) {
// return NewRoute();
//}));
},
热重载应用，再次点击“open new route”按钮，依然可以打开新的路由页。
#4. 命名路由参数传递
在Flutter最初的版本中，命名路由是不能传递参数的，后来才支持了参数；下面展示命名路由如何传递并获取路由参数：
我们先注册一个路由：
routes:{
"new_page":(context) => EchoRoute(),
} ,
在路由页通过RouteSetting对象获取路由参数：
class EchoRoute extends StatelessWidget {
@override
Widget build(BuildContext context) {
//获取路由参数
var args=ModalRoute.of(context).settings.arguments;
//...省略无关代码
}
}
在打开路由时传递参数
Navigator.of(context).pushNamed("new_page", arguments: "hi");
#5. 适配
假设我们也想将上面路由传参示例中的TipRoute路由页注册到路由表中，以便也可以通过路由名来打开它。但是，由于TipRoute接受一个text 参数，我们如何在不改变TipRoute源码的前提下适配这种情况？其实很简单：
MaterialApp(
... //省略无关代码
routes: {
"tip2": (context){
return TipRoute(text: ModalRoute.of(context)!.settings.arguments);
},
},
);
#2.4.6 路由生成钩子
假设我们要开发一个电商App，当用户没有登录时可以看店铺、商品等信息，但交易记录、购物车、用户个人信息等页面需要登录后才能看。为了实现上述功能，我们需要在打开每一个路由页前判断用户登录状态！如果每次打开路由前我们都需要去判断一下将会非常麻烦，那有什么更好的办法吗？答案是有！
MaterialApp有一个onGenerateRoute属性，它在打开命名路由时可能会被调用，之所以说可能，是因为当调用Navigator.pushNamed(...)打开命名路由时，如果指定的路由名在路由表中已注册，则会调用路由表中的builder函数来生成路由组件；如果路由表中没有注册，才会调用onGenerateRoute来生成路由。onGenerateRoute回调签名如下：
Route Function(RouteSettings settings)
有了onGenerateRoute回调，要实现上面控制页面权限的功能就非常容易：我们放弃使用路由表，取而代之的是提供一个onGenerateRoute回调，然后在该回调中进行统一的权限控制，如：
MaterialApp(
... //省略无关代码
onGenerateRoute:(RouteSettings settings){
return MaterialPageRoute(builder: (context){
String routeName = settings.name;
// 如果访问的路由页需要登录，但当前未登录，则直接返回登录页路由，
// 引导用户登录；其他情况则正常打开路由。
}
);
}
);
注意，
onGenerateRoute只会对命名路由生效。
#2.4.7 总结
本章先介绍了Flutter中路由管理、传参的方式，然后又着重介绍了命名路由相关内容。在此需要说明一点，由于命名路由只是一种可选的路由管理方式，在实际开发中，读者可能心中会犹豫到底使用哪种路由管理方式。在此，根据笔者经验，建议读者最好统一使用命名路由的管理方式，这将会带来如下好处：
- 语义化更明确。
- 代码更好维护；如果使用匿名路由，则必须在调用
Navigator.push的地方创建新路由页，这样不仅需要import新路由页的dart文件，而且这样的代码将会非常分散。 - 可以通过
onGenerateRoute做一些全局的路由跳转前置处理逻辑。
综上所述，笔者比较建议使用命名路由，当然这并不是什么金科玉律，读者可以根据自己偏好或实际情况来决定。
另外，还有一些关于路由管理的内容我们没有介绍，比如路由MaterialApp中还有navigatorObservers和onUnknownRoute两个回调属性，前者可以监听所有路由跳转动作，后者在打开一个不存在的命名路由时会被调用，由于这些功能并不常用，而且也比较简单，我们便不再花费篇幅来介绍了，读者可以自行查看API文档。
课堂小延展：
class RouterManage {
static String? currentRouterName;
/// 路由声明 - CupertinoPageRoute
static final Map routes = {
RouteConstant.LAUNCH: (ctx) => const LaunchPage(),
RouteConstant.HOME: (ctx) => HomePage(
params: _buildRouteParams(ctx),
),
RouteConstant.BROWSER_WEB: (ctx) => BrowserPage(
params: _buildRouteParams(ctx),
),
RouteConstant.LOGIN_PAGE: (ctx) => const LoginPage(),
RouteConstant.LOGIN_CODE_PAGE: (ctx) => LoginCodePage(
params: _buildRouteParams(ctx),
),
RouteConstant.LOGIN_ONE_PAGE: (ctx) => LoginOnePage(params: _buildRouteParams(ctx),),
RouteConstant.UPDATE_HEADER_PAGE: (ctx) => const UpdateHeaderPage(),
RouteConstant.UPDATE_AI_HEADER_PAGE: (ctx) => const UpdateAiHeaderPage(),
RouteConstant.CHAT_PAGE: (ctx) => ChatPage(params: _buildRouteParams(ctx),),
RouteConstant.CHAT_LIST_PAGE: (ctx) => const ChatListPage(),
RouteConstant.GUIDE_MAP_PAGE: (ctx) => GuideMapPage(
params: _buildRouteParams(ctx),
),
RouteConstant.FRIEND_PAGE: (ctx) => const FriendPage(),
RouteConstant.TICKET_PAGE: (ctx) => const TicketPage(),
RouteConstant.SET_PAGE: (ctx) => const SetPage(),
RouteConstant.SET_THEME_PAGE: (ctx) => const SetThemePage(),
RouteConstant.PERSON_PAGE: (ctx) => const PersonPage(),
RouteConstant.ROUTE_PAGE: (ctx) => RouteMapPage(
params: _buildRouteParams(ctx),
),
RouteConstant.ABOUT_PAGE: (ctx) => const AboutPage(),
RouteConstant.COUPON_PAGE: (ctx) => const CouponPage(),
RouteConstant.MY_COLLECT_PAGE: (ctx) => const MyCollectPage(),
RouteConstant.MY_ORDER_PAGE: (ctx) => const MyOrderPage(),
};
/// 根路由
static const String initialRoute = RouteConstant.LAUNCH;
/// 路由钩子
static final RouteFactory generateRoute = (settings) {
// if (settings.name == HMRouteConstant.HOME) {
// return MaterialPageRoute(builder: (ctx) {
// return const HomePage();
// });
// }
debugPrint('============${settings.name}');
return null;
};
/// 未知路由页面
static final RouteFactory unknownRoute = (settings) {
return MaterialPageRoute(builder: (ctx) {
return const UnknownPage();
});
};
static Map _buildRouteParams(BuildContext ctx) {
Map map = {};
try {
var arguments = ModalRoute.of(ctx)?.settings.arguments;
if (arguments != null) {
map = arguments as Map;
}
} catch (e) {
debugPrint('_buildRouteParams-error:$e');
}
return map;
}
static Future pushPage(
BuildContext context, String router,
{Map? arguments}) {
return Navigator.of(context).pushNamed(router, arguments: arguments);
}
///返回到目标路由页面，打开新页面，targetRoute为空时会关闭所有页面，打开新页面
static Future pushNamedAndRemoveUntil(
BuildContext context, String router,
{String? targetRoute, Map? arguments}) {
return Navigator.of(context).pushNamedAndRemoveUntil(router, (route) {
if (ObjUtil.isEmpty(targetRoute)) {
return false;
} else {
return route.settings.name == targetRoute;
}
}, arguments: arguments);
}
static pop(BuildContext context, {Map? result}) {
Map popResult = result ?? {};
Navigator.of(context).pop(popResult);
}
static maybePop(BuildContext context, {Map? result}) {
Map popResult = result ?? {};
Navigator.of(context).maybePop(popResult);
}
static bool canPop(BuildContext context) {
return Navigator.of(context).canPop();
}
static Future pushReplacementNamed(
BuildContext context,
String routeName, {
TO? result,
Map? arguments,
}) {
return Navigator.of(context).pushReplacementNamed(routeName,
arguments: arguments, result: result);
}
static Future pushAndRemoveUntil(
BuildContext context, Route newRoute,
{String? targetRoute}) {
return Navigator.of(context).pushAndRemoveUntil(
newRoute, (route) => route.settings.name == targetRoute);
}
/// pop到目标路由,targetName为空时 返回到roottabbar
static popTargetRoute(BuildContext context, {String? targetName}) {
Navigator.of(context).popUntil((route) {
if (route.settings.name == null ||
route.settings.name == (targetName ??= RouteConstant.HOME)) {
return true;
}
return false;
});
}
static Widget leftBackAction(BuildContext context,
{GestureTapCallback? onPress, Color color = Colors.white}) {
return GestureDetector(
onTap: () {
onPress == null ? RouterManage.maybePop(context) : onPress.call();
},
behavior: HitTestBehavior.translucent,
child: Container(
width: 48.w,
height: 44.w,
alignment: Alignment.center,
child: SvgPicture.asset('assets/nav_back.svg',
width: 22.w, colorFilter: ColorFilter.mode(color, BlendMode.srcIn))),
);
}
}
class CustomSlidePageTransitionsBuilder extends PageTransitionsBuilder {
@override
Widget buildTransitions(
PageRoute route,
BuildContext context,
Animation animation,
Animation secondaryAnimation,
Widget child,
) {
const begin = Offset(1.0, 0.0);
const end = Offset.zero;
const curve = Curves.ease;
var tween = Tween(begin: begin, end: end).chain(CurveTween(curve: curve));
return SlideTransition(
position: animation.drive(tween),
child: child,
);
}
}