WEBVTT 1 00:00:00.080 --> 00:00:02.359 Welcome to the Depth Dive, where we take a stack 2 00:00:02.399 --> 00:00:06.040 of information and really extract the most important nuggets of 3 00:00:06.080 --> 00:00:09.919 knowledge and insight tailored just for you. Today, we're doing 4 00:00:09.960 --> 00:00:13.080 something a little different. It's like a fascinating TimewARP. We're 5 00:00:13.119 --> 00:00:17.000 diving into the Android Application Development Cookbook, second edition, which, 6 00:00:17.320 --> 00:00:19.640 believe it or not, was published way back in March 7 00:00:19.679 --> 00:00:23.079 twenty sixteen. Our mission here is basically to give you 8 00:00:23.120 --> 00:00:26.480 a shortcut, a shortcut to understanding what Android app development 9 00:00:26.519 --> 00:00:29.839 looked like, you know, nearly a decade ago. We'll uncover 10 00:00:29.920 --> 00:00:33.880 the core ideas, some practical recipes for problems developers face then, 11 00:00:34.000 --> 00:00:36.039 and maybe some surprising things that we're cutting edge and 12 00:00:36.079 --> 00:00:38.880 see how much or maybe how little things have really changed. 13 00:00:39.359 --> 00:00:42.439 Our main source is that cookbook by Rick Boyer and 14 00:00:42.520 --> 00:00:45.560 Kyle mu It's very much designed for developers who learn 15 00:00:45.759 --> 00:00:48.560 by doing a by jumping into code. It's literally broken 16 00:00:48.600 --> 00:00:51.600 down into these recipes with sections like getting ready, how 17 00:00:51.600 --> 00:00:53.960 to do it, how it works. So let's imagine you're 18 00:00:54.000 --> 00:00:56.280 an Android dep back in twenty sixteen, staring at a 19 00:00:56.280 --> 00:00:59.280 blank screen. What were the absolute first things you'd write? 20 00:00:59.439 --> 00:01:00.920 What were those fundamental building block? 21 00:01:01.000 --> 00:01:03.799 Yeah, it's really interesting looking back, what's fascinating is how 22 00:01:04.120 --> 00:01:07.760 clearly the book lays out these core components that honestly 23 00:01:08.120 --> 00:01:11.319 are still pretty foundational today, even of how we implement 24 00:01:11.319 --> 00:01:14.640 them has evolved quite a bit. The absolute bedrock for 25 00:01:14.680 --> 00:01:17.719 almost any Android app then, and you could argue still now, 26 00:01:17.959 --> 00:01:21.760 were activity activities. Right, Think of an activity as like 27 00:01:22.120 --> 00:01:25.200 a single screen in your app, or a distinct user 28 00:01:25.200 --> 00:01:28.719 interface view every single screen, your main menu settings, a 29 00:01:28.719 --> 00:01:31.640 photo viewer that would typically be its own activity, and 30 00:01:31.680 --> 00:01:35.359 these were all declared in that central file, the Android 31 00:01:35.359 --> 00:01:36.480 Manifest dot XML. 32 00:01:36.680 --> 00:01:39.120 Ah, the manifest okay exactly. 33 00:01:39.120 --> 00:01:42.719 And crucially specific things called intent filters in there, like 34 00:01:42.799 --> 00:01:45.959 main and launcher. They told the system which activity was 35 00:01:45.959 --> 00:01:47.920 the main entry point, you know, the one that gets 36 00:01:47.920 --> 00:01:49.519 the icon on your phone's home screen. 37 00:01:49.640 --> 00:01:52.560 Okay, So activities are like the individual rooms in a house, 38 00:01:52.599 --> 00:01:55.280 and the Manifest is the blueprint saying this room is 39 00:01:55.319 --> 00:01:58.079 the front door. Got it? But how did these rooms 40 00:01:58.079 --> 00:02:00.439 talk to each other inside the same app, or even 41 00:02:00.560 --> 00:02:02.480 like talking to other apps on the phone. 42 00:02:02.599 --> 00:02:07.040 That's where the incredibly powerful intent object came in. It's 43 00:02:07.120 --> 00:02:09.199 essentially a message object. Think of it as a way 44 00:02:09.199 --> 00:02:11.840 to say I want to do something, Yeah, but without 45 00:02:11.879 --> 00:02:14.800 needing to know exactly who we'll do it. So, for example, 46 00:02:14.879 --> 00:02:17.639 you could use intents dot action view. You tell the system, hey, 47 00:02:17.639 --> 00:02:21.680 I want to view this capacity URL maybe huh, and 48 00:02:21.680 --> 00:02:24.560 Android would figure out okay, the default web browser should 49 00:02:24.599 --> 00:02:26.319 handle this and launch it for you. 50 00:02:26.560 --> 00:02:28.800 Right, So the app doesn't need to know which browser 51 00:02:28.879 --> 00:02:30.759 the user has installed exactly. 52 00:02:30.919 --> 00:02:33.840 And what was really clever and still is is that 53 00:02:33.879 --> 00:02:36.560 different types of data could launch completely different apps. A 54 00:02:36.639 --> 00:02:39.360 location might open a map app, a contact file might 55 00:02:39.400 --> 00:02:42.120 open the contact app. It showed how flexible the system 56 00:02:42.199 --> 00:02:45.639 was letting apps work together without hard coding dependencies. 57 00:02:45.840 --> 00:02:49.520 That's huge, that interoperability. Okay, so that's talking between apps. 58 00:02:49.879 --> 00:02:53.039 What about just moving between screens inside your own appic 59 00:02:53.319 --> 00:02:55.159 from a list to a detail screen. 60 00:02:55.360 --> 00:02:59.800 Intents handle that too. You just create an intent specifying 61 00:02:59.840 --> 00:03:03.080 the target activity, say moving from your main activity to 62 00:03:03.240 --> 00:03:05.879 a second activity. As simple as that, And if you 63 00:03:05.919 --> 00:03:09.199 needed to send some information along, you'd use put extra. 64 00:03:10.080 --> 00:03:13.479 It worked with name value pairs, like packing little bits 65 00:03:13.479 --> 00:03:14.960 of data into the intent. 66 00:03:14.919 --> 00:03:17.199 Like sticking a post it note on the message. 67 00:03:16.840 --> 00:03:18.879 Pretty much yeah, exactly like a post it and the 68 00:03:19.000 --> 00:03:22.639 receiving activity would just grab that data using methods like 69 00:03:23.000 --> 00:03:25.199 get string extra looking for the name you give it. 70 00:03:25.280 --> 00:03:27.960 Okay, And what if you needed to get something back 71 00:03:28.000 --> 00:03:31.360 from that second screen. Let's say you launched a contact 72 00:03:31.360 --> 00:03:34.800 picker and you need the phone number the user picked. 73 00:03:34.639 --> 00:03:37.879 Ah, right, for that, you wouldn't just start the activity. 74 00:03:37.919 --> 00:03:40.840 You'd use start activity for results the result makes sense, 75 00:03:41.360 --> 00:03:44.199 and the result would come back to the original activity 76 00:03:44.520 --> 00:03:49.120 in a special callback method on activity results. And for 77 00:03:49.360 --> 00:03:53.080 apps doing lots of this, maybe calling different activities for results, 78 00:03:53.360 --> 00:03:55.840 there was something called a request code. There's a number 79 00:03:55.879 --> 00:03:58.080 you defined when you started the activity, so that when 80 00:03:58.159 --> 00:04:00.800 on activity result was called, you could check that code 81 00:04:01.000 --> 00:04:05.479 and know which request was returing its result. Kept things organized, right, 82 00:04:05.599 --> 00:04:08.080 because the mobile world is just so dynamic, isn't it. 83 00:04:08.120 --> 00:04:10.199 You're in an app, a phone call comes in, you 84 00:04:10.240 --> 00:04:13.439 switch to another app, The system might even kill your 85 00:04:13.439 --> 00:04:15.680 app in the background, off the needs memory. It feels 86 00:04:15.680 --> 00:04:18.839 like a constant battle with the OS. So what did 87 00:04:18.839 --> 00:04:20.759 this all mean for a developer trying to make an 88 00:04:20.800 --> 00:04:24.720 app feel smooth and seamless even with all those interruptions. 89 00:04:24.839 --> 00:04:28.000 That's the million dollar question really, and connecting this to 90 00:04:28.040 --> 00:04:30.839 the bigger picture, understanding the activity life cycle was just 91 00:04:30.959 --> 00:04:35.920 absolutely critical paramount for app stability user experience, especially back 92 00:04:35.959 --> 00:04:38.720 then on devices that maybe didn't have tons of memory. 93 00:04:39.040 --> 00:04:43.000 Think about this, just rotating your phone. Yeah, by default, 94 00:04:43.079 --> 00:04:46.160 Android would completely destroy your current activity and then recreate 95 00:04:46.160 --> 00:04:46.839 it from a scratch. 96 00:04:46.879 --> 00:04:48.600 Wait, destroy it just for rotating? 97 00:04:48.680 --> 00:04:51.720 Yeah, destroy and recreate, which, as you can imagine, could 98 00:04:51.759 --> 00:04:54.000 lead to a really terrible user experience if you weren't 99 00:04:54.000 --> 00:04:57.639 ready for it. All the user's input gone, the scroll 100 00:04:57.639 --> 00:04:58.720 position lost. 101 00:04:58.920 --> 00:05:01.839 Wow. Okay, so how did developers handle that? That's where 102 00:05:01.839 --> 00:05:04.720 these life cycle callback methods were vital, Things like on 103 00:05:04.800 --> 00:05:08.399 save instance state and on restore instance. On save instance 104 00:05:08.519 --> 00:05:10.759 date gave you a chance right before the activity was 105 00:05:10.800 --> 00:05:14.519 potentially destroyed to save small bits of data like user 106 00:05:14.519 --> 00:05:17.800 input or UI state okay, And then if the activity 107 00:05:17.879 --> 00:05:21.360 was recreated on restore instance state or on create what 108 00:05:21.399 --> 00:05:23.680 would be called and you could get that save data 109 00:05:23.720 --> 00:05:25.800 back and restore the state so the user could just 110 00:05:25.800 --> 00:05:26.920 pick up where they left off. 111 00:05:27.079 --> 00:05:29.639 So you had to manually save and restore anything important 112 00:05:29.639 --> 00:05:31.959 every time a configuration might change, like rotation. 113 00:05:32.279 --> 00:05:32.800 Pretty much. 114 00:05:32.920 --> 00:05:33.199 Yes. 115 00:05:33.560 --> 00:05:38.720 The book details the core life cycle states active, pause, stopped, destroyed, 116 00:05:39.079 --> 00:05:42.120 and the methods tied to them. On create on resume, 117 00:05:42.720 --> 00:05:46.879 on pause, on stop, on destroy. The US was described 118 00:05:46.920 --> 00:05:50.160 as ruthless with resource management. If your app went into 119 00:05:50.199 --> 00:05:52.360 the pause or stop state, it was fair game for 120 00:05:52.399 --> 00:05:54.160 the OS to kill it to reclaim memory. 121 00:05:54.319 --> 00:05:56.439 That sounds like a lot of manual work and potential 122 00:05:56.480 --> 00:05:57.000 for bugs. 123 00:05:57.279 --> 00:06:01.279 It absolutely was a major source of frustration. Bilbote's got 124 00:06:01.279 --> 00:06:05.079 to be really careful about calling the superclass methods, understanding 125 00:06:05.120 --> 00:06:08.079 when each callback fired what they could safely do in 126 00:06:08.120 --> 00:06:11.120 each one. It's honestly one of the main reasons modern 127 00:06:11.160 --> 00:06:14.120 Android development shifted towards things like view model from the 128 00:06:14.199 --> 00:06:15.720 architecture components. 129 00:06:15.480 --> 00:06:19.079 Right to abstract away some of that life cycle complexity exactly. 130 00:06:19.399 --> 00:06:24.199 View models survive configuration changes like rotation, automatically holding UI 131 00:06:24.319 --> 00:06:27.240 related data without you needing to manually save and restore 132 00:06:27.240 --> 00:06:31.160 it in the activity nearly as much. It simplified things massively. 133 00:06:31.399 --> 00:06:33.959 Okay, so we've got the basic structure with activities and 134 00:06:34.000 --> 00:06:36.759 intents and a sense of the constant dance with the 135 00:06:36.759 --> 00:06:40.600 OS life cycle. But an app is nothing without its interface. 136 00:06:41.040 --> 00:06:44.040 This is where it gets really interesting, right, optimizing what 137 00:06:44.120 --> 00:06:47.560 the user actually sees and interacts with. It's not just 138 00:06:47.560 --> 00:06:49.560 what you put on screen, but how you put. 139 00:06:49.360 --> 00:06:52.800 It there absolutely, and that raises the question, how do 140 00:06:52.879 --> 00:06:56.879 you build a complex, good looking UI that still performs well, 141 00:06:57.160 --> 00:07:00.360 especially considering the huge variety of Android devices out there. 142 00:07:00.399 --> 00:07:03.959 Even back then, the techniques in the cookbook, even from 143 00:07:03.959 --> 00:07:08.199 twenty sixteen, really emphasize that performance starts with design, and 144 00:07:08.240 --> 00:07:11.160 the foundation of UI design was layouts and view. 145 00:07:10.959 --> 00:07:13.560 Groups w groups. That's like a container precisely. 146 00:07:13.600 --> 00:07:16.240 A view group is the base class for containers, and 147 00:07:16.360 --> 00:07:19.120 layout classes, which inherit from view group, are what you 148 00:07:19.199 --> 00:07:22.319 use to actually organize the UI elements, the buttons, the 149 00:07:22.360 --> 00:07:25.160 text fields, the images. They define the structure. 150 00:07:25.480 --> 00:07:28.399 What were the main layout types developers were using back then? 151 00:07:28.800 --> 00:07:32.600 The book covers several key ones. Relative layout was really powerful. 152 00:07:32.720 --> 00:07:35.279 It let you position views relative to each other or 153 00:07:35.360 --> 00:07:37.680 relative to the parent container. You could say, this button 154 00:07:37.720 --> 00:07:39.920 goes to the right of that text view or center 155 00:07:40.000 --> 00:07:43.720 this image. Very flexible for complex screens. Okay, yeah, Linear 156 00:07:43.800 --> 00:07:47.360 layout much simpler. It just arranged views one after another, 157 00:07:47.560 --> 00:07:50.360 either vertically in a column or horizontally in a row. 158 00:07:50.439 --> 00:07:53.199 Simple but probably useful, very and. 159 00:07:53.120 --> 00:07:56.800 Its key feature was layout weight. This allowed views within 160 00:07:56.839 --> 00:08:00.199 the linear layout to take up proportional space. Like one 161 00:08:00.199 --> 00:08:02.399 element takes seventy percent of the width, the other takes 162 00:08:02.480 --> 00:08:05.480 thirty percent. Super useful for dividing space. 163 00:08:05.319 --> 00:08:08.639 Dynamically right and for grids like a calculator or a 164 00:08:08.639 --> 00:08:09.439 photo gallery. 165 00:08:09.680 --> 00:08:12.839 For grid like structures, there was table layout and grid layout. 166 00:08:12.920 --> 00:08:16.079 They approached it slightly differently how they defined rows and columns, 167 00:08:16.480 --> 00:08:19.279 but both serve that purpose. And of course you could 168 00:08:19.279 --> 00:08:22.079 nest these layouts, put a linear layout inside a relative 169 00:08:22.160 --> 00:08:26.160 layout inside another linear layout. That's how you built up 170 00:08:26.199 --> 00:08:28.480 really complex UI hierarchies. 171 00:08:28.519 --> 00:08:31.040 But nesting sounds like it could get complicated fast and 172 00:08:31.160 --> 00:08:34.039 maybe slow things down. Were there tools to help optimize 173 00:08:34.039 --> 00:08:34.679 these layouts? 174 00:08:34.720 --> 00:08:38.480 You bet? Performance was definitely a concern. The cookbook highlights 175 00:08:38.519 --> 00:08:40.679 a couple of essential tools from that era. First, the 176 00:08:40.759 --> 00:08:43.480 hierarchy Viewer hierarchy veer. Yeah, there's a tool that let 177 00:08:43.519 --> 00:08:46.200 you visually inspect your layout structure as a tree. You 178 00:08:46.200 --> 00:08:49.600 could see how deeply nested things were, identify redundant layouts. 179 00:08:49.960 --> 00:08:53.000 Super useful for fine bottlenecks. The catch was, back then 180 00:08:53.039 --> 00:08:55.480 it usually required a rooted device or an emulator to 181 00:08:55.559 --> 00:08:55.840 use it. 182 00:08:56.240 --> 00:08:58.000 Ah, okay, bit of a hurdle. 183 00:08:57.759 --> 00:09:00.679 A bit, yeah, But then there was lint. Lint was 184 00:09:00.799 --> 00:09:04.519 and still is part of the Android SDK integrated into 185 00:09:04.600 --> 00:09:08.279 Android Studio. Think of it as like a static code analyzer, 186 00:09:08.480 --> 00:09:10.200 but specifically for androids. 187 00:09:09.879 --> 00:09:12.080 So it would warn you about problems exactly. 188 00:09:12.120 --> 00:09:16.320 It would flag potential layout issues automatically, things like deep layouts, 189 00:09:16.320 --> 00:09:19.399 warning you if your view hierarchy was nested too many 190 00:09:19.480 --> 00:09:24.000 levels deep which killed performance, or nested weights in linear layouts, 191 00:09:24.120 --> 00:09:28.279 another notorious performance trap. It also flagged things like useless 192 00:09:28.320 --> 00:09:32.000 parent layouts or useless leaf views that weren't contributing anything 193 00:09:32.519 --> 00:09:34.240 really helpful for keeping UIs lean. 194 00:09:34.480 --> 00:09:35.879 And what if you had a part of the UI 195 00:09:35.960 --> 00:09:39.159 that was complex but maybe wasn't used very often, like 196 00:09:39.200 --> 00:09:41.720 a detailed error message panel. Was there a way to 197 00:09:41.799 --> 00:09:43.200 avoid loading that all the time? 198 00:09:43.320 --> 00:09:45.639 Yes, that's where view stub came in. It was described 199 00:09:45.639 --> 00:09:48.840 as a lazy load mechanism. Basically, it was a placeholder 200 00:09:48.879 --> 00:09:51.679 in your layout. This very lightweight took up almost no 201 00:09:51.840 --> 00:09:55.279 memory or inflation time initially only when you explicitly told 202 00:09:55.320 --> 00:09:57.960 the view stub to inflate, usually in your code, when 203 00:09:58.000 --> 00:10:01.200 that specific UI was actually needed. Would it load the 204 00:10:01.240 --> 00:10:05.159 real more complex layout it was referencing great for reducing 205 00:10:05.240 --> 00:10:08.639 initial screen load time and memory usage for rarely seeing 206 00:10:08.720 --> 00:10:10.080 UI components clever. 207 00:10:10.240 --> 00:10:13.279 Okay, so that's the structure. What about the actual things 208 00:10:13.320 --> 00:10:15.600 the user sees and taps on? The widgets? 209 00:10:15.759 --> 00:10:18.399 Right, the views and widgets. The book mentions all the 210 00:10:18.440 --> 00:10:22.240 common built in ones you'd expect text view for text, button, checkbox, 211 00:10:22.440 --> 00:10:26.639 even things like clock, date, picker, calendar, A whole toolbox 212 00:10:26.679 --> 00:10:28.480 of standard UI elements. 213 00:10:28.080 --> 00:10:30.440 But could you make your own if the standard ones 214 00:10:30.440 --> 00:10:31.000 weren't enough. 215 00:10:31.399 --> 00:10:35.519 Absolutely, customization was key. You could extend an existing widget 216 00:10:35.519 --> 00:10:38.720 to add functionality, or you could create a totally custom 217 00:10:38.799 --> 00:10:41.879 view from scratch by extending the base view class. Doing 218 00:10:41.919 --> 00:10:43.840 that often meant you had to get your hands dirty 219 00:10:43.879 --> 00:10:46.919 overwriting methods like on measure to tell Android how big 220 00:10:46.960 --> 00:10:49.399 your custom view should be, and on draw to actually 221 00:10:49.480 --> 00:10:51.759 draw its appearance on the screen. Using the canvas. 222 00:10:51.480 --> 00:10:54.279 API sounds like more work, but powerful. 223 00:10:54.600 --> 00:10:58.320 Definitely more work, but it gave you complete control. Another 224 00:10:58.320 --> 00:11:02.080 common technique mentioned was creating compound controls. This just meant 225 00:11:02.120 --> 00:11:06.120 grouping several existing controls together into a single reusable component, 226 00:11:06.519 --> 00:11:09.320 like creating a custom search bar widget made up of 227 00:11:09.360 --> 00:11:10.480 a text view and a button. 228 00:11:10.679 --> 00:11:13.279 Okay, so you build a layout, put the widgets in, 229 00:11:13.759 --> 00:11:17.159 but then you need consistent styling, right colors, font sizes. 230 00:11:17.399 --> 00:11:18.240 How is that handled? 231 00:11:18.320 --> 00:11:20.919 That's where styles and themes came in. They were crucial 232 00:11:20.960 --> 00:11:25.000 for maintainability and achieving a consistent look and feel. Styles 233 00:11:25.000 --> 00:11:27.919 were defined in an XML file, usually styles dot XML. 234 00:11:28.320 --> 00:11:31.279 A style was basically a collection of attributes like android 235 00:11:31.279 --> 00:11:34.600 dot layout with android dot background, android dot text color, 236 00:11:34.919 --> 00:11:38.120 android dot text size. You could define a style once 237 00:11:38.320 --> 00:11:40.919 like a CSS class, exactly like a CSS class to 238 00:11:41.000 --> 00:11:45.080 define it once, then apply that style to multiple views button, textview, etc. 239 00:11:45.399 --> 00:11:47.039 In your layouts. So if you needed to change the 240 00:11:47.080 --> 00:11:49.480 standard button color across your app, you just changed it 241 00:11:49.519 --> 00:11:52.039 in the style definition, not on every single button. 242 00:11:52.240 --> 00:11:54.480 Much cleaner in themes, How are they different? 243 00:11:54.759 --> 00:11:57.919 Themes were broader. They applied to an entire activity or 244 00:11:57.960 --> 00:12:02.200 even the whole application, rather than individual views. Themes affected 245 00:12:02.200 --> 00:12:05.679 things like the default appearance of standard widgets or window 246 00:12:05.720 --> 00:12:08.679 attributes like the status bar color, or whether the activity 247 00:12:08.720 --> 00:12:11.120 had a title bar or an action bar. You could 248 00:12:11.159 --> 00:12:13.039 even use a theme to make an activity look like 249 00:12:13.080 --> 00:12:14.960 a floating dialogue box, for instance. 250 00:12:15.200 --> 00:12:17.679 And dealing with different Android versions was a big thing 251 00:12:17.720 --> 00:12:21.039 back then, right with Holo themes the material design coming in. 252 00:12:21.120 --> 00:12:22.240 How did themes handle that? 253 00:12:22.559 --> 00:12:25.799 Yeah, that was a major challenge, the fragmentation. The book 254 00:12:25.799 --> 00:12:30.080 explains how developers used resource qualifiers. You could define different 255 00:12:30.080 --> 00:12:33.759 theme versions and folders like values v eleven for Android 256 00:12:33.799 --> 00:12:37.080 three point zero Honeycomb which introduced the Holo theme, or 257 00:12:37.440 --> 00:12:40.559 values v twenty one for Android five point Oho Lollipop 258 00:12:40.759 --> 00:12:41.759 with material design. 259 00:12:41.919 --> 00:12:44.360 Ah, so the system would automatically pick the right one 260 00:12:44.480 --> 00:12:46.200 based on the device's Android version. 261 00:12:46.559 --> 00:12:50.559 Correct, the system handles selecting the most appropriate resources. But 262 00:12:50.639 --> 00:12:54.279 even more importantly, the app compat library was absolutely essential. 263 00:12:54.480 --> 00:12:58.080 It was a support library from Google that backpoorded newer 264 00:12:58.200 --> 00:13:01.159 UI elements and theme features like the action bar and 265 00:13:01.240 --> 00:13:04.799 material design components to older Android. 266 00:13:04.399 --> 00:13:08.000 Versions, so you could use newer features without dropping support 267 00:13:08.039 --> 00:13:09.639 for older phones exactly. 268 00:13:10.200 --> 00:13:13.320 App Compat was a lifeline for developers trying to provide 269 00:13:13.720 --> 00:13:18.679 a reasonably consistent and modern looking UI across that fragmented landscape. 270 00:13:18.720 --> 00:13:20.679 It smoothed over a lot of the version differences. 271 00:13:20.799 --> 00:13:24.039 Okay, so building on that, the app looks good, it's structured, well, 272 00:13:24.360 --> 00:13:26.399 now it needs to actually respond to the user in 273 00:13:26.480 --> 00:13:30.279 smart ways, provide feedback guide them. What were the standard 274 00:13:30.279 --> 00:13:32.759 ways to handle interaction like menus and alerts. 275 00:13:32.919 --> 00:13:35.600 Right. This is where the user experience really starts to 276 00:13:35.600 --> 00:13:39.440 take shape, making the app feel interactive and intuitive. The 277 00:13:39.480 --> 00:13:43.080 cookbook dies into several key areas here, starting with menu systems. 278 00:13:43.360 --> 00:13:46.440 Menus were and still are a fundamental way to provide 279 00:13:46.480 --> 00:13:47.919 options and actions to the user. 280 00:13:48.080 --> 00:13:50.200 What were the main kinds of menus available back in 281 00:13:50.240 --> 00:13:51.720 twenty sixteen, Well, the main. 282 00:13:51.600 --> 00:13:54.720 One was the options menu. That's the standard menu, typically 283 00:13:54.759 --> 00:13:56.639 appearing in the action bar at the top of the screen. 284 00:13:57.240 --> 00:13:59.960 If there wasn't enough space, items would go into that 285 00:14:00.039 --> 00:14:01.720 familiar three dot overflow menu. 286 00:14:01.799 --> 00:14:03.000 Okay, the standard stuff. 287 00:14:03.120 --> 00:14:07.600 Yeah. Developers used XML attributes like show as action to 288 00:14:07.639 --> 00:14:10.159 suggest whether an item should appear directly in the bar 289 00:14:10.480 --> 00:14:13.720 bedroom or always being the overflow never. Then there was 290 00:14:13.799 --> 00:14:18.480 contextual mode or Contextual Action Mode CM. This was seen 291 00:14:18.480 --> 00:14:21.600 as a big improvement introduced around Android three point zero. 292 00:14:22.000 --> 00:14:24.159 You typically trigger it with a long press on an 293 00:14:24.200 --> 00:14:27.200 item like a list item or some text. 294 00:14:27.039 --> 00:14:28.720 Ah like a right click on desktop. 295 00:14:28.840 --> 00:14:31.080 Exactly like a right click, it would bring up a 296 00:14:31.080 --> 00:14:33.799 temporary action bar at the top with action specific to 297 00:14:33.840 --> 00:14:37.240 the item or items you selected. It supported selecting multiple 298 00:14:37.240 --> 00:14:41.200 items too, for batch actions. Like deleting multiple emails. Way 299 00:14:41.240 --> 00:14:43.279 better than the older floating context menus. 300 00:14:43.320 --> 00:14:45.679 Okay, that sounds useful any other menu types. 301 00:14:45.879 --> 00:14:48.799 There was also the pop up menu. This was simpler, 302 00:14:48.879 --> 00:14:51.320 just a little menu that pops up, often anchored to 303 00:14:51.360 --> 00:14:55.519 a specific view, providing some extra actions. It wasn't necessarily 304 00:14:55.559 --> 00:14:57.960 tied to acting on the view that triggered it, more 305 00:14:58.039 --> 00:15:01.159 like providing related options in nearby, like a spinner, but 306 00:15:01.320 --> 00:15:02.279 in a menu format. 307 00:15:02.519 --> 00:15:06.000 Got it. So beyond menus for explicit actions, how did 308 00:15:06.039 --> 00:15:09.000 apps grab the user's attention or give quick feedback without 309 00:15:09.039 --> 00:15:09.919 being too disruptive? 310 00:15:10.120 --> 00:15:13.279 For that, you had various alerts and notifications. For immediate 311 00:15:13.279 --> 00:15:16.360 physical feedback. Apps could use the vibrator service to make 312 00:15:16.399 --> 00:15:19.639 the phone vibrate simple enough, or play sounds using the 313 00:15:19.679 --> 00:15:23.759 ringtone manager to pla say, the default notification sound. The 314 00:15:23.759 --> 00:15:27.120 book even mentions a newer API twenty three feature set 315 00:15:27.159 --> 00:15:30.360 torch mode to flash the camera light briefly as an alert. 316 00:15:30.679 --> 00:15:32.240 Using the flashlight for alerts. 317 00:15:32.320 --> 00:15:35.120 That's novel, Yeah, a bit unusual, but shows the kind 318 00:15:35.120 --> 00:15:39.080 of low level control you had for quick non blocking messages. 319 00:15:39.440 --> 00:15:41.039 Toasts or the standard toasts. 320 00:15:41.120 --> 00:15:43.720 Right, those little gray boxes that pop up briefly at 321 00:15:43.759 --> 00:15:45.600 the bottom exactly. 322 00:15:45.279 --> 00:15:49.080 They'd show a short text message and then fade away, simple, unobtrusive. 323 00:15:49.360 --> 00:15:52.600 You could even customize their layout if you wanted something fancier. 324 00:15:52.279 --> 00:15:55.519 Than just text, and for messages that needed a user 325 00:15:55.600 --> 00:15:58.039 response like a confirmation. 326 00:15:57.519 --> 00:16:00.720 That's where alert dialogue came in the classic message box. 327 00:16:01.159 --> 00:16:04.120 You could create dialogues with a title, a message, and 328 00:16:04.200 --> 00:16:08.720 up to three standard buttons positive, negative, neutral like yes, 329 00:16:08.759 --> 00:16:11.639 no cancel. You could also add icons or even put 330 00:16:11.639 --> 00:16:15.080 lists inside them single choice lists, multi choice lists, or 331 00:16:15.159 --> 00:16:18.440 embed a completely custom layout if needed. Very flexible. 332 00:16:18.519 --> 00:16:22.039 What about showing progress like if something was loading. 333 00:16:22.200 --> 00:16:25.320 There was progress dialogue. It showed a spinning wheel or 334 00:16:25.320 --> 00:16:29.720 a progress bar, typically indicating loading or some indeterminate task. However, 335 00:16:29.720 --> 00:16:34.000 the cookbook explicitly advised developers to avoid progress dialogue if possible. 336 00:16:34.039 --> 00:16:35.240 Why I avoid it. 337 00:16:35.440 --> 00:16:38.440 Because it was modal. It blocked the user from interacting 338 00:16:38.480 --> 00:16:40.559 with the rest of the app until it was dismissed, 339 00:16:41.080 --> 00:16:43.519 which could be really frustrating if the task took a while. 340 00:16:44.000 --> 00:16:46.720 The recommendation was to integrate a progress bar directly into 341 00:16:46.759 --> 00:16:49.440 your apps layout instead, so the user could still interact 342 00:16:49.480 --> 00:16:51.120 with other parts of the UI. Wall waiting. 343 00:16:51.360 --> 00:16:54.720 That's a key usability point even back then. Okay, so 344 00:16:54.799 --> 00:16:58.559 that's in app alerts. What about the system notifications, the 345 00:16:58.559 --> 00:17:00.879 ones that appear in the notification. 346 00:17:00.320 --> 00:17:04.720 Drawer, Ah notifications. Yeah, super important for engaging users when 347 00:17:04.759 --> 00:17:08.039 the app wasn't in the foreground. Developers built these using 348 00:17:08.079 --> 00:17:12.119 notification compat builder. That compact part signifies it came from 349 00:17:12.160 --> 00:17:16.440 the support library, helping ensure compatibility across different Android versions. 350 00:17:16.720 --> 00:17:19.480 You'd set things like a small icon, a title, the 351 00:17:19.519 --> 00:17:20.799 main content text, and. 352 00:17:20.720 --> 00:17:24.279 Could you add buttons to notifications like reply or archive? 353 00:17:24.720 --> 00:17:27.839 Yes? Absolutely, you could add action buttons using something called 354 00:17:27.920 --> 00:17:31.400 pending intent. A pending intent is basically a token that 355 00:17:31.440 --> 00:17:34.240 you give to the Android system. It wraps an intent 356 00:17:34.480 --> 00:17:36.680 and grants the system permission to send that intent on 357 00:17:36.680 --> 00:17:39.359 your app's behalf at a later time, even if your 358 00:17:39.400 --> 00:17:40.160 app isn't running. 359 00:17:40.559 --> 00:17:42.920 So the notification itself could trigger an action in your 360 00:17:42.920 --> 00:17:44.759 app securely exactly. 361 00:17:45.000 --> 00:17:48.720 It's how notification actions worked. Clicking a reply button might 362 00:17:48.799 --> 00:17:51.559 launch a specific activity in your app, or trigger a 363 00:17:51.559 --> 00:17:55.200 background service to handle the reply. Later Android versions added 364 00:17:55.200 --> 00:17:59.480 more features like expanded notifications. Android four point one plus 365 00:18:00.079 --> 00:18:02.720 could show more content, like a longer text snippet or 366 00:18:02.759 --> 00:18:06.240 an image using set style, and Android five point zero 367 00:18:06.319 --> 00:18:10.559 brought specialized styles like media player notifications with playback controls, 368 00:18:10.839 --> 00:18:13.839 though the book notes this wasn't in the compat library yet, 369 00:18:14.119 --> 00:18:15.960 and also heads up notifications. 370 00:18:16.000 --> 00:18:17.680 Oh those ones that pop up over everything. 371 00:18:17.759 --> 00:18:19.960 Yeah, the really intrusive ones. They appeared on top of 372 00:18:20.000 --> 00:18:22.519 whatever app you were using. They were reserved for high 373 00:18:22.599 --> 00:18:25.920 priority things and required setting priority macs and usually having 374 00:18:25.960 --> 00:18:29.480 a sound or vibration to trigger them. You sparingly definitely. 375 00:18:29.799 --> 00:18:34.119 Okay, so we've got menus, alerts, notifications. What about handling 376 00:18:34.119 --> 00:18:36.480 direct touch on the screen and tapping into all those 377 00:18:36.519 --> 00:18:38.279 sensors phones have, right. 378 00:18:38.119 --> 00:18:41.519 Making the app physically responsive. The book covers touchscreen and 379 00:18:41.599 --> 00:18:45.160 sensors quite well. For the basics simple clicks and long 380 00:18:45.200 --> 00:18:48.759 presses you'd use on click listener and on long click listener. 381 00:18:48.880 --> 00:18:50.960 You can set these up in your Java colon code 382 00:18:51.200 --> 00:18:54.359 or even directly in the XML layout using the Android 383 00:18:54.400 --> 00:18:57.279 dot on click attribute. For simple cases, any of you 384 00:18:57.440 --> 00:18:58.880 could have these listeners. 385 00:18:58.599 --> 00:19:01.799 And for more complex gestures swiping, pinching. 386 00:19:02.359 --> 00:19:07.279 For common gestures like detecting swipes, flings, double taps, single taps, 387 00:19:07.759 --> 00:19:10.880 the gesture detector compact class from the support library was 388 00:19:10.920 --> 00:19:14.279 the way to go. It's simplified detecting these standard motions 389 00:19:14.799 --> 00:19:18.200 for multi touch, specifically pinched to zoom, there was scale 390 00:19:18.240 --> 00:19:21.440 gesture detector. It would track two fingers and provide you 391 00:19:21.480 --> 00:19:23.680 with a scale factor indicating how much the user was 392 00:19:23.720 --> 00:19:26.240 trying to zoom in or out. You'd then use that 393 00:19:26.240 --> 00:19:28.640 factor to resize an image or map for example. 394 00:19:28.759 --> 00:19:32.279 Okay, and that common pattern pulling down to refresh a list. 395 00:19:32.240 --> 00:19:35.000 Ah, yes, swipe to refresh. That was made much easier 396 00:19:35.039 --> 00:19:37.440 with the swipe refreshed layout widget. You just wrap your 397 00:19:37.480 --> 00:19:40.960 list view like a blist view or recycle view inside 398 00:19:40.960 --> 00:19:43.640 this layout, set up a listener and it would handle 399 00:19:43.680 --> 00:19:47.160 detecting the pull gester and showing the standard refresh indicator 400 00:19:47.200 --> 00:19:49.160 for you much less boilerplate code. 401 00:19:49.359 --> 00:19:54.680