26 posts tagged with "Flutter"

在 MVVM 架构中，我们面临着两个维度的状态管理需求：

1. 异步状态维度（由 AsyncValue 处理）

   • 加载状态管理
   • 网络请求生命周期
   • 异步操作重试

2. 业务错误维度（由 Result 模式处理）

   • 接口返回的业务错误
   • 数据校验失败
   • 缓存策略错误

本文将演示如何在分层架构中协同使用这两种模式，实现清晰的错误责任划分。

在 Flutter 应用开发中，处理异步操作的状态管理始终是开发者面临的核心挑战。一个典型的网络请求场景往往涉及：

1. 加载中状态展示
2. 数据成功渲染
3. 错误处理与重试
4. 状态间的平滑过渡

传统实现方式需要为每个异步操作重复编写模板代码，导致以下问题：

• 代码冗余率高达 60% 以上
• 状态处理逻辑分散难以维护
• 错误处理缺乏统一标准
• UI 与业务逻辑高度耦合

本文将解析 Riverpod 中 AsyncValue 的设计思想，并演示如何在不依赖任何状态管理库的情况下，构建完整的异步状态管理体系。

在 Flutter 应用开发中，状态管理始终是一个核心话题。虽然 Flutter 提供了 ValueListenableBuilder 这样的基础工具来处理单一值的响应式更新，但在实际开发中，我们经常需要同时监听多个值的变化。本文将深入探讨如何设计和实现一个类型安全、高性能且易于使用的多值监听解决方案。

在 Flutter 应用开发中,我们经常需要处理多种状态和类型的数据。例如,一个网络请求可能处于加载中、成功、失败等不同状态。传统的做法可能使用枚举或继承体系来处理这些情况,但往往会面临类型安全和维护性的挑战。

Dart 3.0 引入的 sealed class 和增强的模式匹配特性,为这类问题提供了更优雅的解决方案。其实我们已经在前面的文章《Flutter 优化 API 错误响应：Result 模式实践指南》 中提过 sealed class ，并给出了具体的实现方式，但是没有针对这个新语法做更多的深入探索。本文将延续这一话题，让我们通过实际案例来更加深入理解这些特性。

在 Flutter 开发中，状态管理方案的选择往往让开发者感到困惑。从 Stacked、Provider、Bloc 到全能的 GetX，从 web 端过来的 Redux、Mobx、Signal，再到最近很火的 Provider 的亲兄弟 Riverpod，各种方案都有其独特的优势和适用场景，但每一种都有一些地方让我难以理解或认同，要么规定了很多骚操作，要么模板代码太多，要么背后隐藏着太多 “魔法”，而我需要的是简单易懂、尽可能简洁、可扩展的方案。

于是便有了这篇文章，我要介绍一种不使用第三方状态管理方案的方法，它唯一用到的第三方包是 GetIt（但不是用于管理状态，而是依赖注入管理），而对于状态改变时重建 UI，会使用 Flutter 自带的 ValueNotifier 和 ValueListenableBuilder 类。

在移动应用开发的漫长旅程中，错误处理一直是一个令人头疼的话题。作为一名从 Objective-C 开始，历经 Swift 3.0 到 6.0 的 iOS 开发者，现转到 Flutter 跨平台开发的程序员，我深切地体会到了传统错误处理方式的局限性。本文将深入探讨如何在 Flutter 中使用 Result 模式，彻底改变我们处理 API 错误的方式。

在构建大型 Flutter 应用时，首要考虑的问题之一是如何 组织项目结构。

合理的项目结构能够确保整个团队遵循清晰的规范，并以一致的方式添加新功能。

本文将探讨两种常见的项目结构方法：功能优先 和 层级优先。

我们将学习它们的优缺点，识别在实际应用中实施它们时可能遇到的常见问题，避免在开发过程中出现代价高昂的错误。

最近，Flutter 社区 itsallwidgets 建了一个论坛，目前加入的人不多，大家可以注册账号，跟国外的活跃开发者们一起讨论关于 Flutter 开发的话题。

虽然人不多，但也有一些比较有意思的主题讨论，其中一个主题是: Lesser known classes and functions from the Dart core libraries ，讨论一些日常开发中比较少用到，但是却很有意思和实用的类和函数。

本文分成两部分，第一部分是对论坛评论里提到的类和函数进行总结，第二部分将额外补充一些没有提到的。

Flutter 的 dart sdk是不带反射功能的，导致社区需要开发一些注解工具来辅助生成一些模板代码，大部分都是基于官方的build_runner 工具。

但是在构建的时候，每次都去生成模板代码，非常耗时。尤其是当你的项目比较大时，有可能超过1分多钟来等待处理完成，而且每次都得重新编译，非常影响开发效率。

另外，你用的生成库越多，越影响生成速度。

在 Flutter 开发中，我们经常需要创建可重用的组件。这些组件可以是简单的 UI 元素，也可以是复杂的布局结构。

一般主要有两种方式来定义这些组件：

• 使用类（class）
• 使用函数（function）

很多人使用函数创建组件，更多的考虑是速度，更快的编码。不可否认的是，相比类组件而言，函数组件省了好几行代码，比如构造函数和变量定义部分。在我的工作中，也经常看见大量使用函数返回 widget 来创建组件，但是官方的 Flutter 团队更推荐使用类。

为什么？本文将详细探讨这一原因。