WEBVTT

1
00:00:00.080 --> 00:00:03.759
<v Speaker 1>Welcome to the deep dive. This is where we really

2
00:00:03.799 --> 00:00:07.559
<v Speaker 1>dig into complex topics, pull out the essentials, and basically

3
00:00:07.559 --> 00:00:09.720
<v Speaker 1>give you a shortcut to being well informed.

4
00:00:09.839 --> 00:00:13.439
<v Speaker 2>Yep. We sift through the information, figure out what matters most,

5
00:00:13.560 --> 00:00:15.759
<v Speaker 2>and hopefully find some useful takeaways for you.

6
00:00:16.079 --> 00:00:19.640
<v Speaker 1>And today we're tackling Android design patterns and best practice.

7
00:00:19.839 --> 00:00:22.160
<v Speaker 1>We've got a great source to guide us, and the

8
00:00:22.199 --> 00:00:25.719
<v Speaker 1>mission is pretty clear. Understand how using these patterns can

9
00:00:25.760 --> 00:00:28.800
<v Speaker 1>help you build better Android apps.

10
00:00:28.600 --> 00:00:32.640
<v Speaker 2>Apps that are more reliable, robust, easier to maintain, just

11
00:00:33.119 --> 00:00:34.399
<v Speaker 2>more efficient overall.

12
00:00:34.600 --> 00:00:36.679
<v Speaker 1>And we're going to frame this by imagining we're building

13
00:00:36.679 --> 00:00:39.679
<v Speaker 1>an app for a small business like local sandwich delivery

14
00:00:39.719 --> 00:00:40.679
<v Speaker 1>service exactly.

15
00:00:41.039 --> 00:00:42.960
<v Speaker 2>It's a good way to see how these patterns actually

16
00:00:43.000 --> 00:00:46.079
<v Speaker 2>pop up naturally during development. They're not just theory, they're

17
00:00:46.119 --> 00:00:47.359
<v Speaker 2>practical solutions.

18
00:00:47.560 --> 00:00:50.920
<v Speaker 1>Yeah, Understanding them gives you this vocabulary, this toolkit. It

19
00:00:50.920 --> 00:00:52.799
<v Speaker 1>helps you spot potential problems earlier.

20
00:00:52.880 --> 00:00:56.240
<v Speaker 2>Right, Definitely, It's like having a set of blueprints for

21
00:00:56.320 --> 00:01:00.240
<v Speaker 2>common coding challenges makes avoiding design flaws way easier. It

22
00:01:00.280 --> 00:01:02.200
<v Speaker 2>really accelerates lending good practice.

23
00:01:02.359 --> 00:01:05.840
<v Speaker 1>Okay, let's start at the beginning. What exactly are design.

24
00:01:05.640 --> 00:01:10.319
<v Speaker 2>Patterns Fundamentally, they're like proven recipes for solving common software

25
00:01:10.319 --> 00:01:14.079
<v Speaker 2>design problems. Think of them less as specific code snippets

26
00:01:14.079 --> 00:01:18.159
<v Speaker 2>and more as programming philosophies or strategies.

27
00:01:18.200 --> 00:01:20.040
<v Speaker 1>And these aren't just Android things, are they not?

28
00:01:20.159 --> 00:01:22.879
<v Speaker 2>At all? The concepts are universal. You see them across

29
00:01:22.920 --> 00:01:25.920
<v Speaker 2>different languages and platforms. In fact, the Android SDK itself

30
00:01:26.000 --> 00:01:29.200
<v Speaker 2>uses tons of them, Like what, well, you've got factory

31
00:01:29.239 --> 00:01:33.439
<v Speaker 2>methods for creating objects, builder patterns for assembling complex ones.

32
00:01:33.840 --> 00:01:37.200
<v Speaker 2>The whole listener system relies heavily on the observer pattern.

33
00:01:37.480 --> 00:01:40.120
<v Speaker 1>They're baked right in, so it's more about grasping the

34
00:01:40.200 --> 00:01:42.840
<v Speaker 1>idea behind the pattern than memorizing a.

35
00:01:42.879 --> 00:01:45.879
<v Speaker 2>List Precisely, if you get the core concept, you can

36
00:01:45.920 --> 00:01:49.560
<v Speaker 2>spot it, understand why it's used, adapt it, maybe even

37
00:01:49.599 --> 00:01:50.959
<v Speaker 2>come up with your own variations.

38
00:01:51.040 --> 00:01:55.719
<v Speaker 1>Okay, back to our sandwich shop. The scenario is an

39
00:01:55.719 --> 00:01:59.120
<v Speaker 1>independent developer gets approached by this small business.

40
00:01:58.760 --> 00:02:01.480
<v Speaker 2>Right the clients struggling with phone orders, mix ups, the

41
00:02:01.599 --> 00:02:04.519
<v Speaker 2>usual chaos. They think a mobile app could be the answer.

42
00:02:04.760 --> 00:02:08.360
<v Speaker 1>It's a classic setup, small business problem, potential tech solution.

43
00:02:08.719 --> 00:02:11.719
<v Speaker 1>It gives us concrete issues that patterns can help solve.

44
00:02:11.960 --> 00:02:13.919
<v Speaker 2>So before we even write a line of code for

45
00:02:13.960 --> 00:02:16.639
<v Speaker 2>this samich app. We need to set up the environment first,

46
00:02:16.680 --> 00:02:19.719
<v Speaker 2>big decision, Which Android versions to support? Ah?

47
00:02:19.840 --> 00:02:22.240
<v Speaker 1>Yes, the API levels you've got minds DK.

48
00:02:22.240 --> 00:02:24.560
<v Speaker 2>Version, the oldest version your app will run on. Yeah,

49
00:02:24.800 --> 00:02:27.800
<v Speaker 2>and targets decay version, which is the version you've tested

50
00:02:27.800 --> 00:02:30.120
<v Speaker 2>against and optimized for. You set these in your build

51
00:02:30.120 --> 00:02:33.759
<v Speaker 2>dot gradal file and sometimes the Android manifest dot XML.

52
00:02:34.000 --> 00:02:36.680
<v Speaker 1>The tricky part is wanting the cool new features but

53
00:02:36.759 --> 00:02:39.120
<v Speaker 1>not cutting off users on older phones.

54
00:02:39.000 --> 00:02:41.719
<v Speaker 2>And that's exactly why the support library is so important.

55
00:02:41.800 --> 00:02:44.639
<v Speaker 2>It's basically a set of libraries from Google that provide

56
00:02:44.719 --> 00:02:48.800
<v Speaker 2>backward compatible versions of newer Android features and UI components, so.

57
00:02:48.759 --> 00:02:51.000
<v Speaker 1>You can use modern stuff even if your mine's DK

58
00:02:51.199 --> 00:02:52.400
<v Speaker 1>version is relatively low.

59
00:02:52.560 --> 00:02:55.280
<v Speaker 2>Exactly, it bridges that gap lets you build more modern

60
00:02:55.319 --> 00:02:58.080
<v Speaker 2>apps for a wider audience. Hugely valuable.

61
00:02:58.159 --> 00:03:01.840
<v Speaker 1>Okay, environment setup? Wow. Inevitably things go wrong.

62
00:03:01.960 --> 00:03:06.960
<v Speaker 2>Debugging debugging, Oh yeah, essential. Testing on actual physical devices

63
00:03:07.039 --> 00:03:10.759
<v Speaker 2>is a must. You enable developer options, turn on USB debugging,

64
00:03:10.800 --> 00:03:11.599
<v Speaker 2>connect your phone.

65
00:03:11.719 --> 00:03:15.080
<v Speaker 1>But you also need virtual devices, right emulators.

66
00:03:14.400 --> 00:03:18.719
<v Speaker 2>Absolutely Android virtual devices or avds. They let you quickly

67
00:03:18.759 --> 00:03:22.759
<v Speaker 2>test on different screen sizes, different API levels without needing

68
00:03:22.800 --> 00:03:24.159
<v Speaker 2>a drawer full of old phones.

69
00:03:24.280 --> 00:03:26.479
<v Speaker 1>Emulators used to be painfully slow though that are much

70
00:03:26.520 --> 00:03:27.199
<v Speaker 1>much better now.

71
00:03:27.360 --> 00:03:30.000
<v Speaker 2>Yeah, and there are third party options to like gen

72
00:03:30.080 --> 00:03:33.280
<v Speaker 2>Emotion or Android by eighty six which can sometimes be

73
00:03:33.360 --> 00:03:36.560
<v Speaker 2>even faster or offer more specific simulation features.

74
00:03:36.599 --> 00:03:38.800
<v Speaker 1>And for just checking layouts quickly.

75
00:03:38.599 --> 00:03:42.759
<v Speaker 2>Androids Studios Layout Preview is fantastic for that you can

76
00:03:42.800 --> 00:03:46.439
<v Speaker 2>see how your UI looks on different screen sizes, densities, themes,

77
00:03:46.479 --> 00:03:50.240
<v Speaker 2>even landscape versus portrait, all without running the app. Massive timesaver.

78
00:03:50.560 --> 00:03:52.080
<v Speaker 1>What about when the app is running, how do you

79
00:03:52.120 --> 00:03:53.960
<v Speaker 1>see what's going on inside.

80
00:03:53.479 --> 00:03:56.240
<v Speaker 2>The Android device? Monitors your friend there you can monitor

81
00:03:56.280 --> 00:04:00.159
<v Speaker 2>things like memory usage, CPU load, network activity in real time.

82
00:04:00.280 --> 00:04:03.159
<v Speaker 1>You can capture detailed performance data too, right the traces

83
00:04:03.159 --> 00:04:03.960
<v Speaker 1>and stuff.

84
00:04:03.800 --> 00:04:08.759
<v Speaker 2>Yep method tracking, resource usage, allocation tracking, plus simple things

85
00:04:08.800 --> 00:04:11.919
<v Speaker 2>like taking screenshots or recording a video of the app running.

86
00:04:12.120 --> 00:04:14.840
<v Speaker 1>But for just tracking the flow and seeing messages from

87
00:04:14.919 --> 00:04:16.079
<v Speaker 1>your code.

88
00:04:15.840 --> 00:04:20.240
<v Speaker 2>Logcat Oka definitely logcat It shows system messages errors, but

89
00:04:20.319 --> 00:04:23.040
<v Speaker 2>the real power is adding your own log messages.

90
00:04:23.160 --> 00:04:26.680
<v Speaker 1>So you put log dot d my tag doing this

91
00:04:26.720 --> 00:04:28.920
<v Speaker 1>thing now in your code.

92
00:04:28.560 --> 00:04:31.079
<v Speaker 2>And then you can filter the logcat output and Android

93
00:04:31.079 --> 00:04:34.120
<v Speaker 2>Studio or the device monitor to see just your messages.

94
00:04:34.199 --> 00:04:37.480
<v Speaker 2>It's way better than sticking temporary text views all over

95
00:04:37.519 --> 00:04:39.160
<v Speaker 2>your UI to see variable values.

96
00:04:39.240 --> 00:04:43.199
<v Speaker 1>Yeah, much cleaner. Okay, let's start building our sandwich app logic.

97
00:04:43.399 --> 00:04:47.639
<v Speaker 1>First up, creating the basic objects, like the different types

98
00:04:47.680 --> 00:04:50.959
<v Speaker 1>of bread or fillings. This gets us into creational patterns.

99
00:04:51.160 --> 00:04:53.560
<v Speaker 1>The factory pattern seems foundational, it really is.

100
00:04:53.639 --> 00:04:56.240
<v Speaker 2>The core idea is creating objects without the client code

101
00:04:56.240 --> 00:04:59.160
<v Speaker 2>needing to know the exact class being created. You ask

102
00:04:59.199 --> 00:05:01.319
<v Speaker 2>a factory for a object and it gives you one

103
00:05:01.560 --> 00:05:01.879
<v Speaker 2>like our.

104
00:05:01.800 --> 00:05:05.199
<v Speaker 1>Bread factory example. Instead of new roll or new brioche,

