1 00:00:05,500 --> 00:00:06,800 Good day, everyone. Welcome back. 2 00:00:07,300 --> 00:00:11,300 We've changed our coroutines to use the new ViewModelScope. 3 00:00:12,100 --> 00:00:13,100 Let's see if it works. 4 00:00:13,600 --> 00:00:16,100 Run the app and make sure your logcat's visible. 5 00:00:23,000 --> 00:00:27,000 I'll filter the logcat on ViewModelProvider 6 00:00:27,200 --> 00:00:30,000 and position the emulator over towards the right 7 00:00:30,360 --> 00:00:32,259 so that we can see the logcat entries. 8 00:00:46,260 --> 00:00:50,260 Make sure the regex box is ticked, otherwise the filter won't work. 9 00:00:51,060 --> 00:00:53,310 Remember that we get the process ID 10 00:00:53,670 --> 00:00:57,770 followed by the thread ID after the time for each logcat entry. 11 00:00:58,470 --> 00:01:01,070 You should see the entries from app provider 12 00:01:01,670 --> 00:01:03,170 running on a separate thread. 13 00:01:03,970 --> 00:01:07,270 The retrieved timing entries run on the main thread. 14 00:01:08,260 --> 00:01:11,860 That's the first few entries from app provider in my logcat. 15 00:01:12,660 --> 00:01:14,160 We did that deliberately. 16 00:01:14,160 --> 00:01:17,460 The timing has to be retrieved before the UI is shown 17 00:01:17,760 --> 00:01:20,560 to prevent the user from timing a new task 18 00:01:20,560 --> 00:01:22,460 before we've retrieved the existing one. 19 00:01:23,260 --> 00:01:26,860 The last three from app provider are on a different thread. 20 00:01:27,760 --> 00:01:31,260 I'll edit a task and change its sort order. 21 00:01:41,460 --> 00:01:45,260 When I tap save, the database is updated on another thread. 22 00:01:46,160 --> 00:01:50,360 We also see the data being re-queried again on the background thread. 23 00:01:51,860 --> 00:01:55,160 Of course, you'll want to perform a thorough test of the app. 24 00:01:55,520 --> 00:02:00,380 You should test adding a new task, deleting a task and timing tasks. 25 00:02:01,080 --> 00:02:04,740 You'll also want to make sure the reports are loading data on a background thread. 26 00:02:05,640 --> 00:02:08,000 I won't spend time doing that in this video, 27 00:02:08,000 --> 00:02:11,400 but I didn't want to give the impression that this is all the testing you have to do. 28 00:02:11,950 --> 00:02:16,510 All right. Let's get back to the code and have a look at the SaveTask function 29 00:02:16,760 --> 00:02:18,360 in TaskTimerViewModel. 30 00:02:26,660 --> 00:02:30,160 Whenever we've launched a coroutine using ViewModelScope, 31 00:02:30,520 --> 00:02:33,120 we're passing Dispatchers.IO. 32 00:02:33,780 --> 00:02:37,780 We can see that on line 95 and line 105. 33 00:02:39,280 --> 00:02:42,280 The default dispatcher when using ViewModelScope 34 00:02:42,280 --> 00:02:44,180 is dispatchers.main. 35 00:02:44,950 --> 00:02:48,050 That means our co-routine will run on the main UI thread. 36 00:02:48,650 --> 00:02:51,250 If we don't specify dispatchers.io. 37 00:02:52,050 --> 00:02:53,750 That's a sensible default 38 00:02:53,750 --> 00:02:57,410 because Google don't know what we'll be doing in our coroutines 39 00:02:57,910 --> 00:03:01,710 using dispatchers.main is suitable for a co-routine 40 00:03:01,710 --> 00:03:03,310 that performs light work. 41 00:03:04,610 --> 00:03:08,810 You can find a table that briefly describes the uses for the three dispatchers 42 00:03:09,170 --> 00:03:11,570 in a blog post by Sean McQuillan 43 00:03:11,570 --> 00:03:13,870 Google's android developer advocate. 44 00:03:14,470 --> 00:03:16,470 I'll switch to that blog in my browser. 45 00:03:24,770 --> 00:03:27,170 The table is about two thirds of the way down. 46 00:03:31,470 --> 00:03:35,460 For database work we should use Dispatchers.IO, 47 00:03:35,460 --> 00:03:38,660 which is what we're doing. In the next video, 48 00:03:38,660 --> 00:03:43,060 we'll look at what happens if we just let ViewModelScope users default 49 00:03:43,360 --> 00:03:47,360 and leave the coroutine on the main thread. I'll see you there.