وبلاگ - مطالب آموزشی

0
310
تست و تزریق وابستگی در اندروید با استفاده از Model View Presenter

تست و تزریق وابستگی در اندروید با استفاده از Model View Presenter

در بخش اول این مطلب آموزشی با مفاهیم اولیه Model View Presenter آشنایی پیدا کردید و در بخش دوم نحوه پیاده سازی آن در یک اپلیکیشن توضیح داده شد. در این مطلب قصد داریم که با شرح جزئیات موارد زیر را مورد بررسی قرار دهیم:

– راه اندازی یک محیط تست و نوشتن تست های واحد برای کلاس های MVP

– پیاده سازی الگوی MVP با استفاده از تزریق وابستگی و با کمک Dagger 2

– تشریح نحوه جلوگیری از مشکلات رایج در استفاده از MVP در اندروید

1. تست واحد

یکی از بزرگ ترین مزایای استفاده از الگوی MVP تسهیل فرآیند تست واحد می باشد. کار را با نوشتن تست هایی برای کلاس های Model و Presenter که در بخش نهایی مطلب قبلی ساخته بودیم آغاز می نماییم. اجرای تست های نوشته شده را توسط Robolectric که یک فریم ورک تست واحد است به انجام می رسانیم. به منظور ساخت آبجکت های تقلیدی، Mockito را استفاده می کنیم که ما را قادر به تایید در صورت فراخوانی متدهای خاص می گرداند.

گام 1: راه اندازی

فایل build.gradle از ماژول اپلیکیشن خود را ویرایش کرده و وابستگی های زیر را به آن بیفزایید.

