सेवा

मोबाइल ऐप डेवलपमेंट

ऐसे ऐप जो नेटवर्क न होने पर भी चलते रहें।

उन टीमों के लिए जिनके उपयोगकर्ता डेस्क पर नहीं बैठते — फ़ील्ड स्टाफ़, साइट सुपरवाइज़र, डिलीवरी टीमें, सड़क पर सेल्स — और उन ग्राहक-मुखी ऐप के लिए जहाँ पहला मिनट तय करता है कि ऐप रखा जाएगा या नहीं। यहाँ जो इंजीनियरिंग मायने रखती है वह ऑफ़लाइन व्यवहार और सिंक है, स्क्रीन नहीं।

फ़ैसला

यह कब सही फ़ैसला है।

ज़्यादातर मोबाइल ऐप ऑफ़िस वाई-फ़ाई पर दिखाए जाते हैं और साइट के गेट पर कमज़ोर 4G कनेक्शन पर इस्तेमाल होते हैं। यही अंतर वह जगह है जहाँ वे विफल होते हैं। जो ऐप कनेक्टिविटी मान लेता है, उस पर वह डेटा खोने का इल्ज़ाम लगेगा जो उसे कभी मिला ही नहीं — और एक बार फ़ील्ड स्टाफ़ का भरोसा टूट जाए, तो वे काग़ज़ पर लौट जाते हैं, जो ठीक वही नतीजा है जिसे रोकने के लिए प्रोजेक्ट को पैसा मिला था।

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

हम बनाने से पहले टकराव का मॉडल तय करते हैं, ऑफ़लाइन को अपवाद नहीं बल्कि सामान्य स्थिति मानते हैं, और वाई-फ़ाई के बजाय धीमे कनेक्शन पर जाँचते हैं। स्क्रीन तो आसान आधा हिस्सा हैं।

आपको क्या मिलता है

काम में क्या शामिल है।

ऑफ़लाइन-फ़र्स्ट डेटा

सेशन के लिए स्थानीय स्टोरेज ही सच का स्रोत, साथ में ऐसी क़तार जो ऐप बंद कर दिए जाने पर भी बची रहे, और सोच-समझकर चुना गया टकराव का नियम।

ऐसा सिंक जिसे आप जाँच सकें

सिंक की स्थिति उपयोगकर्ता और सहायता टीम दोनों को दिखती है, ताकि 'सेव नहीं हुआ' एक ऐसा सवाल बने जिसका जवाब हो।

नेटिव या क्रॉस-प्लेटफ़ॉर्म

Kotlin और Swift वहाँ जहाँ हार्डवेयर, बैकग्राउंड काम या परफ़ॉर्मेंस माँग करे; और साझा कोडबेस वहाँ जहाँ ऐप ज़्यादातर स्क्रीन हो और बचत सचमुच हो।

बैकग्राउंड काम जो चलता रहे

निर्धारित सिंक और अपलोड जो Android की बैटरी पाबंदियों के बावजूद चलता रहे, और उन वेंडर स्किन पर जाँचा गया हो जो इसे तोड़ती हैं।

ऐसा ऑथेंटिकेशन जो सुरक्षित ढंग से विफल हो

टोकन एक्सपायरी ठीक से संभाली जाती है — समाप्त सेशन उपयोगकर्ता को साइन आउट कर देता है, न कि मरे हुए अनुरोध को हमेशा दोहराता रहे।

रिलीज़ इंजीनियरिंग

साइन किए बिल्ड, चरणबद्ध रोलआउट, क्रैश रिपोर्टिंग और ऐप के भीतर अपडेट संकेत, ताकि ख़राब रिलीज़ रोकी जा सके।

स्टैक

हम इसे किससे बनाते हैं।

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

Android

Kotlin के साथ Jetpack Compose, स्थानीय स्टोरेज के लिए Room, बैकग्राउंड सिंक के लिए WorkManager।

iOS

Swift के साथ SwiftUI, और किसी ब्रिज परत के बजाय प्लेटफ़ॉर्म का अपना पर्सिस्टेंस।

