در فصل ۲۸ و در چند مطلب به بحث معماری در برنامه‌های اندروید پرداختیم:

مقدمه معماری MVP در برنامه‌های اندروید

معماری MVP در برنامه‌های اندروید

تست برنامه‌های MVP

در ادامه این مطالب با برنامه todo گوگل آشنا شدیم:

برنامه نمونه todo از گوگل برای آشنایی با MVP

در ادامه این مطالب به موضوع تزریق وابستگی یا dependency injection پرداختیم:

تزریق وابستگی با Dagger2

در این مطلب می‌خواهیم ببینیم چطور باید تزریق وابستگی را به پروژه todo اضافه کنیم. بنابراین اگر مطالب قبلی را مطالعه نکردید یا احتمالا به علت فاصله طولانی بین و وقفه‌ای که بین این مطالب افتاده، آن‌ها را فراموش کرده‌اید، توصیه می‌کنم یک بار دیگر آن‌ها را مرور کنید.

مروری بر برنامه

برنامه todo mvp + Dagger2 را از گیت‌هاب دانلود کنید یا آن را با گیت کلون کنید. اگر نگاهی به ساختار برنامه بیاندازید مشابهت بسیار زیادی با برنامه todo-mvp دارد. تنها تفاوت اصلی برنامه، تزریق وابستگی‌ها توسط Dagger2 است.

اولین تغییر این برنامه تنظیمات گریدل پروژه و ماژول اپ است. ابتدا باید در بخش وابستگی‌های گریدل پروژه وابستگی به کتابخانه android-apt را اضافه کنیم:

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:2.3.1'
        classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
    }
}

بعد در بیلد گریدل مربوط به ماژول اپ باید دو تغییر بدهیم:

اضافه کردن android-apt و اضافه کردن Dagger:

apply plugin: 'com.android.application'

android {
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion
//...
}

و

dependencies {
    // Dagger dependencies
    apt "com.google.dagger:dagger-compiler:$rootProject.daggerVersion"
    provided 'org.glassfish:javax.annotation:10.0-b28'
    compile "com.google.dagger:dagger:$rootProject.daggerVersion"
    // ...
}

حالا که همه پیش‌نیازهای Dagger به پروژه اضافه شده است باید برنامه را جوری تغییر بدهیم تا بتوانیم اجزای برنامه (مدل، نمایشگر و معرف) را به برنامه تزریق کنیم. قبل از آن باید ببینیم قبل از اضافه کردن Dagger به پروژه کارها چطور انجام می‌شد. تا الان برای ساختن مدل، نمایشگر و معرف در اکتیویتی به شکل زیر اقدام می‌شود:

نمایشگر:

TasksFragment tasksFragment =
		(TasksFragment) getSupportFragmentManager().findFragmentById(R.id.contentFrame);
if (tasksFragment == null) {
	// Create the fragment
	tasksFragment = TasksFragment.newInstance();
	ActivityUtils.addFragmentToActivity(
			getSupportFragmentManager(), tasksFragment, R.id.contentFrame);
}

مدل:

TasksRepository taskRepository = Injection.provideTasksRepository(getApplicationContext());

البته کمی کد را تغییر دادم تا خوانایی آن بالاتر برود.

معرف:

mTasksPresenter = new TasksPresenter(taskRepository, tasksFragment);

همانطور که می‌بینید همه این اشیا را در اکتیویتی می‌سازیم که می‌دانیم روش درستی نیست و نباید اجزای اصلی برنامه به اکتیویتی و چرخه زندگی آن وابستگی داشته باشند. پس چه کار باید کرد؟ چاره استفاده از تزریق وابستگی است و Dagger2 در حال حاضر بهترین راه‌حل برای پیاده‌سازی تزریق وابستگی است.

افزودن تزریق وابستگی به پروژه

همانطور که پیش از این و در مطلب «تزریق وابستگی با Dagger2» گفتیم، اجزای اصلی Dagger کامپوننت و ماژول هستند. برای شروع کار یک کلاس به اسم ToDoApplication به ریشه پروژه اضافه می‌کنیم و در مانیفست برنامه آن را به عنوان کلاس Application برنامه معرفی می‌کنیم:

<application
    // ...
    android:name="com.example.android.architecture.blueprints.todoapp.ToDoApplication">