105
00:05:05.519 --> 00:05:08.759
<v Speaker 1>you'd call something like breadfactory dot get bread roll exactly.

106
00:05:09.360 --> 00:05:13.879
<v Speaker 2>The factory encapsulates the logic of which specific class to instantiate.

107
00:05:14.560 --> 00:05:18.439
<v Speaker 2>The big win here is abstraction. How so, well, if

108
00:05:18.439 --> 00:05:20.399
<v Speaker 2>you want to add a new bread type, say sourdough,

109
00:05:20.720 --> 00:05:22.800
<v Speaker 2>you add the sour dough class and update the factory.

110
00:05:23.560 --> 00:05:26.199
<v Speaker 2>The code using the factory doesn't need to change at all,

111
00:05:26.279 --> 00:05:28.959
<v Speaker 2>as long as the factory still returns a bread object.

112
00:05:29.319 --> 00:05:31.439
<v Speaker 2>It decouples the creation from the usage.

113
00:05:31.600 --> 00:05:35.360
<v Speaker 1>Nice It isolates changes, and this scales up when ingredients

114
00:05:35.399 --> 00:05:39.480
<v Speaker 1>get more complex with images, descriptions, calorie counts.

115
00:05:39.680 --> 00:05:43.040
<v Speaker 2>Yep, the factory just handles creating those more complex objects,

116
00:05:43.120 --> 00:05:44.000
<v Speaker 2>hiding the details.

117
00:05:44.040 --> 00:05:46.519
<v Speaker 1>Okay, building on that. What's the abstract factory pattern?

118
00:05:46.560 --> 00:05:49.519
<v Speaker 2>It sounds similar, It is related. If a regular factory

119
00:05:49.519 --> 00:05:53.240
<v Speaker 2>creates one type of object like bread, an abstract factory

120
00:05:53.319 --> 00:05:56.199
<v Speaker 2>is designed to create families of related objects. It's sometimes

121
00:05:56.279 --> 00:05:57.399
<v Speaker 2>called a factory.

122
00:05:57.000 --> 00:05:58.560
<v Speaker 1>Of factories, a factory of factories.

123
00:05:58.600 --> 00:06:01.120
<v Speaker 2>Okay, so an abstract food fact three might have methods

124
00:06:01.199 --> 00:06:04.040
<v Speaker 2>like create bread and create filling. This ensures that the

125
00:06:04.079 --> 00:06:06.560
<v Speaker 2>bread and filling you get are compatible, may be part

126
00:06:06.600 --> 00:06:10.360
<v Speaker 2>of the same meal deal or regional style. It enforces

127
00:06:10.399 --> 00:06:12.639
<v Speaker 2>consistency across related object types.

128
00:06:12.879 --> 00:06:17.079
<v Speaker 1>Got it factory for one thing, abstract factory for related

129
00:06:17.120 --> 00:06:19.480
<v Speaker 1>sets of things. What are the builder pattern?

130
00:06:19.759 --> 00:06:23.879
<v Speaker 2>The builder is different Again, It's specifically for constructing complex

131
00:06:23.959 --> 00:06:27.079
<v Speaker 2>objects step by step. Instead of getting a fully formed

132
00:06:27.120 --> 00:06:29.920
<v Speaker 2>object from a factory, a builder lets you assemble it

133
00:06:30.040 --> 00:06:30.879
<v Speaker 2>piece by piece.

134
00:06:31.000 --> 00:06:34.560
<v Speaker 1>Ah. Perfect for our sandwich. A sandwich isn't one simple thing.

135
00:06:34.639 --> 00:06:37.879
<v Speaker 1>It's bread plus fillings plus toppings exactly.

136
00:06:37.920 --> 00:06:40.839
<v Speaker 2>You'd have a sandwich builder. You'd call methods like builder

137
00:06:40.879 --> 00:06:44.360
<v Speaker 2>dot set bread whole wheat, then builder dot ad filling

138
00:06:44.600 --> 00:06:49.319
<v Speaker 2>Turkey builder dot adfilling, cheese, builder, dot AD topping lettuce,

139
00:06:49.399 --> 00:06:52.519
<v Speaker 2>and finally called builder dot build to get the finished

140
00:06:52.560 --> 00:06:53.519
<v Speaker 2>sandwich object.

141
00:06:53.800 --> 00:06:56.079
<v Speaker 1>So it's great when an object has lots of optional

142
00:06:56.120 --> 00:06:57.959
<v Speaker 1>parts or as specific assembly order.

143
00:06:58.040 --> 00:07:01.439
<v Speaker 2>Precisely, it makes the construction code much more readable than

144
00:07:01.480 --> 00:07:04.360
<v Speaker 2>having a constructor with like ten parameters, many of which

145
00:07:04.439 --> 00:07:06.600
<v Speaker 2>might be null. It clarifies the process.

146
00:07:06.680 --> 00:07:09.279
<v Speaker 1>Okay, we can build our sandwich object. Now let's think

147
00:07:09.279 --> 00:07:10.040
<v Speaker 1>about how it looks.

148
00:07:10.279 --> 00:07:10.480
<v Speaker 2>Yeah.

149
00:07:10.560 --> 00:07:13.800
<v Speaker 1>Material design patterns are crucial for the UI absolutely.

150
00:07:13.879 --> 00:07:17.759
<v Speaker 2>Material Design is Google's design system for Android. It provides

151
00:07:17.800 --> 00:07:21.360
<v Speaker 2>guidelines and ready made components. Themes and styles are the foundation.

152
00:07:21.839 --> 00:07:24.319
<v Speaker 1>That's the overall look and feel right, colors, fonts.

153
00:07:24.600 --> 00:07:28.399
<v Speaker 2>Yeah, a theme applies styling consistently across your entire app.

154
00:07:28.519 --> 00:07:31.439
<v Speaker 2>You can pick a base material theme and then customize

155
00:07:31.439 --> 00:07:34.360
<v Speaker 2>it using the theme editor in Andrei Studio, defining your

156
00:07:34.360 --> 00:07:38.079
<v Speaker 2>app's color palette, default text appearances, and so on, and.

157
00:07:38.079 --> 00:07:40.560
<v Speaker 1>You define these colors in a resource file colors dot

158
00:07:40.800 --> 00:07:42.120
<v Speaker 1>xml best practice.

159
00:07:42.279 --> 00:07:47.319
<v Speaker 2>Yes, Material Design has specific recommendations for using primary, secondary,

160
00:07:47.360 --> 00:07:49.079
<v Speaker 2>and accent colors purposefully.

161
00:07:49.360 --> 00:07:52.360
<v Speaker 1>The guidelines get pretty specific, even down to text sizes.

162
00:07:52.519 --> 00:07:55.480
<v Speaker 2>They do. They recommend a specific type scale like twelve

163
00:07:55.600 --> 00:07:59.279
<v Speaker 2>P for captions, fourteen SP for body text, sixteen SP

164
00:07:59.399 --> 00:08:02.879
<v Speaker 2>for subheadings, et cetera. Using these standard sizes helps create

165
00:08:02.959 --> 00:08:05.879
<v Speaker 2>visual consistency and good readability.

166
00:08:05.519 --> 00:08:07.439
<v Speaker 1>And even text color isn't just black or gray.

167
00:08:07.600 --> 00:08:11.360
<v Speaker 2>Often no material design suggests using transparency levels on your

168
00:08:11.399 --> 00:08:14.560
<v Speaker 2>primary text color to create secondary or disabled text states.

169
00:08:14.839 --> 00:08:17.759
<v Speaker 2>This works better visually, especially on colored backgrounds, than just

170
00:08:17.839 --> 00:08:19.000
<v Speaker 2>using different shades of gray.

171
00:08:19.240 --> 00:08:22.240
<v Speaker 1>Images are vital for a food app. How does Android

172
00:08:22.240 --> 00:08:23.680
<v Speaker 1>handle different screen densities?

173
00:08:23.959 --> 00:08:29.079
<v Speaker 2>MDPI, ACPI, right devices have different pixel densities. To make

174
00:08:29.160 --> 00:08:32.960
<v Speaker 2>images look sharp everywhere without wasting memory, you provide multiple

175
00:08:33.039 --> 00:08:39.799
<v Speaker 2>versions of each image asset in density specific drawable folders, drawable, MDPA, drawable, HDPI, drawable, XHDPI,

176
00:08:39.919 --> 00:08:41.600
<v Speaker 2>drawble XHDPI, et cetera.

177
00:08:41.799 --> 00:08:42.840
<v Speaker 1>Do you really need all of them?

178
00:08:43.120 --> 00:08:48.080
<v Speaker 2>Often No. For most apps, providing versions for MDPI, HDPI, XXDPI,

179
00:08:48.159 --> 00:08:51.759
<v Speaker 2>and maybe XDFDPI covers the vast majority of device as well.

180
00:08:52.279 --> 00:08:54.960
<v Speaker 2>The system automatically picks the best one for the device

181
00:08:55.000 --> 00:08:55.679
<v Speaker 2>it's running.

182
00:08:55.480 --> 00:08:57.559
<v Speaker 1>On, as long as you reference it correctly. Like at

183
00:08:57.639 --> 00:08:59.039
<v Speaker 1>drawable my image.

184
00:08:58.720 --> 00:09:02.519
<v Speaker 2>Exactly, you use the resource ID and Android handles selecting

185
00:09:02.519 --> 00:09:05.759
<v Speaker 2>the right density version. It's much more efficient than just

186
00:09:05.879 --> 00:09:10.279
<v Speaker 2>using one huge image and material guidelines suggest photographic images

187
00:09:10.279 --> 00:09:13.639
<v Speaker 2>should be clear, simple, and have an unambiguous subject.

188
00:09:13.799 --> 00:09:18.360
<v Speaker 1>A really common material component is the cardview. Those rounded rectangles.

189
00:09:17.919 --> 00:09:21.360
<v Speaker 2>Yeah, they're everywhere. Cardview is great for grouping related information

190
00:09:21.679 --> 00:09:24.559
<v Speaker 2>and image some text maybe a button about a single topic,

191
00:09:24.960 --> 00:09:27.679
<v Speaker 2>perfect for showing our sandwich ingredients or menu items.

192
00:09:27.679 --> 00:09:29.240
<v Speaker 1>Is known in the support library.

193
00:09:29.000 --> 00:09:31.600
<v Speaker 2>Yep, so they work back to API level seven. A

194
00:09:31.639 --> 00:09:34.440
<v Speaker 2>card view itself is just a container, usually with its

195
00:09:34.440 --> 00:09:37.559
<v Speaker 2>own layout inside, like a linear layout or relative layout

196
00:09:37.879 --> 00:09:39.080
<v Speaker 2>holding the actual content.

197
00:09:39.159 --> 00:09:41.919
<v Speaker 1>They have a built in shadow effect to the elevation right.

198
00:09:42.000 --> 00:09:44.840
<v Speaker 2>A default elevation of two DP, which typically increases to

199
00:09:44.879 --> 00:09:48.200
<v Speaker 2>ADP when it's pressed or actively being interacted with gives

200
00:09:48.279 --> 00:09:52.919
<v Speaker 2>nice visual feedback. And remember to use string resources at

201
00:09:52.960 --> 00:09:56.840
<v Speaker 2>string ingredient name for text inside cards not hard coded

202
00:09:56.879 --> 00:09:58.960
<v Speaker 2>strings essential for translation later.

203
00:09:59.159 --> 00:10:02.240
<v Speaker 1>Image ratio on card matter too, right, sixteen point nine

204
00:10:02.320 --> 00:10:03.679
<v Speaker 1>or one point one usually.

205
00:10:03.440 --> 00:10:05.360
<v Speaker 2>Those are common guidelines for visual consistency.

206
00:10:05.399 --> 00:10:09.559
<v Speaker 1>Yeah okay. Another core UI element the app bar or toolbar.

207
00:10:09.759 --> 00:10:12.600
<v Speaker 2>The toolbar is the modern replacement for the old action bar.

208
00:10:13.080 --> 00:10:15.120
<v Speaker 2>A key difference is that the toolbar is a view

