CalendarView#setupAsync uses GlobalScope
See original GitHub issueHello. It’s wrong way to use GlobalScope. Better way is pass CoroutineScope as parameter to CalendarView#setupAsync.
For example:
fun setupAsync(startMonth: YearMonth, endMonth: YearMonth, firstDayOfWeek: DayOfWeek, coroutineScope: CoroutineScope, completion: Completion? = null)...
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:5 (4 by maintainers)
Top Results From Across the Web
The reason to avoid GlobalScope - Roman Elizarov - Medium
It seems that using GlobalScope is a good default for launching work in background, however we do not recommend using GlobalScope . Why?...
Read more >Why not use GlobalScope.launch? - Stack Overflow
Starting a new coroutine from the global scope using GlobalScope.async or GlobalScope.launch will create a top-level "independent" coroutine.
Read more >GlobalScope - Kotlin
Global scope is used to launch top-level coroutines which are operating on the whole application lifetime and are not cancelled prematurely.
Read more >Kotlin Coroutines 1.5: GlobalScope Marked as Delicate ...
Global scope is used to launch top-level coroutines that operate during the whole application lifetime and are not canceled prematurely. Active ...
Read more >Manual CoroutineScopes: how to avoid GlobalScope
Sometimes you need to run async work outside the View Model. Don't use GlobalScope. Ideally, you should manually create and manage a ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
In version 1.1.0, a cancellation block is provided to cancel the job. This way Java and Kotlin users can benefit.
On second thought, I realized it would be better to make the method a suspend function. I am not sure how that would be called from Java, but I know it’s going to get ugly for Java users. Also, that would be a breaking change even for Kotlin users.