حالا یک ماژول Dagger به نام ApplicationModule به برنامه اضافه می‌کنیم. کار اصلی این ماژول تزریق وابستگی به Context در هر جایی است که به این شی نیاز دارد:

@Module
public final class ApplicationModule {

    private final Context mContext;

    ApplicationModule(Context context) {
        mContext = context;
    }

    @Provides
    Context provideContext() {
        return mContext;
    }
}

اگر می‌دانید که این کلاس چه کاری می‌کند اعلام می‌کنم که Dagger را خوب یاد گرفته‌اید! این کلاس یک شی از نوع Context را اصطلاحا provide یا عرضه می‌کند. بنابراین در جاهایی که به Context نیاز داریم می‌توانیم از این ماژول استفاده کنیم. این شی Context از کجا می‌آید؟ بله درست حدس زدید از کلاس ToDoApplication:

public class ToDoApplication extends Application {

    private TasksRepositoryComponent mRepositoryComponent;

    @Override
    public void onCreate() {
        super.onCreate();

        mRepositoryComponent = DaggerTasksRepositoryComponent.builder()
                .applicationModule(new ApplicationModule((getApplicationContext())))
                .build();

    }

    public TasksRepositoryComponent getTasksRepositoryComponent() {
        return mRepositoryComponent;
    }

}

همانطور که می‌بینید در این کلاس با کمک Dagger یک نمونه از کامپوننت TasksRepositoryComponent ساخته می‌شود و یک نمونه از ApplicationModule به آن فرستاده می‌شود.

ساختار این کامپوننت به شکل زیر است:

@Singleton
@Component(modules = {TasksRepositoryModule.class, ApplicationModule.class})
public interface TasksRepositoryComponent {

    TasksRepository getTasksRepository();
}

حالا به ساختار پروژه یک نگاهی بیاندازیم:

همانطور که می‌بینید در هر شاخه که مربوط به یک اکتیویتی برنامه است، دو کلاس Component و Module اضافه شده است. این کلاس‌ها مربوط به Dagger هستند.

ما کلاس‌های TasksPresenterModule و TasksComponent را برای بررسی بیشتر باز می‌کنیم:

@Module
public class TasksPresenterModule {

    private final TasksContract.View mView;

    public TasksPresenterModule(TasksContract.View view) {
        mView = view;
    }

    @Provides
    TasksContract.View provideTasksContractView() {
        return mView;
    }

}

کار اصلی این ماژول تزریق نمایشگر یا View مرتبط با این صفحه است. تنها «ویژگی» این کلاس از نوع TasksContract.View است. یک متد سازنده دارد که این ویژگی را مقداردهی می‌کند و یک متد که با حاشیه‌نوشت @Provide مشخص شده است، این نمایشگر را تزریق می‌کند، به همین سادگی!

حالا نگاهی می‌اندازیم به کلاس TasksComponent:

@FragmentScoped
@Component(dependencies = TasksRepositoryComponent.class, modules = TasksPresenterModule.class)
public interface TasksComponent {

    void inject(TasksActivity activity);
}

فعلا به حاشیه‌نوشت @FragmentScoped کاری نداریم. کامپوننت‌های Dagger حتما باید با حاشیه‌نوشت @Component معرفی شوند. همانطور که می‌بینید این کامپوننت یک وابستگی دارد به کامپوننت TasksRepositoryComponent که کارش تزریق مدل است و یک وابستگی دارد به ماژول TasksPresenterModule که کارش تزریق نمایشگر است. همه این‌ها قرار است در اکتیویتی TasksActivity تزریق شوند. حالا سری می‌زنیم به TasksActivity تا ببینیم پایان قصه تزریق وابستگی به کجا می‌رسد:

import javax.inject.Inject;

public class TasksActivity extends AppCompatActivity {

    @Inject TasksPresenter mTasksPresenter;
	// ...

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.tasks_act);

        // Create the presenter
        DaggerTasksComponent.builder()
                .tasksRepositoryComponent(((ToDoApplication) getApplication()).getTasksRepositoryComponent())
                .tasksPresenterModule(new TasksPresenterModule(tasksFragment)).build()
                .inject(this);

				// ...
    }

	// ...
}

