إدخال الاعتمادية اليدوية

تشجع بنية التطبيق الموصى بها من Android بتقسيم الرمز البرمجي إلى فئات للاستفادة من فصل الاهتمامات، وهو مبدأ يكون فيه كل فئة من فئات التسلسل الهرمي مسؤولية واحدة محدّدة. يؤدي هذا إلى المزيد من الفئات الأصغر التي تحتاج إلى ربطها معًا لتلبية تبعيات بعضها البعض.

يمكن تمثيل التبعيات بين الفئات كرسم بياني، ترتبط فيه كل فئة بالفئات التي تعتمد عليها. يُشكّل الرسم البياني للتطبيق تمثيل جميع الصفوف وتبعياتها. في الشكل 1، يمكنك مشاهدة تجريد الرسم البياني للتطبيق. عندما تعتمد الفئة أ (ViewModel) على الفئة ب (Repository)، يكون هناك خط يشير من أ إلى ب يمثل تلك التبعية.

يساعد حقن التبعية في إجراء هذه الروابط ويتيح لك تبديل عمليات التنفيذ للاختبار. على سبيل المثال، عند اختبار ViewModel يعتمد على المستودع، يمكنك وضع عمليات تنفيذ مختلفة لـ Repository باستخدام مواد مزيفة أو نماذج تجريبية لاختبار الحالات المختلفة.

أساسيات إدخال التبعية يدويًا

يتناول هذا القسم كيفية تطبيق إضافة التبعية اليدوية في سيناريو تطبيق Android حقيقي. حيث يتضمن نهجًا تكراريًا لكيفية البدء في استخدام حقن التبعية في تطبيقك. يتحسن هذا الأسلوب حتى يصل إلى نقطة تشبه إلى حد كبير ما سينشئه Dagger تلقائيًا لك. لمزيد من المعلومات حول Dagger، يُرجى الاطّلاع على أساسيات Dagger.

ضع في اعتبارك التدفق ليكون مجموعة من الشاشات في تطبيقك تتوافق مع إحدى الميزات. تسجيل الدخول والتسجيل والدفع كلها أمثلة على التدفقات.

عند تغطية عملية تسجيل الدخول لتطبيق Android عادي، يعتمد LoginActivity على LoginViewModel، والتي تعتمد بدورها على UserRepository. وتعتمد السمة UserRepository بعد ذلك على خدمة UserLocalDataSource وUserRemoteDataSource، وهذا بدوره يعتمد على خدمة Retrofit.

LoginActivity هو نقطة الدخول إلى مسار تسجيل الدخول ويتفاعل المستخدم مع النشاط. بالتالي، على "LoginActivity" إنشاء LoginViewModel بجميع العناصر التابعة له.

تبدو فئتا Repository وDataSource في التدفق على النحو التالي:

class UserRepository(
    private val localDataSource: UserLocalDataSource,
    private val remoteDataSource: UserRemoteDataSource
) { ... }

class UserLocalDataSource { ... }
class UserRemoteDataSource(
    private val loginService: LoginRetrofitService
) { ... }

class UserLocalDataSource {
    public UserLocalDataSource() { }
    ...
}

class UserRemoteDataSource {

    private final Retrofit retrofit;

    public UserRemoteDataSource(Retrofit retrofit) {
        this.retrofit = retrofit;
    }

    ...
}

class UserRepository {

    private final UserLocalDataSource userLocalDataSource;
    private final UserRemoteDataSource userRemoteDataSource;

    public UserRepository(UserLocalDataSource userLocalDataSource, UserRemoteDataSource userRemoteDataSource) {
        this.userLocalDataSource = userLocalDataSource;
        this.userRemoteDataSource = userRemoteDataSource;
    }

    ...
}

إليك المظهر الذي يبدو عليه LoginActivity:

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // In order to satisfy the dependencies of LoginViewModel, you have to also
        // satisfy the dependencies of all of its dependencies recursively.
        // First, create retrofit which is the dependency of UserRemoteDataSource
        val retrofit = Retrofit.Builder()
            .baseUrl("https://example.com")
            .build()
            .create(LoginService::class.java)

        // Then, satisfy the dependencies of UserRepository
        val remoteDataSource = UserRemoteDataSource(retrofit)
        val localDataSource = UserLocalDataSource()

        // Now you can create an instance of UserRepository that LoginViewModel needs
        val userRepository = UserRepository(localDataSource, remoteDataSource)

        // Lastly, create an instance of LoginViewModel with userRepository
        loginViewModel = LoginViewModel(userRepository)
    }
}

public class MainActivity extends Activity {

    private LoginViewModel loginViewModel;

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

        // In order to satisfy the dependencies of LoginViewModel, you have to also
        // satisfy the dependencies of all of its dependencies recursively.
        // First, create retrofit which is the dependency of UserRemoteDataSource
        Retrofit retrofit = new Retrofit.Builder()
                .baseUrl("https://example.com")
                .build()
                .create(LoginService.class);

