|
|
|
|
# 项目名称：现场问题检查系统
|
|
|
|
|
|
|
|
|
|
## 核心功能
|
|
|
|
|
|
|
|
|
|
本系统旨在为现场工作人员提供一个高效的问题记录与管理平台，支持离线操作和数据同步。
|
|
|
|
|
|
|
|
|
|
1.1 在线/离线登录
|
|
|
|
|
需求： 用户能够使用用户名和密码进行登录。如果设备曾成功登录过，即使在离线状态下也能进入应用。
|
|
|
|
|
|
|
|
|
|
技术实现思路：
|
|
|
|
|
|
|
|
|
|
在线： 登录成功后，从服务器获取用户身份信息和Token。
|
|
|
|
|
|
|
|
|
|
离线： 将登录凭证（如Token）安全地存储在本地数据库中，启动时优先检查本地凭证。如果凭证有效，直接进入主界面。
|
|
|
|
|
|
|
|
|
|
1.2 问题数据离线增删改查
|
|
|
|
|
需求： 用户在离线状态下能完整地创建、编辑、删除和查询问题数据。
|
|
|
|
|
|
|
|
|
|
技术实现思路：
|
|
|
|
|
|
|
|
|
|
本地数据库： 使用 SQFlite 作为本地数据库。
|
|
|
|
|
|
|
|
|
|
数据结构： 设计清晰的数据库表结构，包含问题描述、图片路径、创建时间、状态（如“待上传”）等字段。
|
|
|
|
|
|
|
|
|
|
操作： 所有的增删改查操作都直接在本地数据库上进行。
|
|
|
|
|
|
|
|
|
|
1.3 问题数据上传/下载
|
|
|
|
|
需求： 在有网络连接时，系统能自动或手动将本地数据同步到服务器，并从服务器下载最新数据。
|
|
|
|
|
|
|
|
|
|
技术实现思路：
|
|
|
|
|
|
|
|
|
|
上传队列： 在本地数据库中新增一个“待上传”队列。当用户离线进行增删改操作时，将这些操作记录在队列中。
|
|
|
|
|
|
|
|
|
|
智能同步： 当网络恢复时，按顺序处理上传队列中的任务。使用统一的 HTTP/Dio 拦截器处理身份验证和错误重试。
|
|
|
|
|
|
|
|
|
|
差异化下载： 从服务器下载数据时，只拉取自上次同步以来有更新的数据，避免全量下载。
|
|
|
|
|
|
|
|
|
|
2. 系统架构：MVVM + 仓库模式
|
|
|
|
|
此架构能有效分离关注点，提高代码的可测试性和可维护性。
|
|
|
|
|
|
|
|
|
|
模型 (Model): 负责数据管理。定义问题数据的实体类，如 Problem。
|
|
|
|
|
|
|
|
|
|
视图模型 (ViewModel): 作为视图和模型之间的桥梁。
|
|
|
|
|
|
|
|
|
|
负责业务逻辑、状态管理和数据处理。
|
|
|
|
|
|
|
|
|
|
通过 GetX 管理 UI 状态，并与视图进行绑定。
|
|
|
|
|
|
|
|
|
|
使用 GetX 的依赖注入（DI）管理 Repository 实例。
|
|
|
|
|
|
|
|
|
|
视图 (View): 负责 UI 展示。
|
|
|
|
|
|
|
|
|
|
使用 Flutter Widgets 构建界面。
|
|
|
|
|
|
|
|
|
|
通过 GetX 提供的响应式组件（如 Obx），监听 ViewModel 中的状态变化并自动更新 UI。
|
|
|
|
|
|
|
|
|
|
仓库 (Repository): 负责统一数据源（本地数据库和网络）。
|
|
|
|
|
|
|
|
|
|
封装数据访问逻辑，向 ViewModel 提供统一的数据接口。
|
|
|
|
|
|
|
|
|
|
根据网络状态，决定是从 SQFlite 获取数据还是从网络请求。
|
|
|
|
|
|
|
|
|
|
3. 技术栈
|
|
|
|
|
Flutter SDK： 跨平台应用开发框架。
|
|
|
|
|
|
|
|
|
|
GetX：
|
|
|
|
|
|
|
|
|
|
状态管理： 轻量高效，用于管理 UI 状态。
|
|
|
|
|
|
|
|
|
|
路由管理： 简化页面跳转。
|
|
|
|
|
|
|
|
|
|
依赖注入： 方便管理和提供单例服务（如 Repository）。
|
|
|
|
|
|
|
|
|
|
SQFlite： 本地数据库，用于离线数据存储。
|
|
|
|
|
|
|
|
|
|
Image Picker： 用于从图库或相机选择图片。
|
|
|
|
|
|
|
|
|
|
HTTP/Dio： 网络请求库。推荐使用 Dio，因为它提供了更强大的拦截器、表单数据处理和错误处理功能。
|
