WEBVTT

1
00:00:00.080 --> 00:00:04.559
<v Speaker 1>Okay, let's unpack this. In a world just drowning in information,

2
00:00:04.759 --> 00:00:07.280
<v Speaker 1>where does a busy, curious mind go, you know, to

3
00:00:07.280 --> 00:00:09.800
<v Speaker 1>get genuinely well informed fast. You want the gold, the

4
00:00:09.839 --> 00:00:13.039
<v Speaker 1>surprising facts, the practical insights, without getting bogged down in

5
00:00:13.080 --> 00:00:16.800
<v Speaker 1>every single detail. And well, that's exactly our mission today.

6
00:00:17.079 --> 00:00:19.320
<v Speaker 1>We're taking a deep dive into the fascinating world of

7
00:00:19.359 --> 00:00:23.160
<v Speaker 1>building Android applications using Python, specifically with a framework called

8
00:00:23.199 --> 00:00:25.760
<v Speaker 1>kiv Our. Core material for this deep dive comes from

9
00:00:25.800 --> 00:00:28.920
<v Speaker 1>a really insightful guide building Android apps in Python using

10
00:00:29.000 --> 00:00:32.679
<v Speaker 1>Kivy with androids Studio with Pigeonius Plier and Buildozer by

11
00:00:32.719 --> 00:00:35.759
<v Speaker 1>Ahmed Fazzy Mohammed Gad. So we're here to extract those

12
00:00:35.799 --> 00:00:38.719
<v Speaker 1>essential nuggets, those aha moments and the practical knowledge, the

13
00:00:38.759 --> 00:00:40.479
<v Speaker 1>stuff that will let you walk away with a solid

14
00:00:40.520 --> 00:00:43.679
<v Speaker 1>grasp of out Python can well conger mobile development.

15
00:00:43.880 --> 00:00:47.079
<v Speaker 2>Yeah. And what's truly fascinating here is how this approach

16
00:00:47.200 --> 00:00:51.200
<v Speaker 2>radically challenges the traditional landscape. I mean, for years, Java

17
00:00:51.280 --> 00:00:54.479
<v Speaker 2>and Cotlin have been the undisputed kings of Android development.

18
00:00:55.159 --> 00:00:58.880
<v Speaker 2>This deep dive explores a really compelling alternative. It's one

19
00:00:58.920 --> 00:01:02.039
<v Speaker 2>that allows the huge community of Python developers to leap

20
00:01:02.039 --> 00:01:05.599
<v Speaker 2>into the mobile space using skills they already possess. That's

21
00:01:05.640 --> 00:01:06.799
<v Speaker 2>a game changer for many.

22
00:01:06.879 --> 00:01:09.079
<v Speaker 1>Really, that's a great point. It really does challenge the

23
00:01:09.120 --> 00:01:12.319
<v Speaker 1>status quo, doesn't it. So for someone maybe steeped in

24
00:01:12.439 --> 00:01:16.079
<v Speaker 1>Java or colin, what's the single most compelling reason they

25
00:01:16.079 --> 00:01:20.920
<v Speaker 1>should even consider this alternative beyond just its Python? Let's

26
00:01:20.959 --> 00:01:24.359
<v Speaker 1>kick things off with the kiv Foundation. Why Python for Android?

27
00:01:24.519 --> 00:01:25.799
<v Speaker 1>What exactly is kivy?

28
00:01:26.040 --> 00:01:29.159
<v Speaker 2>Well, okay, at its heart, kivy is a cross platform

29
00:01:29.200 --> 00:01:32.560
<v Speaker 2>Python framework. It's designed for building applications with what they

30
00:01:32.560 --> 00:01:35.680
<v Speaker 2>call a natural user interface or NUI. Now, this isn't

31
00:01:35.719 --> 00:01:38.079
<v Speaker 2>just about making buttons look nice. It's about making interfaces

32
00:01:38.079 --> 00:01:41.599
<v Speaker 2>feel intuitive, responsive, almost you know, touch first. But the

33
00:01:41.599 --> 00:01:44.079
<v Speaker 2>real hook, as you said, is cross platform. Write your

34
00:01:44.120 --> 00:01:47.560
<v Speaker 2>kiv code once and it runs unchanged on Windows, Linux, Mac,

35
00:01:47.640 --> 00:01:49.120
<v Speaker 2>Android and iOS devices.

36
00:01:49.200 --> 00:01:49.599
<v Speaker 1>Wow.

37
00:01:49.680 --> 00:01:52.560
<v Speaker 2>For a developer, that means huge time savings and reaching

38
00:01:52.560 --> 00:01:56.400
<v Speaker 2>a much wider audience. And thinking about the author's background

39
00:01:56.439 --> 00:02:01.560
<v Speaker 2>in deep learning machine learning, it just shows python incredible versatility. Right,

40
00:02:01.599 --> 00:02:04.239
<v Speaker 2>It's no longer just stuck in data science or web

41
00:02:04.239 --> 00:02:08.120
<v Speaker 2>back ends. It's actually powering interactive mobile applications.

42
00:02:07.519 --> 00:02:10.680
<v Speaker 1>Now that truly sounds like a developer's dream right once

43
00:02:11.039 --> 00:02:14.360
<v Speaker 1>run everywhere. So KIV is powerful, but it's not a

44
00:02:14.360 --> 00:02:17.360
<v Speaker 1>magic bullet on its own, is it? What's the unsung

45
00:02:17.400 --> 00:02:20.039
<v Speaker 1>hero here? The thing that truly bridges the gap between

46
00:02:20.080 --> 00:02:24.479
<v Speaker 1>your Python code and a working Android app? Yeah, and thybeah.

47
00:02:24.520 --> 00:02:27.159
<v Speaker 1>What's one surprising thing it handles that most developers dread?

48
00:02:27.360 --> 00:02:30.599
<v Speaker 2>Ah? That would be Bill Dozer. Absolutely think of Billdozer

49
00:02:30.639 --> 00:02:34.039
<v Speaker 2>as your personal mobile app construction crew. Its core function

