تشجع بنية التطبيق الموصى بها من Android بتقسيم الرمز البرمجي إلى فئات للاستفادة من فصل الاهتمامات، وهو مبدأ يكون فيه كل فئة من فئات التسلسل الهرمي مسؤولية واحدة محدّدة. يؤدي هذا إلى المزيد من الفئات الأصغر التي تحتاج إلى ربطها معًا لتلبية تبعيات بعضها البعض.
![تتألف تطبيقات Android عادةً من العديد من الفئات، ويعتمد بعضها على بعضها بعضًا.](https://developer.android.com/static/topic/libraries/architecture/images/final-architecture.png?authuser=5&hl=ar)
يمكن تمثيل التبعيات بين الفئات كرسم بياني، ترتبط فيه كل فئة بالفئات التي تعتمد عليها. يُشكّل الرسم البياني للتطبيق تمثيل جميع الصفوف وتبعياتها.
في الشكل 1، يمكنك مشاهدة تجريد الرسم البياني للتطبيق.
عندما تعتمد الفئة أ (ViewModel
) على الفئة ب (Repository
)، يكون هناك
خط يشير من أ إلى ب يمثل تلك التبعية.
يساعد حقن التبعية في إجراء هذه الروابط ويتيح لك تبديل
عمليات التنفيذ للاختبار. على سبيل المثال، عند اختبار ViewModel
يعتمد على المستودع، يمكنك وضع عمليات تنفيذ مختلفة لـ
Repository
باستخدام مواد مزيفة أو نماذج تجريبية لاختبار الحالات المختلفة.
أساسيات إدخال التبعية يدويًا
يتناول هذا القسم كيفية تطبيق إضافة التبعية اليدوية في سيناريو تطبيق Android حقيقي. حيث يتضمن نهجًا تكراريًا لكيفية البدء في استخدام حقن التبعية في تطبيقك. يتحسن هذا الأسلوب حتى يصل إلى نقطة تشبه إلى حد كبير ما سينشئه Dagger تلقائيًا لك. لمزيد من المعلومات حول Dagger، يُرجى الاطّلاع على أساسيات Dagger.
ضع في اعتبارك التدفق ليكون مجموعة من الشاشات في تطبيقك تتوافق مع إحدى الميزات. تسجيل الدخول والتسجيل والدفع كلها أمثلة على التدفقات.
عند تغطية عملية تسجيل الدخول لتطبيق Android عادي، يعتمد LoginActivity
على LoginViewModel
، والتي تعتمد بدورها على UserRepository
.
وتعتمد السمة UserRepository
بعد ذلك على خدمة UserLocalDataSource
وUserRemoteDataSource
، وهذا بدوره يعتمد على خدمة Retrofit
.
![](https://developer.android.com/static/images/training/dependency-injection/2-application-graph.png?authuser=5&hl=ar)
LoginActivity
هو نقطة الدخول إلى مسار تسجيل الدخول ويتفاعل المستخدم مع النشاط. بالتالي، على "LoginActivity
" إنشاء
LoginViewModel
بجميع العناصر التابعة له.
تبدو فئتا Repository
وDataSource
في التدفق على النحو التالي:
Kotlin
class UserRepository( private val localDataSource: UserLocalDataSource, private val remoteDataSource: UserRemoteDataSource ) { ... } class UserLocalDataSource { ... } class UserRemoteDataSource( private val loginService: LoginRetrofitService ) { ... }
Java
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
:
Kotlin
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) } }
Java
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); } }
ثمة مشاكل في هذا المنهج:
هناك الكثير من الرموز النموذجية. إذا أردت إنشاء مثيل آخر من الترميز
LoginViewModel
في جزء آخر من الرمز، سيكون لديك تكرار.يجب الإعلان عن التبعيات بالترتيب. يجب إنشاء مثيل
UserRepository
قبلLoginViewModel
لإنشائه.من الصعب إعادة استخدام الكائنات. إذا أردت إعادة استخدام
UserRepository
على مستوى ميزات متعددة، عليك جعله يتّبع نمط سينغلتون. نمط سينغلتون يجعل الاختبار أكثر صعوبة لأن جميع الاختبارات تشترك في نفس مثيل سينغلتون.
إدارة التبعيات باستخدام حاوية
لحلّ مشكلة إعادة استخدام العناصر، يمكنك إنشاء فئة حاوية التبعيات الخاصة بك والتي تستخدمها للحصول على التبعيات. يمكن أن تكون جميع الحالات
التي تقدّمها هذه الحاوية علنية. في هذا المثال، بما أنّك تحتاج فقط إلى مثيل من UserRepository
، يمكنك جعل تبعياته خاصة من خلال
خيار جعلها علنية في المستقبل إذا لزم الأمر:
Kotlin
// 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) }
Java
// 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
.
Kotlin
// 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() }
Java
// 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
:
Kotlin
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) } }
Java
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
على النحو التالي:
Kotlin
// 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) } }
Java
// 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
يستهلكها:
Kotlin
// 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() } }
Java
// 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(); } }
هذا النهج أفضل من السابق، ولكن لا تزال هناك بعض التحديات التي يجب وضعها في الاعتبار:
عليك إدارة
AppContainer
بنفسك من خلال إنشاء مثيلات لكل التبعيات يدويًا.لا يزال هناك الكثير من الرموز النموذجية. تحتاج إلى إنشاء مصانع أو معلمات يدويًا حسب ما إذا كنت تريد إعادة استخدام كائن أم لا.
إدارة التبعيات في تدفقات التطبيقات
يصبح AppContainer
معقدًا عندما تريد تضمين المزيد من
الوظائف في المشروع. عندما يصبح تطبيقك أكبر حجمًا وتبدأ في تقديم تدفقات مختلفة للميزات، هناك المزيد من المشكلات التي تنشأ:
عندما يكون لديك تدفقات مختلفة، فقد ترغب في أن تعيش الكائنات في نطاق ذلك التدفق. على سبيل المثال، عند إنشاء
LoginUserData
(الذي قد يتكوّن من اسم المستخدم وكلمة المرور المستخدَمين فقط في عملية تسجيل الدخول)، لا تريد الاحتفاظ بالبيانات من تدفق تسجيل الدخول القديم من مستخدم آخر. تريد مثيلاً جديدًا لكل تدفق جديد. يمكنك تحقيق ذلك من خلال إنشاء كائناتFlowContainer
داخلAppContainer
كما هو موضّح في مثال الرمز التالي.وقد يكون من الصعب أيضًا تحسين الرسم البياني للتطبيق وحاويات التدفق. تحتاج إلى تذكر حذف الحالات التي لا تحتاجها، بناءً على التدفق الذي تتواجد فيه.
تخيل أنّ لديك عملية تسجيل دخول تتكون من نشاط واحد (LoginActivity
)
وأجزاء متعددة (LoginUsernameFragment
وLoginPasswordFragment
).
تريد طرق العرض هذه ما يلي:
يمكنك الوصول إلى مثيل
LoginUserData
نفسه الذي يجب مشاركته حتى انتهاء عملية تسجيل الدخول.يمكنك إنشاء مثيل جديد من
LoginUserData
عند بدء التدفق مرة أخرى.
يمكنك تحقيق ذلك باستخدام حاوية تدفق تسجيل الدخول. يجب إنشاء هذه الحاوية عند بدء تدفق تسجيل الدخول وإزالتها من الذاكرة عند انتهاء التدفق.
يمكننا إضافة LoginContainer
إلى نموذج الرمز. إذا كنت تريد أن تتمكّن من إنشاء عدة مثيلات من LoginContainer
في التطبيق، فبدلاً من جعلها
فردية واحدة، اجعلها فئة تتضمّن التبعيات التي يحتاجها تدفق تسجيل الدخول من AppContainer
.
Kotlin
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 }
Java
// 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()
.
Kotlin
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() } }
Java
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 لأتمتة هذه العملية وإنشاء الرمز البرمجي نفسه الذي كنت ستكتبه يدويًا.