क्रॉस-प्लेटफ़ॉर्म

React Native या Flutter, जहाँ ऐप स्क्रीन-प्रधान है और एक कोडबेस सचमुच आधा काम बचाता है।

बैकएंड

वही API जो आपका वेब प्लेटफ़ॉर्म इस्तेमाल करता है, और वह वर्ज़न वाला हो ताकि फ़ील्ड में पड़ा पुराना ऐप चलता रहे।

वितरण

Play Store और App Store, या जहाँ ऐप आंतरिक है वहाँ प्रबंधित एंटरप्राइज़ वितरण।

तुलना

क्रॉस-प्लेटफ़ॉर्म बनाम नेटिव।

मोबाइल प्रोजेक्ट का पहला असली फ़ैसला। हम दोनों बनाते हैं, इसलिए यह तालिका किसी एक के पक्ष की पिच नहीं, असली तर्क है।

क्रॉस-प्लेटफ़ॉर्म बनाम नेटिव
पहलूक्रॉस-प्लेटफ़ॉर्मनेटिव
किसके लिए सबसे ठीकफ़ॉर्म, सूचियाँ, सिंक — ऐसे ऐप जो ज़्यादातर API के ऊपर की स्क्रीन हैंकैमरा, बैकग्राउंड लोकेशन, ब्लूटूथ या लगातार बनी रहने वाली परफ़ॉर्मेंस
दो प्लेटफ़ॉर्म की लागतमोटे तौर पर एक बिल्ड, साथ में प्लेटफ़ॉर्म-विशेष फ़िनिशिंगलगभग दो बिल्ड, और बाद में दो कोडबेस संभालने पड़ते हैं
ऑफ़लाइन और सिंकपूरी तरह संभव है; फ़्रेमवर्क से कहीं ज़्यादा सिंक का डिज़ाइन मायने रखता हैवही — यह डेटा-मॉडल का फ़ैसला है, प्लेटफ़ॉर्म का नहीं
हार्डवेयर और OS की सुविधाएँआम चीज़ों के लिए ठीक है; कुछ भी असामान्य हो तो वैसे भी नेटिव मॉड्यूल चाहिएसीधी पहुँच, और वेंडर के व्यवहार बदलने पर डीबग करने को कोई ब्रिज नहीं
Android की बैटरी पाबंदियों के तहत बैकग्राउंड कामचल जाता है, पर वेंडर की आक्रामक स्किन दोनों ही सूरत में जाँचनी पड़ती हैंनियंत्रित करना आसान, और डिवाइस प्रोसेस बंद कर दे तो पता लगाना भी आसान
लंबे समय का रखरखावएक कोडबेस, साथ में एक फ़्रेमवर्क जिसका अपना अपग्रेड चक्र हैदो कोडबेस, पर हर एक अपने प्लेटफ़ॉर्म के अच्छी तरह दस्तावेज़ीकृत रास्ते पर

यह कैसे चलता है

पहली बातचीत से लाइव होने तक।

इस तरह के काम के लिए अनुमानित। पायलट वैकल्पिक नहीं है — जब तक इस्तेमाल करने वाले यह न कहें कि यह टिकता है, कुछ भी स्विच नहीं किया जाता।

  1. 1 हफ़्ता

    डिस्कवरी

    हम कुछ भी डिज़ाइन करने से पहले तय करते हैं कि टकराव कैसे सुलझेगा और ऑफ़लाइन में क्या होगा। इनमें से कोई भी बाद में जोड़ना लगभग दोबारा लिखने जैसा है।

  2. 4-8 हफ़्ते

    मुख्य निर्माण

    पहले स्थानीय स्टोरेज, सिंक क़तार और मुख्य कार्य-पथ, और उनकी जाँच ऑफ़िस वाई-फ़ाई पर नहीं, धीमे कनेक्शन पर।

  3. 2-3 हफ़्ते

    फ़ील्ड पायलट

    असली उपयोगकर्ता अपने ही फ़ोन पर — सस्ते फ़ोन सहित — जबकि काग़ज़ वाली प्रक्रिया चलती रहती है। ऑफ़लाइन को लेकर बनाई गई धारणाएँ यहीं सुधरती हैं।

  4. 1-2 हफ़्ते

    रिलीज़

    स्टोर सबमिशन या प्रबंधित वितरण, चरणबद्ध रोलआउट, क्रैश रिपोर्टिंग, और ऐप के भीतर अपडेट संकेत ताकि ख़राब बिल्ड रोका जा सके।