        // Then, satisfy the dependencies of UserRepository
        UserRemoteDataSource remoteDataSource = new UserRemoteDataSource(retrofit);
        UserLocalDataSource localDataSource = new UserLocalDataSource();

        // Now you can create an instance of UserRepository that LoginViewModel needs
        UserRepository userRepository = new UserRepository(localDataSource, remoteDataSource);

        // Lastly, create an instance of LoginViewModel with userRepository
        loginViewModel = new LoginViewModel(userRepository);
    }
}

ثمة مشاكل في هذا المنهج:

1. هناك الكثير من الرموز النموذجية. إذا أردت إنشاء مثيل آخر من الترميز LoginViewModel في جزء آخر من الرمز، سيكون لديك تكرار.

2. يجب الإعلان عن التبعيات بالترتيب. يجب إنشاء مثيل UserRepository قبل LoginViewModel لإنشائه.

3. من الصعب إعادة استخدام الكائنات. إذا أردت إعادة استخدام UserRepository على مستوى ميزات متعددة، عليك جعله يتّبع نمط سينغلتون. نمط سينغلتون يجعل الاختبار أكثر صعوبة لأن جميع الاختبارات تشترك في نفس مثيل سينغلتون.

إدارة التبعيات باستخدام حاوية

لحلّ مشكلة إعادة استخدام العناصر، يمكنك إنشاء فئة حاوية التبعيات الخاصة بك والتي تستخدمها للحصول على التبعيات. يمكن أن تكون جميع الحالات التي تقدّمها هذه الحاوية علنية. في هذا المثال، بما أنّك تحتاج فقط إلى مثيل من UserRepository، يمكنك جعل تبعياته خاصة من خلال خيار جعلها علنية في المستقبل إذا لزم الأمر:

// Container of objects shared across the whole app
class AppContainer {

    // Since you want to expose userRepository out of the container, you need to satisfy
    // its dependencies as you did before
    private val retrofit = Retrofit.Builder()
                            .baseUrl("https://example.com")
                            .build()
                            .create(LoginService::class.java)

    private val remoteDataSource = UserRemoteDataSource(retrofit)
    private val localDataSource = UserLocalDataSource()

    // userRepository is not private; it'll be exposed
    val userRepository = UserRepository(localDataSource, remoteDataSource)
}

// Container of objects shared across the whole app
public class AppContainer {

    // Since you want to expose userRepository out of the container, you need to satisfy
    // its dependencies as you did before
    private Retrofit retrofit = new Retrofit.Builder()
            .baseUrl("https://example.com")
            .build()
            .create(LoginService.class);

    private UserRemoteDataSource remoteDataSource = new UserRemoteDataSource(retrofit);
    private UserLocalDataSource localDataSource = new UserLocalDataSource();

    // userRepository is not private; it'll be exposed
    public UserRepository userRepository = new UserRepository(localDataSource, remoteDataSource);
}

بما أنّ هذه التبعيات تُستخدَم في التطبيق بأكمله، يجب وضعها في مكان مشترك يمكن أن تستخدمه جميع الأنشطة، وهو الفئة Application. أنشئ فئة Application مخصّصة تحتوي على مثيل AppContainer.

// Custom Application class that needs to be specified
// in the AndroidManifest.xml file
class MyApplication : Application() {

    // Instance of AppContainer that will be used by all the Activities of the app
    val appContainer = AppContainer()
}

// Custom Application class that needs to be specified
// in the AndroidManifest.xml file
public class MyApplication extends Application {

    // Instance of AppContainer that will be used by all the Activities of the app
    public AppContainer appContainer = new AppContainer();
}

يمكنك الآن الحصول على مثيل AppContainer من التطبيق والحصول على مشاركة مثيل UserRepository:

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Gets userRepository from the instance of AppContainer in Application
        val appContainer = (application as MyApplication).appContainer
        loginViewModel = LoginViewModel(appContainer.userRepository)
    }
}

public class MainActivity extends Activity {

    private LoginViewModel loginViewModel;

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

        // Gets userRepository from the instance of AppContainer in Application
        AppContainer appContainer = ((MyApplication) getApplication()).appContainer;
        loginViewModel = new LoginViewModel(appContainer.userRepository);
    }
}

بهذه الطريقة، لن يكون لديك UserRepository فردي. بدلاً من ذلك، تتم مشاركة AppContainer في كل الأنشطة التي تحتوي على عناصر من الرسم البياني وإنشاء مثيلات لتلك العناصر التي يمكن أن تستهلكها فئات أخرى.

