کتابخانه Volley

کتابخانه volley

 

کتابخانه Volley به عنوان یک کتابخانه برنامه نویسی شبکه (networking)، در Google I/O 2013 معرفی شد. توسعه کتابخانه Volley برای جبران نبود یک کلاس networking کارا در SDK اندروید بود، کلاسی که همه مشکلات موجود در موارد قبلی مانند java.net.HttpURLConnection و org.apache.http.client را رفع کند.

صرف نظر از همه باگ های مرسوم کلاسهای فوق، نکته مهمتر این بود که همه موارد در یک ارتباط HTTP باید از صفر نوشته می شد، مواردی همانند cache کردن عکس ها یا تغییر اولویت درخواست های ارسالی به سرور.

در ادامه مروری خواهیم داشت بر دلایل برتری کتابخانه volley بر روش های پیشین:

الف) دیگر نیازی به HttpUrlConnection یا HttpClient نیست

در API های پایین تر (API 8-10)، هم HttpUrlConnection و هم HttpClinet، مشکلات و باگ های زیادی داشتند که برخی هرگز حل نشدند. به علاوه HttpClinet از API 22 منسوخ اعلام شده و شاید در نسخه های بعدی به کلی حذف شود.

ب) دیگر نیازی به AsyncTask هم نیست

از معرفی API 11 به بعد، اعلام شد که عملیات شبکه باید در یک thread جداگانه انجام شود، threadی مجزا از Main Thread یا همان UI Thread. در نتیجه توسعه دهندگان به صورت گسترده به استفاده از  <AsyncTask <Params, Progress, Result  روی آوردند. استفاده از AsyncTask شامل سه مرحله زیر است که بسیار ساده تر از راه اندازی یک سرویس جداگانه با یک عالمه ملاحظات و پیچیدگی است:

۱- تعریف context در onPreExecute

۲- انجام فعالیت های زمانبر در متد doInBackground

۳- بررسی نتایج در onPostExecute

اگر چه مشکل دیگری در سری سازی درخواست ها پیش می آید. با کلاس AsyncTask نمی توان تعیین کرد که چه درخواستی اول ارسال شود و کدام درخواست منتظر بماند، همه ی درخواست ها وارد صف FIFO می شوند، یعنی اولین ورودی برابر است با اولین خروجی!

در موارد عادی این داستان، ایرادی ندارد، ولی در نظر بگیرید که قرار است شبیه فیس.بوک یا توییتر، فهرستی از آیتم ها با هر بار اسکرول کردن کاربر بارگذاری شوند. کاربر با اسکرول به سمت پایین منتظر بارگذاری موارد جدیدتر است، ولی با کلاس AsyncTask عملاً امکان اولویت بندی در بارگذاری موارد وجود ندارد و نمی توان اعلان کرد که نخست موارد مربوط به صفحه آخر بارگذاری شود و سپس صفحه های قبلی! می توانید تصور کنید که این مشکل چقدر در تجربه کاربری تاثیر منفی دارد…

کتابخانه Volley با در نظر گرفتن یک API قوی برای لغو درخواست ها، این مشکل را به سادگی حل کرده است. دیگر نیازی نیست برای ارسال یک درخواست در  onPostExecute به انتظار destroy شدن یک اکتیویتی بمانیم و این مسئله به زیبایی مشکل  NullPointerException ناخواسته را نیز برطرف کرده است.

پ) سرعت بالاتر

در زمان معرفی کتابخانه volley، تیم Instracture بررسی ای انجام دادند که در طی آن زمان پاسخ به درخواست در volley به طرز قابل ملاحظه ای کمتر از روش AsyncTask است.

ت) همه چیز برای شما cache می شود!

کتابخانه Volley همه درخواست ها را کش می کند و این زمانی ارزشمند است که به destroy شدن اکتیویتی با هر بار گردش صفحه فکر کنیم! فقط در نظر بگیرید که بدون ویژگی cache، کاربر یک صفحه پر از عکس های حجیم را بچرخاند 😐 این به معنای درخواست بارگذاری مجدد همه عکس ها از سرور و صرف بیهوده حجم اینترنت و وقت کاربر است.

