基于 Flutter × OpenHarmony 的旅行记录应用实践 ------ 添加新的旅行记录
前言
在移动应用开发领域，"记录生活"类应用始终占据着重要位置。旅行记录应用不仅承载着用户对时间与空间的记忆，也对应用在 交互体验、数据组织、跨平台一致性 等方面提出了更高要求。
在前一阶段中，我们已经完成了旅行记录列表与单个旅行卡片的构建。本文将进一步聚焦 "添加新的旅行记录" 这一核心功能，并结合 Flutter × OpenHarmony 的跨端能力，系统性讲解旅行类型选择、记录过滤以及添加入口的整体设计与实现。
背景
随着 OpenHarmony 在多终端场景中的不断成熟，越来越多的开发者开始尝试使用 Flutter 作为统一 UI 层 ，以降低多端开发成本。
在旅行记录类应用中，常见的业务诉求包括：
- 多条件筛选旅行记录（关键词 + 类型）
- 统一的数据模型与状态管理
- 流畅、低学习成本的添加记录交互
- 在手机、平板等设备上的一致体验
因此，在本项目中我们选择：
- Flutter：负责 UI 构建与交互逻辑
- OpenHarmony：作为系统运行环境，承载跨设备能力
- 组件化设计：便于后期扩展至云同步、本地数据库等能力
Flutter × Harmony OpenHarmony 跨端开发介绍
构建旅行类型选择器
在"添加旅行记录"这一功能中，旅行类型（如：城市游、自然风光、商务出行等） 是一个典型的结构化字段。
设计目标
- 类型可枚举、可扩展
- UI 上支持快速筛选
- 与列表过滤逻辑天然联动
核心思路
- 使用
enum或固定字符串作为旅行类型 - 在状态中维护
_selectedType - 所有过滤与添加逻辑围绕该字段展开
这种设计方式在 Flutter 与 OpenHarmony 组合中非常自然，不依赖平台特性，具有良好的可移植性。
开发核心代码
下面进入核心逻辑部分，重点围绕 旅行记录过滤 与 添加记录入口设计 展开。
一、旅行记录过滤逻辑解析
dart
/// 过滤旅行记录
void _filterTravelRecords() {
setState(() {
_filteredRecords = _travelRecords.where((record) {
final matchesSearch =
record.destination.toLowerCase().contains(_searchKeyword.toLowerCase()) ||
record.city.toLowerCase().contains(_searchKeyword.toLowerCase()) ||
record.country.toLowerCase().contains(_searchKeyword.toLowerCase());
final matchesType =
_selectedType == null || record.type == _selectedType;
return matchesSearch && matchesType;
}).toList();
});
}1. setState 的作用
在 Flutter 中，setState 是触发 UI 刷新的核心机制。
每当筛选条件变化（搜索关键词或类型），调用该方法即可重新计算可见列表。
2. 多字段关键词匹配
dart
record.destination
record.city
record.country- 同一个关键词可匹配多个字段
- 使用
toLowerCase()实现大小写无关搜索 - 提升用户搜索的容错性与体验
3. 旅行类型过滤
dart
final matchesType = _selectedType == null || record.type == _selectedType;设计要点：
_selectedType == null表示"不过滤类型"- 逻辑清晰，扩展成本低
- 非常适合与下拉选择器或 Tab 组件联动
二、添加新的旅行记录入口设计
dart
/// 添加新的旅行记录
void _addTravelRecord(BuildContext context) {
// 这里可以实现添加旅行记录的对话框或页面
showDialog(
context: context,
builder: (context) {
return AlertDialog(
title: const Text('添加旅行记录'),
content: const Text('添加旅行记录功能开发中...'),
actions: [
TextButton(
onPressed: () => Navigator.pop(context),
child: const Text('确定'),
),
],
);
},
);
}1. 为什么使用 Dialog 作为入口
在跨端场景下：
AlertDialog具有良好的平台适配性- 不依赖底层系统弹窗能力
- 在 OpenHarmony 与 Android 上表现一致
2. 职责划分清晰
当前实现的意义并不在于"功能完整"，而在于：
-
明确 添加入口
-
为后续功能预留扩展点，例如：
- 表单输入页面
- 图片选择
- 日期选择
- 位置选择
3. 推荐的下一步演进
后续可以将该方法升级为：
- 跳转到独立的
AddTravelPage - 使用
Form + TextFormField - 提交后向
_travelRecords中追加数据 - 自动触发
_filterTravelRecords()
心得
在 Flutter × OpenHarmony 的组合下开发旅行记录类应用，有一个非常明显的感受：
业务逻辑几乎不需要为平台做任何妥协。
- 过滤逻辑完全是纯 Dart
- UI 组件具有高度一致性
- 状态驱动视图的模式非常适合"记录型应用"
尤其是在旅行记录这种 以数据为核心、以展示为主导 的场景中，Flutter 的声明式 UI 能显著降低维护成本。
总结
通过本文的实践可以看到，在 Flutter × OpenHarmony 的跨端架构中，实现"添加新的旅行记录"并不复杂，真正重要的是 设计思路的前置与逻辑的可扩展性。我们通过关键词搜索与类型筛选相结合的方式，构建了一个清晰、可维护的记录过滤机制；同时，以 Dialog 作为添加入口，为后续完整的旅行记录编辑流程打下了坚实基础。该设计在保持代码简洁性的同时，也充分考虑了未来功能扩展的可能性，例如本地数据库持久化、云端同步、多设备协同等。整体来看，这种以 Flutter 为统一 UI 层、以 OpenHarmony 作为系统承载的开发模式，非常适合中长期演进的应用型项目，尤其是在生活记录、个人管理与内容展示等领域，具备极高的实践价值。
欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.csdn.net