209
00:10:15.159 --> 00:10:18.840
<v Speaker 2>group you actually place inside your layout XML, giving you

210
00:10:18.919 --> 00:10:21.639
<v Speaker 2>much more control over its position and behavior compared to

211
00:10:21.679 --> 00:10:22.519
<v Speaker 2>the action bar You.

212
00:10:22.440 --> 00:10:25.320
<v Speaker 1>Put the title there, maybe navigation icons action buttons like

213
00:10:25.320 --> 00:10:26.720
<v Speaker 1>searcher settings.

214
00:10:26.360 --> 00:10:29.600
<v Speaker 2>Exactly, and you control which action icons appear directly in

215
00:10:29.639 --> 00:10:33.200
<v Speaker 2>the toolbar versus collapsing into an overflow menu using the

216
00:10:33.240 --> 00:10:36.840
<v Speaker 2>show as action attribute in your MENUXML file options like

217
00:10:36.879 --> 00:10:38.519
<v Speaker 2>if room or always again.

218
00:10:38.639 --> 00:10:41.919
<v Speaker 1>Using string resources for titles and menu items always good practice.

219
00:10:41.960 --> 00:10:45.360
<v Speaker 1>And the slide out navigation drawer is another standard material pattern.

220
00:10:45.399 --> 00:10:48.759
<v Speaker 1>You mentioned something called ratio key lines for dividing vertical

221
00:10:48.759 --> 00:10:49.360
<v Speaker 1>space in there.

222
00:10:49.399 --> 00:10:53.039
<v Speaker 2>Ah. Yeah, that's a more subtle material guideline for components

223
00:10:53.080 --> 00:10:56.440
<v Speaker 2>like a navigation drawer header. It suggests using scandered aspect

224
00:10:56.480 --> 00:10:59.039
<v Speaker 2>ratios like sixteen point nine four point three one point

225
00:10:59.080 --> 00:11:02.240
<v Speaker 2>one to defy fine key horizontal division lines based on

226
00:11:02.279 --> 00:11:03.600
<v Speaker 2>the components with So.

227
00:11:03.519 --> 00:11:06.200
<v Speaker 1>If the drawers say three twenty dp wide, the sixteen

228
00:11:06.240 --> 00:11:08.559
<v Speaker 1>point nine key line would be it owned eightydp down

229
00:11:08.559 --> 00:11:10.240
<v Speaker 1>from the top. Yeah, three twenty nine.

230
00:11:10.120 --> 00:11:13.279
<v Speaker 2>To sixteen exactly. Using these key lines for placing major

231
00:11:13.320 --> 00:11:15.960
<v Speaker 2>elements like the bottom of a header image can create

232
00:11:16.000 --> 00:11:19.159
<v Speaker 2>a more visually harmonious layout. It's about structured.

233
00:11:18.720 --> 00:11:22.639
<v Speaker 1>Proportions, interesting detail, okay. Shifting from UI to code structure

234
00:11:22.679 --> 00:11:25.879
<v Speaker 1>and data organization structural patterns, the singleton is a well

235
00:11:25.879 --> 00:11:26.320
<v Speaker 1>known one.

236
00:11:26.440 --> 00:11:29.080
<v Speaker 2>The singleton pattern ensures you only ever have one instance

237
00:11:29.080 --> 00:11:32.000
<v Speaker 2>of a particular class in your entire application, and it

238
00:11:32.039 --> 00:11:36.360
<v Speaker 2>provides a single global way to access that instance, like the.

239
00:11:36.320 --> 00:11:40.159
<v Speaker 1>Current user idea. Usually only one person is logged into

240
00:11:40.200 --> 00:11:40.759
<v Speaker 1>the app at a.

241
00:11:40.720 --> 00:11:44.159
<v Speaker 2>Time, right, It's useful for managing things that are inherently singular,

242
00:11:44.279 --> 00:11:48.159
<v Speaker 2>like access to a shared resource, maybe a database connection pool,

243
00:11:48.200 --> 00:11:53.360
<v Speaker 2>though that's debatable, global configuration, or yeah, the currently logged

244
00:11:53.360 --> 00:11:54.279
<v Speaker 2>in user's data.

245
00:11:54.320 --> 00:11:57.440
<v Speaker 1>But the source warns about overusing it definitely.

246
00:11:57.639 --> 00:12:00.919
<v Speaker 2>Singletons can make testing harder and create tight coupling between

247
00:12:00.960 --> 00:12:03.120
<v Speaker 2>different parts of your app if you're not careful use

248
00:12:03.120 --> 00:12:03.840
<v Speaker 2>them thoughtfully.

249
00:12:04.279 --> 00:12:08.759
<v Speaker 1>We talked about basic layouts, linear layout, relative layout. The

250
00:12:08.799 --> 00:12:11.679
<v Speaker 1>source mentions using percentages for more flexible sizing.

251
00:12:12.279 --> 00:12:15.519
<v Speaker 2>Yes, sometimes fixed dimensions or even weights don't quite give

252
00:12:15.559 --> 00:12:18.360
<v Speaker 2>you the proportional layout you want across different screen sizes.

253
00:12:18.759 --> 00:12:22.639
<v Speaker 2>The percent support library provides percent relative layout and percent

254
00:12:22.720 --> 00:12:23.799
<v Speaker 2>frame layout.

255
00:12:23.759 --> 00:12:26.759
<v Speaker 1>Letting you say this view should take up thirty percent.

256
00:12:26.519 --> 00:12:29.759
<v Speaker 2>Of the screen with exactly layout fix percent or lay

257
00:12:29.799 --> 00:12:32.639
<v Speaker 2>with height percent. It can help avoid distortion or awkward

258
00:12:32.639 --> 00:12:35.039
<v Speaker 2>spacing on unusually sized screens.

259
00:12:34.679 --> 00:12:37.600
<v Speaker 1>And for fundamentally different layouts, like for a phone versus

260
00:12:37.600 --> 00:12:38.080
<v Speaker 1>a tablet.

261
00:12:38.279 --> 00:12:41.480
<v Speaker 2>That's where resource qualifiers are essential. You create different layout

262
00:12:41.519 --> 00:12:44.759
<v Speaker 2>directories named with qualifiers like reslayout sixty six hundred DP

263
00:12:45.320 --> 00:12:47.399
<v Speaker 2>for screens with a small swidth of six hundred DP

264
00:12:47.559 --> 00:12:50.879
<v Speaker 2>or more like small tablets, or reslay out lasex of

265
00:12:51.039 --> 00:12:55.000
<v Speaker 2>twenty DP for larger tablets. Android automatically picks the layout

266
00:12:55.000 --> 00:12:57.080
<v Speaker 2>from the most appropriate directory.

267
00:12:56.840 --> 00:12:59.840
<v Speaker 1>So you might have reslayot activity main dot XML for

268
00:12:59.840 --> 00:13:03.960
<v Speaker 1>fur phones and reslayoutsh sex six hundred deep activity main

269
00:13:04.080 --> 00:13:05.519
<v Speaker 1>dot XML for tablets.

270
00:13:05.559 --> 00:13:09.519
<v Speaker 2>Precisely keeps your device specific layouts separate and organized, and

271
00:13:09.679 --> 00:13:12.720
<v Speaker 2>layout aliases can help bridge the gap for older devices

272
00:13:12.720 --> 00:13:15.799
<v Speaker 2>that used older qualifiers like large or x large, letting

273
00:13:15.840 --> 00:13:19.360
<v Speaker 2>them reuse your newer SWOW qualified layouts without duplicating files.

274
00:13:19.519 --> 00:13:23.080
<v Speaker 1>Okay, our sandwich app needs lists, list of ingredients, list

275
00:13:23.080 --> 00:13:25.639
<v Speaker 1>of menu items, list of past orders. How do we

276
00:13:25.679 --> 00:13:28.000
<v Speaker 1>display these efficiently, especially if they get long?

277
00:13:28.240 --> 00:13:31.240
<v Speaker 2>The modern standard for this is recycler view. It's designed

278
00:13:31.240 --> 00:13:34.919
<v Speaker 2>specifically for displaying large or potentially large data sets efficiently.

279
00:13:35.120 --> 00:13:36.000
<v Speaker 1>What makes it efficient?

280
00:13:36.120 --> 00:13:39.840
<v Speaker 2>Its key feature is view recycling. Instead of creating a

281
00:13:40.000 --> 00:13:42.919
<v Speaker 2>new view object for every single item in your list,

282
00:13:43.159 --> 00:13:46.600
<v Speaker 2>which gets incredibly slow and memory hungry for long lists,

283
00:13:47.159 --> 00:13:51.919
<v Speaker 2>Recycler View reuses the view objects as they scroll offscreen.

284
00:13:51.559 --> 00:13:53.840
<v Speaker 1>So it keeps a small pool of views and just

285
00:13:54.000 --> 00:13:55.399
<v Speaker 1>updates their content as you.

286
00:13:55.320 --> 00:13:59.159
<v Speaker 2>Scroll exactly much much better performance. To make it work,

287
00:13:59.240 --> 00:14:00.799
<v Speaker 2>you need three components.

288
00:14:00.919 --> 00:14:01.679
<v Speaker 1>Okay, what are they?

289
00:14:01.759 --> 00:14:04.960
<v Speaker 2>First? The layout manager. This determines how the items are

290
00:14:05.039 --> 00:14:09.000
<v Speaker 2>arranged in a vertical list, linear layout manager, a grid

291
00:14:09.600 --> 00:14:12.879
<v Speaker 2>grid layout manager, or even a staggered grid a stagger

292
00:14:12.919 --> 00:14:16.480
<v Speaker 2>grid layout manager. The adapter. This is the bridge between

293
00:14:16.519 --> 00:14:18.919
<v Speaker 2>your data like your list of ingredient objects, and the

294
00:14:18.919 --> 00:14:22.759
<v Speaker 2>recycler View. It's responsible for creating the views when needed

295
00:14:22.799 --> 00:14:24.840
<v Speaker 2>and binding your data to those views.

296
00:14:25.000 --> 00:14:26.559
<v Speaker 1>And Third, the viewholder.

297
00:14:27.000 --> 00:14:30.159
<v Speaker 2>This is a small helper class usually defined inside your adapter,

298
00:14:30.519 --> 00:14:33.480
<v Speaker 2>that holds references to the actual UI elements within a

299
00:14:33.519 --> 00:14:36.240
<v Speaker 2>single list items layout, like the text view for the

300
00:14:36.360 --> 00:14:39.440
<v Speaker 2>ingredient name the image view for its picture. The adapter

301
00:14:39.639 --> 00:14:42.639
<v Speaker 2>uses the viewholder to quickly update the views without needing

302
00:14:42.639 --> 00:14:45.759
<v Speaker 2>to repeatedly call find view beyide, so.

303
00:14:45.840 --> 00:14:50.360
<v Speaker 1>Layout manager positions things, adapter gets the data and creates

304
00:14:50.440 --> 00:14:54.960
<v Speaker 1>updates views using viewholders. That's the flow. Now, speaking of adapters,

305
00:14:54.960 --> 00:14:58.159
<v Speaker 1>the adapter pattern is also a structural pattern, separate from

306
00:14:58.200 --> 00:15:00.000
<v Speaker 1>the recycler of view dot adapter component.

307
00:15:00.240 --> 00:15:03.639
<v Speaker 2>Right, yes, good distinction. The adapter pattern is a general

308
00:15:03.639 --> 00:15:07.440
<v Speaker 2>design pattern whose purpose is to allow two incompatible interfaces

309
00:15:07.440 --> 00:15:08.159
<v Speaker 2>to work together.

310
00:15:08.240 --> 00:15:09.080
<v Speaker 1>How does it do that.

311
00:15:09.360 --> 00:15:12.120
<v Speaker 2>You create an adapter class that implements the interface the

312
00:15:12.159 --> 00:15:15.639
<v Speaker 2>client code expects to use. Inside this adapter class holds

313
00:15:15.679 --> 00:15:17.919
<v Speaker 2>a reference to an objects that has the interface you