50
00:02:34.159 --> 00:02:36.919
<v Speaker 2>is to take your KIPI Python project and meticulously package

51
00:02:36.960 --> 00:02:40.319
<v Speaker 2>it into an Android studio project. Then ultimately it compiles

52
00:02:40.319 --> 00:02:43.520
<v Speaker 2>it into that installable Android application package, the APK.

53
00:02:43.280 --> 00:02:44.680
<v Speaker 1>File oka the APK.

54
00:02:44.560 --> 00:02:48.879
<v Speaker 2>And one truly surprising, well helpful fact is how it

55
00:02:48.919 --> 00:02:53.039
<v Speaker 2>automates the whole Android SDK and NDK setup. Native development

56
00:02:53.159 --> 00:02:57.680
<v Speaker 2>often involves hours of you know, versioning, headaches and dependency. Hell,

57
00:02:58.080 --> 00:03:01.159
<v Speaker 2>Billdozer either fetches exactly what it needs or just lets

58
00:03:01.159 --> 00:03:04.639
<v Speaker 2>you point to your offline tools. It's a huge time saver, So.

59
00:03:04.719 --> 00:03:08.039
<v Speaker 1>It handles the messy bits automatically. Yes, how do you,

60
00:03:08.439 --> 00:03:11.879
<v Speaker 1>as the developer tell Billdozer what your app actually needs?

61
00:03:11.919 --> 00:03:14.159
<v Speaker 1>Is there like a central control panel for it?

62
00:03:14.319 --> 00:03:18.080
<v Speaker 2>Exactly Yeah. This entire packaging process is largely configured through

63
00:03:18.159 --> 00:03:21.120
<v Speaker 2>just one single file called billdozer dot.

64
00:03:20.960 --> 00:03:22.240
<v Speaker 1>Spec build dozer dot spec.

65
00:03:22.280 --> 00:03:24.639
<v Speaker 2>Okay, it's like the DNA of your app. Inside you

66
00:03:24.719 --> 00:03:28.120
<v Speaker 2>define crucial characteristics like your app's titles, say first app,

67
00:03:28.360 --> 00:03:31.599
<v Speaker 2>and unique identifiers like package dot name and package dot domain.

68
00:03:31.800 --> 00:03:34.280
<v Speaker 2>Those are absolutely vital for publishing later. You point it

69
00:03:34.319 --> 00:03:36.400
<v Speaker 2>to your main Python file using source dot dr. And

70
00:03:36.439 --> 00:03:40.159
<v Speaker 2>here's a really neat part the requirements proper. Right, You

71
00:03:40.199 --> 00:03:44.560
<v Speaker 2>simply list all the Python libraries your app needs, KIV, NumPy, whatever,

72
00:03:44.759 --> 00:03:48.280
<v Speaker 2>and Billdozer automatically downloads and links them, no manual fuss.

73
00:03:48.759 --> 00:03:53.319
<v Speaker 2>You also specify visual assets, define screen orientation, and critically

74
00:03:53.439 --> 00:03:56.840
<v Speaker 2>list the Android dot permissions your app requires, like Internet

75
00:03:56.960 --> 00:04:01.039
<v Speaker 2>or camera. Builldozer translates these directly to the androm manifest

76
00:04:01.039 --> 00:04:03.400
<v Speaker 2>dot xml file. It's incredibly efficient.

77
00:04:03.719 --> 00:04:06.599
<v Speaker 1>Okay, we've talked about the building blocks KIV and Billdozer,

78
00:04:07.240 --> 00:04:09.759
<v Speaker 1>but how do you truly bring your Python code to

79
00:04:09.919 --> 00:04:13.000
<v Speaker 1>life like seeing it run on an actual Android device.

80
00:04:13.199 --> 00:04:15.800
<v Speaker 1>Let's walk through that journey. Taking your very first Kidi

81
00:04:15.879 --> 00:04:17.920
<v Speaker 1>app from your desktop right into your hands. How does

82
00:04:17.959 --> 00:04:18.360
<v Speaker 1>that work?

83
00:04:18.519 --> 00:04:21.040
<v Speaker 2>Right? Well, the best practice, and what the book recommends

84
00:04:21.120 --> 00:04:23.879
<v Speaker 2>is to start simple. Build your kiv application first as

85
00:04:23.920 --> 00:04:24.759
<v Speaker 2>a desktop app.

86
00:04:24.879 --> 00:04:26.480
<v Speaker 1>Oh okay, desktop first.

87
00:04:26.560 --> 00:04:29.720
<v Speaker 2>Yeah. This lets you quickly iterate, test your logic, make

88
00:04:29.759 --> 00:04:33.040
<v Speaker 2>sure everything's working perfectly before you even think about mobile deployment.

89
00:04:33.519 --> 00:04:37.399
<v Speaker 2>The desktop phase is basically your debugging sandbox that makes sense.

90
00:04:37.839 --> 00:04:40.240
<v Speaker 1>And when you're mapping out that initial desktop app the

91
00:04:40.399 --> 00:04:43.680
<v Speaker 1>UI part, where do you focus? Is there a specific

92
00:04:44.279 --> 00:04:48.199
<v Speaker 1>kiv tool for separating the visual design from the actual code.

93
00:04:48.519 --> 00:04:52.000
<v Speaker 2>Absolutely. Kivy has its own specialized design language. It's called

94
00:04:52.079 --> 00:04:55.240
<v Speaker 2>kV language PD language. It's a declarative way to define

95
00:04:55.279 --> 00:04:58.360
<v Speaker 2>your user interface. It lets you elegantly separate the visual

96
00:04:58.399 --> 00:05:01.519
<v Speaker 2>design from your Python logic, which keeps your code clean

97
00:05:01.680 --> 00:05:04.560
<v Speaker 2>and your UI flexible. So, for example, instead of writing

98
00:05:04.560 --> 00:05:07.600
<v Speaker 2>lots of Python code to define every button's position and size,

99
00:05:07.680 --> 00:05:09.279
<v Speaker 2>you can do most of that in the kV file,

