कॉर्पोरेट प्रोजेक्ट

बिलीसिम: मोबाइल इन्वेंटरी और बारकोड ट्रैकिंग एप्लिकेशन

डेल्फ़ी/फ़ायरमंकी के साथ ऑफ़लाइन-पहला मोबाइल इन्वेंट्री एप्लिकेशन: बारकोड स्कैनिंग, जीपीएस टैगिंग, SQLite और REST सिंक्रोनाइज़ेशन।

DelphiObject PascalFireMonkeyRAD StudioCross-Platform MobileSQLiteFireDACOffline-FirstBarcode ScanningZXingREST APIGPS
Ünlem Bilişim मोबाइल इन्वेंट्री और बारकोड ट्रैकिंग एप्लिकेशन

ENGINEERING IMPACT

मापने योग्य दायरा और परिणाम

कार्य मॉडल
ऑफ़लाइन-प्रथम

कनेक्शन बाधित होने पर भी फ़ील्ड प्रवाह जारी रखना।

क्षेत्र संकेत
बारकोड + जीपीएस

इन्वेंट्री रिकॉर्ड का भौतिक स्थान और उत्पाद आईडी से मिलान किया गया।

डेटा निरंतरता
SQLite + REST सिंक्रनाइज़ेशन

स्थानीय रजिस्ट्री और केंद्रीय प्रणाली के बीच का पुल।

त्वरित तथ्य

  • कंपनी: Ünlem Bilişim Teknolojileri A.Ş.
  • भूमिका: इंटर्न मोबाइल एप्लिकेशन डेवलपर
  • परियोजना अवधि: 2015-2016
  • पृष्ठ प्रकाशन दिनांक: 2024-08-01
  • प्लेटफार्म: आईओएस, एंड्रॉइड
  • प्रौद्योगिकी: डेल्फ़ी रेड स्टूडियो, फ़ायरमंकी, ऑब्जेक्ट पास्कल, SQLite, फ़ायरडैक, ZXing
  • सीमाएँ: ऑफ़लाइन उपयोग, कम डिवाइस क्षमता, तेज़ बारकोड रीडिंग

इस अध्ययन का उद्देश्य एक मोबाइल इन्वेंट्री एप्लिकेशन तैयार करना है जिसका उपयोग क्षेत्र में इंटर्नशिप कार्यक्रम की अंतिम परियोजना के रूप में किया जा सकता है। एकल कोडबेस, ऑफ़लाइन ऑपरेशन और बारकोड के साथ तेज़ लेनदेन प्रवाह के साथ iOS/एंड्रॉइड वितरण पर ध्यान केंद्रित किया गया था। आउटपुट एक पायलट उत्पाद था जहां फ़ील्ड टीमें टैबलेट/फोन के माध्यम से गिनती और डेबिट लेनदेन कर सकती थीं।

समयरेखा

  • 2015: इंटर्नशिप की शुरुआत, क्षेत्र की जरूरतों का संग्रह और पहला प्रोटोटाइप।
  • 2016: अनुप्रयोग विकास, क्षेत्र परीक्षण और वितरण।
  • 2024-08-01: पृष्ठ प्रकाशन तिथि (दिनांकप्रकाशित)।

समस्याएँ और बाधाएँ

एसएमई में, कम कनेक्शन गुणवत्ता वाले क्षेत्र में इन्वेंट्री गिनती और स्टॉक अपडेट किया गया था। डेस्कटॉप सिस्टम पोर्टेबल नहीं थे; मोबाइल पर, बारकोड रीडिंग, ऑफ़लाइन कार्य और तेज़ डेटा एक्सेस एक ही समय में प्रदान किया जाना था। डिवाइस विविधता, कम रोशनी और सीमित हार्डवेयर संसाधन डिज़ाइन की मुख्य बाधाएँ थीं। गोदाम में वाई-फाई की खराबी, बारकोड खराब होने और विभिन्न डिवाइस कैमरों के कारण उत्पाद का स्थिर रूप से काम करना मुश्किल हो गया। इसके अतिरिक्त, मौजूदा ईआरपी सेवाओं के साथ संगत डेटा मॉडल को बनाए रखना होगा।

समाधान सारांशमैंने डेल्फ़ी/फ़ायरमॉन्की के साथ एक ही कोडबेस से आईओएस और एंड्रॉइड के लिए एक ऑफ़लाइन-पहला मोबाइल इन्वेंट्री एप्लिकेशन विकसित किया। फ़ील्ड टीमों को तेज़ और त्रुटि-मुक्त संचालन करने में सक्षम बनाने के लिए बारकोड स्कैनिंग, जीपीएस टैगिंग, स्थानीय SQLite डेटाबेस और REST सिंक्रोनाइज़ेशन एक साथ आए। एप्लिकेशन को कोई कनेक्शन न होने पर सभी महत्वपूर्ण परिचालनों को पूरा करने के लिए डिज़ाइन किया गया था; जब कनेक्शन आया, तो परिवर्तन कतार से सर्वर पर भेजे गए। बारकोड स्कैनिंग, गिनती और डेबिट प्रवाह को न्यूनतम स्पर्श के साथ पूरा करने के लिए डिज़ाइन किया गया है।