314
00:15:18.000 --> 00:15:21.639
<v Speaker 2>actually have. The adapter then translates calls from the expected

315
00:15:21.679 --> 00:15:24.679
<v Speaker 2>interface into calls on the actual object's interface.

316
00:15:25.120 --> 00:15:28.240
<v Speaker 1>Like the example with old location versus new location. You

317
00:15:28.320 --> 00:15:31.639
<v Speaker 1>make an adapter that looks like new location, but internally

318
00:15:31.840 --> 00:15:34.639
<v Speaker 1>uses an old location object to do the work exactly.

319
00:15:34.679 --> 00:15:37.519
<v Speaker 2>It's like putting a plug adapter on your European hair

320
00:15:37.600 --> 00:15:39.919
<v Speaker 2>dryer so you can plug it into a US socket.

321
00:15:40.279 --> 00:15:43.879
<v Speaker 2>It converts the interface. It's often used to integrate legacy

322
00:15:43.919 --> 00:15:47.039
<v Speaker 2>code or third party libraries that don't quite fit your

323
00:15:47.080 --> 00:15:48.480
<v Speaker 2>current system's interfaces.

324
00:15:48.600 --> 00:15:50.679
<v Speaker 1>Okay, and how does this differ from the bridge pattern.

325
00:15:50.720 --> 00:15:53.240
<v Speaker 1>They sound a bit similar structurally.

326
00:15:52.799 --> 00:15:56.120
<v Speaker 2>The key difference is intent and timing. The adapter pattern

327
00:15:56.200 --> 00:15:59.480
<v Speaker 2>is usually applied after the fact to make existing incompatible

328
00:15:59.480 --> 00:16:02.879
<v Speaker 2>things work together. The bridge pattern is typically designed upfront

329
00:16:02.919 --> 00:16:05.919
<v Speaker 2>to decouple an abstraction from its implementation, So bridge is.

330
00:16:05.919 --> 00:16:07.279
<v Speaker 1>About proactive separation.

331
00:16:07.720 --> 00:16:11.519
<v Speaker 2>Right With bridge, you define an interface the abstraction and

332
00:16:11.600 --> 00:16:16.039
<v Speaker 2>separate concrete implementations. The client code interacts with the interface,

333
00:16:16.360 --> 00:16:19.639
<v Speaker 2>and you can swap out different implementations behind that interface

334
00:16:19.679 --> 00:16:22.559
<v Speaker 2>without the client needing to know. It allows the abstraction

335
00:16:22.639 --> 00:16:27.159
<v Speaker 2>and implementation to evolve independently. The sandwich interface being separate

336
00:16:27.200 --> 00:16:30.559
<v Speaker 2>from how a sandwich is actually stored or built could

337
00:16:30.639 --> 00:16:31.639
<v Speaker 2>be a bridge example.

338
00:16:31.759 --> 00:16:36.279
<v Speaker 1>Adapter fixes incompatibility. Bridge enables independent evolution.

339
00:16:36.919 --> 00:16:40.399
<v Speaker 2>Got it. Next up the facade pattern. This one seems simpler.

340
00:16:40.519 --> 00:16:43.320
<v Speaker 1>It often is, but it's very useful. A facade provides

341
00:16:43.360 --> 00:16:47.519
<v Speaker 1>a simplified, high level interface to a larger, more complex subsystem.

342
00:16:48.159 --> 00:16:51.080
<v Speaker 1>It hides the complexity behind a single entry point.

343
00:16:50.879 --> 00:16:53.919
<v Speaker 2>Like simplifying a complex ordering system behind a single order

344
00:16:53.960 --> 00:16:55.440
<v Speaker 2>manager dot place order method.

345
00:16:55.519 --> 00:16:59.039
<v Speaker 1>Perfect example, the client doesn't need to know about inventory checking,

346
00:16:59.080 --> 00:17:02.000
<v Speaker 1>payment processing, delivery scheduling. They just talk to the.

347
00:17:01.919 --> 00:17:06.279
<v Speaker 2>Facade makes sense, and the criteria pattern or filter pattern.

348
00:17:06.440 --> 00:17:08.799
<v Speaker 1>This one is great for dynamically selecting objects from a

349
00:17:08.799 --> 00:17:11.720
<v Speaker 1>collection based on different criteria. Think of filtering our list

350
00:17:11.720 --> 00:17:16.279
<v Speaker 1>of sandwich ingredients like show me only vegetarian ingredients, or

351
00:17:16.519 --> 00:17:18.720
<v Speaker 1>show me ingredients that are local and low calorie.

352
00:17:18.759 --> 00:17:23.480
<v Speaker 2>Exactly. You define separate criteria objects for each condition, for example,

353
00:17:23.799 --> 00:17:27.599
<v Speaker 2>is vegetarian criteria, is local criteria, is low calorie criteria.

354
00:17:27.839 --> 00:17:30.279
<v Speaker 2>Then you can use them individually or combine them using

355
00:17:30.359 --> 00:17:34.400
<v Speaker 2>logical criteria objects and criteria or criteria.

356
00:17:34.480 --> 00:17:36.640
<v Speaker 1>So you pass your list of ingredients and the combined

357
00:17:36.680 --> 00:17:40.079
<v Speaker 1>criteria object to a filter method and it returns just

358
00:17:40.119 --> 00:17:41.720
<v Speaker 1>the matching ingredients precisely.

359
00:17:41.960 --> 00:17:45.720
<v Speaker 2>It keeps the filtering logic clean, separate, and easily extensible.

360
00:17:46.279 --> 00:17:49.480
<v Speaker 2>Adding a new filter like is gluten free criteria doesn't

361
00:17:49.480 --> 00:17:53.599
<v Speaker 2>require changing existing code, just adding the new criteria class

362
00:17:54.119 --> 00:17:56.079
<v Speaker 2>much better than giant Ifel's chains.

363
00:17:56.160 --> 00:17:59.480
<v Speaker 1>Okay, we've covered buildings, structuring, and filtering. Let's get into

364
00:17:59.480 --> 00:18:03.039
<v Speaker 1>activating patterns, making things happen in the UI and connecting

365
00:18:03.079 --> 00:18:06.359
<v Speaker 1>the pieces. Complex scrolling behavior seems like a good place

366
00:18:06.400 --> 00:18:07.039
<v Speaker 1>to start.

367
00:18:06.880 --> 00:18:09.799
<v Speaker 2>Right, especially with coordinator layout. This layout is designed to

368
00:18:09.799 --> 00:18:13.720
<v Speaker 2>coordinate interactions between its child views, particularly between scrolling views

369
00:18:14.039 --> 00:18:17.160
<v Speaker 2>like recycler view or nested scroll view and an app

370
00:18:17.200 --> 00:18:17.720
<v Speaker 2>bar layout.

371
00:18:17.839 --> 00:18:19.960
<v Speaker 1>The app bar layout holds the toolbar right.

372
00:18:20.079 --> 00:18:23.759
<v Speaker 2>Maybe other fis yes, and by setting layout scroll flags

373
00:18:23.759 --> 00:18:26.759
<v Speaker 2>on the toolbar or other views inside the app bar layout,

374
00:18:27.160 --> 00:18:30.480
<v Speaker 2>you control how it reacts when the content below scrolls.

375
00:18:31.240 --> 00:18:33.960
<v Speaker 1>Like scroll makes it scroll off screen with the content.

376
00:18:33.680 --> 00:18:36.759
<v Speaker 2>Yep exit until it collapse, makes it scroll partially off

377
00:18:36.839 --> 00:18:39.799
<v Speaker 2>until it reaches a minimum height. Enter always makes it

378
00:18:39.839 --> 00:18:43.079
<v Speaker 2>reappear immediately when you scroll back up. Snap makes it

379
00:18:43.160 --> 00:18:45.559
<v Speaker 2>settle fully open or fully closed.

380
00:18:45.920 --> 00:18:48.599
<v Speaker 1>And you can make things inside the collapsing toolbar move too,

381
00:18:48.880 --> 00:18:49.960
<v Speaker 1>like parallax effects.

382
00:18:50.039 --> 00:18:53.279
<v Speaker 2>Yeah, using layout collapse mode parallax on an image view

383
00:18:53.599 --> 00:18:56.920
<v Speaker 2>inside a collapsing toolbar layout, which often wraps the content

384
00:18:56.960 --> 00:19:00.200
<v Speaker 2>inside the app bar layout, or layout collapse mode in

385
00:19:00.359 --> 00:19:02.559
<v Speaker 2>to make an element stick at the top. One collapsed

386
00:19:02.880 --> 00:19:05.720
<v Speaker 2>coordinator layout enables these rich scrolling effects.

387
00:19:05.759 --> 00:19:08.079
<v Speaker 1>And we can use our factory pattern to create the

388
00:19:08.119 --> 00:19:10.160
<v Speaker 1>actual data list for the recycler view.

389
00:19:10.319 --> 00:19:13.680
<v Speaker 2>Absolutely, you might have a cheese factory generate a list

390
00:19:13.759 --> 00:19:17.519
<v Speaker 2>cheese objects which you then pass to your recycler views adapter.

391
00:19:18.119 --> 00:19:21.319
<v Speaker 1>Let's talk about implementing that adapter. We know the concepts

392
00:19:21.359 --> 00:19:23.759
<v Speaker 1>adapter viewholder, but what does the code look like.

393
00:19:23.920 --> 00:19:27.960
<v Speaker 2>You'll create a class, say ingredient adapter that extends recyclerview

394
00:19:28.079 --> 00:19:32.880
<v Speaker 2>dot adapter. Inside that, you define your viewholder class, which

395
00:19:32.960 --> 00:19:35.839
<v Speaker 2>finds and holds references to the views in your list

396
00:19:35.880 --> 00:19:40.000
<v Speaker 2>item layout XML as she textview ingredient name, image, view

397
00:19:40.160 --> 00:19:41.000
<v Speaker 2>ingredient image.

398
00:19:41.079 --> 00:19:43.799
<v Speaker 1>Then you implement the required methods in the adapter.

399
00:19:43.680 --> 00:19:47.119
<v Speaker 2>Right on creteewholder is called when the recycler view needs

400
00:19:47.119 --> 00:19:50.599
<v Speaker 2>a new view. Here, you inflate your item layout XML

401
00:19:50.759 --> 00:19:52.359
<v Speaker 2>and create a new instance.

402
00:19:51.920 --> 00:19:54.680
<v Speaker 1>Of your viewholder on bindviewholder.

403
00:19:54.000 --> 00:19:56.799
<v Speaker 2>That's called when the recycler view wants to display data

404
00:19:56.839 --> 00:19:59.720
<v Speaker 2>at a specific position. You get the data item for

405
00:19:59.720 --> 00:20:02.119
<v Speaker 2>that p position from your list and use the provided

406
00:20:02.200 --> 00:20:05.240
<v Speaker 2>viewholder to set the data on the views og holder

407
00:20:05.240 --> 00:20:08.640
<v Speaker 2>dot ingredient name dot, set text ingredient dot, get.

408
00:20:08.559 --> 00:20:10.640
<v Speaker 1>Name and get adam count. Just returns the size of

409
00:20:10.680 --> 00:20:11.920
<v Speaker 1>your data list exactly.

410
00:20:12.359 --> 00:20:16.000
<v Speaker 2>Then in your activity or fragments on create or on vcreated,

411
00:20:16.319 --> 00:20:18.720
<v Speaker 2>you create an instance of your adapter pass at your

412
00:20:18.799 --> 00:20:21.759
<v Speaker 2>data list. Create a layout manager and set both the

413
00:20:21.839 --> 00:20:24.519
<v Speaker 2>layout manager and the adapter on your recycler view.

414
00:20:24.559 --> 00:20:25.680
<v Speaker 1>You can add dividers too.

415
00:20:25.759 --> 00:20:29.319
<v Speaker 2>Yep, using recyclview dot item decoration. There are built in

416
00:20:29.400 --> 00:20:30.920
<v Speaker 2>helpers for simple dividers.