100
00:05:09.519 --> 00:05:12.120
<v Speaker 2>and within that you'll work with core UI concepts like

101
00:05:12.199 --> 00:05:14.959
<v Speaker 2>box layout that's a container that organizes things neatly in

102
00:05:15.040 --> 00:05:18.160
<v Speaker 2>rows or columns, and then common widgets like text input

103
00:05:18.240 --> 00:05:20.920
<v Speaker 2>for user input, label for text, and of course button

104
00:05:20.959 --> 00:05:24.199
<v Speaker 2>for interaction. kV handles the on press event for buttons

105
00:05:24.279 --> 00:05:26.759
<v Speaker 2>letting you easily connect taps to your Python functions.

106
00:05:26.839 --> 00:05:30.759
<v Speaker 1>Got it. So, once your desktop app is solid, looks good,

107
00:05:31.240 --> 00:05:33.600
<v Speaker 1>the transition to Android sounds like the moment of truth.

108
00:05:33.639 --> 00:05:36.160
<v Speaker 1>How smooth is that with Billdozer? Is it complicated?

109
00:05:36.639 --> 00:05:42.839
<v Speaker 2>It's surprisingly seamless. Honestly, Billdozer offers a single, really powerful command,

110
00:05:43.279 --> 00:05:47.680
<v Speaker 2>buildozer Android debug deploy run one command, one command. It

111
00:05:47.720 --> 00:05:51.120
<v Speaker 2>handles the entire pipeline. It builds your APK. Then if

112
00:05:51.160 --> 00:05:54.639
<v Speaker 2>you have a USB connected Android device with USB debugging enabled,

113
00:05:54.720 --> 00:05:57.639
<v Speaker 2>that's important. It deploys the app directly to it and

114
00:05:57.680 --> 00:06:01.759
<v Speaker 2>even launches it automatically. Anyone who's wrestled with manual APK

115
00:06:01.920 --> 00:06:06.279
<v Speaker 2>transfers or complex build scripts before, well, this feels like magic.

116
00:06:06.399 --> 00:06:08.120
<v Speaker 2>It really streamlines the whole process.

117
00:06:08.160 --> 00:06:11.120
<v Speaker 1>That's incredibly efficient. So once you've tested it on your device,

118
00:06:11.560 --> 00:06:14.120
<v Speaker 1>hammered out the bugs, and you're ready for the big stage. Right,

119
00:06:14.279 --> 00:06:17.879
<v Speaker 1>how does publishing work? Getting it onto Google Play? Right?

120
00:06:17.959 --> 00:06:20.079
<v Speaker 2>So publishing is the next logical step. For that, you'd

121
00:06:20.160 --> 00:06:24.000
<v Speaker 2>use a slightly different command, buildozer Android release release.

122
00:06:24.079 --> 00:06:24.399
<v Speaker 1>Okay.

123
00:06:24.639 --> 00:06:27.639
<v Speaker 2>This command creates a release version of your APK, which

124
00:06:27.639 --> 00:06:31.759
<v Speaker 2>is optimized for distribution. This release APK then needs to

125
00:06:31.800 --> 00:06:34.639
<v Speaker 2>be digitally signed. That's a crucial step for security and

126
00:06:34.680 --> 00:06:38.319
<v Speaker 2>identity verification. After signing, you can upload it to platforms

127
00:06:38.319 --> 00:06:41.879
<v Speaker 2>like Google Play. The book also emphasizes setting your target

128
00:06:41.920 --> 00:06:45.240
<v Speaker 2>API level properly, say API twenty six or higher now

129
00:06:45.480 --> 00:06:48.319
<v Speaker 2>to ensure compatibility and meet platform requirements.

130
00:06:48.360 --> 00:06:51.279
<v Speaker 1>That makes perfect sense. Okay, Now let's explore some more

131
00:06:51.319 --> 00:06:56.079
<v Speaker 1>advanced kivvy stuff beyond basic UI. What about interacting with

132
00:06:56.120 --> 00:06:58.720
<v Speaker 1>the device's hardware, like the camera.

133
00:06:59.079 --> 00:07:01.560
<v Speaker 2>Yeah, intergra the vice camera is a pretty common requirement

134
00:07:01.600 --> 00:07:04.600
<v Speaker 2>these days, right. Kiv provides a dedicated camera widget for

135
00:07:04.600 --> 00:07:07.399
<v Speaker 2>this hiple enough, it's your direct getway to pulling in

136
00:07:07.439 --> 00:07:10.959
<v Speaker 2>live video feeds. Now, there is a common hurdle. The

137
00:07:10.959 --> 00:07:14.639
<v Speaker 2>Android camera output often comes rotated in ninety degrees by default.

138
00:07:14.920 --> 00:07:16.360
<v Speaker 1>Thenoro oh right, I've seen that.

139
00:07:16.600 --> 00:07:20.439
<v Speaker 2>Yeah, So the book explains how Kiv's canvas instances and

140
00:07:20.560 --> 00:07:23.639
<v Speaker 2>context instructions are used to fix this. Think of the

141
00:07:23.680 --> 00:07:28.000
<v Speaker 2>canvas as like a painter's workspace. For that specific widget,

142
00:07:28.360 --> 00:07:31.439
<v Speaker 2>you can apply transformations directly to that canvas, things like

143
00:07:31.759 --> 00:07:34.959
<v Speaker 2>rotate with an angle negat ninety along with color and

144
00:07:35.000 --> 00:07:38.199
<v Speaker 2>rectangle instructions to make sure the camera feed displays correctly

145
00:07:38.240 --> 00:07:39.279
<v Speaker 2>for the user, and to.

146
00:07:39.240 --> 00:07:42.920
<v Speaker 1>Make sure those transformations only affect say, the camera view,

147
00:07:42.959 --> 00:07:44.600
<v Speaker 1>and not everything else on the screen.

148
00:07:44.800 --> 00:07:48.639
<v Speaker 2>Good point. Kiv offers push matrix and pop matrix instructions

149
00:07:48.680 --> 00:07:52.120
<v Speaker 2>for that. These act like a temporary scope for your canvas.

