- यह लेख Google की आवश्यकताएँ अपडेट होने पर legacy Android ऐप्स को मेंटेन करने में आने वाली चुनौतियों पर एक केस स्टडी है.
- लेखक की टीम कई वर्षों से एक ऐसे Android ऐप की ज़िम्मेदारी संभाल रही थी जो स्थिर था, और उस पर सक्रिय डेवलपमेंट नहीं हो रहा था.
- Google ने ईमेल भेजकर कहा कि सभी ऐप्स को API level 31 या उससे ऊपर को target करना होगा, ताकि वे उन डिवाइसों पर भी यूज़र्स के लिए उपलब्ध रहें जो ऐप के target API level से ऊँचा Android OS चला रहे हों.
- लेखक ने
targetSdkVersion को API level 30 से 33 पर अपडेट किया और analytics से जुड़ी असंगत dependencies हटा दीं.
- अपडेट किया गया ऐप सफलतापूर्वक Google Play Store पर अपलोड हो गया, और शुरुआत में वह अपेक्षा के अनुसार काम करता हुआ लगा.
- लेकिन ग्राहकों ने बताया कि वे एप्लिकेशन के सबसे नए वर्ज़न का उपयोग करके अपने अकाउंट में लॉग इन नहीं कर पा रहे थे. Android के वास्तविक डिवाइस पर लॉग इन करने के बाद ऐप क्रैश हो जाता था.
- यह समस्या सबसे नए Android वर्ज़न (उस समय 13) तक सीमित थी, और लेखक को एहसास हुआ कि उन्होंने इस वर्ज़न पर ऐप का परीक्षण ही नहीं किया था.
- इसके बाद लेखक ने Google Play Store में पुराने काम करने वाले वर्ज़न पर वापस जाने की कोशिश की, लेकिन Google की पाबंदियों के कारण यह संभव नहीं था.
- फिर लेखक ने
targetSdkVersion को दोबारा API level 30 पर लाकर Play Store में नई रिलीज़ बनाने की कोशिश की, लेकिन Google की अनिवार्य API level 33 requirement के कारण यह भी संभव नहीं हुआ.
- एकमात्र समाधान यही था कि सबसे नए Android वर्ज़न पर होने वाले क्रैश को ठीक किया जाए और नई रिलीज़ बनाई जाए.
- लेखक ने ज्ञात क्रैश समस्या को ठीक करके नया वर्ज़न रिलीज़ किया, लेकिन ऐप लंबे समय तक "In review" स्थिति में अटका रहा.
- लेखक मोबाइल ऐप डेवलपमेंट पर Google और Apple के नियंत्रण की आलोचना करते हैं और कहते हैं कि इससे डेवलपर्स को production समस्याएँ हल करने में बाधा आ सकती है.
- लेखक product/service डेवलपमेंट पर दोबारा नियंत्रण पाने के लिए open web standards की ओर लौटने का सुझाव देते हैं.
- लेखक का अनुभव ऐप डिस्ट्रीब्यूशन के लिए third-party platforms पर निर्भर रहने के संभावित खतरों और हर संभावित user environment में गहन testing के महत्व को रेखांकित करता है.
1 टिप्पणियां
Hacker News की राय