417
00:20:31.160 --> 00:20:35.359
<v Speaker 1>Okay, user interaction, we need buttons like maybe a shopping

418
00:20:35.359 --> 00:20:37.319
<v Speaker 1>cart icon action icons.

419
00:20:37.920 --> 00:20:42.119
<v Speaker 2>Material Design has specific guidelines for icons, size, style, padding.

420
00:20:42.759 --> 00:20:45.519
<v Speaker 2>Google provides a standard set of material icons you can

421
00:20:45.559 --> 00:20:48.799
<v Speaker 2>easily import into Android Studio. You typically use them with

422
00:20:48.880 --> 00:20:51.680
<v Speaker 2>image button or set them as the drawable on a

423
00:20:51.759 --> 00:20:53.279
<v Speaker 2>regular button or menu item.

424
00:20:53.480 --> 00:20:55.440
<v Speaker 1>And colors follow the theme usually yes.

425
00:20:55.799 --> 00:20:58.759
<v Speaker 2>They often use the primary or secondary text colors with

426
00:20:58.799 --> 00:21:01.920
<v Speaker 2>appropriate transparency, adapting to light or dark themes.

427
00:21:02.079 --> 00:21:05.200
<v Speaker 1>What about confirming an action like tapping the cart icon

428
00:21:05.319 --> 00:21:06.880
<v Speaker 1>leads to a proceed to check out?

429
00:21:07.359 --> 00:21:12.000
<v Speaker 2>Confirmation dialogues dialogues are perfect for that alert Dialogue Builder

430
00:21:12.119 --> 00:21:15.960
<v Speaker 2>is the standard way to create simple confirmation dialogues with titles, messages,

431
00:21:16.000 --> 00:21:17.599
<v Speaker 2>and standard positive and negative buttons.

432
00:21:17.599 --> 00:21:18.839
<v Speaker 1>Do you put custom stuff in them?

433
00:21:18.920 --> 00:21:21.759
<v Speaker 2>Absolutely? You can use builder dot set view and provide

434
00:21:21.759 --> 00:21:25.440
<v Speaker 2>your own custom layout XML file inflated. Using layout inflator,

435
00:21:25.759 --> 00:21:28.279
<v Speaker 2>this lets you put pretty much any UI elements inside

436
00:21:28.279 --> 00:21:28.839
<v Speaker 2>a dialogue.

437
00:21:28.880 --> 00:21:32.079
<v Speaker 1>Cool. Another common list interaction is swiping items away, like

438
00:21:32.200 --> 00:21:33.799
<v Speaker 1>dismissing an ingredient choice.

439
00:21:33.920 --> 00:21:37.559
<v Speaker 2>Android provides item touch Helper for exactly this. It's a

440
00:21:37.640 --> 00:21:40.960
<v Speaker 2>utility class that attaches to your recycler view and handles

441
00:21:40.960 --> 00:21:43.319
<v Speaker 2>detecting swipe and dragon drop gestures.

442
00:21:43.400 --> 00:21:44.079
<v Speaker 1>How do you use it?

443
00:21:44.200 --> 00:21:47.279
<v Speaker 2>You create an item touch helper simple callback where you

444
00:21:47.359 --> 00:21:50.680
<v Speaker 2>override methods like on swiped. When on swiped is called,

445
00:21:50.720 --> 00:21:53.039
<v Speaker 2>you get the viewholder that was swiped and the direction.

446
00:21:53.960 --> 00:21:56.880
<v Speaker 2>Inside this method, you need to remove the corresponding item

447
00:21:56.960 --> 00:21:58.319
<v Speaker 2>from your adapter's data.

448
00:21:58.160 --> 00:22:00.880
<v Speaker 1>List and then tell the adapter crucially yes.

449
00:22:01.200 --> 00:22:04.599
<v Speaker 2>After removing the data, you call adapter dot notify item

450
00:22:04.640 --> 00:22:08.720
<v Speaker 2>removed cost position, and maybe adapter dot notify item range

451
00:22:08.839 --> 00:22:12.599
<v Speaker 2>changed position. Adapter dot get item count. So the recycler

452
00:22:12.680 --> 00:22:15.480
<v Speaker 2>view updates its display correctly animating the removal.

453
00:22:15.599 --> 00:22:18.640
<v Speaker 1>So item touch Helper handles the gesture detection. Your callback

454
00:22:18.920 --> 00:22:22.200
<v Speaker 1>handles the data update notification. That's the pattern. Sometimes you

455
00:22:22.240 --> 00:22:25.119
<v Speaker 1>might want to build layouts dynamically in code instead of

456
00:22:25.200 --> 00:22:25.880
<v Speaker 1>just XML.

457
00:22:26.200 --> 00:22:30.039
<v Speaker 2>It's less common for mainscreen layouts, but definitely possible and

458
00:22:30.079 --> 00:22:34.319
<v Speaker 2>sometimes necessary for highly dynamic content. You can programmatically create

459
00:22:34.359 --> 00:22:38.319
<v Speaker 2>instances of linear layout text, view, button, et cetera. Set

460
00:22:38.359 --> 00:22:42.720
<v Speaker 2>their properties layout per ams text click listeners and add

461
00:22:42.759 --> 00:22:46.079
<v Speaker 2>them to a parent layout in your activities. On create method,

462
00:22:46.759 --> 00:22:49.680
<v Speaker 2>the source shows a simple builder like approach for this.

463
00:22:49.839 --> 00:22:52.480
<v Speaker 1>Okay, we've got a lot of pieces. Let's think about

464
00:22:52.640 --> 00:22:57.200
<v Speaker 1>combining patterns for more complex needs, focusing on flexibility and efficiency.

465
00:22:57.559 --> 00:23:00.759
<v Speaker 2>Right as our sandwich app gets more sofie sticated, maybe

466
00:23:00.799 --> 00:23:04.720
<v Speaker 2>storing favorite custom sandwiches, handling complex promotions, planning the data

467
00:23:04.720 --> 00:23:07.759
<v Speaker 2>structures becomes really important. You need to think ahead about

468
00:23:07.759 --> 00:23:08.480
<v Speaker 2>how data.

469
00:23:08.279 --> 00:23:11.519
<v Speaker 1>Relates and for efficiency, especially if creating objects is slow

470
00:23:11.599 --> 00:23:14.480
<v Speaker 1>or resource intensive, the prototype pattern can help.

471
00:23:14.720 --> 00:23:17.559
<v Speaker 2>The prototype pattern is all about creating new objects by

472
00:23:17.640 --> 00:23:21.599
<v Speaker 2>copying or cloning an existing object instance the prototype.

473
00:23:21.599 --> 00:23:23.480
<v Speaker 1>Why would you do that instead of just using new.

474
00:23:23.519 --> 00:23:27.799
<v Speaker 2>It's beneficial when object creation is computationally expensive, like maybe

475
00:23:27.799 --> 00:23:32.240
<v Speaker 2>calculating complex nutritional info for a custom sandwich, or when

476
00:23:32.279 --> 00:23:34.799
<v Speaker 2>you have an object already configured in a certain state

477
00:23:35.200 --> 00:23:38.000
<v Speaker 2>and you want an exact copy of that state without

478
00:23:38.039 --> 00:23:40.079
<v Speaker 2>repeating the configuration.

479
00:23:39.519 --> 00:23:43.640
<v Speaker 1>Steps like the sequence generation example, calculating prime numbers is slow,

480
00:23:44.039 --> 00:23:46.559
<v Speaker 1>so you pre calculate a sequence and then just clone

481
00:23:46.559 --> 00:23:47.799
<v Speaker 1>it when needed exactly.

482
00:23:48.160 --> 00:23:51.440
<v Speaker 2>The sequence cash holds prototype sequences, and the client code

483
00:23:51.480 --> 00:23:54.880
<v Speaker 2>calls clone on a prototype. Instead of doing the expensive

484
00:23:54.920 --> 00:23:58.119
<v Speaker 2>calculation again, you just need your class to implement the

485
00:23:58.119 --> 00:24:01.599
<v Speaker 2>clonable interface and override the clone method correctly.

486
00:24:01.920 --> 00:24:04.359
<v Speaker 1>Another pattern for flexibility is the decorator pattern.

487
00:24:04.759 --> 00:24:07.839
<v Speaker 2>Decorator is really interesting. It lets you add new responsibilities

488
00:24:07.920 --> 00:24:11.880
<v Speaker 2>or behaviors to individual objects dynamically at run time without

489
00:24:11.960 --> 00:24:16.000
<v Speaker 2>changing the object's class. It's a flexible alternative to subclassing

490
00:24:16.039 --> 00:24:17.400
<v Speaker 2>for extending functionality.

491
00:24:17.519 --> 00:24:19.319
<v Speaker 1>How does that work? Sounds like magic?

492
00:24:19.680 --> 00:24:22.720
<v Speaker 2>Think about adding options to our bread. You could have

493
00:24:22.880 --> 00:24:27.319
<v Speaker 2>subclasses like buttered roll, toasted roll, buttered toasted roll, but

494
00:24:27.480 --> 00:24:30.920
<v Speaker 2>that quickly leads to a class explosion. With decorator, you

495
00:24:30.960 --> 00:24:34.680
<v Speaker 2>have your base bread object like roll. Then you have

496
00:24:34.759 --> 00:24:38.559
<v Speaker 2>decorator classes like butter decorator and toasted decorator, which also

497
00:24:38.599 --> 00:24:40.000
<v Speaker 2>implement the bread interface.

498
00:24:40.079 --> 00:24:42.240
<v Speaker 1>Do you wrap the original object exactly?

499
00:24:42.480 --> 00:24:45.519
<v Speaker 2>You create a roll, then wrap it in a butter decorator,

500
00:24:45.559 --> 00:24:48.839
<v Speaker 2>Then wrap that in a toasted decorator. New toasted decorator,

501
00:24:48.880 --> 00:24:52.640
<v Speaker 2>new butter decorator, new role. Each decorator adds its functionality

502
00:24:53.039 --> 00:24:56.599
<v Speaker 2>like adding cost or changing the description, and then delegates

503
00:24:56.640 --> 00:24:58.559
<v Speaker 2>the call to the object it wraps, so.

504
00:24:58.559 --> 00:25:00.720
<v Speaker 1>You can mix and match decorations on the fly for

505
00:25:00.799 --> 00:25:01.680
<v Speaker 1>any bread object.

506
00:25:02.079 --> 00:25:05.400
<v Speaker 2>Precisely, you could add a double portion decorator for fillings too.

507
00:25:05.559 --> 00:25:07.359
<v Speaker 2>It allows adding features and layers.

508
00:25:07.480 --> 00:25:09.480
<v Speaker 1>It sounds a bit like the builder pattern in terms

509
00:25:09.480 --> 00:25:10.400
<v Speaker 1>of chaining calls.

510
00:25:10.559 --> 00:25:13.480
<v Speaker 2>The syntax can look similar, but the purpose is different.

511
00:25:13.799 --> 00:25:17.200
<v Speaker 2>Builder constructs an object step by step. Decorator takes a

512
00:25:17.200 --> 00:25:20.759
<v Speaker 2>fully formed object and adds extra responsibilities or modifies its

513
00:25:20.759 --> 00:25:24.759
<v Speaker 2>behavior after it's already created. Enhancement versus construction got it.

514
00:25:25.720 --> 00:25:30.359
<v Speaker 1>Moving on to composing patterns, building hierarchies, and making data persistent,

515
00:25:31.160 --> 00:25:33.720
<v Speaker 1>The composite pattern seems key for hierarchies.

516
00:25:34.200 --> 00:25:37.119
<v Speaker 2>It is The composite pattern lets you compose objects into

517
00:25:37.119 --> 00:25:41.599
<v Speaker 2>tree structures to represent part whole hierarchies. Crucially, it allows

518
00:25:41.599 --> 00:25:46.079
<v Speaker 2>clients to treat individual objects, leaves, and compositions of objects

519
00:25:46.240 --> 00:25:48.359
<v Speaker 2>composits uniformly.

