企业项目

Ünlem Bilisim:移动库存和条形码跟踪应用程序

采用 Delphi/FireMonkey 的离线优先移动库存应用程序:条形码扫描、GPS 标记、SQLite 和 REST 同步。

DelphiObject PascalFireMonkeyRAD StudioCross-Platform MobileSQLiteFireDACOffline-FirstBarcode ScanningZXingREST APIGPS
Ünlem Bilişim 移动库存和条形码跟踪应用程序

工程影响

可衡量的范围与结果

工作模式
离线优先

即使连接中断也能继续现场流动。

现场信号
条码+GPS

将库存记录与实际位置和产品 ID 进行匹配。

数据连续性
SQLite + REST 同步

本地登记处和中央系统之间的桥梁。

小知识

  • 公司:Ünlem Bilişim Teknolojileri A.Ş.
  • 角色:实习移动应用开发人员
  • 项目期间:2015-2016
  • 页面发布日期:2024-08-01
  • 平台:iOS、Android
  • 技术:Delphi RAD Studio、FireMonkey、Object Pascal、SQLite、FireDAC、ZXing
  • 限制:离线使用、设备容量低、条码读取速度快

本研究旨在开发一个可在现场使用的移动库存应用程序,作为实习计划的最终项目。重点是具有单一代码库、离线操作和条形码快速交易流程的 iOS/Android 发行版。产出是一个试点产品,现场团队可以通过平板电脑/手机执行计数和借记交易。

时间轴

  • 2015 年:开始实习、收集现场需求和第一个原型。
  • 2016 年:应用开发、现场试验和交付。
  • 2024-08-01:页面发布日期(发布日期)。

问题和限制

在中小企业中,库存盘点和库存更新是在现场完成的,连接质量较低。桌面系统不便于携带;在移动设备上,必须同时提供条码读取、离线工作和快速数据访问。设备多样性、弱光和有限的硬件资源是设计的主要限制。仓库Wi-Fi中断、条码磨损、不同设备摄像头等问题导致产品难以稳定工作。此外,还必须维护与现有 ERP 服务兼容的数据模型。

解决方案总结我使用 Delphi/Fire

Monkey 从单个代码库开发了适用于 iOS 和 Android 的离线优先移动库存应用程序。条形码扫描、GPS 标签、本地 SQLite 数据库和 REST 同步结合在一起,使现场团队能够快速、无差错地执行操作。该应用程序被设计为在没有连接时完成所有关键操作;当连接到达时,更改将从队列发送到服务器。条码扫描、计数和借记流程旨在通过最少的接触来完成。

架构概览

  • 使用本地 SQLite + FireDAC 进行离线数据存储。
  • 使用 REST API 定期同步和增量更新。
  • 使用更改日志保护数据发送。
  • 简单的冲突策略:最后写入获胜+手动控制。
  • 具有重试/退避功能的同步耐久性。
  • 用于授权的轻量级令牌控制。

这种结构旨在保持与中心单次记录的兼容性,同时减少低连接条件下的数据丢失。

数据模型和同步策略

数据模型;它由“产品”、“库存”、“位置”和“交易日志”表组成。每条记录都会保留Last_modified和设备ID;这样,就可以跟踪哪些变化来自哪里。此外,挂起的更新已排队并通过 SyncQueue 表安全发送。

同步以推/拉流进行。应用程序首先将本地累积的更改以小数据包发送到服务器,然后仅从服务器拉取更改的记录。当网络出现故障时,队列将被保留并自动重试。

主要特点

  • 通过条形码扫描 (ZXing) 快速查找和计数产品。
  • 基于位置的库存验证,带有 GPS 标签。
  • 离线优先操作和网络自动同步。- 简单快捷的界面:列表、明细、计数、搜索。
  • 借方和仓库移动记录。
  • 快速搜索/过滤(条形码、名称、位置)。
  • 基于角色的屏幕访问和基本授权。

考虑到仓库人员使用手套,通过大按钮和短表格简化了工作流程。

工程权衡

  • 通过限制一些特定于平台的优化来平衡单个代码库的速度。
  • 最后写入获胜的便利性产生了在关键区域进行手动批准的需要。
  • 离线优先方法优先考虑连续性而不是数据新鲜度。
  • 由于高分辨率会降低条形码读取速度,因此采用了采样。
  • GPS 灵敏度与电池消耗进行了平衡。

冲突解决和数据完整性

我使用了最后写入获胜的方法来避免现场工作人员在不同时间更新同一产品的可能性。对于严重冲突,我向用户发出了“上次更新警告”,并添加了手动验证流程。我使用 SQLite 事务管理和 FireDAC 维护了数据完整性。为了减少重叠率,我保持较短的同步间隔并小批量发送更改数据包。

性能说明

  • 通过条码扫描中的帧采样和图像缩小来降低 CPU 负载。
  • 使用 SQLite 索引加速了条形码和产品名称搜索。
  • 后台同步旨在不阻塞 UI 线程。
  • 内存使用已与列表屏幕上的分页进行了平衡。
  • 相机预览中使用了低光自动曝光首选项。

这些优化确保了应用程序保持流畅,尤其是在较旧的 Android 设备上。主要目标是避免扫描屏幕和列表屏幕之间的任何延迟,以便在现场快速计数。

结果/影响- 试点使用过程加速

  • 20% - 周期:试点 3 周 - 来源:现场反馈(客户报告)。
  • 易于使用和移动访问 - 质量改进 - 来源:用户评论(内部观察)。
  • 实习后提供兼职机会 - 根据项目产出的反馈(轶事)。
  • 离线使用满意度 - 质量改进 - 来源:现场笔记(内部观察)。

经验教训

  • 离线优先架构,现场场景最大价值。
  • 简单的用户界面,对于非技术用户至关重要。
  • 通过正确的采样和索引来保持移动性能。
  • 测量背景和记录保存在实习项目中非常重要。
  • 同步策略直接影响数据的一致性。
  • 真实的用户反馈,最快的设计验证。

这段经历教会了我对移动产品开发承担端到端的责任。

项目快照

  • 公司:Ünlem Bilişim Teknolojileri A.Ş.
  • 项目类型:实习期末项目
  • 角色:移动应用程序开发人员
  • 项目期间:2015-2016
  • 完成日期:2016年8月
  • 页面日期:2024-08-01
  • 平台:iOS、安卓
  • 技术:Delphi RAD Studio、FireMonkey、Object Pascal
  • 数据库:SQLite + FireDAC
  • 集成:REST API、JSON、ZXing、GPS

常见问题解答

Delphi 的移动应用程序性能如何?

由于使用 FireMonkey 进行本机编译,性能足够;在关键点应用了优化。

离线场景是如何管理的?

使用 SQLite 保留本地副本,并在网络到达时通过 REST 完成同步。

条码读取稳定吗?

通过 ZXing 采样和分辨率降低技术实现了稳定的读数。

为什么 FireMonkey 是首选?使用单一代码库发布到 iOS 和 Android,并与现有的 Delphi 生态系统兼容。

冲突是如何解决的?

实施了最后写入获胜,并在关键情况下向用户提供验证。

GPS 标签是用来做什么的?

用于现场操作中的产品位置验证和仓库内记录。

将类似的架构决策 应用到你的产品——写信给我。