WEBVTT 1 00:00:00.040 --> 00:00:02.279 Never picked up your phone, open an app you use 2 00:00:02.319 --> 00:00:06.040 all the time, and then just nothing, just a frozen screen, 3 00:00:06.040 --> 00:00:08.240 maybe a little spinner, or you get that absolutely dreaded 4 00:00:08.439 --> 00:00:12.400 application not responding message asking if you want to force quit? 5 00:00:12.519 --> 00:00:14.839 Oh, I know that feeling. It's instantly frustrating, isn't It 6 00:00:14.960 --> 00:00:18.199 basically screams this app is broken at the user. And 7 00:00:18.280 --> 00:00:21.879 almost every single time that feeling, it's because the app's 8 00:00:22.000 --> 00:00:23.760 main thread got completely tied up. 9 00:00:23.879 --> 00:00:26.600 The main thread that's like the nerve center of the 10 00:00:26.640 --> 00:00:29.920 app on Android gap, the bit doing everything you see 11 00:00:29.960 --> 00:00:31.280 and interact with exactly. 12 00:00:31.320 --> 00:00:33.560 It's often called the UI thread, and for good reason, 13 00:00:33.640 --> 00:00:37.200 it draws everything on the screen, handles your taps, your swipes, 14 00:00:37.320 --> 00:00:41.719 runs crucial activity callbacks. Think of it like, well, a 15 00:00:41.880 --> 00:00:44.200 very busy air traffic controller for the UI. 16 00:00:44.200 --> 00:00:47.280 And if that controller gets bogged down trying to I 17 00:00:47.320 --> 00:00:50.159 don't know, calculate pie to a million places instead of 18 00:00:50.280 --> 00:00:51.520 landing planes. 19 00:00:51.200 --> 00:00:54.520 Everything grinds to a halt. The UI freezes solid. 20 00:00:54.840 --> 00:00:57.920 So blocking that main thread, that's the real villain behind 21 00:00:57.960 --> 00:01:03.000 the unresponsiveness, that jerky animations, the jank and yeah, ultimately 22 00:01:03.079 --> 00:01:07.040 that anr dialogue precisely Okay, so our source material for 23 00:01:07.079 --> 00:01:11.719 this deep dive asynchronous Android by Steve Lyles. It goes 24 00:01:11.840 --> 00:01:15.599 right into this problem. It's all about using the power 25 00:01:15.599 --> 00:01:19.200 of modern phones, you know, with their multiple process or 26 00:01:19.239 --> 00:01:20.400 core is just sitting. 27 00:01:20.079 --> 00:01:22.400 There right, leveraging that power to keep. 28 00:01:22.200 --> 00:01:26.040 Apps smooth and responsive by doing work off that critical 29 00:01:26.079 --> 00:01:26.640 main thread. 30 00:01:26.840 --> 00:01:29.319 Yeah, and our mission today is basically to unpack the 31 00:01:29.439 --> 00:01:32.319 key ideas and tools Android gives us for handling this 32 00:01:32.359 --> 00:01:35.760 background work properly. We want to give you, the listener, 33 00:01:35.840 --> 00:01:38.760 a kind of shortcut to understanding how to build apps 34 00:01:38.760 --> 00:01:41.879 that actually feel responsive, drawing straight from the book. 35 00:01:42.000 --> 00:01:45.200 Right, mission accepted, Let's dive in. So why is this 36 00:01:45.239 --> 00:01:49.159 such a big deal on mobile specifically compared to say 37 00:01:49.200 --> 00:01:50.040 a desktop app. 38 00:01:50.159 --> 00:01:52.879 Well, mobile devices, even though they're super powerful now, they 39 00:01:52.920 --> 00:01:55.840 still operate under tighter constraints than a desktop or a server. 40 00:01:55.920 --> 00:01:59.159 You know, limited battery, often less ram efficiency. 41 00:01:58.640 --> 00:02:00.799 Is key, right, And like you said, each Android app 42 00:02:00.799 --> 00:02:03.680 process usually just gets that one main thread and all 43 00:02:03.680 --> 00:02:05.400 the critical UI stuff happens there. 44 00:02:05.640 --> 00:02:08.680 And this is where it gets really painful if you're 45 00:02:08.680 --> 00:02:11.360 not careful, If you try to do anything that takes 46 00:02:11.400 --> 00:02:14.400 a noticeable amount of time reading a big file, doing 47 00:02:14.439 --> 00:02:17.639 heavy math, or the classic one making a network request. 48 00:02:17.680 --> 00:02:19.680 If you do that directly on them a main thread. 49 00:02:19.520 --> 00:02:22.560 That's when the trouble starts. How quickly does it become noticeable? 50 00:02:22.719 --> 00:02:23.960 Like how much time is too much? 51 00:02:24.280 --> 00:02:26.439 Oh, a user will feel a delay of even just 52 00:02:26.479 --> 00:02:30.759 a couple hundred milliseconds. But for smooth UI for animations 53 00:02:30.800 --> 00:02:34.400 and scrolling, you're aiming for sixty frames per second. That 54 00:02:34.439 --> 00:02:38.039 means you have about sixteen point sixty seven milliseconds to 55 00:02:38.159 --> 00:02:39.199 draw each frame. 56 00:02:39.439 --> 00:02:41.520 Wow, it's not much time at all, not at all. 57 00:02:41.560 --> 00:02:43.759 And if your main thread is busy doing something else 58 00:02:43.840 --> 00:02:46.800 for longer than that sixteen milliseconds, you drop a frame. 59 00:02:47.280 --> 00:02:51.560 That's the jank. Your smooth scrolling suddenly becomes a stuttering mess. 60 00:02:51.840 --> 00:02:54.479 And the absolute worst case the ANR. 61 00:02:54.599 --> 00:02:57.719 The ANR, Yeah, block that main thread for five whole seconds, 62 00:02:57.759 --> 00:03:00.759 and Android basically throws its hands up. This app is 63 00:03:00.800 --> 00:03:03.759 stuck and shows that dialogue offering to kill it. The 64 00:03:03.800 --> 00:03:06.639 system takes unresponsiveness very seriously. 65 00:03:06.719 --> 00:03:09.400 Even built in protections at the platform level, didn't they. 66 00:03:09.360 --> 00:03:12.840 They definitely did. You've got developer tools like strict mode, 67 00:03:12.919 --> 00:03:16.400 which can flash the screen red if you do slow 68 00:03:16.520 --> 00:03:20.719 operations on the main thread during development handy and crucially, 69 00:03:21.199 --> 00:03:25.199 starting back in Honeycomb API eleven, they introduced the network 70 00:03:25.199 --> 00:03:27.360 on main thread exception. If you try to make a 71 00:03:27.400 --> 00:03:29.919 network call on the main thread in a modern app, 72 00:03:30.039 --> 00:03:31.759 it just crashes boom. 73 00:03:31.800 --> 00:03:33.960 So they're literally stopping you from making that mistake. 74 00:03:34.000 --> 00:03:36.840 They are actively pushing you away from it, which leads 75 00:03:36.840 --> 00:03:41.039 to the fundamental solution the source hammers home. You have 76 00:03:41.080 --> 00:03:46.080 to offload long running work, heavy computation file io network calls, 77 00:03:46.120 --> 00:03:48.719 get them onto background threads, let the main thread focus 78 00:03:48.759 --> 00:03:49.240 on the UI. 79 00:03:49.680 --> 00:03:54.319 Simple idea, but I guess managing multiple threads isn't always straightforward. 80 00:03:53.719 --> 00:03:55.599 Not at all. That's why you run into the classic 81 00:03:55.639 --> 00:03:59.800 headaches of concurrent programming. You get correctness issues like race. 82 00:03:59.639 --> 00:04:02.159 Condition Race conditions was a simple example of that. 83 00:04:02.400 --> 00:04:05.919 The book uses a great one. Imagine an integer variable 84 00:04:06.120 --> 00:04:09.560 mind starting at zero, Thread A reads it cee zero 85 00:04:09.960 --> 00:04:12.319 before A can update it. Thread B also reads it 86 00:04:12.319 --> 00:04:15.199 ce zero. Then thread A adds one and writes one back. 87 00:04:15.479 --> 00:04:17.800 Then thread B adds one to the zero at red 88 00:04:17.839 --> 00:04:18.839 and writes one back. 89 00:04:19.040 --> 00:04:22.199 Ah. So even though two threads incremented, the result is 90 00:04:22.240 --> 00:04:24.879 one not two. Because they race to read the old 91 00:04:24.959 --> 00:04:25.959 value exactly. 92 00:04:25.959 --> 00:04:28.360 They tripped over each other and the result is wrong. 93 00:04:28.800 --> 00:04:32.000 You can also get liveness issues like deadlock. That's where 94 00:04:32.160 --> 00:04:34.680 thread A is waiting for a lock held by thread B, 95 00:04:35.079 --> 00:04:36.959 and thread B is waiting for a lock held by. 96 00:04:36.920 --> 00:04:38.399 Thread A like a gridlock. 97 00:04:38.759 --> 00:04:41.480 Nobody can move precisely, stuck forever. 98 00:04:41.639 --> 00:04:45.439 And Android adds its own specific wrinkles to these concurrency problems. 99 00:04:45.519 --> 00:04:48.040 It sure does. The activity life cycle is probably the 100 00:04:48.040 --> 00:04:50.600 biggest one. So you spin up a background thread and 101 00:04:50.639 --> 00:04:53.279 it holds a direct reference to your activity or maybe 102 00:04:53.279 --> 00:04:55.600 one of its views. Okay, now the user rotates to 103 00:04:55.639 --> 00:04:58.439 the phone, The system destroys the old activity instance and 104 00:04:58.480 --> 00:05:00.839 creates a new one. But your background thread might still 105 00:05:00.879 --> 00:05:03.600 be chugging along holding onto that reference to the old 106 00:05:03.720 --> 00:05:05.120 now dead activity, and that. 107 00:05:05.079 --> 00:05:08.279 Means the old activity can't be garbage collected exactly. 108 00:05:08.439 --> 00:05:11.560 Instant memory leak because something still has a grip on it. 109 00:05:11.639 --> 00:05:15.279 Ooh, memory leaks the bane of mobile development, they really are. 110 00:05:15.839 --> 00:05:18.639 And then there's the whole synchronization challenge. Your background thread 111 00:05:18.639 --> 00:05:20.800 does its work, it's a result, great, but how do 112 00:05:20.839 --> 00:05:23.600 you get that result back to the UI. You must 113 00:05:23.720 --> 00:05:27.120 update UI elements on the main thread, right, So getting 114 00:05:27.240 --> 00:05:30.439 data safely from the background thread to the main thread 115 00:05:30.759 --> 00:05:33.920 is a fundamental problem that the Android toolkit is designed 116 00:05:33.920 --> 00:05:34.680 to help solve. 117 00:05:34.920 --> 00:05:38.519 Okay, so this is why Android provides these specific asynchronous 118 00:05:38.560 --> 00:05:42.160 tools to give us safer managed ways to deal with threads, 119 00:05:42.360 --> 00:05:44.560 life cycle issues, and UI updates. 120 00:05:44.639 --> 00:05:47.360 That's the core idea. Instead of just dealing with raw 121 00:05:47.480 --> 00:05:50.040 JABA threads and hoping for the best, you use these 122 00:05:50.160 --> 00:05:53.560 higher level building blocks, which brings us neatly to the 123 00:05:53.560 --> 00:05:54.480 toolkit itself. 124 00:05:54.839 --> 00:05:58.000 Let's walk through that toolkit then, following the source. First 125 00:05:58.040 --> 00:05:59.759 up is the one everyone seems to know. Maybe the 126 00:05:59.800 --> 00:06:01.839 post child acinc tasks. 127 00:06:01.879 --> 00:06:05.120 Ah, Yes, good old acinc task introduce way back in 128 00:06:05.199 --> 00:06:08.000 API three, specifically to make it easier to do short 129 00:06:08.040 --> 00:06:11.000 background tasks and get results back to the UI. It's 130 00:06:11.079 --> 00:06:13.360 really a helper class for that common pattern, and. 131 00:06:13.360 --> 00:06:16.879 It uses that specific structure of callback methods right, each 132 00:06:17.000 --> 00:06:18.839 running on a particular thread. 133 00:06:18.920 --> 00:06:21.439 Correct, you've got on pre execute, which runs first on 134 00:06:21.480 --> 00:06:24.639 the main thread. Good for setting things up like showing 135 00:06:24.680 --> 00:06:28.639 a progress spinner. Then the main work course do in background. 136 00:06:28.639 --> 00:06:30.759 This runs on a background thread. This is where your 137 00:06:30.800 --> 00:06:33.959 slow operation goes, and critically, you cannot touch the UI 138 00:06:34.079 --> 00:06:35.360 directly from here. 139 00:06:35.319 --> 00:06:38.879 Right, But what if you need to show progress, like 140 00:06:38.959 --> 00:06:39.720 for a download. 141 00:06:39.920 --> 00:06:41.920 That's what published progress is for. You call it from 142 00:06:42.040 --> 00:06:45.160 inside do in background and that triggers it triggers on 143 00:06:45.240 --> 00:06:47.639 progress update, which runs back on the main thread, so 144 00:06:47.680 --> 00:06:50.519 you can safely update your progress bar or. 145 00:06:50.319 --> 00:06:53.240 A text view makes sense. And when do in background. 146 00:06:52.920 --> 00:06:55.879 Finishes, it returns a result which gets passed to on 147 00:06:56.000 --> 00:06:59.319 post execute, and on post execute also runs on the 148 00:06:59.319 --> 00:07:02.879 main thread, perfect for hiding the spinner showing the final data, 149 00:07:03.000 --> 00:07:03.839 updating the UI. 150 00:07:04.079 --> 00:07:06.480 And there's non canceled too if the task gets canceled 151 00:07:06.519 --> 00:07:07.240 before finishing. 152 00:07:07.480 --> 00:07:11.199 Yep, and a really key thing to remember. Each acing 153 00:07:11.240 --> 00:07:14.879 task object is single use. You create it, you execute 154 00:07:14.879 --> 00:07:16.959 it once, and that's it. You can't reuse it. 155 00:07:17.199 --> 00:07:20.800 Now. You mentioned earlier that how acing task runs tasks 156 00:07:20.839 --> 00:07:23.279 concurrently or one after another has changed over time. That 157 00:07:23.360 --> 00:07:24.800 sounds potentially confusing. 158 00:07:24.959 --> 00:07:27.199 Slight chuckle. Yeah, it's got a bit of a history. 159 00:07:27.680 --> 00:07:32.120 Originally API three it executed tasks serially, one at a time. 160 00:07:32.639 --> 00:07:35.600 Then in API four they switched it to run concurrently 161 00:07:36.079 --> 00:07:38.319 using a thread pool that could handle like up to 162 00:07:38.360 --> 00:07:40.040 one hundred and twenty eight tasks at once. 163 00:07:40.160 --> 00:07:41.600 Oh, that's a big change. 164 00:07:41.439 --> 00:07:45.399 Huge, and it caused problems because developers often implicitly relied 165 00:07:45.439 --> 00:07:49.120 on the old serial behavior. So from API eleven onwards 166 00:07:49.279 --> 00:07:52.560 they switched it back. The default execute method now runs 167 00:07:52.600 --> 00:07:53.839 tasks serially again. 168 00:07:54.000 --> 00:07:57.000 Okay, so the tricky period is really API four through ten, 169 00:07:57.120 --> 00:08:00.639 where just calling execute might give you unexpected concurrency. 170 00:08:00.759 --> 00:08:03.319 Exactly. That's the danger zone. If you need explicit control, 171 00:08:03.360 --> 00:08:05.759 you should use execute on executor. You can pass it 172 00:08:05.879 --> 00:08:08.839 acing task dop threadpool executor to get the concurrent behavior, 173 00:08:09.199 --> 00:08:13.199 or acing test serial executor to force serial execution regardless 174 00:08:13.199 --> 00:08:14.120 of the API level. 175 00:08:14.279 --> 00:08:17.560 So the advice is target API eleven or higher if 176 00:08:17.600 --> 00:08:20.399 you can test carefully on older versions, or maybe even 177 00:08:20.680 --> 00:08:23.759 reimplement it yourself if you need absolute consistency. 178 00:08:23.959 --> 00:08:26.040 Those are the main options. The source lays out. 179 00:08:26.120 --> 00:08:29.800 Yeah, okay, beyond the concurrency history, what are the other 180 00:08:30.040 --> 00:08:33.679 common traps with acing task? I feel like I've run 181 00:08:33.679 --> 00:08:36.000 into issues using them inside activities before. 182 00:08:36.200 --> 00:08:40.159 Ah. Yes, the activity life cycle strikes again. This is 183 00:08:40.200 --> 00:08:43.720 probably the most common pitfall. If you declare your acing 184 00:08:43.799 --> 00:08:47.240 task as a regular inner class or an anonymous inner 185 00:08:47.240 --> 00:08:49.759 class inside your activity. 186 00:08:49.279 --> 00:08:52.000 It automatically gets a reference to the activity instance. 187 00:08:51.720 --> 00:08:55.360 Right, precisely an implicit strong reference because it often needs 188 00:08:55.440 --> 00:08:57.720 to call activity methods or update views. 189 00:08:57.840 --> 00:08:59.759 But if the user rotates, the screen. 190 00:09:00.000 --> 00:09:02.639 System destroys the old activity and creates a new one. 191 00:09:02.679 --> 00:09:05.159 But your acing task might still be running in the background, 192 00:09:05.279 --> 00:09:08.720 holding onto that reference to the old destroyed activity. 193 00:09:08.320 --> 00:09:12.600 Preventing it from being garbage collected memory. Leak city population. 194 00:09:12.120 --> 00:09:15.440 You exactly leak city. So how do you fight that? Well? 195 00:09:15.440 --> 00:09:18.200 Can't you just call cancel on the acing task and 196 00:09:18.240 --> 00:09:19.840 the activities on destroy. 197 00:09:19.600 --> 00:09:22.639 Or something you definitely should call cancel, maybe an on 198 00:09:22.879 --> 00:09:25.720 pause or on destroy. It signals the task that it 199 00:09:25.720 --> 00:09:29.200 should stop on canceled gets called instead of on post execute. 200 00:09:29.480 --> 00:09:31.200 But cancel is just a request. 201 00:09:31.919 --> 00:09:34.720 It doesn't magically stop the doing background method. 202 00:09:35.039 --> 00:09:38.440 No, your code inside doing background needs to periodically check 203 00:09:38.480 --> 00:09:41.759 that is canceled flag and actually stop doing work if 204 00:09:41.759 --> 00:09:45.440 it's true. So cancelation helps, but it might not prevent 205 00:09:45.480 --> 00:09:47.519 the leak if the task takes a while to notice 206 00:09:47.559 --> 00:09:49.840 it's been canceled and the activity is already gone. 207 00:09:50.080 --> 00:09:53.799 Okay, So cancelation is good hygiene, but not a perfect 208 00:09:53.840 --> 00:09:57.080 leak prevention. What's the more robust solution? The book talks about. 209 00:09:56.960 --> 00:09:59.320 Using what's called a retained headless fragment. 210 00:09:59.639 --> 00:10:01.320 Okay, that sounds complicated. 211 00:10:01.440 --> 00:10:03.840 It sounds worse than it is. The idea is pretty neat. 212 00:10:03.840 --> 00:10:05.799 You create a fragment, but it doesn't have any UI, 213 00:10:05.960 --> 00:10:09.919 it's headless, and you call set retain instance true on it. 214 00:10:09.960 --> 00:10:11.360 What is set retain instance true. 215 00:10:11.480 --> 00:10:14.279 It tells the system when the activity is destroyed and 216 00:10:14.320 --> 00:10:18.279 recreated due to a configuration change like rotation, keep this 217 00:10:18.360 --> 00:10:21.720 fragment instance alive. Don't destroy and recreate it. 218 00:10:21.919 --> 00:10:26.679 Ah, so the fragment survives the rotation unlike the activity exactly. 219 00:10:26.919 --> 00:10:30.360 You host your assing task inside this retain fragment. The 220 00:10:30.399 --> 00:10:33.399 fragment can then hold onto the task safely. When the 221 00:10:33.440 --> 00:10:37.000 new activity instance is created, the fragment reattaches to it. 222 00:10:37.200 --> 00:10:39.440 And how does the fragment talk to the activity? Then? 223 00:10:39.799 --> 00:10:43.600 Typically using an interface? The activity implements the interface like 224 00:10:43.720 --> 00:10:47.159 task callbacks. The fragment gets a reference to the activity 225 00:10:47.200 --> 00:10:50.440 and it's on attached method checks if it implements the interface, 226 00:10:50.480 --> 00:10:53.360 and stores it, often as a weak reference just to 227 00:10:53.360 --> 00:10:57.080 be extra safe, though less critical here than with handlers. 228 00:10:57.600 --> 00:11:01.519 It detaches an on detach. The task running inside the 229 00:11:01.559 --> 00:11:04.559 fragment can then call back to the currently attached activity 230 00:11:04.639 --> 00:11:05.440 via the fragment. 231 00:11:05.679 --> 00:11:08.399 So the fragment acts like a stable, surviving container for 232 00:11:08.440 --> 00:11:11.679 the task, decoupling it from the activity's messy life cycle. 233 00:11:11.720 --> 00:11:15.360 Precisely. It's a much safer pattern for managing acing tasks 234 00:11:15.440 --> 00:11:18.080 tied to activities, and it's available in the support library, 235 00:11:18.120 --> 00:11:19.120 so it works way back. 236 00:11:19.320 --> 00:11:22.879 That's really clever. So bottom line for acing task. Good 237 00:11:22.960 --> 00:11:26.039 for simple short background jobs closely tied to the UI, 238 00:11:26.480 --> 00:11:29.559 especially needing progress updates. But watch out for leaks and 239 00:11:29.639 --> 00:11:31.639 use that retained fragment pattern if needed. 240 00:11:31.799 --> 00:11:35.919 Yep, that's a good summary. Now, moving deeper into the toolkit, 241 00:11:36.039 --> 00:11:39.639 the source introduces handler and handler thread. These are more 242 00:11:39.679 --> 00:11:43.240 like the fundamental building blocks. In fact, acinc task uses 243 00:11:43.320 --> 00:11:44.639 handlers under the hood. 244 00:11:44.879 --> 00:11:48.440 Okay, handlers, This involves the looper right, What exactly is 245 00:11:48.480 --> 00:11:48.879 a looper? 246 00:11:49.000 --> 00:11:51.600 A looper is basically a message loop for a thread. 247 00:11:52.000 --> 00:11:54.360 A thread associated with a leaper runs a loop that 248 00:11:54.399 --> 00:11:57.919 continuously checks a message queue. If there's a message or 249 00:11:57.960 --> 00:12:00.679 a task like a runnable in the quy you, the 250 00:12:00.720 --> 00:12:03.200 looper pulls it out and processes it. And the key 251 00:12:03.240 --> 00:12:05.559 thing is key thing is the main thread and Android 252 00:12:05.639 --> 00:12:08.080 already has a looper running on it. That's how it 253 00:12:08.120 --> 00:12:11.799 processes UI events, drawing updates and everything else. It's constantly 254 00:12:11.879 --> 00:12:13.039 checking its message queue. 255 00:12:13.120 --> 00:12:15.720 Okay, so the main thread is just a special thread 256 00:12:15.759 --> 00:12:18.159 that happens to have this built in message processing loop. 257 00:12:18.240 --> 00:12:20.440 You got it. And a handler is an object you 258 00:12:20.480 --> 00:12:23.799 create that's bound to a specific looper and therefore to 259 00:12:23.919 --> 00:12:25.240 that looper's thread. 260 00:12:25.080 --> 00:12:27.639 Bound to the looper, so bound to the thread essentially. 261 00:12:27.759 --> 00:12:30.639 Yes, The handler gives you a way to post tasks 262 00:12:30.679 --> 00:12:34.120 onto that specific threads message queue. You can call handler 263 00:12:34.120 --> 00:12:37.279 dot post runnable or handler dot send message message. 264 00:12:37.519 --> 00:12:39.720 Ah. So if I create a handler on the main 265 00:12:39.840 --> 00:12:43.320 thread which automatically binds it to the main threads looper, 266 00:12:44.080 --> 00:12:47.360 I can then pass that handler object to a background 267 00:12:47.360 --> 00:12:50.559 thread exactly, and the background thread can use it, say 268 00:12:50.600 --> 00:12:54.039 main thread handler dot post some runnable and some runnable 269 00:12:54.200 --> 00:12:56.759 will get added to the main threads queue and eventually 270 00:12:56.840 --> 00:12:57.720 run on the main thread. 271 00:12:57.840 --> 00:13:00.879 That's the core mechanism. It's the stamp way to get 272 00:13:00.919 --> 00:13:03.679 results or UI updates from a background thread back to 273 00:13:03.720 --> 00:13:07.000 the main thread safely. Your background thread does its calculation, 274 00:13:07.240 --> 00:13:10.240 then posts the runnable via the main thread handler to 275 00:13:10.360 --> 00:13:11.799 update a text view or. 276 00:13:11.759 --> 00:13:14.799 Whatever, and that explains methods like post delayed too just 277 00:13:14.840 --> 00:13:17.039 adds it to the queue to be run later right. 278 00:13:16.960 --> 00:13:19.279 Post delayed, post out time, post out front of queue. 279 00:13:19.360 --> 00:13:21.600 They all just manipulate how and when the task gets 280 00:13:21.639 --> 00:13:25.039 added to the target threads message queue and activity dot 281 00:13:25.120 --> 00:13:28.480 run on UI thread. Runnable is basically just a shortcut 282 00:13:28.559 --> 00:13:30.720 for getting a handler for the main thread and posting 283 00:13:30.759 --> 00:13:31.519 your runnable to it. 284 00:13:31.639 --> 00:13:34.000 What about sending message objects instead of runables? 285 00:13:34.399 --> 00:13:37.720 Messages are an alternative way to send work. They're often 286 00:13:37.799 --> 00:13:40.720 better if you need to pass structured data along with 287 00:13:40.799 --> 00:13:44.159 the request. A message object has fields like what, an 288 00:13:44.240 --> 00:13:47.159 integer code for the message type arge one, arch two, 289 00:13:47.279 --> 00:13:49.480 and objection for arbitrary data. 290 00:13:49.519 --> 00:13:51.519 So you define different message types. 291 00:13:51.240 --> 00:13:54.240 With what yeah, and then in your handler instead of 292 00:13:54.279 --> 00:13:58.960 just posting runnables, you override the handle message message msg method. 293 00:13:59.440 --> 00:14:02.480 Inside that method, you typically have a switch statement based 294 00:14:02.519 --> 00:14:05.120 on msg doob what to decide how to process different 295 00:14:05.159 --> 00:14:08.559 kinds of messages. The source also points out using message 296 00:14:08.600 --> 00:14:11.960 dot obtain to reuse message objects from a system pool, 297 00:14:11.960 --> 00:14:14.399 which is more efficient than creating new message every time. 298 00:14:14.519 --> 00:14:16.399 Okay, and handler thread? What's that for? 299 00:14:16.679 --> 00:14:19.679 Handler thread? Is just a convenience class provided by the SDK. 300 00:14:20.039 --> 00:14:23.519 It's basically a standard Java thread subclass that automatically sets 301 00:14:23.600 --> 00:14:25.240 up a looper on itself when it starts. 302 00:14:25.279 --> 00:14:27.480 Ah, so it gives you a ready made background thread 303 00:14:27.480 --> 00:14:29.679 that already has its own message Q and looper. 304 00:14:29.960 --> 00:14:32.720 Exactly. You start the handler thread, get its looper, create 305 00:14:32.720 --> 00:14:35.120 a handler bound to that looper, and now you have 306 00:14:35.200 --> 00:14:38.440 an easy way to post tasks to run sequentially on 307 00:14:38.480 --> 00:14:41.840 that specific background thread. It's really useful if you need 308 00:14:42.039 --> 00:14:44.639 a dedicated worker thread for a series of tasks like 309 00:14:44.720 --> 00:14:46.320 processing sensor data or something. 310 00:14:46.480 --> 00:14:50.200 Do handlers have the same memory leak problems as async 311 00:14:50.279 --> 00:14:52.879 tasks if you're not careful like using them as inner 312 00:14:52.879 --> 00:14:53.960 classes in inactivity? 313 00:14:54.000 --> 00:14:57.639 Oh? Absolutely, same exact problem. A non static inner handler 314 00:14:57.679 --> 00:15:01.440 class holds an implicit reference to the outer activity. If 315 00:15:01.480 --> 00:15:04.080 you post a delayed message or runnable to that handler 316 00:15:04.320 --> 00:15:07.639 and the activity gets destroyed before the message is processed. 317 00:15:07.240 --> 00:15:10.480 The handler and its pending message keep the old activity 318 00:15:10.480 --> 00:15:12.120 alive leak yep. 319 00:15:12.840 --> 00:15:16.279 So the solution is identical. Make your handler subclass static 320 00:15:16.559 --> 00:15:18.480 if it needs to talk back to the activity or 321 00:15:18.519 --> 00:15:21.759 its views, pass the activity context to it, and store 322 00:15:21.759 --> 00:15:22.759 it in a weak reference. 323 00:15:22.919 --> 00:15:25.480 Use weak reference so the garbage collector can still reclaim 324 00:15:25.480 --> 00:15:27.120 the activity if nothing else holds. 325 00:15:26.919 --> 00:15:30.679 It strongly exactly, and typically you'd have methods like attach 326 00:15:30.799 --> 00:15:34.759 activity and detach in your static handler class to set 327 00:15:34.799 --> 00:15:37.440 and clear that weak reference as the activity comes and 328 00:15:37.480 --> 00:15:39.320 goes standard safe pattern. 329 00:15:39.799 --> 00:15:43.840 Okay, So handlers and handler threads offer more fundamental control 330 00:15:43.919 --> 00:15:47.320 over threading and message passing. Good for when async task 331 00:15:47.399 --> 00:15:50.159 is too simple where you need fine grain control or 332 00:15:50.159 --> 00:15:52.039 communication between arbitrary threads. 333 00:15:52.120 --> 00:15:54.960 That's a great way to put it. More control, more flexibility, 334 00:15:54.960 --> 00:15:58.000 but also requires a bit more care with life cycle management. 335 00:15:58.120 --> 00:16:00.960 All right, Moving on in the toolkit. The next major 336 00:16:01.000 --> 00:16:04.360 piece the source covers is the loader framework. This sounds 337 00:16:04.360 --> 00:16:06.679 specifically data oriented. 338 00:16:06.279 --> 00:16:10.320 It absolutely is. Loaders are designed primarily for asynchronously loading 339 00:16:10.399 --> 00:16:13.080 data that's going to be displayed in UI components, especially 340 00:16:13.159 --> 00:16:15.440 things like list views or recycler views. 341 00:16:15.519 --> 00:16:19.480 Asynchronously loading data. Okay, well, what's their killer feature? Why 342 00:16:19.559 --> 00:16:21.600 use them over, say, an async task? 343 00:16:21.960 --> 00:16:24.840 Their main advantage is how they integrate with the activity 344 00:16:24.879 --> 00:16:29.240 and fragment life cycle. They automatically handle things like configuration changes, 345 00:16:29.559 --> 00:16:34.320 screen rotations, and can efficiently cache data and deliver updates 346 00:16:34.360 --> 00:16:37.159 without you having to manually manage all the state restoration. 347 00:16:37.639 --> 00:16:41.519 Ah. So they solve that reload data on rotation problem. 348 00:16:41.559 --> 00:16:44.279 That they do it beautifully. The core component is the 349 00:16:44.320 --> 00:16:46.480 loader manager. You get an instance of it from your 350 00:16:46.519 --> 00:16:50.559 activity or fragment. The loader manager is responsible for managing 351 00:16:50.559 --> 00:16:52.519 the life cycle of your loader. 352 00:16:52.279 --> 00:16:54.440 Instances and how do you interact with it. 353 00:16:54.639 --> 00:16:58.759 Your activity or fragment implements an interface called loadermanager dot 354 00:16:58.799 --> 00:17:02.120 loader callbacks. This has three methods you need to implement. 355 00:17:02.200 --> 00:17:03.000 Okay, what are they? 356 00:17:03.080 --> 00:17:05.599 First is on create loader. This is called by the 357 00:17:05.680 --> 00:17:08.880 loader manager when you initialize a loader using in it 358 00:17:08.920 --> 00:17:11.920 loader or restart loader. Your job here is just to 359 00:17:11.960 --> 00:17:14.519 create and return the specific loader instance you. 360 00:17:14.480 --> 00:17:17.000 Need, like a loader for database queries or maybe a 361 00:17:17.039 --> 00:17:18.519 custom one exactly. 362 00:17:18.960 --> 00:17:22.119 The second callback is onload finish. This is the important one. 363 00:17:22.599 --> 00:17:24.880 It gets called on the main thread when the loader 364 00:17:24.880 --> 00:17:28.680 has successfully finished loading its data. You receive that a 365 00:17:28.759 --> 00:17:32.319 here and update your UI like populating an adapter. And 366 00:17:32.400 --> 00:17:35.920 a third onloader reset This gets called when the loader 367 00:17:35.960 --> 00:17:38.839 is being destroyed or reset. Your job here is to 368 00:17:38.880 --> 00:17:41.400 clear out any references you might be holding to the 369 00:17:41.440 --> 00:17:44.720 loader's data, so it can be garbage collected, for example 370 00:17:44.799 --> 00:17:47.480 telling your adapter that the data is no longer valid. 371 00:17:47.880 --> 00:17:50.920 So the loader manager orchestrates the loading, caching, and life 372 00:17:50.920 --> 00:17:54.759 cycle awareness, and your activity fragment just plugs into these 373 00:17:54.799 --> 00:17:56.279 specific life cycle points. 374 00:17:56.640 --> 00:17:59.079 That's the idea. It abstracts away a lot of the 375 00:17:59.079 --> 00:18:01.839 tricky life cycle management. If you need to create your 376 00:18:01.880 --> 00:18:05.160 own custom loader. Acing taskloader is a common base. 377 00:18:04.920 --> 00:18:08.119 Class to use ACM taskloader, so it uses acing tasks 378 00:18:08.240 --> 00:18:09.079 in charge does. 379 00:18:09.359 --> 00:18:12.359 It provides the basic structure you implement the loading background method. 380 00:18:12.440 --> 00:18:14.960 That's where your actual data loading happens off the main thread. 381 00:18:15.319 --> 00:18:18.759 The framework handles delivering the result via onload finished. It 382 00:18:18.799 --> 00:18:22.000 also manages things like caching the result and only reloading 383 00:18:22.039 --> 00:18:23.759 if the underlying data has changed. 384 00:18:24.039 --> 00:18:26.839 The book gives an example. Right a thumbnail loader. 385 00:18:26.720 --> 00:18:31.400 Yes, loading a bitmap thumbnail Loading background does the slow 386 00:18:31.480 --> 00:18:35.599 work of decoding the image. Onload finished gets the bitmap 387 00:18:35.680 --> 00:18:38.440 back on the main thread to display it. On start 388 00:18:38.440 --> 00:18:41.559 loading checks if a cached version exists before starting the 389 00:18:41.599 --> 00:18:44.599 load on reset would be where you might recycle the 390 00:18:44.640 --> 00:18:46.480 bitmap if needed, and. 391 00:18:46.440 --> 00:18:49.200 You kick things off using loadermanager dot in it loader 392 00:18:49.799 --> 00:18:52.720 with some unique ID for each loader correct. 393 00:18:52.599 --> 00:18:56.440 That ID links the netloader call to your specific implementation 394 00:18:56.599 --> 00:18:57.680 of the loader callbacks. 395 00:18:57.759 --> 00:18:59.799 What about cursor loader That seems like a really common 396 00:18:59.839 --> 00:19:00.160 one one. 397 00:19:00.279 --> 00:19:04.599 It's a specialized subclass of acyink taskloader designed specifically for 398 00:19:04.759 --> 00:19:09.599 querying content providers, thin contacts, calendar data, or very commonly 399 00:19:09.839 --> 00:19:12.319 the Media Store for images, music, et cetera. 400 00:19:12.759 --> 00:19:15.960 So it handles queerying a database via a content provider. 401 00:19:16.079 --> 00:19:19.200