वास्तुकला एक नज़र में

  • स्थानीय SQLite + FireDAC के साथ ऑफ़लाइन डेटा भंडारण।
  • REST API के साथ आवधिक सिंक्रनाइज़ेशन और डेल्टा अपडेट।
  • परिवर्तन लॉग के साथ सुरक्षित डेटा सबमिशन।
  • सरल संघर्ष नीति: अंतिम-जीत-जीत + मैन्युअल नियंत्रण।
  • पुनः प्रयास/बैकऑफ़ के साथ सिंक्रनाइज़ेशन स्थायित्व।
  • प्राधिकरण के लिए हल्के टोकन नियंत्रण।

इस संरचना का उद्देश्य कम कनेक्शन स्थितियों में डेटा हानि को कम करते हुए केंद्र में एकल रिकॉर्डिंग के साथ संगत रहना है।

डेटा मॉडल और सिंक रणनीति

डेटा मॉडल; इसमें उत्पाद, इन्वेंटरी, स्थान और लेन-देन लॉग तालिकाएँ शामिल थीं। प्रत्येक रिकॉर्ड के लिए Last_modified और डिवाइस आईडी रखी गई थी; इस प्रकार, यह ट्रैक करना संभव था कि कौन से परिवर्तन कहाँ से आए। इसके अतिरिक्त, लंबित अद्यतनों को कतारबद्ध किया गया और SyncQueue तालिका के साथ सुरक्षित रूप से भेजा गया।

सिंक्रनाइज़ेशन पुश/पुल प्रवाह के साथ आगे बढ़ा। एप्लिकेशन ने पहले स्थानीय रूप से संचित परिवर्तनों को छोटे पैकेटों में सर्वर पर भेजा, और फिर सर्वर से केवल परिवर्तित रिकॉर्ड खींचे। जब नेटवर्क डाउन हो जाता है, तो कतार संरक्षित रहती है और पुनः प्रयास स्वचालित हो जाते हैं।

मुख्य विशेषताएं

  • बारकोड स्कैनिंग (ZXing) के साथ तेजी से उत्पाद ढूंढना और गिनती करना।
  • जीपीएस टैगिंग के साथ स्थान-आधारित सूची सत्यापन।
  • जब नेटवर्क की बात आती है तो ऑफ़लाइन-पहला ऑपरेशन और स्वचालित सिंक।- सरल और तेज़ इंटरफ़ेस: लिस्टिंग, विवरण, गिनती, खोज।
  • डेबिट और वेयरहाउस मूवमेंट रिकॉर्ड।
  • त्वरित खोज/फ़िल्टर (बारकोड, नाम, स्थान)।
  • भूमिका-आधारित स्क्रीन एक्सेस और बुनियादी प्राधिकरण।

गोदाम कर्मियों द्वारा दस्तानों के उपयोग को ध्यान में रखते हुए, बड़े बटनों और छोटे रूपों के माध्यम से वर्कफ़्लो को सरल बनाया गया।

इंजीनियरिंग व्यापार-बंद

  • कुछ प्लेटफ़ॉर्म-विशिष्ट अनुकूलन को सीमित करके एकल कोडबेस गति को संतुलित किया गया है।
  • अंतिम जीत की सुविधा ने महत्वपूर्ण क्षेत्रों में मैन्युअल अनुमोदन की आवश्यकता पैदा की।
  • ऑफ़लाइन-प्रथम दृष्टिकोण ने डेटा ताजगी पर निरंतरता को प्राथमिकता दी।
  • नमूनाकरण इसलिए लागू किया गया क्योंकि उच्च रिज़ॉल्यूशन बारकोड पढ़ने की गति को कम कर देता है।
  • जीपीएस संवेदनशीलता को बैटरी की खपत के साथ संतुलित किया गया है।

संघर्ष समाधान और डेटा अखंडता

फ़ील्ड कर्मियों द्वारा एक ही उत्पाद को अलग-अलग समय पर अपडेट करने की संभावना से बचने के लिए मैंने अंतिम-लिखो-जीत दृष्टिकोण का उपयोग किया। गंभीर विवादों के लिए, मैंने उपयोगकर्ता को "अंतिम अद्यतन चेतावनी" दी और एक मैन्युअल सत्यापन प्रवाह जोड़ा। मैंने SQLite लेनदेन प्रबंधन और FireDAC के साथ डेटा अखंडता बनाए रखी। ओवरलैप दर को कम करने के लिए, मैंने सिंक्रोनाइज़ेशन अंतराल को छोटा रखा और छोटे बैचों में परिवर्तन पैकेट भेजे।

