Volley — यह क्या है, Google की नेटवर्किंग लाइब्रेरी की विशेषताएँ

Volley क्या है?

Volley Android अनुप्रयोगों में नेटवर्क संचार के लिए एक लाइब्रेरी है, जिसे Google ने I/O 2013 सम्मेलन में प्रस्तुत किया था। Volley नाम का अर्थ है «एक सैल्वो» — लाइब्रेरी कई समानांतर तेज़ अनुरोधों को निष्पादित करने के लिए डिज़ाइन की गई है, जो UI-उन्मुख अनुप्रयोगों की विशेषता है जहाँ इंटरफ़ेस प्रतिक्रिया गति महत्वपूर्ण है।

Volley को HttpURLConnection और AsyncTask की समस्याओं के समाधान के रूप में बनाया गया था: मैनुअल थ्रेड प्रबंधन, कैशिंग की कमी, अनुरोध प्राथमिकता निर्धारण की जटिलता और भारी कोड। Google ने Volley को «fire-and-forget» प्रकार के संचालन के लिए लाइब्रेरी के रूप में स्थापित किया — छोटे अनुरोध जिनके परिणाम तुरंत इंटरफ़ेस में प्रदर्शित होते हैं।

Volley आर्किटेक्चर में तीन मुख्य घटक शामिल हैं: RequestQueue (कतार प्रबंधक), CacheDispatcher (कैश की गई प्रतिक्रियाओं के लिए थ्रेड) और NetworkDispatcher (नेटवर्क थ्रेड)। यह आर्किटेक्चर स्वचालित रूप से अनुरोधों को वितरित करता है: पहले कैश की जाँच की जाती है, और केवल इसकी अनुपस्थिति में नेटवर्क अनुरोध किया जाता है। यह बार-बार किए गए डेटा के लिए विलंबता को 50–80% तक कम करता है।

Volley कैसे काम करता है

RequestQueue Volley का केंद्रीय वर्ग है। इसमें Request<T> ऑब्जेक्ट जोड़े जाते हैं, और कतार स्वचालित रूप से उन्हें दो प्रकार के थ्रेड में वितरित करती है: CacheDispatcher (एक थ्रेड, संभावित कैश वाले अनुरोधों को संभालता है) और NetworkDispatcher (कई थ्रेड, वास्तविक HTTP अनुरोध करते हैं)। डिफ़ॉल्ट रूप से, Volley 4 नेटवर्क थ्रेड बनाता है।

जब कोई अनुरोध जोड़ा जाता है, RequestQueue जाँचता है कि क्या इसे कैश से प्राप्त किया जा सकता है। यदि कैश में अद्यतन प्रतिक्रिया है, CacheDispatcher इसे तुरंत लौटाता है, बिना नेटवर्क अनुरोध के। यदि कैश पुराना है या अनुपस्थित है, तो अनुरोध NetworkDispatcher को भेजा जाता है। अनुरोध प्राथमिकता (low, normal, high, immediate) कतार के भीतर प्रसंस्करण क्रम निर्धारित करती है — उच्च प्राथमिकता वाले अनुरोध सामान्य से पहले संसाधित होते हैं।

अनुरोध निष्पादित होने के बाद, परिणाम Handler के माध्यम से मुख्य थ्रेड (UI थ्रेड) पर पहुँचाया जाता है। Volley स्वचालित रूप से onResponse() और onErrorResponse() कॉलबैक को मुख्य थ्रेड पर स्विच करता है, इसलिए इंटरफ़ेस को सीधे कॉलबैक में अतिरिक्त थ्रेड स्विचिंग के बिना अपडेट किया जा सकता है। यह कोड को सरल बनाता है और थ्रेडिंग त्रुटियों की एक पूरी श्रेणी को समाप्त करता है।

Volley की एक और विशेषता स्वचालित अनुरोध डिडुप्लीकेशन है। यदि एक ही URL और समान पैरामीटर वाले दो समान GET अनुरोध कतार में जोड़े जाते हैं, Volley उनमें से केवल एक को निष्पादित करता है और दोनों कॉलबैक को समान प्रतिक्रिया लौटाता है। यह उन स्क्रीन के लिए विशेष रूप से उपयोगी है जहाँ कई घटक स्वतंत्र रूप से समान डेटा का अनुरोध करते हैं — उदाहरण के लिए, एक उपयोगकर्ता प्रोफ़ाइल जो हेडर और सेटिंग्स फ़्रैगमेंट दोनों के लिए एक साथ आवश्यक है।

Volley में अनुरोध जीवनचक्र

