इस पेज पर कई स्ट्रक्चर के सबसे सही तरीके और सुझाव दिए गए हैं. इन्हें अपनाएं, ताकि आपके ऐप्लिकेशन की क्वालिटी, ऐप्लिकेशन की क्षमता, और ऐप्लिकेशन बड़े स्तर पर काम कर सके. उन्होंने यह भी आपके ऐप्लिकेशन की जांच और रखरखाव करना आसान हो जाता है.
यहां दिए गए सबसे सही तरीकों को विषय के हिसाब से ग्रुप में रखा गया है. हर एक की प्राथमिकता होती है, जो का सुझाव भी दिया जाता है. प्राथमिकताओं की सूची यहां दी गई है:
- इसका सुझाव दिया जाता है: आपको यह तरीका तब तक लागू करना चाहिए, जब तक कि इसका असर न हो जो बुनियादी तौर पर आपकी सोच से मेल खाते हैं.
- सुझाव: इस तरीके से आपके ऐप्लिकेशन को बेहतर बनाया जा सकता है.
- ज़रूरी नहीं: इस तरीके से कुछ खास मामलों में आपके ऐप्लिकेशन को बेहतर बनाया जा सकता है.
लेयर्ड आर्किटेक्चर
हमारा सुझाव है कि अलग-अलग लेयर वाला आर्किटेक्चर समस्याओं को अलग-अलग कैटगरी में बांटता हो. यह यूज़र इंटरफ़ेस (यूआई) को डेटा मॉडल से ड्राइव करता है, जो ट्रुथ सिद्धांत के एक ही सोर्स का पालन करता है, और एकतरफ़ा डेटा फ़्लो के सिद्धांतों का पालन करता है. यहां कुछ सबसे सही लेयर्ड आर्किटेक्चर के लिए इस्तेमाल किए जाने वाले तरीके:
सुझाव | ब्यौरा |
---|---|
साफ़ तौर पर तय किए गए डेटा लेयर का इस्तेमाल करें.
खास तौर पर सुझाया गया |
डेटा लेयर, ऐप्लिकेशन के डेटा को ऐप्लिकेशन के बाकी हिस्से में दिखाता है. साथ ही, इसमें आपके ऐप्लिकेशन के ज़्यादातर कारोबारी लॉजिक शामिल होते हैं.
|
साफ़ तौर पर बताई गई यूज़र इंटरफ़ेस (यूआई) लेयर का इस्तेमाल करें.
खास तौर पर सुझाया गया |
यूज़र इंटरफ़ेस (यूआई) लेयर, स्क्रीन पर ऐप्लिकेशन का डेटा दिखाती है. साथ ही, उपयोगकर्ता के इंटरैक्शन की मुख्य जगह के तौर पर काम करती है.
|
डेटा लेयर को रिपॉज़िटरी का इस्तेमाल करके ऐप्लिकेशन डेटा दिखाना चाहिए.
खास तौर पर सुझाया गया |
यूज़र इंटरफ़ेस (यूआई) लेयर के कॉम्पोनेंट, जैसे कि कंपोज़ेबल, ऐक्टिविटी या ViewModels को सीधे तौर पर डेटा सोर्स से इंटरैक्ट नहीं करना चाहिए. डेटा सोर्स के उदाहरण यहां दिए गए हैं:
|
कोरूटीन और फ़्लो का इस्तेमाल करें.
खास तौर पर सुझाया गया |
लेयर के बीच कम्यूनिकेट करने के लिए, कोरूटीन और फ़्लो का इस्तेमाल करें.
कोरूटीन इस्तेमाल करने के कुछ और सबसे सही तरीके यहां दिए गए हैं. |
डोमेन लेयर का इस्तेमाल करें.
बड़े ऐप्लिकेशन में इसके इस्तेमाल का सुझाव दिया जाता है |
अगर आपको कई ViewModels में डेटा लेयर के साथ इंटरैक्ट करने वाले बिज़नेस लॉजिक का फिर से इस्तेमाल करना है या किसी खास ViewModel की बिज़नेस लॉजिक की जटिलता को आसान बनाना है, तो डोमेन लेयर का इस्तेमाल करें |
यूज़र इंटरफ़ेस (यूआई) लेयर
यूज़र इंटरफ़ेस (यूआई) लेयर का काम, ऐप्लिकेशन के डेटा को स्क्रीन पर दिखाना है और उपयोगकर्ता इंटरैक्शन के मुख्य बिंदु के रूप में काम करते हैं. यहाँ कुछ सबसे सही तरीक़े बताए गए हैं यह यूज़र इंटरफ़ेस (यूआई) लेयर के लिए:
सुझाव | ब्यौरा |
---|---|
यूनिडायरेक्शनल डेटा फ़्लो (यूडीएफ़) का पालन करें.
खास तौर पर सुझाया गया |
यूनिडायरेक्शनल डेटा फ़्लो (यूडीएफ़) के सिद्धांतों को अपनाएं. यहां ViewModels, ऑब्ज़र्वर पैटर्न का इस्तेमाल करके यूज़र इंटरफ़ेस (यूआई) की स्थिति दिखाता है और तरीके कॉल के ज़रिए यूज़र इंटरफ़ेस (यूआई) से कार्रवाइयां लेता है. |
अगर AAC Viewमॉडल के फ़ायदे आपके ऐप्लिकेशन पर लागू होते हैं, तो उनका इस्तेमाल करें.
खास तौर पर सुझाया गया |
कारोबार के लॉजिक को मैनेज करने के लिए, AAC ViewModels का इस्तेमाल करें और यूज़र इंटरफ़ेस (यूआई) की स्थिति को यूज़र इंटरफ़ेस (यूआई) (लिखें या Android व्यू) में दिखाने के लिए ऐप्लिकेशन डेटा फ़ेच करें.
ViewModel इस्तेमाल करने के सबसे सही तरीके यहां देखें. ViewModels के फ़ायदे यहां देखें. |
लाइफ़साइकल की जानकारी वाले यूआई स्टेट कलेक्शन का इस्तेमाल करें.
खास तौर पर सुझाया गया |
लाइफ़साइकल के बारे में जानकारी वाले कोरूटीन बिल्डर का इस्तेमाल करके, यूज़र इंटरफ़ेस (यूआई) की स्थिति इकट्ठा करें: व्यू सिस्टम में repeatOnLifecycle और Jetpack Compose में collectAsStateWithLifecycle .
|
ViewModel के इवेंट, यूज़र इंटरफ़ेस (यूआई) पर नहीं भेजें.
खास तौर पर सुझाया गया |
इवेंट को ViewModel में तुरंत प्रोसेस करें और इवेंट को हैंडल करने के बाद स्टेटस अपडेट करें. यूज़र इंटरफ़ेस (यूआई) इवेंट के बारे में यहां ज़्यादा जानें. |
एक गतिविधि वाले ऐप्लिकेशन का इस्तेमाल करें.
सुझाव |
अगर आपके ऐप्लिकेशन में एक से ज़्यादा स्क्रीन हैं, तो अलग-अलग स्क्रीन और डीप लिंक के बीच नेविगेट करने के लिए, नेविगेशन फ़्रैगमेंट या नेविगेशन कंपोज़ का इस्तेमाल करें. |
Jetpack Compose का इस्तेमाल करें.
सुझाव |
Jetpack Compose का इस्तेमाल करके फ़ोन, टैबलेट, फ़ोल्ड किए जा सकने वाले डिवाइसों, और Wear OS के लिए नए ऐप्लिकेशन बनाएं. |
नीचे दिया गया स्निपेट, लाइफ़साइकल की जानकारी में यूज़र इंटरफ़ेस (यूआई) स्थिति को इकट्ठा करने का तरीका बताता है तरीका:
व्यू
class MyFragment : Fragment() {
private val viewModel: MyViewModel by viewModel()
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
viewLifecycleOwner.lifecycleScope.launch {
viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
viewModel.uiState.collect {
// Process item
}
}
}
}
}
Compose
@Composable
fun MyScreen(
viewModel: MyViewModel = viewModel()
) {
val uiState by viewModel.uiState.collectAsStateWithLifecycle()
}
ViewModel
ViewModels, यूज़र इंटरफ़ेस (यूआई) की स्थिति और डेटा लेयर. ViewModels के लिए कुछ सबसे सही तरीके यहां दिए गए हैं:
सुझाव | ब्यौरा |
---|---|
ViewModels, Android लाइफ़साइकल के हिसाब से नहीं होने चाहिए.
खास तौर पर सुझाया गया |
ViewModels में लाइफ़साइकल से जुड़े किसी भी टाइप का रेफ़रंस नहीं होना चाहिए. डिपेंडेंसी के तौर पर Activity, Fragment, Context या Resources को पास न करें.
अगर ViewModel में किसी चीज़ के लिए Context की ज़रूरत है, तो आपको अच्छे से आकलन करना चाहिए कि वह सही लेयर में है या नहीं. |
कोरूटीन और फ़्लो का इस्तेमाल करें.
खास तौर पर सुझाया गया |
ViewModel, डेटा या डोमेन लेयर के साथ इंटरैक्ट करने के लिए, इनका इस्तेमाल करता है:
|
स्क्रीन लेवल पर ViewModels इस्तेमाल करें.
खास तौर पर सुझाया गया |
यूज़र इंटरफ़ेस (यूआई) के फिर से इस्तेमाल किए जा सकने वाले हिस्सों में ViewModels इस्तेमाल न करें. आपको ViewModels का इस्तेमाल इन देशों में करना चाहिए:
|
फिर से इस्तेमाल किए जा सकने वाले यूज़र इंटरफ़ेस (यूआई) के कॉम्पोनेंट में, प्लेन स्टेट होल्डर क्लास का इस्तेमाल करें.
खास तौर पर सुझाया गया |
फिर से इस्तेमाल किए जा सकने वाले यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट में जटिलता को मैनेज करने के लिए, प्लेन स्टेट होल्डर क्लास का इस्तेमाल करें. ऐसा करने से, इस राज्य को बाहरी तौर पर इकट्ठा और कंट्रोल किया जा सकता है. |
AndroidViewModel का इस्तेमाल न करें.
सुझाव |
ViewModel क्लास का इस्तेमाल करें, न कि AndroidViewModel का. ViewModel में Application क्लास का इस्तेमाल नहीं किया जाना चाहिए. इसके बजाय, डिपेंडेंसी को यूज़र इंटरफ़ेस (यूआई) या डेटा लेयर पर ले जाएं. |
यूज़र इंटरफ़ेस (यूआई) की स्थिति दिखाएं.
सुझाव |
ViewModels को यूज़र इंटरफ़ेस (यूआई) को uiState नाम की एक प्रॉपर्टी के ज़रिए डेटा दिखाना चाहिए. अगर यूज़र इंटरफ़ेस (यूआई) में डेटा के एक से ज़्यादा ऐसे हिस्से दिखते हैं जो एक-दूसरे से मेल नहीं खाते, तो वीएम यूज़र इंटरफ़ेस (यूआई) की कई स्टेट प्रॉपर्टी दिखा सकता है.
|
नीचे दिया गया स्निपेट बताता है कि ViewModel की मदद से यूज़र इंटरफ़ेस (यूआई) की स्थिति कैसे दिखाई जा सकती है:
@HiltViewModel
class BookmarksViewModel @Inject constructor(
newsRepository: NewsRepository
) : ViewModel() {
val feedState: StateFlow<NewsFeedUiState> =
newsRepository
.getNewsResourcesStream()
.mapToFeedState(savedNewsResourcesState)
.stateIn(
scope = viewModelScope,
started = SharingStarted.WhileSubscribed(5_000),
initialValue = NewsFeedUiState.Loading
)
// ...
}
लाइफ़साइकल
सुझाव | ब्यौरा |
---|---|
ऐक्टिविटी या फ़्रैगमेंट में लाइफ़साइकल के तरीकों को न बदलें.
खास तौर पर सुझाया गया |
गतिविधियों या फ़्रैगमेंट में onResume जैसे लाइफ़साइकल तरीकों को न बदलें. इसके बजाय, LifecycleObserver का इस्तेमाल करें. अगर लाइफ़साइकल के तय Lifecycle.State तक पहुंचने पर ऐप्लिकेशन को काम करना हो, तो repeatOnLifecycle एपीआई का इस्तेमाल करें. |
नीचे दिए गए स्निपेट में बताया गया है कि आप लाइफ़साइकल स्थिति:
व्यू
class MyFragment: Fragment() {
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
viewLifecycleOwner.lifecycle.addObserver(object : DefaultLifecycleObserver {
override fun onResume(owner: LifecycleOwner) {
// ...
}
override fun onPause(owner: LifecycleOwner) {
// ...
}
}
}
}
Compose
@Composable
fun MyApp() {
val lifecycleOwner = LocalLifecycleOwner.current
DisposableEffect(lifecycleOwner, ...) {
val lifecycleObserver = object : DefaultLifecycleObserver {
override fun onStop(owner: LifecycleOwner) {
// ...
}
}
lifecycleOwner.lifecycle.addObserver(lifecycleObserver)
onDispose {
lifecycleOwner.lifecycle.removeObserver(lifecycleObserver)
}
}
}
डिपेंडेंसी हैंडल करता है
डिपेंडेंसी मैनेज करते समय, ऐसे कई सबसे सही तरीके हैं जिनका आपको ध्यान रखना चाहिए कॉम्पोनेंट:
सुझाव | ब्यौरा |
---|---|
डिपेंडेंसी इंजेक्शन का इस्तेमाल करें.
खास तौर पर सुझाया गया |
अगर हो सके, तो डिपेंडेंसी इंजेक्शन के सबसे सही तरीकों का इस्तेमाल करें. खास तौर पर, कंस्ट्रक्टर इंजेक्शन का इस्तेमाल करें. |
ज़रूरत पड़ने पर कॉम्पोनेंट का स्कोप.
खास तौर पर सुझाया गया |
डिपेंडेंसी कंटेनर का स्कोप तब स्कोप |
Hilt का इस्तेमाल करें.
सुझाव |
आसान ऐप्लिकेशन में, Hilt या मैन्युअल डिपेंडेंसी इंजेक्शन का इस्तेमाल करें. अगर आपका प्रोजेक्ट काफ़ी जटिल है, तो Hilt का इस्तेमाल करें. उदाहरण के लिए, अगर आपके चैनल पर:
|
टेस्ट करना
टेस्टिंग के लिए कुछ सबसे सही तरीके यहां दिए गए हैं:
सुझाव | ब्यौरा |
---|---|
जानें कि क्या टेस्ट करना है.
खास तौर पर सुझाया गया |
अगर प्रोजेक्ट करीब-करीब किसी hello World ऐप्लिकेशन जैसा आसान न हो, तो आपको इसकी जांच करनी चाहिए. कम से कम इस तरीके से:
|
नकल करने के बजाय, नकली चीज़ों को प्राथमिकता देनी है.
खास तौर पर सुझाया गया |
ज़्यादा जानकारी के लिए, Android दस्तावेज़ में टेस्ट डबल्स का इस्तेमाल करना लेख पढ़ें. |
टेस्ट स्टेट फ़्लो.
खास तौर पर सुझाया गया |
StateFlow की जांच करते समय:
|
ज़्यादा जानकारी के लिए, Android DAC (, Android SDK) की जांच करने वाली गाइड में क्या टेस्ट करें देखें.
मॉडल
अपने ऐप्लिकेशन में मॉडल डेवलप करते समय, आपको इन सबसे सही तरीकों को देखना चाहिए:
सुझाव | ब्यौरा |
---|---|
जटिल ऐप्लिकेशन में हर लेयर के लिए मॉडल बनाएं.
सुझाव |
कॉम्प्लेक्स ऐप्लिकेशन में, अलग-अलग लेयर या कॉम्पोनेंट में नए मॉडल बनाएं. ये उदाहरण देखें:
|
नाम रखने के तरीके
अपने कोड बेस को नाम देते समय, आपको इन सबसे सही तरीकों के बारे में जानकारी होनी चाहिए:
सुझाव | ब्यौरा |
---|---|
नाम रखने के तरीके.
ज़रूरी नहीं |
तरीके, क्रिया वाला वाक्यांश होना चाहिए. उदाहरण के लिए, makePayment() . |
नाम रखने से जुड़ी प्रॉपर्टी.
ज़रूरी नहीं |
प्रॉपर्टी, संज्ञा वाक्यांश में होनी चाहिए. उदाहरण के लिए, inProgressTopicSelection . |
डेटा की स्ट्रीम को नाम देना.
ज़रूरी नहीं |
जब क्लास से कोई फ़्लो स्ट्रीम, LiveData या कोई अन्य स्ट्रीम दिखती है, तो नाम रखने का फ़ॉर्मैट get{model}Stream() होता है. उदाहरण के लिए, getAuthorStream(): Flow<Author>
अगर फ़ंक्शन, मॉडल की सूची दिखाता है, तो मॉडल का नाम बहुवचन में होना चाहिए: getAuthorsStream(): Flow<List<Author>> |
इंटरफ़ेस का नाम लागू करना.
ज़रूरी नहीं |
इंटरफ़ेस को लागू करने के लिए सही नाम दिए जाने चाहिए. अगर कोई बेहतर नाम नहीं मिलता है, तो प्रीफ़िक्स के रूप में Default को शामिल करें. उदाहरण के लिए, NewsRepository इंटरफ़ेस के लिए, आपके पास OfflineFirstNewsRepository या InMemoryNewsRepository हो सकता है. अगर आपको कोई अच्छा नाम नहीं मिलता है, तो DefaultNewsRepository का इस्तेमाल करें.
नकली लागू करने की प्रोसेस के शुरू में Fake होना चाहिए, जैसा कि FakeAuthorsRepository में है. |