150
00:07:51.720 --> 00:07:53.600
<v Speaker 1>Instructions like parentheses for graphics.

151
00:07:53.720 --> 00:07:56.920
<v Speaker 2>Exactly. You push matrix to start applying transformations, do your

152
00:07:57.000 --> 00:08:00.040
<v Speaker 2>rotation or whatever, and then pop matrix this limit and

153
00:08:00.079 --> 00:08:02.639
<v Speaker 2>it's their effect just to the widget you intended preventing,

154
00:08:02.800 --> 00:08:06.240
<v Speaker 2>you know, weird unintended changes to other UI elements. It's

155
00:08:06.279 --> 00:08:07.240
<v Speaker 2>precise control.

156
00:08:07.319 --> 00:08:10.680
<v Speaker 1>Okay, precise control. Now, what about capturing images from that

157
00:08:10.759 --> 00:08:13.079
<v Speaker 1>camera widget, especially if you need it fast, like for

158
00:08:13.120 --> 00:08:15.639
<v Speaker 1>real time stuff? Saving to a file sounds slow.

159
00:08:15.720 --> 00:08:17.879
<v Speaker 2>Yeah, saving to a file every frame is definitely too

160
00:08:17.920 --> 00:08:21.240
<v Speaker 2>slow for real time. The book introduces Bellera read pixels

161
00:08:21.439 --> 00:08:22.720
<v Speaker 2>and get region.

162
00:08:22.680 --> 00:08:25.600
<v Speaker 1>Goal read pixels sounds low level.

163
00:08:25.759 --> 00:08:27.800
<v Speaker 2>It is a bit but think of these as super

164
00:08:27.839 --> 00:08:31.480
<v Speaker 2>fast direct memory grabs. Instead of writing an image to disk,

165
00:08:31.600 --> 00:08:34.200
<v Speaker 2>they scoop up the raw pixel data directly into memory

166
00:08:34.200 --> 00:08:37.759
<v Speaker 2>as biterer rays. This avoids all the file io overhead,

167
00:08:38.039 --> 00:08:41.039
<v Speaker 2>making them vastly more efficient for processing video streams or

168
00:08:41.039 --> 00:08:42.720
<v Speaker 2>doing things like continuous uploads.

169
00:08:42.840 --> 00:08:46.639
<v Speaker 1>Ah okay, continuous uploads. That leads perfectly into the next bit.

170
00:08:46.759 --> 00:08:49.840
<v Speaker 1>One really practical application discussed in the source material using

171
00:08:49.879 --> 00:08:53.480
<v Speaker 1>these fast methods is continuously uploading captured images to an

172
00:08:53.600 --> 00:08:56.159
<v Speaker 1>HTTP server. So you've got your crev app on the

173
00:08:56.159 --> 00:08:58.919
<v Speaker 1>phone acting as a client, and maybe a Python flask

174
00:08:58.919 --> 00:09:00.000
<v Speaker 1>gap running on a ser.

175
00:09:00.200 --> 00:09:04.120
<v Speaker 2>Somewhere exactly, and the server communication flow described is quite clever.

176
00:09:04.399 --> 00:09:07.080
<v Speaker 2>The Kiwi client first sends the image dimensions the width

177
00:09:07.120 --> 00:09:09.879
<v Speaker 2>and height to the flask server just once in a

178
00:09:09.919 --> 00:09:13.519
<v Speaker 2>preliminary post message. Why just once, Well, the image size

179
00:09:13.519 --> 00:09:15.919
<v Speaker 2>is usually fixed, right, so sending it repeatedly is just

180
00:09:16.000 --> 00:09:20.440
<v Speaker 2>wasted bandwidth. After that initial handshake, the client continuously uploads

181
00:09:20.480 --> 00:09:24.159
<v Speaker 2>the actual image data as byte arrays. On the server side,

182
00:09:24.240 --> 00:09:28.000
<v Speaker 2>the flask app receives these mit arrays, it processes them,

183
00:09:28.000 --> 00:09:30.840
<v Speaker 2>maybe using something like the Python imaging library pil dot

184
00:09:30.960 --> 00:09:34.080
<v Speaker 2>image dot from bytes, it might need to rotate them again,

185
00:09:34.120 --> 00:09:36.879
<v Speaker 2>you know, image dot rotate nash nine d for consistency,

186
00:09:37.200 --> 00:09:39.279
<v Speaker 2>and then it could display them maybe in an HTML

187
00:09:39.320 --> 00:09:42.639
<v Speaker 2>page that auto refreshes showing the incoming frames. It's a

188
00:09:42.679 --> 00:09:45.679
<v Speaker 2>pretty robust way to handle live data streams between device

189
00:09:45.720 --> 00:09:46.080
<v Speaker 2>and server.

190
00:09:46.440 --> 00:09:49.440
<v Speaker 1>Very cool. Okay, let's shift gears now to something really

191
00:09:49.480 --> 00:09:54.120
<v Speaker 1>fun but also potentially quite complex, building a game. The

192
00:09:54.120 --> 00:09:57.159
<v Speaker 1>book goes into detail on constructing a multi level adventure game.

193
00:09:57.360 --> 00:10:00.279
<v Speaker 1>For game development, the float layout widget apparently becomes article.

194
00:10:00.320 --> 00:10:02.720
<v Speaker 1>How does that change things compared to the box layout

195
00:10:02.720 --> 00:10:03.440
<v Speaker 1>we mentioned earlier?

196
00:10:03.639 --> 00:10:07.440
<v Speaker 2>Right, float layout is definitely a game changer for games. Literally.

197
00:10:08.200 --> 00:10:12.600
<v Speaker 2>Unlike box layout, which kind of rigidly arranges widgets in lines,

198
00:10:13.039 --> 00:10:17.639
<v Speaker 2>float layout gives you precise dynamic control over positioning and sizing.

199
00:10:18.360 --> 00:10:21.919
<v Speaker 2>You place widgets using relative coordinates what kiv calls pautient