ث) بهینه برای عملیات کوچک Metadata

در Main Thread، بنا به محدودیتی که پیشتر درباره AsyncTask توضیح دادیم، فقط امکان ارسال درخواست و رسیدگی به پاسخ آن فراهم است، نه بیشتر و نه کمتر! نتیجه این که Volley به صورت خودکار عملیات مربوط به HTTP و cache را در Threadهای جداگانه ای پیش می برد.

هنگامی که یک درخواست جدید در Main Thread ارسال می کنید، اتفاقات زیادی در پشت پرده انجام می شود. نخست، Volley چک می کند که آیا از طریق پاسخ های موجود در cache می تواند به درخواست فعلی پاسخ دهد یا خیر. اگر پاسخ مثبت باشد (معادل cache hit در تصویر)، پاسخ از cache خوانده شده (توسط متد CacheDispatcher)، سپس تجزیه شده (parse) و تحویل Main Thread می شود.

اگر پاسخ منفی باشد (معادل cache miss در تصویر)، نیاز است که داده مورد نظر دوباره از شبکه دریافت شود، پس درخواست به thread شبکه وارد می شود، که یک ترکیب round robin از چندین thread همزمان در حال کار است. اولین thread شبکه در دسترس، به درخواست ما پاسخ می دهد (از طریق متد NetworkDispatcher)، یک درخواست HTTP ارسال کرده، پاسخ را تجزیه کرده و در cache می نویسد. در نهایت پاسخ تجزیه شده برای Main Thread هم ارسال می گردد، جایی که listenerها در انتظار دریافت پاسخ از شبکه هستند.

 

یک مثال ساده از کاربرد کتابخانه Volley

برای شروع ابتدا dependency زیرا در build.gradle اضافه کنید:

در مرحله بعد، با توجه به آنچه در بالا اشاره شد، کتابخانه Volley با دو کلاس اصلی کار می کند: RequestQueue و Request

پس ابتدا یک RequestQueue می سازیم که مدیریت Requestها را بر عهده بگیرد و نتایج parse شده را به Main Thread برگرداند، سپس می توان یک یا چند Request ساخت و آن ها را به RequestQueue پاس داد.

کلاس Request روش ارتباطی با REST API (یعنی GET, POST, …)، آدرس URL موردنظر و event listener (برای دریافت پاسخ) را به عنوان پارامترهای ورودی قبول می کند.

در انتها به کمک Volley.newRequestQueue، از RequestQueue یک Object ساخته و StringRequest موردنظر را به آن پاس می کنیم:

روش ساده ای به نظر می آید، تعریف یک Request و اضافه کردن آن به RequestQueue 🙂

دقت کنید که فرمول listener مشابه AsyncTask.onPostExecute است و این اتفاقی نیست؛ در واقع توسعه دهندگان Volley این گونه عمل کرده اند تا فرآیند انتقال از متدهای  AsyncTask به Volley راحت تر انجام شود.

این یک مثال ساده بود برای درک فرآیند کار با کتابخانه Volley؛ برای استفاده از درخواست های گوناگون در اکتیویتی های مختلف، بهتر است یک صف درخواست اشتراکی (shared request queue) در سطح application تعریف کنید (یعنی استفاده از کلاس extend شده از application) تا مشکلی پیش نیاید.

در نوشته های بعدی سعی می کنیم درباره انواع Request ها شامل (ImageRequest و JsonRequest) توضیح دهیم.

 

منبع:

 http://code.tutsplus.com/tutorials/an-introduction-to-volley–cms-23800

دیدگاه خود را بیان کنید

اولین نفری باشید که دیدگاهش را بیان می کند

avatar
  Subscribe  
به من اطلاع بده