प्रत्येक अनुरोध चरणों के एक क्रम से गुज़रता है: Request बनाना, RequestQueue में जोड़ना, कैश की जाँच करना (CacheDispatcher), HTTP अनुरोध निष्पादित करना (NetworkDispatcher), Response.Listener के माध्यम से प्रतिक्रिया पार्स करना, UI थ्रेड में परिणाम वितरित करना। जब कोई अनुरोध रद्द किया जाता है (cancel), RequestQueue इसे कतार से हटा देता है और कॉलबैक को कॉल होने से रोकता है।

Volley RetryPolicy का भी समर्थन करता है, जो विफलताओं पर पुनः प्रयास प्रयासों की संख्या निर्धारित करता है। DefaultRetryPolicy डिफ़ॉल्ट रूप से 2.5 सेकंड के टाइमआउट के साथ एक पुनः प्रयास करता है। अस्थिर कनेक्शन के लिए, पुनः प्रयासों की संख्या 3 तक और टाइमआउट 10 सेकंड तक बढ़ाया जा सकता है। कस्टम RetryPolicy को RetryPolicy इंटरफ़ेस के माध्यम से getCurrentTimeout, getCurrentRetryCount और retry विधियों के साथ कार्यान्वित किया जाता है।

Volley अनुरोध प्रकार

Volley सामान्य डेटा प्रारूपों के लिए तैयार अनुरोध प्रकार प्रदान करता है। प्रत्येक प्रकार अमूर्त वर्ग Request<T> को लागू करता है और प्रतिक्रिया पार्स करने की एक विधि परिभाषित करता है। कस्टम प्रारूपों के लिए, आप parseNetworkResponse विधि को ओवरराइड करके अपना स्वयं का प्रकार बना सकते हैं।

कस्टम अनुरोध

Gson या Kotlinx Serialization के साथ काम करने के लिए, आप एक कस्टम Request<T> बना सकते हैं जो parseNetworkResponse में चयनित पार्सर का उपयोग करता है। यह मैन्युअल JSONObject पार्सिंग को दरकिनार करते हुए सीधे टाइप की गई ऑब्जेक्ट प्राप्त करने की अनुमति देता है। यह दृष्टिकोण विशेष रूप से उन परियोजनाओं के लिए उपयोगी है जो पहले से Gson या Moshi के माध्यम से सीरियलाइज़ेशन का उपयोग कर रही हैं।

डेटा भेजने के लिए, Volley तीन बॉडी प्रकारों का समर्थन करता है: JSONObject (POST विधि के साथ JsonObjectRequest के माध्यम से), Form-encoded (कंस्ट्रक्टर में HashMap<String, String> के माध्यम से), और Multipart (कस्टम MultipartRequest के माध्यम से)। Multipart अनुरोध इमेज और फ़ाइलें अपलोड करने के लिए उपयोगी हैं लेकिन मैन्युअल कार्यान्वयन की आवश्यकता होती है क्योंकि Volley में OkHttp या Dio के विपरीत, multipart/form-data के लिए अंतर्निहित समर्थन नहीं है।

Volley की सीमाएँ बड़ी प्रतिक्रियाओं के साथ काम करते समय ध्यान देने योग्य हो जाती हैं। Volley कॉलबैक को पास करने से पहले पूरी प्रतिक्रिया को मेमोरी में लोड करता है, जो 10–20 MB से बड़ी JSON फ़ाइलों के लिए OutOfMemoryError का कारण बन सकता है। बड़ी फ़ाइलें डाउनलोड करने के लिए, Volley उपयुक्त नहीं है — DownloadManager या स्ट्रीमिंग ResponseBody के साथ OkHttp का उपयोग करें। Volley बाधित डाउनलोड (Range हेडर) को फिर से शुरू करने का समर्थन नहीं करता है और रीयल-टाइम में Server-Sent Events या WebSocket जैसे स्ट्रीमिंग प्रोटोकॉल के साथ काम नहीं करता है।

Java और Kotlin में Volley कोड उदाहरण

आइए एक बुनियादी उदाहरण देखें — सर्वर से डेटा प्राप्त करने के लिए StringRequest। पहले, Volley.newRequestQueue(context) के माध्यम से RequestQueue बनाई जाती है। फिर URL और सफलता और त्रुटि कॉलबैक के साथ एक अनुरोध बनाया जाता है।

val queue = Volley.newRequestQueue(context)

val request = StringRequest(
    Request.Method.GET,
    "https://api.github.com/users/octocat",
    { response ->
        println("प्रतिक्रिया: $response")
    },
    { error ->
        println("त्रुटि: ${error.message}")
    }
)

queue.add(request)