إذا احتاجت علامة LoginViewModel في مزيد من مواضع التطبيق، من المنطقي أن يكون لديك مكان مركزي لإنشاء مثيلات لـ LoginViewModel. يمكنك نقل عملية إنشاء LoginViewModel إلى الحاوية وتوفير عناصر جديدة من هذا النوع إلى المصنع. يبدو رمز LoginViewModelFactory على النحو التالي:

// Definition of a Factory interface with a function to create objects of a type
interface Factory<T> {
    fun create(): T
}

// Factory for LoginViewModel.
// Since LoginViewModel depends on UserRepository, in order to create instances of
// LoginViewModel, you need an instance of UserRepository that you pass as a parameter.
class LoginViewModelFactory(private val userRepository: UserRepository) : Factory {
    override fun create(): LoginViewModel {
        return LoginViewModel(userRepository)
    }
}

// Definition of a Factory interface with a function to create objects of a type
public interface Factory<T> {
    T create();
}

// Factory for LoginViewModel.
// Since LoginViewModel depends on UserRepository, in order to create instances of
// LoginViewModel, you need an instance of UserRepository that you pass as a parameter.
class LoginViewModelFactory implements Factory {

    private final UserRepository userRepository;

    public LoginViewModelFactory(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public LoginViewModel create() {
        return new LoginViewModel(userRepository);
    }
}

يمكنك تضمين LoginViewModelFactory في AppContainer وجعل LoginActivity يستهلكها:

// AppContainer can now provide instances of LoginViewModel with LoginViewModelFactory
class AppContainer {
    ...
    val userRepository = UserRepository(localDataSource, remoteDataSource)

    val loginViewModelFactory = LoginViewModelFactory(userRepository)
}

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Gets LoginViewModelFactory from the application instance of AppContainer
        // to create a new LoginViewModel instance
        val appContainer = (application as MyApplication).appContainer
        loginViewModel = appContainer.loginViewModelFactory.create()
    }
}

// AppContainer can now provide instances of LoginViewModel with LoginViewModelFactory
public class AppContainer {
    ...

    public UserRepository userRepository = new UserRepository(localDataSource, remoteDataSource);

    public LoginViewModelFactory loginViewModelFactory = new LoginViewModelFactory(userRepository);
}

public class MainActivity extends Activity {

    private LoginViewModel loginViewModel;

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

        // Gets LoginViewModelFactory from the application instance of AppContainer
        // to create a new LoginViewModel instance
        AppContainer appContainer = ((MyApplication) getApplication()).appContainer;
        loginViewModel = appContainer.loginViewModelFactory.create();
    }
}

هذا النهج أفضل من السابق، ولكن لا تزال هناك بعض التحديات التي يجب وضعها في الاعتبار:

1. عليك إدارة AppContainer بنفسك من خلال إنشاء مثيلات لكل التبعيات يدويًا.

2. لا يزال هناك الكثير من الرموز النموذجية. تحتاج إلى إنشاء مصانع أو معلمات يدويًا حسب ما إذا كنت تريد إعادة استخدام كائن أم لا.

إدارة التبعيات في تدفقات التطبيقات

يصبح AppContainer معقدًا عندما تريد تضمين المزيد من الوظائف في المشروع. عندما يصبح تطبيقك أكبر حجمًا وتبدأ في تقديم تدفقات مختلفة للميزات، هناك المزيد من المشكلات التي تنشأ:

1. عندما يكون لديك تدفقات مختلفة، فقد ترغب في أن تعيش الكائنات في نطاق ذلك التدفق. على سبيل المثال، عند إنشاء LoginUserData (الذي قد يتكوّن من اسم المستخدم وكلمة المرور المستخدَمين فقط في عملية تسجيل الدخول)، لا تريد الاحتفاظ بالبيانات من تدفق تسجيل الدخول القديم من مستخدم آخر. تريد مثيلاً جديدًا لكل تدفق جديد. يمكنك تحقيق ذلك من خلال إنشاء كائنات FlowContainer داخل AppContainer كما هو موضّح في مثال الرمز التالي.

2. وقد يكون من الصعب أيضًا تحسين الرسم البياني للتطبيق وحاويات التدفق. تحتاج إلى تذكر حذف الحالات التي لا تحتاجها، بناءً على التدفق الذي تتواجد فيه.

تخيل أنّ لديك عملية تسجيل دخول تتكون من نشاط واحد (LoginActivity) وأجزاء متعددة (LoginUsernameFragment وLoginPasswordFragment). تريد طرق العرض هذه ما يلي:

1. يمكنك الوصول إلى مثيل LoginUserData نفسه الذي يجب مشاركته حتى انتهاء عملية تسجيل الدخول.

2. يمكنك إنشاء مثيل جديد من LoginUserData عند بدء التدفق مرة أخرى.

يمكنك تحقيق ذلك باستخدام حاوية تدفق تسجيل الدخول. يجب إنشاء هذه الحاوية عند بدء تدفق تسجيل الدخول وإزالتها من الذاكرة عند انتهاء التدفق.