520
00:25:48.119 --> 00:25:51.119
<v Speaker 1>Like Android UI layouts. A text view is a leaf.

521
00:25:51.440 --> 00:25:53.960
<v Speaker 1>A linear layout is a composite that can hold leaves

522
00:25:54.039 --> 00:25:54.960
<v Speaker 1>or other composites.

523
00:25:55.160 --> 00:25:58.680
<v Speaker 2>Perfect analogy, you typically have a common component interface that

524
00:25:58.720 --> 00:26:02.559
<v Speaker 2>both leaf objects and compositor objects implement. The composite object

525
00:26:02.680 --> 00:26:06.079
<v Speaker 2>usually holds a list of child components and delegates. Operations

526
00:26:06.160 --> 00:26:08.920
<v Speaker 2>like draw or calculate price to its children.

527
00:26:09.039 --> 00:26:10.960
<v Speaker 1>So you can call the same method on a single

528
00:26:11.119 --> 00:26:13.880
<v Speaker 1>ingredient or a whole custom sandwich object which is a

529
00:26:13.880 --> 00:26:15.480
<v Speaker 1>composite of bread fillings, etc.

530
00:26:15.839 --> 00:26:17.519
<v Speaker 2>Yes, the client code doesn't need to know if it's

531
00:26:17.559 --> 00:26:20.000
<v Speaker 2>dealing with a single item or a complex group. You

532
00:26:20.039 --> 00:26:22.000
<v Speaker 2>mentioned adding a builder to composite.

533
00:26:21.680 --> 00:26:24.000
<v Speaker 1>Ye, and the source suggested it could simplify building complex

534
00:26:24.000 --> 00:26:25.039
<v Speaker 1>composite structures.

535
00:26:25.279 --> 00:26:29.119
<v Speaker 2>It definitely can. Manually creating and nesting composite objects in

536
00:26:29.240 --> 00:26:32.480
<v Speaker 2>code can get for both. A builder can provide a

537
00:26:32.519 --> 00:26:34.599
<v Speaker 2>cleaner API for assembling the tree.

538
00:26:34.720 --> 00:26:38.200
<v Speaker 1>Okay, structures are great, but our app needs to remember things.

539
00:26:38.880 --> 00:26:43.640
<v Speaker 2>Persistent data storage essential for user settings, saved orders, preferences.

540
00:26:44.000 --> 00:26:48.279
<v Speaker 2>Android offers several ways for static unchanging text. Putting text

541
00:26:48.319 --> 00:26:51.279
<v Speaker 2>files in the resrowd directory is simple. They get compiled

542
00:26:51.279 --> 00:26:54.160
<v Speaker 2>into the app. You read them using an input stream.

543
00:26:54.400 --> 00:26:57.640
<v Speaker 2>Good for help text terms and conditions, stuff that doesn't change.

544
00:26:58.039 --> 00:27:01.079
<v Speaker 2>External storage is more for user gen generrated files or

545
00:27:01.319 --> 00:27:02.759
<v Speaker 2>sharing between apps.

546
00:27:02.480 --> 00:27:05.519
<v Speaker 1>But for user preferences like their default delivery address or

547
00:27:05.559 --> 00:27:06.759
<v Speaker 1>maybe dietary flags.

548
00:27:07.039 --> 00:27:10.519
<v Speaker 2>Shared preferences is the go to for simple key value data.

549
00:27:10.640 --> 00:27:13.279
<v Speaker 2>It's perfect for storing user settings. You get a shared

550
00:27:13.319 --> 00:27:17.640
<v Speaker 2>preferences object, use an editor to put values, strings, booleans, integers,

551
00:27:17.680 --> 00:27:20.960
<v Speaker 2>and call apply to save them asynchronously.

552
00:27:20.240 --> 00:27:22.440
<v Speaker 1>And usually load them in on create and save them

553
00:27:22.480 --> 00:27:23.119
<v Speaker 1>in on pause.

554
00:27:23.240 --> 00:27:26.480
<v Speaker 2>That's a common pattern. Yeah, apply saves in the background

555
00:27:26.519 --> 00:27:29.119
<v Speaker 2>so it doesn't block the UI thread, unlike the older

556
00:27:29.119 --> 00:27:29.799
<v Speaker 2>commit method.

557
00:27:30.039 --> 00:27:32.960
<v Speaker 1>The source mentioned a neat trick using shared preferences for

558
00:27:33.039 --> 00:27:34.000
<v Speaker 1>first run detection.

559
00:27:34.319 --> 00:27:36.599
<v Speaker 2>Yeah, you can store a boolean flag like is a

560
00:27:36.599 --> 00:27:39.279
<v Speaker 2>first run check for it when the app starts. If

561
00:27:39.319 --> 00:27:42.000
<v Speaker 2>it's not there or true, you know it's the first launch,

562
00:27:42.160 --> 00:27:44.640
<v Speaker 2>show your onboarding, and then set the flag to false.

563
00:27:45.119 --> 00:27:47.319
<v Speaker 2>Another way is to generate and store a unique ID

564
00:27:47.680 --> 00:27:50.759
<v Speaker 2>using Java dot util dot uid on the first run.

565
00:27:51.079 --> 00:27:53.599
<v Speaker 2>If the ID exists on subsequent launches, it's.

566
00:27:53.440 --> 00:27:56.599
<v Speaker 1>Not the first run clever, okay. Let's shift to how

567
00:27:56.640 --> 00:27:59.440
<v Speaker 1>different parts of the app communicate and react to events,

568
00:28:00.079 --> 00:28:01.079
<v Speaker 1>observing patterns.

569
00:28:01.440 --> 00:28:06.000
<v Speaker 2>This involves patterns that help manage dependencies and notifications between objects,

570
00:28:06.400 --> 00:28:09.440
<v Speaker 2>essential when the app isn't actively in the foreground. User

571
00:28:09.519 --> 00:28:10.960
<v Speaker 2>notifications are key here.

572
00:28:11.039 --> 00:28:13.240
<v Speaker 1>Things that appear in the status bar right.

573
00:28:13.240 --> 00:28:16.799
<v Speaker 2>Usually triggered by background components like services. They alert the

574
00:28:16.880 --> 00:28:19.160
<v Speaker 2>user to something important, even if they're not using the

575
00:28:19.200 --> 00:28:19.920
<v Speaker 2>app right now.

576
00:28:20.160 --> 00:28:22.240
<v Speaker 1>The observer pattern underlies.

577
00:28:21.839 --> 00:28:23.720
<v Speaker 2>A lot of this, doesn't it It does. The observer

578
00:28:23.799 --> 00:28:27.519
<v Speaker 2>pattern defines a one to many dependency between objects. When

579
00:28:27.599 --> 00:28:31.519
<v Speaker 2>one object, the subject or observable, changes state, all its

580
00:28:31.519 --> 00:28:34.039
<v Speaker 2>dependents observers are notified automatically.

581
00:28:34.440 --> 00:28:37.160
<v Speaker 1>Like our sandwich object could be the subject and an

582
00:28:37.240 --> 00:28:40.279
<v Speaker 1>order object could be an observer. When the sandwich is

583
00:28:40.319 --> 00:28:42.759
<v Speaker 1>marked ready, the order gets notified exactly.

584
00:28:42.920 --> 00:28:45.839
<v Speaker 2>The observer registers itself with the subject, and the subject

585
00:28:45.839 --> 00:28:49.680
<v Speaker 2>calls a specific method like update on all its registered

586
00:28:49.680 --> 00:28:52.880
<v Speaker 2>observers when its state changes. Java even has built in

587
00:28:53.119 --> 00:28:56.039
<v Speaker 2>Java dot util dot observer and Java dot util dot

588
00:28:56.039 --> 00:29:00.119
<v Speaker 2>observable classes, though newer approaches using libraries like love data

589
00:29:00.319 --> 00:29:02.160
<v Speaker 2>or arcs java are often preferred.

590
00:29:02.160 --> 00:29:05.440
<v Speaker 1>Now, how does this relate to the Android Notifications API?

591
00:29:05.640 --> 00:29:08.240
<v Speaker 2>The system notifications you see in the status bar are

592
00:29:08.319 --> 00:29:11.160
<v Speaker 2>a way for your app, often a background service acting

593
00:29:11.160 --> 00:29:13.839
<v Speaker 2>as an observer of some event, to notify the user.

594
00:29:14.279 --> 00:29:16.599
<v Speaker 2>The API lets you build these notifications, and it can

595
00:29:16.640 --> 00:29:17.039
<v Speaker 2>be more.

596
00:29:16.880 --> 00:29:19.200
<v Speaker 1>Than just text. Right actions, big pictures?

597
00:29:19.240 --> 00:29:22.720
<v Speaker 2>Oh yeah, You use notification compat dot builder to construct them.

598
00:29:23.000 --> 00:29:26.720
<v Speaker 2>You can set icons, titles, text, vibration patterns, You can

599
00:29:26.759 --> 00:29:30.440
<v Speaker 2>add actions like buttons within the notification using pending intents

600
00:29:30.440 --> 00:29:33.000
<v Speaker 2>that trigger something in your app when tapped. You can

601
00:29:33.039 --> 00:29:36.599
<v Speaker 2>create expanded notifications with big text style, big picture style,

602
00:29:36.680 --> 00:29:39.000
<v Speaker 2>or inbox style to show more content, and.

603
00:29:39.079 --> 00:29:41.599
<v Speaker 1>Newer Android versions have heads up notifications.

604
00:29:41.839 --> 00:29:45.240
<v Speaker 2>API twenty one plus introduced heads up notifications that slide

605
00:29:45.279 --> 00:29:48.640
<v Speaker 2>in briefly at the top and lock screen notifications. You

606
00:29:48.720 --> 00:29:53.000
<v Speaker 2>need to set priorities and visibility flags visibility, public, visibility, private,

607
00:29:53.039 --> 00:29:56.319
<v Speaker 2>et cetera to control where and how your notifications appear

608
00:29:56.799 --> 00:30:00.400
<v Speaker 2>and use them judiciously for important timely info.

609
00:30:00.720 --> 00:30:03.519
<v Speaker 1>You mentioned services triggering these What are services?

610
00:30:03.839 --> 00:30:07.559
<v Speaker 2>Services are Android components designed for running long running operations

611
00:30:07.559 --> 00:30:10.720
<v Speaker 2>in the background without a user interface. Think playing music,

612
00:30:10.880 --> 00:30:14.440
<v Speaker 2>downloading files, or in our case, maybe monitoring an order

613
00:30:14.480 --> 00:30:16.400
<v Speaker 2>status or setting a reminder timer.

614
00:30:16.680 --> 00:30:19.440
<v Speaker 1>So a service could run, detect the sandwiches ready, and

615
00:30:19.480 --> 00:30:22.559
<v Speaker 1>then use the Notifications API to tell the user exactly.

616
00:30:22.799 --> 00:30:26.359
<v Speaker 2>Services have their own life cycle on create, on start, command,

617
00:30:26.480 --> 00:30:29.839
<v Speaker 2>on destroy. It's crucial to manage their life cycle correctly,

618
00:30:30.039 --> 00:30:33.200
<v Speaker 2>especially stopping them stop service or stop self when their

619
00:30:33.240 --> 00:30:34.799
<v Speaker 2>work is done to avoid draining battery.

620
00:30:34.920 --> 00:30:39.279
<v Speaker 1>Okay, moving towards more complex interactions and algorithms behavioral patterns.

621
00:30:39.400 --> 00:30:42.960
<v Speaker 2>These patterns focus on how objects collaborate and distribute responsibilities

622
00:30:42.960 --> 00:30:44.039
<v Speaker 2>to accomplish tasks.

623
00:30:44.279 --> 00:30:45.559
<v Speaker 1>The template pattern is first.

624
00:30:45.759 --> 00:30:48.920
<v Speaker 2>Template defines the skeleton of an algorithm in a base class,

625
00:30:49.240 --> 00:30:53.599
<v Speaker 2>often abstract, but let subclasses override specific steps of that