JSON अनुरोध के लिए, JsonObjectRequest का उपयोग किया जाता है, जो स्वचालित रूप से प्रतिक्रिया को JSONObject में पार्स करता है। Volley GET और POST अनुरोधों का समर्थन करता है। POST के लिए, अनुरोध निकाय में एक JSONObject पास किया जाता है।

val jsonBody = JSONObject()
jsonBody.put("name", "New Repo")
jsonBody.put("description", "Created via Volley")

val request = JsonObjectRequest(
    Request.Method.POST,
    "https://api.github.com/user/repos",
    jsonBody,
    { response ->
        println("बनाया गया: ${response.getString("id")}")
    },
    { println("त्रुटि: $it") }
)

queue.add(request)

अनुरोध रद्द करना

अनुरोध रद्द करने के लिए, cancel() विधि या टैग द्वारा समूह रद्दीकरण का उपयोग किया जाता है। रद्द करने पर, Volley न तो onResponse और न ही onErrorResponse को कॉल करता है, जो स्क्रीन छोड़ने के बाद इंटरफ़ेस अपडेट को रोकता है। यह Activity और Fragment में मेमोरी लीक को रोकने के लिए महत्वपूर्ण है।

request.tag = "profile_request"
queue.add(request)

// स्क्रीन छोड़ने पर रद्दीकरण
queue.cancelAll("profile_request")

ImageLoader और NetworkImageView

ImageLoader RequestQueue के ऊपर एक रैपर वर्ग है, जो इमेज लोड करने के लिए अनुकूलित है। यह मेमोरी कैश (LruCache) का समर्थन करता है और RecyclerView सूचियों में ImageView के पुन: उपयोग पर स्वचालित रूप से अनुरोध रद्द करता है। ImageLoader View के आकार में फिट होने के लिए इमेज को स्केल भी करता है, जिससे मेमोरी बचती है।

NetworkImageView एक कस्टम View है जो ImageLoader के साथ एकीकृत होता है और स्वचालित रूप से लोडिंग का प्रबंधन करता है: लोडिंग के दौरान प्लेसहोल्डर दिखाता है, विफलता पर इसे त्रुटि से बदल देता है, और View के स्क्रीन छोड़ने पर अनुरोध रद्द कर देता है। DefaultImageUrlLoader URL द्वारा इमेज लोड करता है और तेज़ पुन: प्रदर्शन के लिए इसे LruCache में संग्रहीत करता है।

ImageLoader का उपयोग करने के लिए, बस ImageLoader(queue, ImageCache) के माध्यम से एक इंस्टेंस बनाएँ, जहाँ ImageCache अंदर LruCache के साथ ImageCache इंटरफ़ेस का कार्यान्वयन है। XML लेआउट में NetworkImageView को setImageUrl() विधि के माध्यम से ImageLoader से जोड़ा जाता है, और सभी लोडिंग पूरी तरह से स्वचालित रूप से प्लेसहोल्डर और त्रुटियों को संभालने के लिए अतिरिक्त कोड के बिना होती है।

Volley के साथ काम करते समय सामान्य गलतियाँ

प्रत्येक Activity में RequestQueue बनाना एक सामान्य गलती है जो थ्रेड दोहराव और कैश भ्रम की ओर ले जाती है। RequestQueue को Application में एक बार या सिंगलटन वर्ग के माध्यम से बनाने की अनुशंसा की जाती है। अन्यथा, प्रत्येक स्क्रीन का अपना थ्रेड पूल होगा, और कैश प्रत्येक कतार के लिए अलग से संग्रहीत किया जाएगा।

स्क्रीन रोटेशन पर अनुरोध रद्दीकरण को अनदेखा करना। कॉन्फ़िगरेशन बदलने पर, Activity पुनः बनाई जाती है, और पुरानी Activity के कॉलबैक मेमोरी में बने रहते हैं। इससे लीक होती है और नष्ट किए गए View को अपडेट करने का प्रयास होता है। हमेशा Activity-विशिष्ट टैग के साथ onStop() में cancelAll() के माध्यम से अनुरोध रद्द करें।

Volley HTTP/2 और कोरूटीन का समर्थन नहीं करता — यह उपयोग त्रुटि नहीं बल्कि एक आर्किटेक्चरल सीमा है। Volley 2013 में बनाया गया था और आधुनिक प्रोटोकॉल और Kotlin कोरूटीन का समर्थन नहीं करता है। नई परियोजनाओं के लिए, Google Retrofit + OkHttp का उपयोग करने की अनुशंसा करता है। Volley केवल लीगेसी परियोजनाओं का समर्थन करने या न्यूनतम नेटवर्किंग आवश्यकताओं वाले सरल अनुप्रयोगों के लिए उपयुक्त है।