Mahdi Tajik I'm Mahdi Tajik. I am project manager and Full-stack Android developer. welcome to my personal website.
سلام دوستان عزیز، متاسفانه کمی طول کشید تا مطلب آموزشی بگذارم، کامنت ها و استقبال شما انرژی خاصی به من داد تا هرچه زود تر نسبت به کامل کردن این بحث اقدام کنم. خیلی خوب، در مقاله قبلی با نحوه استفاده از Dagger2 آشنا شدیم. در این بخش می خواهیم چند روش دیگر استفاده را به همراه امکانات بیشتر این کتابخانه مورد برسی قرار دهیم. همانطور که در آموزش قبلی به روز کردم به علت استفاده زیاد از این کتابخانه، گوگل امکان اضافه کردن آن را به صورت مستقیم داده و شما می توانید ازین پس بصورت زیر در gradle در سطح خود برنامه از آن استفاده کنید:
|
1 2 |
compile 'com.google.dagger:dagger:2.7' annotationProcessor 'com.google.dagger:dagger-compiler:2.7' |
می خواهیم کمی بیشتر با DI آشنا شویم و ابزار های آن را در Dagger2 ببینیم. ما چند نوع تزریق داریم.
Constructor injection
برروی کانستراکتور Inject@ گذاشته و در این صورت دیگر نیازی به نوشتن Module نداریم.
Fields injection
همینطور که در آموزش قبل ملاحظه کردید تزریق یک فیلد را گویند. ( در تمامی آموزش قبل از fields injection استفاده کردیم)
Methods injection
بروری یک متدی از یک کلاس Inject@ بگذاریم.
چند انوتیشن که باید در این جلسه با آنها آشنا شویم:
@Scope annotation
اصولا هدف استفاده از این انوتیشن معرفی Scope آبجک تولید شده است. یعنی Dagger2 به شما این امکان را می دهد تا Object های شما چرخه عمر متفاوت داشته باشند و شما فقط تعریف می کنید، مدیریتش با خود Dagger است. پیشنهاد من این است که برای این مقاله تا همین حد کافی است و بعد از اتمام این اموزش به مقاله کامل مراجعه کنید.
@Qualifierوقتی از این انوتیشن استفاده می کنیم که متد ها همنام و و ورودی خروجی یکسان داشته باشند و به Dagger می فهمانیم کِی، چی را تزریق کند.
بسیار عالی. در آموزش قبل دیدیم که هرجا بخواهیم از DI توسط Dagger2 استفاده کنیم باید سه مرحله زیر را انجام دهیم:
۱- ساخت Provider ها در کلاس Module که مشخص می کنیم کلاس ها چگونه تولید شوند.
۲- ساخت اینترفیسی به نام Component که می گویم از کدام Module ها استفاده کند و متدی در آن قرار می دادیم که کلاسی که در آن Inject انجام شده بود وجود داشته باشد تا Dagger2 بفهمد کدام کلاس ها را جهت فیلد انجکشن اسکن و وایراپ کند و متوجه شدیم که Dagger متدها رو بصورت خودکار تولید می کند.
۳- در کلاس استفاده کننده ( قرار است Inject اتفاق بیافتد) متد تعریف شده در Component را از کلاس AutoGenerated توسط Dagger صدا بزنیم و تمام!
اگر هنوز بخش مبهمی مانده با در نظر گرفتن سه مرحله بالا آموزش قبل را دوباره مطالعه کنید.
حال یک سوال:
با توجه به مطالب یاد شده می توانیم هر بخش از برنامه را بصورت DI توسط Dagger2 بنویسیم. مثلا یکسری کلاس هایی را بصورت Inject در کلاس های دیگر استفاده کنید. اما سوال من این است که اگر بخواهیم در کل پروژه از DI استفاده کنیم چه باید کرد؟ یعنی کلاس هایی که به همدیگر ربط پیدا می کنند. (مثلا Context که در خیلی جاها لازم داریم و یا SharedPrefrence و یا خیلی کلاس های دیگر) این سوالی بود که برای خودم هم پیش آمد و بهترین جواب برای آن طراحی از بالا به پایین کل پروژه است! یعنی به جای اینکه بیاییم از پایین به بالا برای تک تک کلاس های استفاده شده Module بنویسیم و سپس برسیم به سطح کامپوننت های اندروید مثل fragment و Activity که واقعاً نشدنی است و ارتباطات خیلی پیچیده می شود و از طرفی Inject های تکراری ایجاد می شد که Dagger2 آن را قبول نمی کند، بهتر است از سطح Application به پایین طراحی کنیم. این نکته را هم در نظر داشته باشید که Dagger2 در یک DI مجزا، امکان ساخت یک کامپوننت اصلی را می دهد ( به شکل بالا توجه کنید) و اگر کامپوننت های دیگری داشتیم باید در ارتباط با کامپوننت اصلی باشند. ( این ارتباط یا از نوع Dependency است یا SubComponent که در انتهای این بحث به تفاوت آنها اشاره خواهم کرد.) البته این مساله در صورتی است که Dependency Injection های مرتبط به هم داشته باشید. اما اگر فقط می خواهید در بخش های خاصی از برنامه از DI استفاده کنید که به هم مرتبط نیستند هر کدام Component و Module مستقل از هم را خواهند داشت که مشکلی هم پیش نمیاید. مثلا در مساله آموزش قبل که DI را برای تولید خودرو استفاده کردیم، فرض کنید یک DI هم برای قایق یا کشتی بنویسیم که بخواهیم تولید قایق را برایمان مدیریت کند. برای این کار دقیقاً مانند DI خودرو Module و Component مربوطه آن را تشکیل می دهیم و ربطی هم به DI خودرو ندارد و از هم مستقل اند. تنها نقطه مشترک کلاسی هست که استفاده کننده است. ( مانند Activity)
می خواهیم مثالی ساده نوشته و آن را باهم برسی کنیم. لطفاً به این بخش خیلی توجه کنید. به علت ارتباط بخش های مختلف ممکن است پیچیدگی ظاهری داشته باشد، اما واقعاً پیچیده نیست و تمامی قوانینی که در جلسه قبل گفتیم صادق است. تلاش من این است که تمامی حالت های ممکن برای ساخت DI را برسی کنیم تا تمامی سوالات برطرف شود.
شرح برنامه:
برنامه ای داریم که با استفاده از اطلاعات کاربری، درخواستی به وب زده و نتیجه را در پایگاه داده ذخیره می کند. توجه کنید که اتفاقات بصورت شماتیک است و هدف برسی روابط آنها در Dagger2 می باشد و صرفاً به ازای اکثر عملیات ها در کد، فقط لاگ کرده ایم. به شکل زیر دقت کنید: کلاس اپلیکیشن دارای کلاس های Context و User و Database (که وابسته به Context و User است) و Activity است و خود کلاس Activity هم شامل NetworkCalss است که وابسته به User است.
نکات برنامه:
کلاس Application به Database نیاز دارد تا آن را در اول برنامه Initilize کند از طرفی Database به User و Context نیاز دارد. سپس Activity یک Network Request می زند و نتیجه را در Database ذخیره می کند.اول از همه Module های مربوط به User و Database را ایجاد می کنیم تا Dagger بفهمد آنها را چگونه تولید کند.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
@Module public class UserModule { @Provides @Singleton User providesUser() { return new User("Farhad", "Majidi"); } } @Module public class DatabaseModule { @Singleton @Provides Database providesDatabase(Context context,User user){ return new Database(context,user); } } @Singleton @Component(modules = {ApplicationModule.class, DatabaseModule.class,UserModule.class}) public interface ApplicationComponent { void inject(DaggerTestApplication application); // Exported for child-components. (subcomponent need this to use Context or User or Database) Context getContext(); User provideUser(); Database provideDatabase(); } |
سوال: چه چیزی را می خواهیم تزریق کنیم؟ جواب: DataBase و User
سوال: چطور ساخته می شود؟ جواب: در UserModule و DatabaseModule مشخص شده است و آنها را به عنوان Module به Component داده ایم!
سوال: استفاده کننده نهایی کیست؟ جواب: DaggerTestApplication است بنابر این یک متد با ورودی خودش نوشتیم تا Inject@ های روی فیلدهایش اسکن شود.
سوال: دوسه تا متد بعدی چیه؟ جواب: باید برای هر کلاسی که child ها به آن نیاز دارند یک متد Exporter بنویسیم.
از آنجایی که می خواهم کلاس NetworkClass را فقط در Activity استفاده کنم و از طرفی NetworkClass به User نیاز دارد بنابراین یک کامپوننت جدا با Scope جدید می نویسیم. چون می خواهم مادامی که Activity وجود دارد NetworkClass نیز وجود داشته باشد. اما لازم است تا Component اصلی متدهایی داشته باشند تا کلاس User را برایم Export کنند. بنابر این من متدی اضافه کردم به نام provideUser که خروجی آن User است. خود Dagger پیداده سازی آن را مدیریت می کند. همچنین چون ممکن است Context برنامه را کلاس های دیگر بخواهند یک متد نیز برای آن نوشتیم و همچنین برای Database هم یک متد Export کننده نوشتم.( خواهید دید که DataBase در Activity جهت ذخیره مورد نیاز قرار خواهد گرفت. پس یک متد Export کننده لازم داشت.) این طراحی بالا به پایینی بود که اول مقاله گفتم. یعنی در Component اصلی که نحوه ارتباط ها را مشخص می کنیم برای فرزند ها نیز وابستگی های مشترک را در نظر بگیریم.
یک نکته دیگر در مورد context است. از آنجایی که کلاس های دیگری ممکن است به آن وابسته شوند یک متد برای آن نوشتیم، اما چون Context را ما نمی سازیم و خود سیستم تولید می کند لازم نیست برایش Module بنویسیم و ساخت و Handle آن توسط خود Dagger با Android system انجام می شود. البته در این پروژه استفاده ای از آن نکردیم، اما مطمئناً به آن نیاز پیدا خواهید کرد.
حال می رویم سراغ وابستگی های Activity و این بخش است که کمی برایمان تازگی دارد.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
@Scope @Retention(RetentionPolicy.RUNTIME) public @interface ActivityScope { } @Module public class ServiceModule { @ActivityScope @Provides NetworkClass providesNetworkClass(User user) { return new NetworkClass(user); } } @ActivityScope @Component(dependencies = ApplicationComponent.class, modules = ServiceModule.class) public interface ActivityComponent { void inject(MainActivity activity); } |
سوال: چه چیزی را می خواهیم تزریق کنیم؟ جواب: NetworkClass
سوال: چطور ساخته می شود؟ جواب: در ServiceModule مشخص شده است و آن را به عنوان Module به Component داده ایم!
سوال: اما نحوه ساخت یوزر را در ServiceModule نداریم؟! جواب: در ActivityComponent مشخص کردیم که
dependencies = ApplicationComponent.class ( یعنی وابستگی به ApplicationComponent داریم و هر کلاسی که در آن Export شده است را می توانیم استفاده کنیم. پس ServiceModule در ساخت NetworkClass یک User به عنوان ورودی می گیرد، و نحوه ساخت آن یوزر را ApplicationComponent می داند.
سوال: چرا Scope جدید دادیم؟ جواب: برای اینکه می خواهیم مادامی که استفاده کننده آن (Activity ) وجود دارد، NetworkClass ما وجود داشته باشد. نحوه دقیق کار Scope در این آموزش موجود است.
سوال: این NetworkClass کجا استفاده می شود و Dagger از کجا می فهمد؟ جواب: این جواب رو دیگه شما هم می دانید و همانطور که در کلاس Activity ملاحظه می کنید چون درون دوتا فیلد اینجکشن داریم ( یکی NetworkClass و دیگری DataBase) بنابر این یک متدی در Component قرار دادم تا ورودی آن از جنس MainActivity باشد تا تمامی Field injection های آن اسکن شود و ارتباط ها برقرار شود.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
public class MainActivity extends AppCompatActivity { @Inject NetworkClass networkClass; @Inject Database database; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); initialize(); webRequest(); } private void webRequest() { networkClass.request("https://google.com"); database.saveToDB(); } private void initialize() { ((DaggerTestApplication)getApplicationContext()).getActivityComponent().inject(this); } } |
ملاحظه خواهید کرد که هم NetworkClass و هم DataBase به درستی در Activity تزریق شده اند و قابل استفاده هستند. حالا که نحوه کار با Dagger2 را متوجه شدیم می توانیم برای متوجه شدن بیشتر این کد را به چند صورت متفاوت نوشت و تغییر داد. که همه اینها در Github در شاخه های با نام های:lesson2, lesson2-type2, lesson2-type3, lesson2-subcomponent قرار گرفته اند.
روش های دیگر برای درک کامل
برای اینکه دقیقاً بفهمید Dagger2 چطور کار می کند حتماً این مثال ها را ببینید و درک کنید. در این چند مثال انواع روش های پیاده سازی را انجام داده ام و فهمیدن انها باعث از بین رفتن گنگی نسبی قضیه و تسلط کامل خواهد شد و جواب بسیاری از سوال هایی که در ذهن دارید را خواهید یافت. تلاشم تغییر روی یک کلاس واحد Database بود تا با ثابت بودن آن تغییر روش ها را ملاحظه نمایید.
شاخه lesson2 : همین کدی است که در این آموزش داشتیم.
شاخه lesson2-type2 :در کلاس Database خود User تزریق شده است. بنابراین ناچاریم تا متدی بنویسیم که ورودی آن Database باشد تا فیلد های تزریق شده اسکن شود.
شاخه lesson2-type3: در کلاس Database از Constructor Injection استفاده کردم. همانطور که در تعریف اول بحث مطرح کردم در این روش Inject@ در روی Constructor کلاس می گذاریم و دیگر نیازی به نوشتن Module برای نحوه پیاده سازی آن نداریم و کلا DatabaseModule حذف می شود. البته ActivityComponent تغییری نمی کند.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
public class Database { private static final String TAG = "mahditajik.ir"; @Inject User user; private Context context; @Inject public Database(Context context) { this.context = context; } public void initialize() { Log.i(TAG, "initialize with context: " + context.toString()); } public void saveToDB() { Log.i(TAG, "saveToDB: " + user.toString()); } } @Singleton @Component(modules = {ApplicationModule.class,UserModule.class}) public interface ApplicationComponent { void inject(DaggerTestApplication application); // Exported for child-components. Context getContext(); User provideUser(); //because it had Constructor injected and do not need for Module or exporter // Database provideDatabase(); } |
Subcomponent vs Dependency
همانطور که در مثال ملاحظه کردید برای ارتباط ActivityComponent با ApplicationComponent از Dependencies استفاده کردیم
|
1 |
@Component(dependencies = ApplicationComponent.class, modules = ServiceModule.class) |
و سپس هر Object که لازم بود را در ApplicationComponent برایش یک متد exporter نوشتیم. اما راه دیگر استفاده به عنوان Subcomponent است. در این روش انترفیس subcomponent به همه Object های Component دسترسی دارد و نیازی به نوشتن متد های exporter ندارد و کارایی آن هنگامی است که واقعاً به تمامی object ها نیاز داریم. برای شناساندن Subcomponent به Component اصلی فقط کافیست که یک متد Factory برایش در Component بنویسیم.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
@MahdiScope @Subcomponent(modules = ServiceModule.class) public interface ActivityComponent { void inject(MainActivity activity); } @Singleton @Component(modules = {ApplicationModule.class, DatabaseModule.class, UserModule.class}) public interface ApplicationComponent { void inject(DaggerTestApplication application); // Exported for child-components. // Context getContext(); // // User provideUser(); // // Database proDatabase(); //sub component ActivityComponent providesActivityComponent(ServiceModule service); } |
و برای استفاده wire-up کردن هم متد ماژول ان را از کامپوننت اصلی بگیریم. ( خط ۲۷)
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
public class MainActivity extends AppCompatActivity { @Inject NetworkClass networkClass; @Inject Database database; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); initialize(); webRequest(); } private void webRequest() { networkClass.request("https://google.com"); database.saveToDB(); } private void initialize() { ((DaggerTestApplication) getApplicationContext()).getAppComponent() .providesActivityComponent(new ServiceModule()).inject(this); } } |
امیدوارم تونسته باشم مطلب رو خوب بیان کنم. در صورت وجود هر گونه مشکل یا سوال یا بحث، که واقعاً این مبحث نیاز به بحث داره، راحت باشید و کامنت بگذارید.
بعد از گرفتن پروژه یکبار اون رو import کنید تا قابل اجرا بشه.
منبع: بایت کد
باسلام.
توضیحاتتون عالیه.
فقط کاشکی نشخه pdf این آموزشتتون رو هم میزاشتید.
سلام خسته نباشید
کلاس DaggerTestApplication رو اصلا توضیح ندادید چزا؟
سلام اگه لطف کنید در مورد متد های expotrer بیشتر توضیح بدین .(نفهمیدم چطوری استفاده میشه )
همینطور در مورد نحوه استفاده از انوتیشن ساخته شده توسط scope مثل scopeActivity متاسفانه مقاله های مربوط رو خوندم ولی نفهمیدم کامل
سلام. ببینید همانطور که در مثال دیدید وقتی یک کامپوننت به یک کامپوننت دیگری نیاز داره (یعنی آبجکت هایی که اون می سازه رو لازم داره) دیدید که در از dependencies = { x, y ,z} استفاده کردیم. حال در کامپوننت مثلا x برای اینکه آبجکت تولید شده اش در معرض دسترسی قرار بگیرد فقط لازمه که یک متد با هر نامی بنویسیم که خروجی آن از جنس آبجک مورد نظر باشه. خیلی خوب حالا بر می گردیم به مثال خودمان و کل قضیه را در سه قدم بهتان خواهم گفت: در مثال ما برای ساخت NetWorkClass که در ServiceModule قرار دارد به User نیاز داشتیم و بجای ساخت مجدد User از User ساخته شده در ApplicationComponent (توسط UserModule ) استفاده کردیم. برای این منظور ۳ کار انجام دادیم. اول یک ورودی User به متد سازنده NetworkClass دادیم، اینکه User از کجا می آید در قدم دوم است ک که به dagger گفتیم که ActivityComponent وابستگی دارد به ApplicationComponent ( که در ماژول ApplicationComponent نحوه ساخت User را مشخص کرده ایم). یعنی هر آبجکتی در ApplicationComponent ساخته می شود به شرطی که یک متد exposer برایش نوشته باشیم در دسترس ActivityComponent نیز قرار خواهد گرفت. پس برای قدم سوم هم متد User provideUser(); را در ApplicationComponent نوشتیم. شما می توانستید هر نام دیگری برای متدتان داشته باشید، فقط نکته این بود که خروجی آن User باشد. امیدوارم با برسی مجدد قسمت های کد با این توضیحات قضیه برایتان حل شود. در مورد scope هم اگر سواالتان را دقیق تر در بخش خودش بگذارید انشاء الله بزودی جوابتان را خواهم نوشت. موفق باشید.
ممکنه راهنماییم کنید چطور میتونم از متدهای یک ماژول بعنوان ورودی متدهای دیگه در یک ماژول دیگه استفاده کنم؟
به ماژول سرویس توجه کنید که برای ساخت NetworkClass نیاز به User دارد و ما فقط ورودی User را نوشتیم و ساخت خود User در ماژول UserModule قرار دارد. پس خروجی یک ماژول (User) در یک ماژول دیگر به عنوان وردی استفاده شد! ( در ServiceModule).
سلام. سوال من اینه که هر سه روش کار با dagger اصولی هستن؟
آیا امکانش هست بگید بعنوان کسی که تازه میخواد ازش استفاده کنه از کدوم روش استفاده کنه بهتره؟
سلام. بله همه راه های گفته شده اصولی هست و در شرایط خاص مجبور به استفاده از یکی از روش ها می شوید. مثلا موقعی که وابستگی دوگانه وجود دارد. A->B و B->A که هروقت برسید خودتان متوجه می شوید. پس بدون ترس بروید سراغش. البته از dagger 1.10 به بعد روش wire-up کمی تغییر کرده که انشاء الله در فرصتی می نویسم. برای شروع همان روش اول پیش بروید.
خسته نباشید.
توضیحات و آموزش هاتون عالی بود.
منتهی، نتیجه ای که من از همه ی آموزش هایی که در وب خوندم که بهترینشون هم مال شما بود گرفتم اینه که، اصولا نباید از Dagger2 استفاده کرد. چون بی جهت برنامه رو پیچیده میکنه و ارزشش رو نداره…
سلام. خیلی لطف دارید. اما نتیجه گیریتون خیلی صحیح نیست اتفاقاً توسعه و اضافه کردن امکانات به برنامه خیلی خیلی راحت میشه. من مقدمه آموزش اول ( قسمت اول Dagger) را برای شما تکمیل کردم. پس لطفاً بخونیدش. اگر بازهم قانع نشدید کتاب مارک سیمن رو که لینکش و گذاشتم مطالعه کنید ( تا حدود صفحه ۷۰). Dagger ابزار بسیار پرکاربرد و مهمیه که در همه مصاحبه های شرکت، جزو سوالاتمون هست و تسلط به اون واقعاً یک نکته خیلی خوب در دولوپرها هست. فقط کافیه بهش عادت کنید و هرچه زود تر هم عادت کنید بهتر ;). موفق باشید
بسیار عالی
ممنون
متشکرم از آموزش جالبتون. سخته
خواهش می کنم. بازهم سوالی داشتید کامنت بگذارید.