626
00:30:53.680 --> 00:30:56.440
<v Speaker 2>algorithm without changing the overall structure.

627
00:30:56.960 --> 00:31:00.000
<v Speaker 1>So the base class provides the template the fixed sequel

628
00:31:00.240 --> 00:31:03.960
<v Speaker 1>of steps, and subclasses fill in the implementation details for

629
00:31:04.160 --> 00:31:05.640
<v Speaker 1>some of those steps precisely.

630
00:31:06.000 --> 00:31:08.720
<v Speaker 2>Like a prepare sandwich template method in a base class

631
00:31:08.839 --> 00:31:13.319
<v Speaker 2>might call abstract methods get bread, ad fillings, add toppings.

632
00:31:13.839 --> 00:31:17.599
<v Speaker 2>Concrete subclasses like prepare clip sandwich or prepare veggie sandwich

633
00:31:17.680 --> 00:31:21.160
<v Speaker 2>would implement those abstract methods differently, but the overall prepare

634
00:31:21.200 --> 00:31:22.720
<v Speaker 2>sandwich sequence remains the same.

635
00:31:23.039 --> 00:31:27.039
<v Speaker 1>Got it enforces structure, allows variation in steps. How does

636
00:31:27.079 --> 00:31:28.799
<v Speaker 1>this strategy pattern compare.

637
00:31:28.599 --> 00:31:31.680
<v Speaker 2>Strategy also deals with algorithms, but its focus is on

638
00:31:31.759 --> 00:31:35.960
<v Speaker 2>making a family of algorithms interchangeable. You encapsulate each algorithm

639
00:31:35.960 --> 00:31:39.640
<v Speaker 2>into a separate strategy object, and the context object holds

640
00:31:39.680 --> 00:31:42.240
<v Speaker 2>a reference to one of these strategies and delegates the

641
00:31:42.279 --> 00:31:43.480
<v Speaker 2>algorithmic task to it.

642
00:31:43.680 --> 00:31:45.920
<v Speaker 1>The key difference being you can swap the strategy at

643
00:31:45.960 --> 00:31:46.359
<v Speaker 1>run time.

644
00:31:46.720 --> 00:31:50.640
<v Speaker 2>Yes, that's the main distinction from template, where the implementation

645
00:31:50.799 --> 00:31:54.559
<v Speaker 2>is fixed by the subclass at compile time. With strategy,

646
00:31:54.640 --> 00:31:58.799
<v Speaker 2>the context object can change which strategy it uses whenever needed.

647
00:31:58.759 --> 00:32:03.279
<v Speaker 1>Like having different delivery strategies flat rate strategy, distance based strategy,

648
00:32:03.440 --> 00:32:06.000
<v Speaker 1>rush hour strategy, and choosing the right one based on

649
00:32:06.039 --> 00:32:07.240
<v Speaker 1>the order time or location.

650
00:32:07.480 --> 00:32:11.160
<v Speaker 2>Perfect example, the order object the context would hold a

651
00:32:11.200 --> 00:32:15.079
<v Speaker 2>pricing strategy object and call its calculate price method. You

652
00:32:15.119 --> 00:32:18.160
<v Speaker 2>can easily swap in a different strategy object to change

653
00:32:18.200 --> 00:32:19.039
<v Speaker 2>the pricing logic.

654
00:32:19.240 --> 00:32:21.920
<v Speaker 1>Okay. The visitor pattern seems a bit more involved.

655
00:32:22.119 --> 00:32:24.880
<v Speaker 2>Visitor lets you add new operations to a set of

656
00:32:24.920 --> 00:32:29.519
<v Speaker 2>existing classes without modifying those classes. It separates the algorithm

657
00:32:29.599 --> 00:32:30.799
<v Speaker 2>from the object structure.

658
00:32:30.799 --> 00:32:35.079
<v Speaker 1>It operates on supermarket analogy. The cashier visitor knows how

659
00:32:35.119 --> 00:32:38.759
<v Speaker 1>to process different items visited elements without the items needing

660
00:32:38.759 --> 00:32:41.599
<v Speaker 1>to know about the cashier specific process exactly.

661
00:32:41.640 --> 00:32:45.200
<v Speaker 2>You have an item interface with an accept visitor v method.

662
00:32:45.920 --> 00:32:50.119
<v Speaker 2>Concrete items, bread, filling, drink implement this method, usually by

663
00:32:50.119 --> 00:32:53.799
<v Speaker 2>calling visitor dot visit this. Then you have a visitor

664
00:32:53.799 --> 00:32:57.839
<v Speaker 2>interface with overloaded visit methods for each concrete item type

665
00:32:58.079 --> 00:32:59.960
<v Speaker 2>visit breadbe, visit filling F.

666
00:33:00.480 --> 00:33:04.640
<v Speaker 1>So a calculat price visitor would implement visit breadbe to

667
00:33:04.640 --> 00:33:06.759
<v Speaker 1>get the bread price, visit filling F to get the

668
00:33:06.759 --> 00:33:07.839
<v Speaker 1>filling price, et cetera.

669
00:33:08.160 --> 00:33:11.720
<v Speaker 2>Right, and later you could add a generate nutritional info

670
00:33:11.799 --> 00:33:14.440
<v Speaker 2>visitor with its own set of visit methods, all without

671
00:33:14.440 --> 00:33:18.000
<v Speaker 2>ever changing the bread, filling, or drink classes. It avoids

672
00:33:18.039 --> 00:33:20.880
<v Speaker 2>polluting your element classes with lots of different operations and

673
00:33:20.920 --> 00:33:23.200
<v Speaker 2>makes adding new operations easier.

674
00:33:23.039 --> 00:33:28.200
<v Speaker 1>Useful for complex processing on diverse object structures. Finally, the state.

675
00:33:27.960 --> 00:33:31.160
<v Speaker 2>Pattern state allows an object to alter its behavior when

676
00:33:31.160 --> 00:33:34.319
<v Speaker 2>its internal state changes to the outside world. The object

677
00:33:34.319 --> 00:33:35.799
<v Speaker 2>appears to change its class.

678
00:33:35.960 --> 00:33:39.720
<v Speaker 1>Like the turnstyle example, it behaves differently push coin depending

679
00:33:39.759 --> 00:33:41.759
<v Speaker 1>on whether it's in the locked or unlocked state.

680
00:33:42.000 --> 00:33:46.079
<v Speaker 2>Yes, you define a state interface and concrete state classes

681
00:33:46.319 --> 00:33:51.039
<v Speaker 2>lock state, unlocked state. The context object the turnstyle holds

682
00:33:51.039 --> 00:33:54.039
<v Speaker 2>a reference to its current state object. When a method

683
00:33:54.119 --> 00:33:57.480
<v Speaker 2>like push is called on the context, it delegates the

684
00:33:57.519 --> 00:33:59.960
<v Speaker 2>call to the current state object current stage out push

685
00:34:00.640 --> 00:34:03.480
<v Speaker 2>the state object handles the logic for that state, and

686
00:34:03.519 --> 00:34:06.680
<v Speaker 2>can also change the context's current state to transition it

687
00:34:07.200 --> 00:34:09.400
<v Speaker 2>context dot sets state.

688
00:34:09.320 --> 00:34:12.519
<v Speaker 1>Unlock state, so the behavior logic is encapsulated within each

689
00:34:12.559 --> 00:34:16.840
<v Speaker 1>state class. Makes handling state dependent behavior much cleaner than

690
00:34:16.960 --> 00:34:20.360
<v Speaker 1>massive I, false or switch statements in the context.

691
00:34:19.880 --> 00:34:23.880
<v Speaker 2>Object exactly very useful for modeling anything with distinct states

692
00:34:23.880 --> 00:34:27.400
<v Speaker 2>and transitions, like workflows, game characters, connection statuses.

693
00:34:27.440 --> 00:34:31.800
<v Speaker 1>We've mostly talked phone tablet but Android is on watches, TVs, cars,

694
00:34:32.079 --> 00:34:33.880
<v Speaker 1>wearable patterns, and other form factors.

695
00:34:33.960 --> 00:34:37.360
<v Speaker 2>Right. Developing for Android ware, now Ware OS, Android TV,

696
00:34:37.440 --> 00:34:41.159
<v Speaker 2>and Android Auto presents different challenges and opportunities. Screen size,

697
00:34:41.199 --> 00:34:43.840
<v Speaker 2>input methods, user context all very different.

698
00:34:43.920 --> 00:34:47.360
<v Speaker 1>Android TV big screen remote control input yeah.

699
00:34:47.360 --> 00:34:51.880
<v Speaker 2>Ten foot UI experience. Androids Studio has TV module templates.

700
00:34:52.199 --> 00:34:55.440
<v Speaker 2>You'll use the leanback support library for TV specific UI

701
00:34:55.480 --> 00:35:00.519
<v Speaker 2>components like rows and grids optimized for remote navigation. The

702
00:35:00.679 --> 00:35:04.559
<v Speaker 2>MVP model view presenter pattern is often recommended for structuring the.

703
00:35:04.519 --> 00:35:08.679
<v Speaker 1>App logic and specific requirements for things like recommendation card

704
00:35:08.760 --> 00:35:09.519
<v Speaker 1>background images.

705
00:35:09.679 --> 00:35:13.519
<v Speaker 2>Yes, very specific dimensions and bleed requirements much larger than

706
00:35:13.559 --> 00:35:17.880
<v Speaker 2>typical phone assets. Graphics quality really matters on a big

707
00:35:17.920 --> 00:35:18.920
<v Speaker 2>TV screen.

708
00:35:18.760 --> 00:35:19.840
<v Speaker 1>Than tiny screens.

709
00:35:20.360 --> 00:35:23.880
<v Speaker 2>Android ware os often companion apps linked to a phone,

710
00:35:23.960 --> 00:35:27.480
<v Speaker 2>but increasingly capable standalone apps too. They have access to

711
00:35:27.559 --> 00:35:30.960
<v Speaker 2>unique sensors like heart rate monitors, opening new possibilities. Maybe

712
00:35:30.960 --> 00:35:34.199
<v Speaker 2>our sandwich app suggests healthier options based on your activity level.

713
00:35:35.000 --> 00:35:37.800
<v Speaker 1>The big challenge there are screen shape right square versus.

714
00:35:37.519 --> 00:35:40.760
<v Speaker 2>Round YEP two main approaches. Create separate layout files for

715
00:35:40.840 --> 00:35:44.039
<v Speaker 2>square and round screens reslayout and reslay out round, or

716
00:35:44.159 --> 00:35:47.079
<v Speaker 2>use the watch view stub component in your layout. Watch

717
00:35:47.159 --> 00:35:50.079
<v Speaker 2>v stub detects the screen shape at runtime and inflates

718
00:35:50.119 --> 00:35:52.079
<v Speaker 2>either erect layout or round layout you.

719
00:35:52.000 --> 00:35:53.840
<v Speaker 1>Specify reading sensors like heart rate.

720
00:35:53.960 --> 00:35:57.360
<v Speaker 2>Uses the standard Android sensor manager and sensor event listener

721
00:35:57.400 --> 00:36:00.000
<v Speaker 2>in her face, just like on a phone, Get the manager,

722
00:36:00.360 --> 00:36:03.159
<v Speaker 2>get the default sensor EVEG sensor dot type, hart rate,

723
00:36:03.639 --> 00:36:06.920
<v Speaker 2>register your listener and get data in on sensor changed.

724
00:36:07.519 --> 00:36:10.719
<v Speaker 2>Always check if the sensor actually exists on the specific watch.

725
00:36:10.519 --> 00:36:14.639
<v Speaker 1>Model first, and Android auto safety is paramount.

726
00:36:14.119 --> 00:36:18.440
<v Speaker 2>Absolutely number one priority. App functionality is heavily restricted to

727
00:36:18.559 --> 00:36:22.360
<v Speaker 2>minimize driver distraction. Primarily it's for audio, music apps and

728
00:36:22.360 --> 00:36:23.119
<v Speaker 2>messaging apps.