लॉन्च के बाद

क्या बदलता है।

  • फ़ील्ड स्टाफ़ दूसरे महीने के बाद भी इसे इस्तेमाल करता रहता है — फ़ील्ड ऐप की असली कसौटी यही है।
  • 'सेव नहीं हुआ' एक ऐसा सवाल बन जाता है जिसका जवाब है, क्योंकि सिंक की स्थिति उपयोगकर्ता और सहायता टीम दोनों को दिखती है।
  • तीन दिन से ऑफ़लाइन पड़ा फ़ोन बिना किसी का काम खोए मिलान कर लेता है।
  • फ़ील्ड में पड़ा पुराना वर्ज़न भी चलता रहता है, क्योंकि API वर्ज़न वाला है, मौजूदा मान लिया गया नहीं।

जानबूझकर गुणात्मक रूप में बताया गया। हम ऐसे प्रतिशत सुधार प्रकाशित नहीं करते जिन्हें हम किसी नामित क्लाइंट से, उनकी सहमति के साथ, जोड़ न सकें।

सवाल

आम सवाल।

नेटिव या क्रॉस-प्लेटफ़ॉर्म — हमें क्या चुनना चाहिए?

अगर ऐप ज़्यादातर फ़ॉर्म, सूचियाँ और सिंक है, तो आमतौर पर क्रॉस-प्लेटफ़ॉर्म का गणित सही बैठता है। अगर वह कैमरा, बैकग्राउंड लोकेशन, ब्लूटूथ हार्डवेयर या लगातार बनी रहने वाली परफ़ॉर्मेंस पर निर्भर है, तो नेटिव अपनी अतिरिक्त लागत वसूल कर लेता है। हम सिफ़ारिश अपनी पसंद से नहीं, इससे करते हैं कि ऐप असल में करता क्या है।

क्या यह इंटरनेट के बिना चलेगा?

जहाँ उपयोग की माँग हो, वहाँ यह शुरू से ही डिज़ाइन में रखा जाता है। रिकॉर्ड स्थानीय रूप से लिखे जाते हैं, क़तार में लगते हैं, और कनेक्शन लौटने पर सिंक होते हैं — और वह क़तार ऐप बंद होने या फ़ोन रीस्टार्ट होने पर भी बची रहती है।

क्या आप हमारे लिए स्टोर पर ऐप प्रकाशित करते हैं?

हाँ, स्टोर लिस्टिंग, स्क्रीनशॉट और समीक्षाओं के जवाब सहित। खाते आपके ही नाम रहते हैं — हम कभी किसी क्लाइंट का स्टोर खाता अपने पास नहीं रखते।

क्या यह हमारे मौजूदा सिस्टम के साथ चल सकता है?

हाँ। हम जो ज़्यादातर मोबाइल ऐप बनाते हैं, वे पहले से मौजूद किसी सिस्टम के ऊपर फ़ील्ड की ओर खुलने वाली परत होते हैं, अपने अलग डेटा वाला अलग उत्पाद नहीं।

क्या आप किसी और का बनाया ऐप आगे संभाल सकते हैं?

आमतौर पर हाँ। हम कोडबेस, रिलीज़ सेटअप और स्टोर खातों की छोटी समीक्षा से शुरू करते हैं और बताते हैं कि इसमें क्या लगेगा। अगर सच्चाई यह हो कि दोबारा बनाना संभालने से सस्ता है, तो हम यही कहेंगे और उसका तर्क भी दिखाएँगे।

क्या हमें ऐप की ज़रूरत भी है, या मोबाइल साइट से काम चल जाएगा?

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