प्रदर्शन नोट्स

  • बारकोड स्कैनिंग में फ्रेम सैंपलिंग और इमेज में कमी के साथ सीपीयू लोड कम हो गया था।
  • SQLite इंडेक्स के साथ बारकोड और उत्पाद नाम खोज को तेज कर दिया गया है।
  • बैकग्राउंड सिंक्रोनाइज़ेशन को यूआई थ्रेड को ब्लॉक न करने के लिए डिज़ाइन किया गया है।
  • मेमोरी उपयोग को लिस्टिंग स्क्रीन पर पेजिंग के साथ संतुलित किया गया है।
  • कैमरा पूर्वावलोकन में कम रोशनी के लिए स्वचालित एक्सपोज़र प्राथमिकताओं का उपयोग किया गया था।

इन अनुकूलनों ने सुनिश्चित किया कि ऐप तरल बना रहे, विशेष रूप से पुराने एंड्रॉइड डिवाइसों पर। मुख्य लक्ष्य क्षेत्र में तेजी से गिनती के लिए स्कैनिंग स्क्रीन और सूची स्क्रीन के बीच किसी भी देरी से बचना था।

परिणाम/प्रभाव

  • पायलट उपयोग में प्रक्रिया त्वरण - 20% - अवधि: 3 सप्ताह पायलट - स्रोत: फ़ील्ड फीडबैक (ग्राहक-रिपोर्ट)।
  • उपयोग में आसानी और मोबाइल पहुंच - गुणात्मक सुधार - स्रोत: उपयोगकर्ता समीक्षाएँ (आंतरिक रूप से देखी गई)।
  • इंटर्नशिप के बाद अंशकालिक प्रस्ताव - परियोजना आउटपुट (उपाख्यान) के आधार पर प्रतिक्रिया।
  • ऑफ़लाइन उपयोग संतुष्टि - गुणात्मक सुधार - स्रोत: फ़ील्ड नोट्स (आंतरिक रूप से देखे गए)।

सबक सीखा गया

  • ऑफ़लाइन-प्रथम आर्किटेक्चर, फ़ील्ड परिदृश्यों में सबसे बड़ा मूल्य।
  • सरल यूआई, गैर-तकनीकी उपयोगकर्ताओं के लिए महत्वपूर्ण।
  • मोबाइल पर प्रदर्शन सही सैंपलिंग और इंडेक्सिंग के साथ बनाए रखा जाता है।
  • इंटर्नशिप परियोजनाओं में माप संदर्भ और रिकॉर्ड रखने का बहुत महत्व है।
  • सिंक्रोनाइज़ेशन रणनीति सीधे डेटा स्थिरता को प्रभावित करती है।
  • वास्तविक उपयोगकर्ता प्रतिक्रिया, डिज़ाइन का सबसे तेज़ सत्यापन।

इस अनुभव ने मुझे मोबाइल उत्पाद विकास के लिए शुरू से अंत तक जिम्मेदारी लेना सिखाया।

प्रोजेक्ट स्नैपशॉट

  • कंपनी: Ünlem Bilişim Teknolojileri A.Ş.
  • प्रोजेक्ट प्रकार: इंटर्नशिप अंतिम प्रोजेक्ट
  • भूमिका: मोबाइल एप्लिकेशन डेवलपर
  • परियोजना अवधि: 2015-2016
  • समापन तिथि: अगस्त 2016
  • पृष्ठ दिनांक: 2024-08-01
  • प्लेटफ़ॉर्म: आईओएस, एंड्रॉइड
  • प्रौद्योगिकी: डेल्फ़ी रेड स्टूडियो, फ़ायरमंकी, ऑब्जेक्ट पास्कल
  • डेटाबेस: SQLite + FireDAC
  • एकीकरण: REST API, JSON, ZXing, GPS

अक्सर पूछे जाने वाले प्रश्न

डेल्फ़ी के साथ मोबाइल ऐप का प्रदर्शन कैसा था?

FireMonkey के साथ मूल संकलन के कारण प्रदर्शन पर्याप्त था; महत्वपूर्ण बिंदुओं पर अनुकूलन लागू किया गया था।

ऑफ़लाइन परिदृश्यों का प्रबंधन कैसे किया गया?

SQLite के साथ एक स्थानीय प्रतिलिपि रखी गई थी, और नेटवर्क आने पर REST के माध्यम से सिंक्रनाइज़ेशन किया गया था।

क्या बारकोड की रीडिंग स्थिर थी?

ZXing सैंपलिंग और रिज़ॉल्यूशन रिडक्शन तकनीकों के साथ स्थिर रीडिंग हासिल की गई।

फायरमंकी को प्राथमिकता क्यों दी गई?एकल कोडबेस के साथ आईओएस और एंड्रॉइड पर जारी किया जाएगा और मौजूदा डेल्फ़ी पारिस्थितिकी तंत्र के साथ संगत होगा।

विवादों का समाधान कैसे हुआ?

लास्ट-राइट-विंस लागू किया गया और गंभीर परिस्थितियों में उपयोगकर्ता को सत्यापन की पेशकश की गई।

जीपीएस टैग का उपयोग किस लिए किया जाता था?

फ़ील्ड संचालन में उत्पाद स्थान सत्यापन और इन-वेयरहाउस रिकॉर्डिंग के लिए।

समान आर्किटेक्चरल निर्णयों को अपने प्रोडक्ट पर लागू करने के लिए लिखें।