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) قطار کے اندر پروسیسنگ کے ترتیب کا تعین کرتی ہے — high ترجیح والی درخواستیں normal سے پہلے پروسیس ہوتی ہیں۔

درخواست کے پروسیس ہونے کے بعد، نتیجہ 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 درخواستیں تصویروں اور فائلوں کو اپ لوڈ کرنے کے لیے مفید ہیں لیکن دستی نفاذ کی ضرورت ہوتی ہے کیونکہ OkHttp یا Dio کے برعکس، Volley کے پاس 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 میں ایک بار یا ایک singleton کلاس کے ذریعے بنایا جائے۔ دیگر طور پر، ہر ایکران کا اپنا ثریڈ پول ہوگا اور کیش ہر قطار کے لیے علاحدہ محفوظ ہوگی۔

ایکران گھومانے پر درخواست منسوخی کو نظرانداز کرنا۔ ترتیب بدلنے پر، Activity دوبارہ بنائی جاتی ہے اور پرانی Activity کے کال بیکس میموری میں موجود رہتے ہیں۔ اس سے لیک ہوتے ہیں اور تباہ شدہ View کو اپ ڈیٹ کرنے کی کوششیں ہوتی ہیں۔ ہمیشہ Activity-مخصوص ٹیگ کے ساتھ onStop() میں cancelAll() کے ذریعے درخواستوں کو منسوخ کریں۔

Volley HTTP/2 اور کوروٹین کو سپورٹ نہیں کرتا — یہ استعمال کی غلطی نہیں بلکہ ایک آرکیٹیکچرل حد ہے۔ Volley 2013 میں بنایا گیا تھا اور جدید پروٹوکلز اور Kotlin کوروٹین کو سپورٹ نہیں کرتا۔ نئے مناصبوں کے لیے، Google Retrofit + OkHttp کا استعمال کرنے کی سفارش کرتا ہے۔ Volley صرف لگیسی مناصبوں کی حمایت یا کم سے کم نیٹورکنگ ضرورتوں کے ساتھ سادہ ایپلیکیشنوں کے لیے موزوں ہے۔