200
00:10:22.080 --> 00:10:25.799
<v Speaker 2>for position and size hint for size. This lets elements

201
00:10:25.840 --> 00:10:28.519
<v Speaker 2>overlap or be placed exactly where you need them on

202
00:10:28.519 --> 00:10:30.840
<v Speaker 2>the screen, which is obviously essential for games.

203
00:10:30.960 --> 00:10:33.440
<v Speaker 1>Makes sense. You need things flying around, not just sitting

204
00:10:33.480 --> 00:10:33.919
<v Speaker 1>in neat.

205
00:10:33.840 --> 00:10:38.000
<v Speaker 2>Rows exactly, controlling character movement, item placement, handling dynamic scenes.

206
00:10:38.120 --> 00:10:39.320
<v Speaker 2>Float layout is built for that.

207
00:10:39.679 --> 00:10:42.720
<v Speaker 1>And what about the core mechanics of a game animation

208
00:10:42.960 --> 00:10:46.559
<v Speaker 1>Touch controls knowing when things bump into each other. How

209
00:10:46.600 --> 00:10:49.759
<v Speaker 1>does kiv make that accessible for Python developers? Is it hard?

210
00:10:50.039 --> 00:10:53.399
<v Speaker 2>Kivy actually makes these surprisingly intuitive For animation, you can

211
00:10:53.440 --> 00:10:56.759
<v Speaker 2>animate pretty much any widget property think potent for movement,

212
00:10:56.879 --> 00:10:58.960
<v Speaker 2>or even the source property of an image to change

213
00:10:59.000 --> 00:11:02.519
<v Speaker 2>character spraites over time. You can set durations, transitions, even

214
00:11:02.559 --> 00:11:03.320
<v Speaker 2>loop them easily.

215
00:11:03.440 --> 00:11:06.279
<v Speaker 1>Okay, animation sounds doable. What about touch screen?

216
00:11:06.320 --> 00:11:09.759
<v Speaker 2>Touch events are handled through simple methods like on touchdown

217
00:11:09.759 --> 00:11:13.039
<v Speaker 2>attached to your main layout or even specific widgets. This

218
00:11:13.080 --> 00:11:15.480
<v Speaker 2>gives you the coordinates of the tap, letting you translate

219
00:11:15.559 --> 00:11:18.240
<v Speaker 2>that directly into character movement or interaction.

220
00:11:17.960 --> 00:11:21.000
<v Speaker 1>And collisions, like knowing when the player hits a monster

221
00:11:21.120 --> 00:11:21.960
<v Speaker 1>or grabs a coin.

222
00:11:22.480 --> 00:11:26.600
<v Speaker 2>For collision detection, Kivy provides the collide widget function. It's

223
00:11:26.639 --> 00:11:29.399
<v Speaker 2>efficient and simply tells you if the bounding boxes of

224
00:11:29.440 --> 00:11:33.320
<v Speaker 2>two widgets are overlapping, perfect for detecting if your player

225
00:11:33.399 --> 00:11:36.200
<v Speaker 2>character runs into a monster or collects a coin. The

226
00:11:36.240 --> 00:11:40.200
<v Speaker 2>book shows examples changing character images based on movement direction,

227
00:11:40.559 --> 00:11:46.039
<v Speaker 2>having monsters move randomly collecting uniformly distributed coins. It demonstrates

228
00:11:46.039 --> 00:11:49.759
<v Speaker 2>how relatively straightforward these core mechanics are to implement in Kivy.

229
00:11:50.000 --> 00:11:52.639
<v Speaker 1>That sounds like a really solid foundation for building almost

230
00:11:52.639 --> 00:11:55.960
<v Speaker 1>any two D game. Now, how does kiv help structure

231
00:11:56.000 --> 00:11:59.120
<v Speaker 1>a larger game, maybe one with multiple levels of menuscreen

232
00:11:59.159 --> 00:12:01.320
<v Speaker 1>that sort of thing. Is it like Android activities?

233
00:12:01.360 --> 00:12:04.679
<v Speaker 2>That's a perfect analogy. Kivy uses screen and screen manager

234
00:12:04.720 --> 00:12:06.480
<v Speaker 2>classes for exactly this purpose.

235
00:12:06.639 --> 00:12:08.000
<v Speaker 1>Green and screen manager okay.

236
00:12:08.159 --> 00:12:11.559
<v Speaker 2>The screen manager acts like a controller, handling transitions between

237
00:12:11.600 --> 00:12:15.320
<v Speaker 2>different screen instances. Each screen could represent a distinct part

238
00:12:15.320 --> 00:12:18.120
<v Speaker 2>of your application, their main menu, level one, level two,

239
00:12:18.159 --> 00:12:21.519
<v Speaker 2>a game over screen, and so on. Keeps everything organized

240
00:12:21.559 --> 00:12:22.679
<v Speaker 2>and modular.

241
00:12:22.399 --> 00:12:25.360
<v Speaker 1>Right prevents one massive code file exactly.

242
00:12:25.799 --> 00:12:28.600
<v Speaker 2>The book also talks about screen life cycle events, things

243
00:12:28.639 --> 00:12:32.080
<v Speaker 2>like on pre enter, one enter, on pre leave. These

244
00:12:32.080 --> 00:12:35.399
<v Speaker 2>are crucial. They let you run code just before screen appears,

245
00:12:35.519 --> 00:12:38.240
<v Speaker 2>right when it appears, or just before it disappears. Think

246
00:12:38.240 --> 00:12:40.480
<v Speaker 2>about setting up a level when the player enters it,

247
00:12:40.919 --> 00:12:44.679
<v Speaker 2>or resetting things when they leave. Very useful for managing

248
00:12:44.720 --> 00:12:48.399
<v Speaker 2>game state per level. The game example also extensively uses

249
00:12:48.440 --> 00:12:51.960
<v Speaker 2>custom widgets, things like a monster widget, a character widget,

250
00:12:52.000 --> 00:12:55.840
<v Speaker 2>a coin widget. This encapsulates their specific look and behavior,

251
00:12:56.039 --> 00:12:59.080
<v Speaker 2>making it really easy to reuse them across multiple levels