مهم‌ترین نکته این کلاس تعریف mTasksPresenter با حاشیه‌نوشت @Inject است. ما دیگر نیازی نیست از روی کلاس معرف یک شی بسازیم و این کار را بر عهده Dagger گذاشته‌ایم تا برای ما این شی را بسازد و به اکتیویتی تزریق کند. برای این کار باید کامپوننت را آماده کنیم و این دومین بخش مهم و متفاوت این کلاس است:

@Override
protected void onCreate(Bundle savedInstanceState) {
    // ...
    // Create the presenter
    ToDoApplication application = (ToDoApplication) getApplication();
    DaggerTasksComponent
        .builder()
        .tasksRepositoryComponent(application.getTasksRepositoryComponent())
        .tasksPresenterModule(new TasksPresenterModule(tasksFragment))
        .build()
        .inject(this);
        // ...
    }
    // ...
}

در این جا از Dagger می‌خواهیم که TasksComponent را به همراه تمام وابستگی‌هایش به اکتیویتی تزریق کند. اولین وابستگی این کامپوننت به یک کامپوننت دیگر به نام TasksRepositoryComponent است. این کامپوننت نمونه‌ای از TaskRepository را تزریق می‌کند. وابستگی دوم به ماژول TasksPresenterModule است که نمایشگر را تزریق می‌کند. پس حالا هم معرف و هم نمایشگر و هم مدل را به کمک Dagger به اکتیویتی تزریق کرده‌ایم بدون این که در اکتیویتی از روی آن‌ها نمونه یا شی‌ای ساخته باشیم و این کار Dagger است.

حالا یک بار با هم سناریو را از اول بررسی می‌کنیم:

۱- طبق معماری MVP باید یک شی مدل (M) داشته باشیم. مدل در اینجا TasksRepository است. بنابراین یک کلاس ساختیم به نام TasksRepositoryComponent. این کامپوننت باید بتواند دو شی متفاوت برای دسترسی به دیتای محلی و نیز دسترسی به دیتای اینترنتی یا remote را برای ما فراهم کند. بنابراین یک کلاس ماژول هم می‌سازیم که این دو نمونه را به ما عرضه (provide) کند:

@Module
abstract class TasksRepositoryModule {

    @Singleton
    @Binds
    @Local
    abstract TasksDataSource provideTasksLocalDataSource(TasksLocalDataSource dataSource);

    @Singleton
    @Binds
    @Remote
    abstract TasksDataSource provideTasksRemoteDataSource(FakeTasksRemoteDataSource dataSource);
}

۲- طبق معماری MVP باید کلاسی داشته باشیم که نقش نمایشگر (M) را بازی کند. بنابراین به ازای هر صفحه برنامه (فرگمنت یا اکتیویتی) یک کلاس ماژول و یک کامپوننت می‌سازیم. کلاس ماژول، نمایشگر را به ما عرضه می‌کند:

@Module
public class TasksPresenterModule {

    private final TasksContract.View mView;

    public TasksPresenterModule(TasksContract.View view) {
        mView = view;
    }

    @Provides
    TasksContract.View provideTasksContractView() {
        return mView;
    }

}

۳- طبق معماری MVP باید کلاسی داشته باشیم که نقش معرف (P) را بازی کند. این کلاس به TasksRepository و پیاده‌سازی‌های Local و Remote آن (همان کلاس‌های مدل) و نیز نمایشگر نیاز دارد. TasksComponent این‌ها را به کلاس TasksActivity تزریق می‌کند:

@FragmentScoped
@Component(dependencies = TasksRepositoryComponent.class, modules = TasksPresenterModule.class)
public interface TasksComponent {

    void inject(TasksActivity activity);
}

۴- در TasksActivity از Dagger می‌خواهیم که این وابستگی‌ها را به اکتیویتی تزریق کند:

@Override
protected void onCreate(Bundle savedInstanceState) {
    // ...
    // Create the presenter
    ToDoApplication application = (ToDoApplication) getApplication();
    DaggerTasksComponent
        .builder()
        .tasksRepositoryComponent(application.getTasksRepositoryComponent())
        .tasksPresenterModule(new TasksPresenterModule(tasksFragment))
        .build()
        .inject(this);
        // ...
    }
    // ...
}

و این کار را در تمام قسمت‌های برنامه تکرار می‌کنیم!