يمكننا إضافة LoginContainer إلى نموذج الرمز. إذا كنت تريد أن تتمكّن من إنشاء عدة مثيلات من LoginContainer في التطبيق، فبدلاً من جعلها فردية واحدة، اجعلها فئة تتضمّن التبعيات التي يحتاجها تدفق تسجيل الدخول من AppContainer.

class LoginContainer(val userRepository: UserRepository) {

    val loginData = LoginUserData()

    val loginViewModelFactory = LoginViewModelFactory(userRepository)
}

// AppContainer contains LoginContainer now
class AppContainer {
    ...
    val userRepository = UserRepository(localDataSource, remoteDataSource)

    // LoginContainer will be null when the user is NOT in the login flow
    var loginContainer: LoginContainer? = null
}

// Container with Login-specific dependencies
class LoginContainer {

    private final UserRepository userRepository;

    public LoginContainer(UserRepository userRepository) {
        this.userRepository = userRepository;
        loginViewModelFactory = new LoginViewModelFactory(userRepository);
    }

    public LoginUserData loginData = new LoginUserData();

    public LoginViewModelFactory loginViewModelFactory;
}

// AppContainer contains LoginContainer now
public class AppContainer {
    ...
    public UserRepository userRepository = new UserRepository(localDataSource, remoteDataSource);

    // LoginContainer will be null when the user is NOT in the login flow
    public LoginContainer loginContainer;
}

بمجرد أن يكون لديك حاوية خاصة بالتدفق، عليك تحديد وقت إنشاء مثيل الحاوية وحذفه. نظرًا لأن تدفق تسجيل الدخول يكون مستقلاً في نشاط (LoginActivity)، فإن النشاط هو الذي يدير دورة حياة تلك الحاوية. بإمكان LoginActivity إنشاء المثيل في onCreate() وحذفه في onDestroy().

class LoginActivity: Activity() {

    private lateinit var loginViewModel: LoginViewModel
    private lateinit var loginData: LoginUserData
    private lateinit var appContainer: AppContainer


    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        appContainer = (application as MyApplication).appContainer

        // Login flow has started. Populate loginContainer in AppContainer
        appContainer.loginContainer = LoginContainer(appContainer.userRepository)

        loginViewModel = appContainer.loginContainer.loginViewModelFactory.create()
        loginData = appContainer.loginContainer.loginData
    }

    override fun onDestroy() {
        // Login flow is finishing
        // Removing the instance of loginContainer in the AppContainer
        appContainer.loginContainer = null
        super.onDestroy()
    }
}

public class LoginActivity extends Activity {

    private LoginViewModel loginViewModel;
    private LoginData loginData;
    private AppContainer appContainer;

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

        appContainer = ((MyApplication) getApplication()).appContainer;

        // Login flow has started. Populate loginContainer in AppContainer
        appContainer.loginContainer = new LoginContainer(appContainer.userRepository);

        loginViewModel = appContainer.loginContainer.loginViewModelFactory.create();
        loginData = appContainer.loginContainer.loginData;
    }

    @Override
    protected void onDestroy() {
        // Login flow is finishing
        // Removing the instance of loginContainer in the AppContainer
        appContainer.loginContainer = null;

        super.onDestroy();
    }
}

وكما هي الحال في LoginActivity، يمكن لأجزاء تسجيل الدخول الوصول إلى LoginContainer من AppContainer واستخدام مثيل LoginUserData الذي تمت مشاركته.

ولأنّك تتعامل مع منطق مراحل نشاط العرض في هذه الحالة، يكون استخدام ملاحظة مراحل النشاط منطقيًا.

الخاتمة

يعتبر حقن التبعية أسلوبًا جيدًا لإنشاء تطبيقات Android قابلة للتطوير والاختبار. استخدِم الحاويات كطريقة لمشاركة مثيلات الفئات في أجزاء مختلفة من تطبيقك وكمكان مركزي لإنشاء مثيلات للفئات باستخدام المصانع.

عندما يزداد حجم تطبيقك، ستبدأ في رؤية أنك تكتب الكثير من التعليمات البرمجية النموذجية (مثل المصانع)، والتي يمكن أن تكون عرضة للخطأ. عليك أيضًا إدارة نطاق ودورة حياة الحاويات بنفسك، وتحسين الحاويات التي لم تعد ضرورية وتجاهلها لإخلاء مساحة من الذاكرة. ويمكن أن يؤدي القيام بذلك بشكل غير صحيح إلى حدوث أخطاء طفيفة وتسرُّب الذاكرة في تطبيقك.

في قسم Dagger، ستتعلّم كيفية استخدام Dagger لأتمتة هذه العملية وإنشاء الرمز البرمجي نفسه الذي كنت ستكتبه يدويًا.