252
00:12:59.120 --> 00:13:00.960
<v Speaker 2>and simplifying the overall development.

253
00:13:01.200 --> 00:13:03.919
<v Speaker 1>And of course, what's a game without sound? The deep

254
00:13:03.919 --> 00:13:08.639
<v Speaker 1>dive mentions adding background music, coin collection sounds, level completion fanfares,

255
00:13:08.840 --> 00:13:12.399
<v Speaker 1>even character death sounds. Those details really add polish, don't they?

256
00:13:12.600 --> 00:13:17.120
<v Speaker 2>Absolutely? Sound design is critical for immersion, Even simple sounds

257
00:13:17.120 --> 00:13:20.320
<v Speaker 2>make a big difference, and for keeping track of progress.

258
00:13:20.679 --> 00:13:24.120
<v Speaker 2>The book introduces using Python's built in Pickle.

259
00:13:23.879 --> 00:13:26.320
<v Speaker 1>Library Pickle for saving game data.

260
00:13:26.440 --> 00:13:29.759
<v Speaker 2>Yep, Pickle lets you easily serialized Python objects, so you

261
00:13:29.799 --> 00:13:33.320
<v Speaker 2>can save things like the player's score, the last completed level,

262
00:13:33.480 --> 00:13:37.440
<v Speaker 2>or maybe whether they've seen the final congratulations message. This

263
00:13:37.600 --> 00:13:40.360
<v Speaker 2>ensures players don't lose their progress when they close the app.

264
00:13:40.480 --> 00:13:44.320
<v Speaker 2>It also mentions creating a custom image button widget, specifically

265
00:13:44.360 --> 00:13:48.320
<v Speaker 2>for the level selection screen, combining visuals with button functionality.

266
00:13:48.360 --> 00:13:51.440
<v Speaker 1>Okay, this is all sounding incredibly capable, but let's pose

267
00:13:51.480 --> 00:13:54.600
<v Speaker 1>a critical question. Now we've seen Kiv's power for UI

268
00:13:55.000 --> 00:13:58.679
<v Speaker 1>games even server coms, But what if your Python KIV

269
00:13:58.799 --> 00:14:02.720
<v Speaker 1>app needs to access really specific Android native features stuff

270
00:14:02.720 --> 00:14:04.879
<v Speaker 1>it isn't easily done in pure Python, or maybe not

271
00:14:04.919 --> 00:14:07.240
<v Speaker 1>covered by a kivi's core widgets. How do you get

272
00:14:07.320 --> 00:14:07.799
<v Speaker 1>under the hood?

273
00:14:07.919 --> 00:14:09.759
<v Speaker 2>Right? That's where things get really interesting and where the

274
00:14:09.759 --> 00:14:13.279
<v Speaker 2>integration story deepens. The book first introduces a library.

275
00:14:12.879 --> 00:14:16.080
<v Speaker 1>Called Plier Plier p l yer that's right.

276
00:14:16.200 --> 00:14:18.840
<v Speaker 2>Plier is a Python library that aims to provide a

277
00:14:18.919 --> 00:14:24.039
<v Speaker 2>simple high level cross platform interface to common native device features,

278
00:14:24.840 --> 00:14:29.480
<v Speaker 2>think things like pushing notifications, reading battery status, controlling the flashlight,

279
00:14:29.679 --> 00:14:34.120
<v Speaker 2>accessing accelerometer data. It's convenient for these kinds of basic interactions. However,

280
00:14:34.639 --> 00:14:36.679
<v Speaker 2>it's important to note, as the book points out, that

281
00:14:36.759 --> 00:14:39.600
<v Speaker 2>at the time it was written, some key features in Plier,

282
00:14:39.720 --> 00:14:44.639
<v Speaker 2>like maybe more advanced camera control, specific audio functionalities, or

283
00:14:44.759 --> 00:14:48.559
<v Speaker 2>detailed Wi Fi info, were still marked as unimplemented or

284
00:14:48.600 --> 00:14:50.559
<v Speaker 2>maybe only worked on certain platforms.

285
00:14:50.600 --> 00:14:53.000
<v Speaker 1>Ah okay, so Plier is good for some common stuff,

286
00:14:53.000 --> 00:14:55.559
<v Speaker 1>but might have gaps if you need something really specific

287
00:14:55.639 --> 00:14:56.200
<v Speaker 1>or advanced.

288
00:14:56.320 --> 00:14:59.279
<v Speaker 2>Exactly, It's a good first step, often sufficient, but sometimes

289
00:14:59.320 --> 00:15:01.440
<v Speaker 2>you need more more direct control.

290
00:15:01.799 --> 00:15:04.080
<v Speaker 1>So if Plier isn't enough, if you truly need to

291
00:15:04.120 --> 00:15:07.440
<v Speaker 1>go deep into the Android system, what's the next level?

292
00:15:07.480 --> 00:15:09.919
<v Speaker 1>What's the tool that really lets Python talk directly to

293
00:15:10.000 --> 00:15:13.159
<v Speaker 1>Android's core? And does using that power come with like

294
00:15:13.399 --> 00:15:14.360
<v Speaker 1>extra complexity.

295
00:15:14.480 --> 00:15:17.240
<v Speaker 2>That's where Paganius comes into play, and yes, this is

296
00:15:17.279 --> 00:15:21.519
<v Speaker 2>incredibly powerful. Pygenis allows your Python can to directly reflect

297
00:15:21.559 --> 00:15:24.679
<v Speaker 2>and interact with Java classes running on the Android system.

298
00:15:24.799 --> 00:15:26.440
<v Speaker 1>Reflect What does that mean exactly?

299
00:15:26.679 --> 00:15:30.120
<v Speaker 2>Think of reflection here as Python gaining a deep understanding

300
00:15:30.159 --> 00:15:33.039
<v Speaker 2>of Java's internal structure. On the fly, it can look

301
00:15:33.080 --> 00:15:36.919
<v Speaker 2>up Java classes by name, find their methods, check their parameters,

