Android में कोरूटीन इस्तेमाल करने के सबसे सही तरीके

इस पेज पर ऐसे कई सबसे सही तरीके बताए गए हैं जिनका इस्तेमाल करने पर, कोरूटीन इस्तेमाल करते समय, आपके ऐप्लिकेशन को बड़े पैमाने पर और टेस्ट किया जा सकता है.

डिस्पैचर इंजेक्ट करें

नए कोरूटीन बनाते या कॉल करते समय, Dispatchers को हार्डकोड न करें withContext.

// DO inject Dispatchers
class NewsRepository(
    private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {
    suspend fun loadNews() = withContext(defaultDispatcher) { /* ... */ }
}

// DO NOT hardcode Dispatchers
class NewsRepository {
    // DO NOT use Dispatchers.Default directly, inject it instead
    suspend fun loadNews() = withContext(Dispatchers.Default) { /* ... */ }
}

डिपेंडेंसी इंजेक्शन पैटर्न से टेस्ट करना आसान हो जाता है, क्योंकि इसकी जगह कोई और यूनिट और इंस्ट्रुमेंटेशन टेस्ट में डिसपैचर टेस्ट डिसपैचर ताकि वे आपके टेस्ट को ज़्यादा सटीक बना सकें.

मुख्य थ्रेड से, निलंबित फ़ंक्शन को कॉल करना सुरक्षित होना चाहिए

निलंबित फ़ंक्शन मुख्य रूप से सुरक्षित होने चाहिए, जिसका मतलब है कि उन्हें मुख्य थ्रेड. अगर कोई क्लास, लंबे समय तक चलने वाले ब्लॉक करने के ऑपरेशन को कोरूटीन, इसकी मदद से प्रोसेस को मुख्य थ्रेड से बाहर ले जाने का काम करती है. इसके लिए, withContext. यह आपके ऐप्लिकेशन की सभी क्लास पर लागू होता है, चाहे जिसमें क्लास की बनावट के बारे में ज़्यादा जानकारी शामिल होती है.

class NewsRepository(private val ioDispatcher: CoroutineDispatcher) {

    // As this operation is manually retrieving the news from the server
    // using a blocking HttpURLConnection, it needs to move the execution
    // to an IO dispatcher to make it main-safe
    suspend fun fetchLatestNews(): List<Article> {
        withContext(ioDispatcher) { /* ... implementation ... */ }
    }
}

// This use case fetches the latest news and the associated author.
class GetLatestNewsWithAuthorsUseCase(
    private val newsRepository: NewsRepository,
    private val authorsRepository: AuthorsRepository
) {
    // This method doesn't need to worry about moving the execution of the
    // coroutine to a different thread as newsRepository is main-safe.
    // The work done in the coroutine is lightweight as it only creates
    // a list and add elements to it
    suspend operator fun invoke(): List<ArticleWithAuthor> {
        val news = newsRepository.fetchLatestNews()

        val response: List<ArticleWithAuthor> = mutableEmptyList()
        for (article in news) {
            val author = authorsRepository.getAuthor(article.author)
            response.add(ArticleWithAuthor(article, author))
        }
        return Result.Success(response)
    }
}

इस पैटर्न से आपके ऐप्लिकेशन को बड़े पैमाने पर इस्तेमाल किया जा सकता है, क्योंकि क्लास में सस्पेंड फ़ंक्शन को कॉल किया जा सकता है आपको इस बात की चिंता नहीं होनी चाहिए कि किस तरह के काम के लिए, Dispatcher का इस्तेमाल कैसे करना है. यह उस क्लास को ज़िम्मेदारी दी जाती है जो काम करती है.

ViewModel को कोरूटीन बनाना चाहिए

ViewModel क्लास को प्राथमिकता देनी चाहिए कारोबार करने के लिए, सस्पेंड फ़ंक्शन को सार्वजनिक करने के बजाय कोरूटीन बनाना लॉजिक. इसके बजाय, अगर ViewModel में निलंबित करना हो, तो फ़ंक्शन काम आ सकता है: डेटा की स्ट्रीम का इस्तेमाल करके स्टेटस दिखाते हैं, तो सिर्फ़ एक वैल्यू उत्सर्जित करनी होगी.

// DO create coroutines in the ViewModel
class LatestNewsViewModel(
    private val getLatestNewsWithAuthors: GetLatestNewsWithAuthorsUseCase
) : ViewModel() {

    private val _uiState = MutableStateFlow<LatestNewsUiState>(LatestNewsUiState.Loading)
    val uiState: StateFlow<LatestNewsUiState> = _uiState

    fun loadNews() {
        viewModelScope.launch {
            val latestNewsWithAuthors = getLatestNewsWithAuthors()
            _uiState.value = LatestNewsUiState.Success(latestNewsWithAuthors)
        }
    }
}

// Prefer observable state rather than suspend functions from the ViewModel
class LatestNewsViewModel(
    private val getLatestNewsWithAuthors: GetLatestNewsWithAuthorsUseCase
) : ViewModel() {
    // DO NOT do this. News would probably need to be refreshed as well.
    // Instead of exposing a single value with a suspend function, news should
    // be exposed using a stream of data as in the code snippet above.
    suspend fun loadNews() = getLatestNewsWithAuthors()
}

कारोबारी नियम लागू करने के लिए, व्यू को सीधे तौर पर किसी कोरूटीन को ट्रिगर नहीं करना चाहिए. इसके बजाय, यह ज़िम्मेदारी ViewModel को सौंपें. इससे आपका कारोबार लॉजिक को टेस्ट करना आसान है, क्योंकि ViewModel ऑब्जेक्ट का इस्तेमाल करने के बजाय यूनिट की जांच की जा सकती है ऐसे इंस्ट्रुमेंटेशन टेस्ट जिनसे व्यू की जांच की जा सकती है.

इसके अलावा, आपके कोरूटीन, कॉन्फ़िगरेशन में होने वाले बदलावों में बने रहेंगे अगर viewModelScope में काम शुरू किया जाता है, तो वह अपने-आप चालू हो जाता है. अगर आपको कोरूटीन, lifecycleScope का इस्तेमाल करते हैं, तो आपको उसे मैन्युअल तौर पर मैनेज करना होगा. अगर कोरूटीन को ViewModel के स्कोप से बाहर रखना है, तो देखें कारोबार और डेटा लेयर सेक्शन में कोरूटीन बनाना.

बदलाव न किए जा सकने वाले टाइप न दिखाएं

अन्य क्लास में नहीं बदले जा सकने वाले टाइप दिखाएं. इस तरह से, बदले जा सकने वाले टाइप को एक क्लास में सेंट्रलाइज़ किया जाता है. इससे हर बार गड़बड़ी होने पर कुछ गलत हो जाता है.

// DO expose immutable types
class LatestNewsViewModel : ViewModel() {

    private val _uiState = MutableStateFlow(LatestNewsUiState.Loading)
    val uiState: StateFlow<LatestNewsUiState> = _uiState

    /* ... */
}

class LatestNewsViewModel : ViewModel() {

    // DO NOT expose mutable types
    val uiState = MutableStateFlow(LatestNewsUiState.Loading)

    /* ... */
}

डेटा और कारोबार लेयर में सस्पेंड फ़ंक्शन और फ़्लो दिखने चाहिए

डेटा और कारोबार की लेयर में मौजूद क्लास, आम तौर पर ऐसे फ़ंक्शन दिखाती हैं जिनसे एक बार में किए जाने वाले कॉल या डेटा में समय के साथ होने वाले बदलावों की सूचना पाने के लिए किया जा सकता है. इन शिक्षण संस्थानों में लेयर में वन-शॉट कॉल के लिए सस्पेंड फ़ंक्शन और फ़्लोर फ़्लो डेटा में हुए बदलावों के बारे में सूचना दें.

// Classes in the data and business layer expose
// either suspend functions or Flows
class ExampleRepository {
    suspend fun makeNetworkRequest() { /* ... */ }

    fun getExamples(): Flow<Example> { /* ... */ }
}

इस सबसे सही तरीके की मदद से कॉलर, आम तौर पर प्रज़ेंटेशन लेयर उन लेयर में चल रहे काम के एक्ज़ीक्यूशन और लाइफ़साइकल को कंट्रोल किया जा सकता है और ज़रूरत पड़ने पर रद्द कर सकते हैं.

कारोबार और डेटा लेयर में कोरूटीन बनाना

डेटा या कारोबार की लेयर में मौजूद उन क्लास के लिए जिन्हें कोरूटीन बनाने की ज़रूरत होती है तो कई विकल्प हैं.

अगर उन कोरूटीन में किया जाने वाला काम सिर्फ़ तब काम का होता है, जब उपयोगकर्ता तो यह कॉलर के लाइफ़साइकल के हिसाब से होना चाहिए. ज़्यादातर मामलों में, कॉलर ViewModel होगा और कॉल रद्द होने के बाद जब उपयोगकर्ता स्क्रीन से दूर जाए और ViewModel मिटा दिया जाए. इस मामले में, coroutineScope या supervisorScope इस्तेमाल किया जाना चाहिए.

class GetAllBooksAndAuthorsUseCase(
    private val booksRepository: BooksRepository,
    private val authorsRepository: AuthorsRepository,
) {
    suspend fun getBookAndAuthors(): BookAndAuthors {
        // In parallel, fetch books and authors and return when both requests
        // complete and the data is ready
        return coroutineScope {
            val books = async { booksRepository.getAllBooks() }
            val authors = async { authorsRepository.getAllAuthors() }
            BookAndAuthors(books.await(), authors.await())
        }
    }
}

अगर किया जाने वाला काम सही है, तो ऐप्लिकेशन को खोले जाने के दौरान ही, किसी विशिष्ट स्क्रीन के लिए सीमित नहीं है, तो कार्य कॉलर के कार्य से बाहर हो जाना चाहिए लाइफ़साइकल. इस स्थिति के लिए, बाहरी CoroutineScope का इस्तेमाल इस तरह से करें कोरूटीन और काम के ऐसे पैटर्न, जिनके लिए ब्लॉग पोस्ट रद्द नहीं की जानी चाहिए.

class ArticlesRepository(
    private val articlesDataSource: ArticlesDataSource,
    private val externalScope: CoroutineScope,
) {
    // As we want to complete bookmarking the article even if the user moves
    // away from the screen, the work is done creating a new coroutine
    // from an external scope
    suspend fun bookmarkArticle(article: Article) {
        externalScope.launch { articlesDataSource.bookmarkArticle(article) }
            .join() // Wait for the coroutine to complete
    }
}

externalScope को ऐसी क्लास को बनाना और मैनेज करना चाहिए जो इससे ज़्यादा समय तक चलती है तो उसे Application क्लास या ViewModel नेविगेशन ग्राफ़ के दायरे में आता है.

परीक्षणों में TestDispatchers इंजेक्ट करें

उदाहरण के लिए, TestDispatcher को टेस्ट में आपकी क्लास में इंजेक्ट किया जाना चाहिए. दो उपलब्ध हैं लागू करना kotlinx-coroutines-test लाइब्रेरी:

• StandardTestDispatcher: शेड्यूलर की मदद से शुरू किए गए कोरूटीन सूची में जोड़े जाते हैं और एक्ज़ीक्यूट किए जाते हैं जब टेस्ट थ्रेड व्यस्त न हो. टेस्ट थ्रेड को निलंबित किया जा सकता है, ताकि सूची में रखे गए अन्य कोरूटीन, इन तरीकों का इस्तेमाल करके चलते हैं: advanceUntilIdle.

• UnconfinedTestDispatcher: ब्लॉक किए गए तरीके से, नए कोरूटीन को तेज़ी से चलाता है. इससे आम तौर पर, लिखना आसान हो जाता है टेस्ट आसान बना देता है, लेकिन यह आपको कम कंट्रोल देता है कि कोरूटीन कैसे काम करते हैं. जांच के दौरान लागू किया जाता है.

अतिरिक्त जानकारी के लिए हर डिस्पैचर लागू करने से जुड़े दस्तावेज़ देखें.

कोरूटीन की जांच करने के लिए, runTest कोरूटीन बिल्डर. runTest, TestCoroutineScheduler ताकि आपको टेस्ट में देरी न हो और वर्चुअल टाइम कंट्रोल किया जा सके. आप यह भी कर सकते हैं इस शेड्यूलर का इस्तेमाल ज़रूरत के हिसाब से अतिरिक्त टेस्ट डिस्पैचर बनाने के लिए करें.

class ArticlesRepositoryTest {

    @Test
    fun testBookmarkArticle() = runTest {
        // Pass the testScheduler provided by runTest's coroutine scope to
        // the test dispatcher
        val testDispatcher = UnconfinedTestDispatcher(testScheduler)

        val articlesDataSource = FakeArticlesDataSource()
        val repository = ArticlesRepository(
            articlesDataSource,
            testDispatcher
        )
        val article = Article()
        repository.bookmarkArticle(article)
        assertThat(articlesDataSource.isBookmarked(article)).isTrue()
    }
}

सभी TestDispatchers को एक ही शेड्यूलर का इस्तेमाल करना चाहिए. इसकी मदद से, ये काम किए जा सकते हैं अपने टेस्ट करने के लिए, सभी कोरूटीन कोड को एक ही टेस्ट थ्रेड पर चलाएं सारणिक. runTest को उन सभी कोरूटीन का इंतज़ार होगा जो एक ही शेड्यूलर या टेस्ट कोरूटीन के बच्चे हैं, जिन्हें लौटने से पहले पूरा करना होता है.

GlobalScope से बचें

यह इंजेक्ट डिस्पैचर के सबसे सही तरीके जैसा है. इस्तेमाल करके GlobalScope तुम CoroutineScope की हार्डकोडिंग कर रहे हो, जिसका इस्तेमाल करके क्लास में कुछ कमियां आती हैं इसके साथ:

• हार्ड-कोडिंग वैल्यू को प्रमोट करता है. अगर आप GlobalScope को हार्डकोड करते हैं, तो हो सकता है कि Dispatchers की हार्ड-कोडिंग भी की जा सकती है.

• जांच को बहुत मुश्किल बना देता है, क्योंकि आपके कोड को अनियंत्रित दायरे में एक्ज़ीक्यूट किया जाता है. आप इसके निष्पादन को कंट्रोल नहीं कर पाएंगे.

• सभी कोरूटीन चलाने के लिए, एक समान CoroutineContext नहीं हो सकता पहले से मौजूद हैं.

इसके बजाय, काम के लिए CoroutineScope इंजेक्ट करने के बारे में सोचें, जिसे पूरा करना ज़रूरी है मौजूदा दायरा. ज़्यादा जानकारी के लिए कारोबार और डेटा लेयर सेक्शन में कोरूटीन बनाना इस विषय के बारे में ज़्यादा जानें.

// DO inject an external scope instead of using GlobalScope.
// GlobalScope can be used indirectly. Here as a default parameter makes sense.
class ArticlesRepository(
    private val articlesDataSource: ArticlesDataSource,
    private val externalScope: CoroutineScope = GlobalScope,
    private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {
    // As we want to complete bookmarking the article even if the user moves
    // away from the screen, the work is done creating a new coroutine
    // from an external scope
    suspend fun bookmarkArticle(article: Article) {
        externalScope.launch(defaultDispatcher) {
            articlesDataSource.bookmarkArticle(article)
        }
            .join() // Wait for the coroutine to complete
    }
}

// DO NOT use GlobalScope directly
class ArticlesRepository(
    private val articlesDataSource: ArticlesDataSource,
) {
    // As we want to complete bookmarking the article even if the user moves away
    // from the screen, the work is done creating a new coroutine with GlobalScope
    suspend fun bookmarkArticle(article: Article) {
        GlobalScope.launch {
            articlesDataSource.bookmarkArticle(article)
        }
            .join() // Wait for the coroutine to complete
    }
}

GlobalScope और उसके दूसरे विकल्पों के बारे में यहां ज़्यादा जानें: कोरूटीन और काम के ऐसे पैटर्न, जिनके लिए ब्लॉग पोस्ट रद्द नहीं की जानी चाहिए.

अपने कोरूटीन को रद्द करने लायक बनाना

कोरूटीन को रद्द करने की प्रक्रिया को-ऑपरेटिव होती है. इसका मतलब है कि जब किसी कोरूटीन की Job रद्द हो गया है. कोरूटीन रद्द तब तक नहीं किया जाता, जब तक उसे निलंबित नहीं किया जाता या उसकी जांच नहीं की जाती रद्द करने के लिए. अगर कोरूटीन में ब्लॉक करने की कार्रवाइयां की जाती हैं, तो पक्का करें कि यह कि कोरूटीन रद्द किया जा सकता है.

उदाहरण के लिए, अगर डिस्क से कई फ़ाइलें पढ़ना है, तो हर फ़ाइल को पढ़ते समय, देखें कि कोरूटीन रद्द हुआ है या नहीं. एक तरफ़ रद्द किए जाने का पता लगाने के लिए, ensureActive फ़ंक्शन का इस्तेमाल करना होगा.

someScope.launch {
    for(file in files) {
        ensureActive() // Check for cancellation
        readFile(file)
    }
}

kotlinx.coroutines से सभी निलंबित फ़ंक्शन, जैसे कि withContext और delay को रद्द किया जा सकता है. अगर आपके कोरूटीन उन्हें कॉल करते हैं, तो आपको ऐसा करने की ज़रूरत नहीं है किसी अन्य काम के लिए भी इसका इस्तेमाल किया जा सकता है.

कोरूटीन में रद्द करने के बारे में ज़्यादा जानकारी के लिए, कोरूटीन ब्लॉग पोस्ट में रद्द करना.

अपवादों से सावधान रहें

कोरूटीन में होने वाले ऐसे अपवाद होते हैं जिन्हें हैंडल नहीं किया जाता. इन अपवादों की वजह से, आपका ऐप्लिकेशन क्रैश हो सकता है. अगर अपवाद हो उन्हें ऐसे कोरोटिन के शरीर में शामिल किया जा सकता है जो इनके साथ बने हैं viewModelScope या lifecycleScope.

class LoginViewModel(
    private val loginRepository: LoginRepository
) : ViewModel() {

    fun login(username: String, token: String) {
        viewModelScope.launch {
            try {
                loginRepository.login(username, token)
                // Notify view user logged in successfully
            } catch (exception: IOException) {
                // Notify view login attempt failed
            }
        }
    }
}

ज़्यादा जानकारी के लिए, यह ब्लॉग पोस्ट देखें कोरूटीन के अपवाद, या कोरूटीन के अपवादों को मैनेज करना Kotlin दस्तावेज़ में.

कोरूटीन के बारे में ज़्यादा जानें

कोरूटीन से जुड़े ज़्यादा संसाधनों के लिए, यह देखें: Kotlin कोरूटीन और फ़्लो के लिए अतिरिक्त संसाधन पेज.