در داخل فولدر src پروژه فولدرهایی به صورت [/java/[package-name]/[app-name بسازید. پس از آن یک پیکربندی دیباگ ساخته و بسته تست را به اجرا در آورید. بر روی Edit Configurations در قسمت بالا کلیک کنید.

blog_17957_1

با کلیک بر روی دکمه + گزینه JUnit را از فهرست نمایش داده شده برگزینید.

blog_17957_2

Working directory را به $MODULE_DIR$ ست کنید.

blog_17957_3

این پیکربندی برای تمامی تست های واحد به اجرا در می آید. Test kind را به All in package ست کرده و در فیلد Package نام پکیج را وارد کنید.

blog_17957_4

گام 2: تست کردن Model

حال فرآیند تست با استفاده از کلاس Model را آغاز می کنیم. تست واحد با استفاده از RobolectricGradleTestRunner.class که منابع موردنیاز برای تست عملکردهای خاص اندروید را در اختیار قرار می دهد، به اجرا در می آید. حاشیه نویسی config@ با گزینه های زیر اهمیت دارد:

ما از یک DAO واقعی برای تست اینکه داده ها به درستی مورد استفاده قرار گرفته اند بهره می گیریم، برای دسترسی به یک Context، از کلاس RuntimeEnvironment.application استفاده می کنیم.

حال زمان تست متدهای Model است.

در این مرحله قادر به اجرای تست Model و بررسی نتایج هستید، علاوه بر این می توانید سایر جنبه های کلاس را نیز بیازمایید.

گام 3: تست Presenter

در این مرحله تمرکز خود را بر روی تست Presenter می گذاریم. برای این کار به Robolectric نیاز خواهیم داشت تا بتوانیم از چندین کلاس اندروید مانند AsyncTask استفاده کنیم. پیکربندی بسیار شبیه به تست Model می باشد. ما از مقلدهای View و Model برای بررسی فراخوانی های متدها و تعریف مقادیر بازگشتی استفاده می نماییم.

جهت تست متدهای Presenter کار را با عملکرد ()clickNewNote آغاز می کنیم که مسئول ایجاد یک یادداشت جدید و ثبت آن در پایگاه داده با استفاده از AsyncTask می باشد.

علاوه بر این می توانستیم یک سناریو را تست کنیم که در آن متد ()insertNote یک خطا را باز می گرداند.

در نهایت، به تست متد ()deleteNote با نتایج موفق و ناموفق می پردازیم.

2. تزریق وابستگی با استفاده از Dagger 2

تزریق وابستگی یک ابزار بسیار خوب است که در دسترس توسعه دهندگان قرار گرفته، چنانچه با این مبحث آشنایی ندارید، مطالعه مقاله Kerry’s article در این باره پیشنهاد می شود.

تزریق وابستگی سبکی از پیکربندی آبجکت است که در آن فیلدها و همکاران آبجکت توسط یک موجودیت خارجی ست می شوند. به بیان دیگر آبجکت ها توسط یک موجودیت خارجی پیکربندی می شوند. تزریق وابستگی یک جایگزین برای یک پیکربندی آبجکت می باشد. Jakob Jenkov

در این مثال تزریق وابستگی، Model و Presenter ساخته شده در خارج از View را می پذیرد و موجب می شود که لایه های MVP آزادانه تر  مرتبط شده و جداسازی وظایف افزایش یابد.

در اینجا Dagger 2 که یک لایبرری بسیار خوب از گوگل است، جهت تزریق وابستگی مورد استفاده قرار می گیرد. راه اندازی آن بسیار ساده بوده و دارای گزینه های بسیار خوبی است و این امر آن را یک لایبرری نسبتا پیچیده گردانیده است.

تمرکز ما تنها بر روی بخش های مرتبط از لایبرری گذاشته شده و لایبرری با جزئیات کامل مورد بررسی قرار نمی گیرد. چنانچه مایل به دریافت جزئیات بیشتری درباره Dagger هستید، Kerry’s tutorial و یا documentation را که توسط گوگل ارائه شده، مطالعه نمایید.

گام 1: راه اندازی Dagger 2

اول از همه کار را با آپدیت کردن فایل build.gradle و افزودن یک وابستگی آغاز کنید.

در گام بعدی فایل build.dagger از پروژه را مشابه چیزی که نمایش داده شده ویرایش کنید.

پروژه را همگام سازی کرده و منتظر تکمیل فرآیند بمانید.

گام 2: پیاده سازی MVP با استفاده از Dagger 2

کار را با ساخت یک scope@ برای کلاس اکتیویتی آغاز می کنیم. یک annotation@ با نام scope بسازید.

در مرحله بعد بر روی یک module@ برای MainActivity کار می کنیم، چنانچه دارای چندین اکتیویتی هستید، لازم است تا یک Module@ برای هر اکتیویتی در اختیار قرار دهید.

علاوه بر این نیاز به یک Subcomponent@ برای ساخت ارتباط با Component@ اپلیکیشن که باید ساخته شود، داریم.

لازم است تا یک Module@ و یک Component@ برای اپلیکیشن بسازیم.

در نهایت به یک کلاس Application جهت مقداردهی اولیه تزریق وابستگی نیاز داریم.

به یاد داشته باشید که نام کلاس را در فایل منیفست پروژه درج کنید.

گام 3: تزریق کلاس های MVP

در آخر می توانیم کلاس های MVP خود را Inject@ کنیم، تغییرات موردنظر در کلاس MainActivity اعمال می شوند. در حقیقت روشی را که model و Presenter مقداردهی اولیه می شوند تغییر داده ایم.

گام نخست تغییر تعریف متغییر MVP_Main.ProvidedPresenterOps است. این متغییر باید public باشد و حاشیه نویسی Inject@ را نیز به آن اضافه کنیم.

به منظور راه اندازی MainActivityComponent قطعه کد زیر را اضافه کنید.

در این مرحله باید مقداردهی اولیه و مجدد Presenter را بسته به حالت آن در StateMaintainer به انجام برسانیم. با افزودن بخش زیر متد ()setupMVP را تغییر دهید:

عناصر MVP هم اکنون دارای پیکربندی مستقل از View می باشند. کد به لطف استفاده از تزریق وابستگی نظم بیشتری دارد، با تزریق کلاس های دیگر مانند DAO می توانید کد را بیشتر از این نیز ارتقا بخشید.

3. پیشگیری از مشکلات رایج

در زیر مشکلات رایجی که باید سعی در جلوگیری از آنها شود، فهرست شده اند.

– همیشه پیش از فراخوانی View در دسترس بودن آن را چک کنید. View به چرخه حیات اپلیکیشن وابسته است و هر زمان که تمایل داشته باشید می توانید آن را از بین ببرید.

– به یاد داشته باشید که با ساخت View جدید یک رفرنس جدید را ارسال کنید.

– هر وقت که View از بین می رود، ()onDestroy موجود در Presenter را فراخوانی کنید. در برخی از موارد لازم است تا Presenter را از رویدادهای onStop و onPause نیز مطلع گردانید.

– در صورت کار با Viewهای پیچیده از چندین Presenter استفاده کنید.

– در صورت استفاده از چندین Presenter، ساده ترین راه جهت ارسال اطلاعات بین آنها بکار بردن ایونت باس می باشد.

– جهت غیرفعال نگه داشتن لایه View تا جای ممکن، از تزریق وابستگی جهت ساخت لایه های Presenter و Model در خارج از View استفاده کنید.
جمع بندی

این سری از مطالب آموزشی به پایان رسید و در آن به شرح الگوی Model View Presenter پرداخته شد. هم اکنون قادر به پیاده سازی الگوی MVP در پروژه ها، تست و بکارگیری تزریق وابستگی می باشید.

 

منبع:

http://code.tutsplus.com

این نوشته را به گوگل توصیه کنید :

بسته های آموزشی جذاب!بیشتر