302
00:15:37.039 --> 00:15:40.519
<v Speaker 2>create instances of Java objects, and call their methods all

303
00:15:40.559 --> 00:15:43.799
<v Speaker 2>from Python code. Whoa, It's like Python suddenly learns to

304
00:15:43.799 --> 00:15:47.080
<v Speaker 2>speak fluent Java. So, for example, you could directly call

305
00:15:47.240 --> 00:15:50.360
<v Speaker 2>standard Java methods like Java dot laying a dot system,

306
00:15:50.399 --> 00:15:52.559
<v Speaker 2>dot out, dot print in LN to print to the

307
00:15:52.600 --> 00:15:56.960
<v Speaker 2>Android log or more usefully, you could instantiate and control

308
00:15:57.039 --> 00:16:00.159
<v Speaker 2>the Android dot media dot media player Java class to

309
00:16:00.200 --> 00:16:03.039
<v Speaker 2>play audio files, giving you finer control than maybe a

310
00:16:03.120 --> 00:16:06.279
<v Speaker 2>simpler library offers. You can even display those little pop

311
00:16:06.320 --> 00:16:08.799
<v Speaker 2>up tost messages the short notifications at the bottom of

312
00:16:08.840 --> 00:16:11.399
<v Speaker 2>the screen by finding the current Android activity, which is

313
00:16:11.399 --> 00:16:16.200
<v Speaker 2>often Python activity, and calling its Java methods directly using Pagenius, So.

314
00:16:16.159 --> 00:16:19.279
<v Speaker 1>You're literally writing Python that calls Java code precisely.

315
00:16:19.879 --> 00:16:23.639
<v Speaker 2>The trade off, as you hinted, is complexity. It's powerful,

316
00:16:23.960 --> 00:16:28.120
<v Speaker 2>but you're now bridging two distinct programming environments. Debugging can

317
00:16:28.159 --> 00:16:31.639
<v Speaker 2>be trickier, as an error might originate in your Python logic,

318
00:16:31.759 --> 00:16:34.360
<v Speaker 2>in the pisenous bridge itself, or in the Java code

319
00:16:34.399 --> 00:16:37.279
<v Speaker 2>you're calling. You need some understanding of both sides.

320
00:16:37.440 --> 00:16:40.279
<v Speaker 1>That makes sense. Power comes with the responsibility, right, So

321
00:16:40.360 --> 00:16:45.320
<v Speaker 1>Pagnius gives Python direct Java access, and the ultimate integration

322
00:16:45.399 --> 00:16:47.639
<v Speaker 1>level discussed in the book seems to be actually working

323
00:16:47.720 --> 00:16:51.519
<v Speaker 1>inside the Android studio project that Buildozer creates. This sounds

324
00:16:51.559 --> 00:16:53.759
<v Speaker 1>like taking the training wheels off entirely. What are you

325
00:16:53.799 --> 00:16:55.840
<v Speaker 1>actually looking at when you open that project and what

326
00:16:55.879 --> 00:16:58.399
<v Speaker 1>can you do by diving into the Java side there?

327
00:16:58.759 --> 00:17:00.600
<v Speaker 2>Exactly? That's where you roll up your sleeves and get

328
00:17:00.639 --> 00:17:03.639
<v Speaker 2>full native control if you need it. When buildoser runs,

329
00:17:03.639 --> 00:17:05.720
<v Speaker 2>it doesn't just make an APK out of thin air.

330
00:17:06.200 --> 00:17:10.680
<v Speaker 2>It first generates a standard Android studio project structure. Inside

331
00:17:10.680 --> 00:17:13.599
<v Speaker 2>that project you find all the familiar Android files, the

332
00:17:13.720 --> 00:17:17.640
<v Speaker 2>Android manifests dot xml for permissions and app configuration, Python

333
00:17:17.680 --> 00:17:20.400
<v Speaker 2>activity dot java, which is usually the main entry point

334
00:17:20.480 --> 00:17:23.079
<v Speaker 2>activity that bootstraps the bike on environment, the build dot

335
00:17:23.079 --> 00:17:26.559
<v Speaker 2>Greedle files for managing dependencies, and the build process strings,

336
00:17:26.599 --> 00:17:28.759
<v Speaker 2>dot xml for text resources.

337
00:17:28.200 --> 00:17:30.160
<v Speaker 1>And so on. So it's a real Android project.

338
00:17:30.279 --> 00:17:34.920
<v Speaker 2>It's a completely standard Android studio project. And this raises

339
00:17:34.960 --> 00:17:37.839
<v Speaker 2>that important question what can you do by modifying this?

340
00:17:38.039 --> 00:17:41.079
<v Speaker 2>Well quite a lot. You could, for instance, add custom

341
00:17:41.160 --> 00:17:43.240
<v Speaker 2>native job of us like an Android text view or

342
00:17:43.319 --> 00:17:47.920
<v Speaker 2>button directly into the Android activity's layout file main dot xml. Usually,

343
00:17:48.279 --> 00:17:51.279
<v Speaker 2>maybe you want some native UI elements visible even during

344
00:17:51.319 --> 00:17:54.039
<v Speaker 2>the initial KIV loading screen. It helps you to understand

345
00:17:54.039 --> 00:17:56.440
<v Speaker 2>that KIV typically runs on top of SDL, the Simple

346
00:17:56.480 --> 00:17:59.559
<v Speaker 2>Direct Media Layer SDL is a cross platform library that

347
00:17:59.599 --> 00:18:02.160
<v Speaker 2>provides it's a low level drawing surface and handles input.

348
00:18:02.680 --> 00:18:05.599
<v Speaker 2>So the KIV interface is drawn onto an SDL surface

349
00:18:05.599 --> 00:18:08.440
<v Speaker 2>within the Android activity. Touch events are captured by the

350
00:18:08.440 --> 00:18:11.559
<v Speaker 2>Android system, passed to the SDL surfaces on touch method

351
00:18:11.559 --> 00:18:14.440
<v Speaker 2>in Java, and then forward it into the KIV event loop.

