Ünlem Bilişim: Mobile Inventory & Barcode Tracking Application

Quick Facts

• Company: Ünlem Bilişim Teknolojileri A.Ş.
• Role: Intern Mobile Application Developer
• Project Period: 2015-2016
• Page Publication Date: 2024-08-01
• Platforms: iOS, Android
• Technology: Delphi RAD Studio, FireMonkey, Object Pascal, SQLite, FireDAC, ZXing
• Limitations: Offline use, low device capacity, fast barcode reading

This study aimed to produce a mobile inventory application that can be used in the field as the final project of the internship program. The focus was on iOS/Android distribution with a single codebase, offline operation, and fast transaction flow with barcodes. The output was a pilot product where field teams could perform counting and debit transactions via tablets/phones.

Timeline

• 2015: Start of internship, collection of field needs and first prototype.
• 2016: Application development, field trials and delivery.
• 2024-08-01: Page publication date (datePublished).

Problems and Constraints

In SMEs, inventory counting and stock updating were done in the field with low connection quality. Desktop systems were not portable; On mobile, barcode reading, offline work and fast data access had to be provided at the same time. Device diversity, low light, and limited hardware resources were the main constraints of the design. Wi-Fi outages in the warehouse, barcode wear and different device cameras made it difficult for the product to work stably. Additionally, the data model compatible with existing ERP services had to be maintained.

Solution Summary

I developed an offline-first mobile inventory application for iOS and Android from a single codebase with Delphi/FireMonkey. Barcode scanning, GPS tagging, local SQLite database and REST synchronization came together to enable field teams to perform fast and error-free operations. The application was designed to complete all critical operations when there is no connection; When the connection arrived, the changes were sent from the queue to the server. Barcode scanning, counting and debit flows are designed to be completed with minimum touch.

Architecture at a Glance

• Offline data storage with Local SQLite + FireDAC.
• Periodic synchronization and delta updates with REST API.
• Secure data sending with change log.
• Simple conflict policy: last-write-wins + manual control.
• Synchronization durability with retry/backoff.
• Lightweight token control for authorization.

This structure aimed to remain compatible with the single recording at the center while reducing data loss in low connection conditions.

Data Model & Sync Strategy

Data model; It consisted of the Products, Inventory, Location and TransactionLog tables. Last_modified and device ID were kept for each record; This way, it was possible to track which changes came from where. Additionally, pending updates were queued and sent securely with the SyncQueue table.

Synchronization proceeded with a push/pull flow. The application first sent the changes accumulated locally to the server in small packets, and then pulled only the changed records from the server. When the network goes down, the queue is preserved and retries are automated.

Key Features

• Fast product finding and counting with barcode scanning (ZXing).
• Location-based inventory verification with GPS tagging.
• Offline-first operation and automatic sync when it comes to network.- Simple and fast interface: listing, detail, counting, search.
• Debit and warehouse movement records.
• Quick search/filter (barcode, name, location).
• Role-based screen access and basic authorization.

Workflows were simplified through large buttons and short forms, considering the use of gloves by warehouse personnel.

Engineering Trade-offs

• Single codebase speed has been balanced by limiting some platform-specific optimizations.
• Last-write-wins convenience created the need for manual approval in critical areas.
• Offline-first approach prioritized continuity over data freshness.
• Sampling was applied because high resolution reduces barcode reading speed.
• GPS sensitivity has been balanced with battery consumption.

Conflict Resolution & Data Integrity

I used a last-write-wins approach to avoid the possibility of field workers updating the same product at different times. For critical conflicts, I gave the user a “last update warning” and added a manual verification flow. I maintained data integrity with SQLite transaction management and FireDAC. To reduce the overlap rate, I kept the synchronization interval short and sent change packets in small batches.

Performance Notes

• CPU load was reduced with frame sampling and image reduction in barcode scanning.
• Barcode and product name search has been accelerated with SQLite indexes.
• Background synchronization is designed to not block the UI thread.
• Memory usage has been balanced with paging on listing screens.
• Automatic exposure preferences for low light were used in the camera preview.

These optimizations ensured that the app remained fluid, especially on older Android devices. The main goal was to avoid any delay between the scanning screen and the list screen for fast counting in the field.

Results / Impact

• Process acceleration in pilot use - 20% - period: 3 weeks pilot - source: field feedback (client-reported).
• Ease of use and mobile access - qualitative improvement - source: user reviews (internally observed).
• Part-time offer after internship - feedback based on project output (anecdotal).
• Offline usage satisfaction - qualitative improvement - source: field notes (internally observed).

Lessons Learned

• Offline-first architecture, the greatest value in field scenarios.
• Simple UI, critical for non-technical users.
• Performance on mobile is maintained with correct sampling and indexing.
• Measurement context and record keeping are of great importance in internship projects.
• Synchronization strategy directly affects data consistency.
• Real user feedback, fastest verification of the design.

This experience taught me to take end-to-end responsibility for mobile product development.

Project Snapshot

• Company: Ünlem Bilişim Teknolojileri A.Ş.
• Project Type: Internship final project
• Role: Mobile Application Developer
• Project Period: 2015-2016
• Completion Date: August 2016
• Page Date: 2024-08-01
• Platform: iOS, Android
• Technology: Delphi RAD Studio, FireMonkey, Object Pascal
• Database: SQLite + FireDAC
• Integration: REST API, JSON, ZXing, GPS

FAQ

How was the mobile app performance with Delphi?

Performance was adequate thanks to native compilation with FireMonkey; Optimization was applied at critical points.

How were offline scenarios managed?

A local copy was kept with SQLite, and synchronization was done via REST when the network arrived.

Was the barcode reading stable?

Stable reading was achieved with ZXing sampling and resolution reduction techniques.

Why was FireMonkey preferred?

To be released to iOS and Android with a single codebase and to be compatible with the existing Delphi ecosystem.

How were conflicts resolved?

Last-write-wins were implemented and verification was offered to the user in critical situations.

What was the GPS tag used for?

For product location verification and in-warehouse recording in field operations.