729
00:36:23.440 --> 00:36:25.719
<v Speaker 1>Strict guidelines and testing very strict.

730
00:36:25.920 --> 00:36:30.440
<v Speaker 2>Google has detailed design guidelines about layout, font sizes, interaction models.

731
00:36:30.639 --> 00:36:34.480
<v Speaker 2>Voice input is key. Avoiding animations or delays you need

732
00:36:34.519 --> 00:36:38.800
<v Speaker 2>to use autosimulators for testing. App configuration involves manifest meather data,

733
00:36:38.800 --> 00:36:41.719
<v Speaker 2>linking to an XML descriptor file, declaring the app type

734
00:36:41.840 --> 00:36:45.039
<v Speaker 2>media or messaging, and requiring specific background services.

735
00:36:45.119 --> 00:36:46.760
<v Speaker 1>Okay, to get our app out there and maybe make

736
00:36:46.840 --> 00:36:49.360
<v Speaker 1>some money. Social patterns and distribution patterns.

737
00:36:49.480 --> 00:36:52.199
<v Speaker 2>Social integration can be a huge boost for discovery and

738
00:36:52.239 --> 00:36:54.000
<v Speaker 2>engagement likes shares.

739
00:36:54.159 --> 00:36:56.599
<v Speaker 1>The webew component seems versatile here it is.

740
00:36:56.800 --> 00:36:59.679
<v Speaker 2>WebView lets you display web pages directly inside your app.

741
00:36:59.679 --> 00:37:03.840
<v Speaker 2>Back to useful for showing help documentation, hosted online terms

742
00:37:03.840 --> 00:37:07.159
<v Speaker 2>of service, or even building parts of your app using webtech.

743
00:37:07.360 --> 00:37:10.199
<v Speaker 2>If content needs frequent updates without pushing an app update

744
00:37:10.519 --> 00:37:12.599
<v Speaker 2>needs the Internet permission obviously.

745
00:37:12.320 --> 00:37:14.119
<v Speaker 1>Just add it to your layout and call load to role.

746
00:37:14.239 --> 00:37:17.639
<v Speaker 2>Basically yes. For more advanced stuff, you can enable JavaScript

747
00:37:17.719 --> 00:37:21.000
<v Speaker 2>and use the JavaScript interface. This lets your web page's

748
00:37:21.079 --> 00:37:24.599
<v Speaker 2>JavaScript call native Java methods in your Android app.

749
00:37:24.719 --> 00:37:25.519
<v Speaker 1>How does that work?

750
00:37:25.679 --> 00:37:29.559
<v Speaker 2>You create a Java class with methods annotated at JavaScript interface.

751
00:37:30.079 --> 00:37:32.320
<v Speaker 2>You add an instance of this class to the WebView

752
00:37:32.440 --> 00:37:36.199
<v Speaker 2>using ad JavaScript interface. Then JavaScript code in the webpage

753
00:37:36.280 --> 00:37:41.400
<v Speaker 2>can call those annotated methods directly, allowing two way communication. Powerful,

754
00:37:41.519 --> 00:37:44.639
<v Speaker 2>but needs careful security considerations.

755
00:37:43.880 --> 00:37:45.199
<v Speaker 1>For direct social sharing.

756
00:37:45.440 --> 00:37:48.920
<v Speaker 2>Facebook requires the Facebook SDK. You add it as a

757
00:37:48.920 --> 00:37:51.800
<v Speaker 2>dependency set up a Facebook app I d add it

758
00:37:51.800 --> 00:37:55.199
<v Speaker 2>to your strings, dot xml and manifest. Then you can

759
00:37:55.320 --> 00:37:58.000
<v Speaker 2>use their pre built UI components like like view or

760
00:37:58.079 --> 00:38:02.440
<v Speaker 2>share button directly in your layouts. Sharing content links photos

761
00:38:02.480 --> 00:38:05.440
<v Speaker 2>is done via their API, usually requiring a content provider

762
00:38:05.440 --> 00:38:08.199
<v Speaker 2>set up in your manifest. For sharing local files, their

763
00:38:08.280 --> 00:38:11.000
<v Speaker 2>sharing Debugger tool is essential for testing how your shared

764
00:38:11.039 --> 00:38:14.000
<v Speaker 2>posts will look. Pure similar idea, you can use the

765
00:38:14.039 --> 00:38:18.480
<v Speaker 2>Twitter SDK, often integrated via fabric Firebase, for simple tweeting.

766
00:38:18.519 --> 00:38:20.559
<v Speaker 2>You might even just use an intent with a specific

767
00:38:20.639 --> 00:38:24.400
<v Speaker 2>Twitter dot Com intent tweet url structure. The SDK offers

768
00:38:24.400 --> 00:38:26.440
<v Speaker 2>more for timelines, direct messaging, et cetera.

769
00:38:26.639 --> 00:38:29.320
<v Speaker 1>Finally, getting the app to users distribution.

770
00:38:29.079 --> 00:38:32.360
<v Speaker 2>Before you publish anywhere, crucial checks remove all log statements

771
00:38:32.440 --> 00:38:35.400
<v Speaker 2>used for debugging, ensure your app has a proper application

772
00:38:35.480 --> 00:38:39.079
<v Speaker 2>label ANDROIDBAT label in icon, android dot icon defined in

773
00:38:39.119 --> 00:38:42.039
<v Speaker 2>the Android manifest dot xml, and double check that all

774
00:38:42.079 --> 00:38:45.199
<v Speaker 2>required permissions uses permission are declared.

775
00:38:44.800 --> 00:38:46.719
<v Speaker 1>In the manifest. The main distribution channel is.

776
00:38:46.719 --> 00:38:50.320
<v Speaker 2>Google play Right that involves generating a signed release build

777
00:38:50.480 --> 00:38:54.960
<v Speaker 2>APK or the preferred Android app bundle AaB, registering for

778
00:38:55.000 --> 00:38:57.719
<v Speaker 2>a Google Play Developer account, which has a one time fee,

779
00:38:58.000 --> 00:39:00.840
<v Speaker 2>and uploading your app bundle through the Play console, filling

780
00:39:00.840 --> 00:39:03.679
<v Speaker 2>in store, listing details, screenshots.

781
00:39:02.920 --> 00:39:04.599
<v Speaker 1>Et cetera. Are there other options?

782
00:39:04.679 --> 00:39:08.039
<v Speaker 2>Sure, you can host the apkab on your own website

783
00:39:08.039 --> 00:39:12.079
<v Speaker 2>for direct download or distribute it via email or other platforms,

784
00:39:12.280 --> 00:39:15.800
<v Speaker 2>but Google Play offers the widest reach. Automatic updates and

785
00:39:15.840 --> 00:39:17.360
<v Speaker 2>discovery features.

786
00:39:16.920 --> 00:39:19.760
<v Speaker 1>And making money monetization.

787
00:39:19.360 --> 00:39:22.559
<v Speaker 2>Two main routes in at billing, selling digital goods or

788
00:39:22.559 --> 00:39:24.280
<v Speaker 2>subscriptions and advertising.

789
00:39:24.440 --> 00:39:26.519
<v Speaker 1>In that billing sounds complex.

790
00:39:26.159 --> 00:39:29.320
<v Speaker 2>It can be. Google provides the Play Billing Library, which

791
00:39:29.320 --> 00:39:32.679
<v Speaker 2>simplifies it greatly compared to the older ADL approach mentioned

792
00:39:32.679 --> 00:39:35.880
<v Speaker 2>in some sources. You add the library dependency, use the

793
00:39:35.880 --> 00:39:39.159
<v Speaker 2>billing client API to query products, launch purchase flows, and

794
00:39:39.199 --> 00:39:42.920
<v Speaker 2>handle purchases. You still need the colm dot Android dot

795
00:39:43.000 --> 00:39:45.199
<v Speaker 2>vending dot billing permission and need to set up your

796
00:39:45.239 --> 00:39:49.159
<v Speaker 2>products in Play console. Security, like verifying purchases on your.

797
00:39:49.079 --> 00:39:52.559
<v Speaker 1>Server is important, and ads usually Google ad Mob.

798
00:39:52.519 --> 00:39:55.000
<v Speaker 2>That's the most common. You need an ad mob account.

799
00:39:55.480 --> 00:39:58.800
<v Speaker 2>Add the Google Mobile Ads SDK dependency part of Google

800
00:39:58.800 --> 00:40:02.519
<v Speaker 2>Play services. Add Internet and access network state permissions to

801
00:40:02.559 --> 00:40:05.800
<v Speaker 2>your manifest plus some metadata and an AD activity declaration.

802
00:40:05.960 --> 00:40:07.960
<v Speaker 1>Then put an adview in the layout yep.

803
00:40:07.800 --> 00:40:11.360
<v Speaker 2>Add an adview to your XML layout, configure its size

804
00:40:11.400 --> 00:40:15.159
<v Speaker 2>and your unique AD unit ID. Then in your activity code,

805
00:40:15.239 --> 00:40:20.400
<v Speaker 2>create an AD request and call adview dot loaded ad request. Crucially,

806
00:40:20.559 --> 00:40:23.239
<v Speaker 2>during development, make sure you can figure it to request

807
00:40:23.440 --> 00:40:26.840
<v Speaker 2>test ads, either by registering your device ID or using

808
00:40:26.880 --> 00:40:29.760
<v Speaker 2>the emulator so you don't violate ad MOB policies.

809
00:40:29.840 --> 00:40:32.760
<v Speaker 1>Wow. Okay, so we've gone from the basic idea of

810
00:40:32.800 --> 00:40:36.719
<v Speaker 1>a sandwich app through defining patterns, building UI for different devices,

811
00:40:36.760 --> 00:40:40.360
<v Speaker 1>handling data, background tasks, social features, all the way to

812
00:40:40.480 --> 00:40:41.599
<v Speaker 1>publishing and monetizing.

813
00:40:41.719 --> 00:40:44.400
<v Speaker 2>It really highlights how these patterns weave through the entire

814
00:40:44.440 --> 00:40:48.880
<v Speaker 2>development process. They provide structure, solve recurring problems, and guide

815
00:40:48.920 --> 00:40:52.280
<v Speaker 2>you towards writing code that's more robust, flexible, and maintainable.

816
00:40:52.559 --> 00:40:55.440
<v Speaker 2>They're not just academic exercises, the practical tools for building

817
00:40:55.440 --> 00:40:56.239
<v Speaker 2>better software.

818
00:40:56.360 --> 00:41:00.000
<v Speaker 1>Seeing how factory helps create ingredients, builder assembles the same

819
00:41:00.039 --> 00:41:03.880
<v Speaker 1>now which rule like review displays lists, observer handles updates,

820
00:41:04.239 --> 00:41:08.800
<v Speaker 1>state manages, order progress. It makes the value really clear exactly.

821
00:41:08.840 --> 00:41:11.400
<v Speaker 2>They give you a shared language and proven approaches to

822
00:41:11.440 --> 00:41:12.360
<v Speaker 2>common challenges.

823
00:41:12.719 --> 00:41:15.280
<v Speaker 1>So maybe the final thought for everyone listening is this.

824
00:41:16.039 --> 00:41:18.360
<v Speaker 1>As you start your next project, or even just tackle

825
00:41:18.400 --> 00:41:20.880
<v Speaker 1>a new feature, pause for a moment. Think about the

826
00:41:20.920 --> 00:41:23.599
<v Speaker 1>problem you're trying to solve. Is there a pattern here?

827
00:41:24.000 --> 00:41:28.039
<v Speaker 1>Could applying a pattern like decorator, strategy or facade simplify

828
00:41:28.079 --> 00:41:31.360
<v Speaker 1>your design, make it more flexible, or prevent future headaches.

829
00:41:31.920 --> 00:41:34.800
<v Speaker 1>Howmit thinking about patterns from the start, change the way

830
00:41:34.840 --> 00:41:37.159
<v Speaker 1>you approach building, not just for phones, but for the

831
00:41:37.199 --> 00:41:39.599
<v Speaker 1>whole diverse ecosystem of Android devices.