352
00:18:14.640 --> 00:18:16.359
<v Speaker 1>Okay, getting technical, but I see.

353
00:18:16.160 --> 00:18:18.519
<v Speaker 2>The layers right, and the book is a really compelling

354
00:18:18.559 --> 00:18:23.480
<v Speaker 2>example of leveraging this, integrating OpenCV, the big Computer Vision library.

355
00:18:23.839 --> 00:18:26.359
<v Speaker 2>You could add the OpenCV library as a standard dependency

356
00:18:26.359 --> 00:18:29.359
<v Speaker 2>in your build dug glidal file. Then you could write

357
00:18:29.440 --> 00:18:32.519
<v Speaker 2>Java code within your Python activity or another Java class

358
00:18:32.559 --> 00:18:37.480
<v Speaker 2>that performs OpenCV operations. Imagine having a button in your KIVUI.

359
00:18:37.920 --> 00:18:40.279
<v Speaker 2>When you press it, it uses pugnius to call a

360
00:18:40.319 --> 00:18:43.680
<v Speaker 2>custom Java method you wrote. That Java method then grabs

361
00:18:43.680 --> 00:18:47.240
<v Speaker 2>a camera frame, uses OpenCV to apply, say a canny

362
00:18:47.359 --> 00:18:50.480
<v Speaker 2>edge detection filter, and maybe displays the result in a

363
00:18:50.559 --> 00:18:53.000
<v Speaker 2>native image view, or even sends the process data back

364
00:18:53.039 --> 00:18:53.559
<v Speaker 2>to Python.

365
00:18:53.680 --> 00:18:56.200
<v Speaker 1>Wow. Okay, so you can have KIV handling the main

366
00:18:56.359 --> 00:19:00.519
<v Speaker 1>UI and logic, but delegate really heavy or platform specific

367
00:19:00.559 --> 00:19:03.519
<v Speaker 1>tasks like advanced image processing directly to Java open CV

368
00:19:03.680 --> 00:19:05.000
<v Speaker 1>running natively exactly.

369
00:19:05.200 --> 00:19:09.200
<v Speaker 2>It demonstrates truly deep, seamless interoperability. You get the best

370
00:19:09.200 --> 00:19:13.079
<v Speaker 2>of both worlds, Python's rapid development and kiv's cross platform UI,

371
00:19:13.240 --> 00:19:15.960
<v Speaker 2>combined with the full power of native Android APIs and

372
00:19:16.039 --> 00:19:17.400
<v Speaker 2>Java libraries when needed.

373
00:19:17.720 --> 00:19:20.079
<v Speaker 1>So let's try to bring this all together. We've covered

374
00:19:20.079 --> 00:19:22.599
<v Speaker 1>a lot today, haven't we. We've journeyed through how KIV,

375
00:19:22.759 --> 00:19:26.160
<v Speaker 1>along with tools like bill Doozer, really empowers Python developers

376
00:19:26.160 --> 00:19:30.480
<v Speaker 1>to build surprisingly sophisticated Android applications, not just a toy.

377
00:19:30.880 --> 00:19:33.119
<v Speaker 1>We saw how you go from simple UIs and basic

378
00:19:33.160 --> 00:19:36.880
<v Speaker 1>interactions all the way to building complex multi level games

379
00:19:36.920 --> 00:19:42.039
<v Speaker 1>with animations, collisions, sound qv offers incredible versatility there, and

380
00:19:42.079 --> 00:19:45.000
<v Speaker 1>then when pure Python our standard KiB widgets are quite enough,

381
00:19:45.279 --> 00:19:48.519
<v Speaker 1>we explored how plier offers a simpler bridge for common tasks,

382
00:19:48.880 --> 00:19:52.079
<v Speaker 1>and now Pivnius provides that really deep connection, letting Python

383
00:19:52.119 --> 00:19:55.599
<v Speaker 1>directly call Java code, which culminates in the ability to

384
00:19:55.640 --> 00:19:59.559
<v Speaker 1>modify the bill Dozer generated Android studio project itself, integrating

385
00:19:59.599 --> 00:20:03.279
<v Speaker 1>powerful native libraries like OpenCV directly. It's quite a spectrum

386
00:20:03.279 --> 00:20:04.079
<v Speaker 1>of possibilities.

387
00:20:04.319 --> 00:20:07.920
<v Speaker 2>Yeah, this deep dive really hammers home a core message.

388
00:20:08.000 --> 00:20:11.640
<v Speaker 2>Python's reach extends far, far beyond its traditional domains. Now

389
00:20:12.000 --> 00:20:14.519
<v Speaker 2>it's not just for data science or web back ends anymore.

390
00:20:14.599 --> 00:20:18.960
<v Speaker 2>It offers powerful, genuinely efficient solutions for cross platform mobile

391
00:20:19.000 --> 00:20:23.480
<v Speaker 2>app development. And the tools we discussed KIV, Billdozer, Pygenius

392
00:20:23.640 --> 00:20:26.720
<v Speaker 2>they make it truly accessible for the vast Python community

393
00:20:26.759 --> 00:20:29.480
<v Speaker 2>to step into the mobile world. They can turn complex

394
00:20:29.519 --> 00:20:32.839
<v Speaker 2>ideas into tangible apps without needing to completely abandon their

395
00:20:32.880 --> 00:20:33.799
<v Speaker 2>existing skills.

396
00:20:34.200 --> 00:20:36.680
<v Speaker 1>So what does this all mean for you listening right now?

397
00:20:36.920 --> 00:20:40.279
<v Speaker 1>Imagine the possibilities for innovation when you can combine Python's

398
00:20:40.359 --> 00:20:43.480
<v Speaker 1>rich ecosystem of libraries. It's ease of use with deep

399
00:20:43.519 --> 00:20:46.680
<v Speaker 1>control over native mobile features. What kind of unique cross

400
00:20:46.680 --> 00:20:49.200
<v Speaker 1>platform apps or maybe even games could you create next

401
00:20:49.359 --> 00:20:51.920
<v Speaker 1>that truly stand out from the crowd. Something to think about.