Speaker 1: Okay, let's unpack this. In a world just drowning in information,
Speaker 1: where does a busy, curious mind go, you know, to
Speaker 1: get genuinely well informed fast. You want the gold, the
Speaker 1: surprising facts, the practical insights, without getting bogged down in
Speaker 1: every single detail. And well, that's exactly our mission today.
Speaker 1: We're taking a deep dive into the fascinating world of
Speaker 1: building Android applications using Python, specifically with a framework called
Speaker 1: kiv Our. Core material for this deep dive comes from
Speaker 1: a really insightful guide building Android apps in Python using
Speaker 1: Kivy with androids Studio with Pigeonius Plier and Buildozer by
Speaker 1: Ahmed Fazzy Mohammed Gad. So we're here to extract those
Speaker 1: essential nuggets, those aha moments and the practical knowledge, the
Speaker 1: stuff that will let you walk away with a solid
Speaker 1: grasp of out Python can well conger mobile development.
Speaker 2: Yeah. And what's truly fascinating here is how this approach
Speaker 2: radically challenges the traditional landscape. I mean, for years, Java
Speaker 2: and Cotlin have been the undisputed kings of Android development.
Speaker 2: This deep dive explores a really compelling alternative. It's one
Speaker 2: that allows the huge community of Python developers to leap
Speaker 2: into the mobile space using skills they already possess. That's
Speaker 2: a game changer for many.
Speaker 1: Really, that's a great point. It really does challenge the
Speaker 1: status quo, doesn't it. So for someone maybe steeped in
Speaker 1: Java or colin, what's the single most compelling reason they
Speaker 1: should even consider this alternative beyond just its Python? Let's
Speaker 1: kick things off with the kiv Foundation. Why Python for Android?
Speaker 1: What exactly is kivy?
Speaker 2: Well, okay, at its heart, kivy is a cross platform
Speaker 2: Python framework. It's designed for building applications with what they
Speaker 2: call a natural user interface or NUI. Now, this isn't
Speaker 2: just about making buttons look nice. It's about making interfaces
Speaker 2: feel intuitive, responsive, almost you know, touch first. But the
Speaker 2: real hook, as you said, is cross platform. Write your
Speaker 2: kiv code once and it runs unchanged on Windows, Linux, Mac,
Speaker 2: Android and iOS devices.
Speaker 1: Wow.
Speaker 2: For a developer, that means huge time savings and reaching
Speaker 2: a much wider audience. And thinking about the author's background
Speaker 2: in deep learning machine learning, it just shows python incredible versatility. Right,
Speaker 2: It's no longer just stuck in data science or web
Speaker 2: back ends. It's actually powering interactive mobile applications.
Speaker 1: Now that truly sounds like a developer's dream right once
Speaker 1: run everywhere. So KIV is powerful, but it's not a
Speaker 1: magic bullet on its own, is it? What's the unsung
Speaker 1: hero here? The thing that truly bridges the gap between
Speaker 1: your Python code and a working Android app? Yeah, and thybeah.
Speaker 1: What's one surprising thing it handles that most developers dread?
Speaker 2: Ah? That would be Bill Dozer. Absolutely think of Billdozer
Speaker 2: as your personal mobile app construction crew. Its core function
Speaker 2: is to take your KIPI Python project and meticulously package
Speaker 2: it into an Android studio project. Then ultimately it compiles
Speaker 2: it into that installable Android application package, the APK.
Speaker 1: File oka the APK.
Speaker 2: And one truly surprising, well helpful fact is how it
Speaker 2: automates the whole Android SDK and NDK setup. Native development
Speaker 2: often involves hours of you know, versioning, headaches and dependency. Hell,
Speaker 2: Billdozer either fetches exactly what it needs or just lets
Speaker 2: you point to your offline tools. It's a huge time saver, So.
Speaker 1: It handles the messy bits automatically. Yes, how do you,
Speaker 1: as the developer tell Billdozer what your app actually needs?
Speaker 1: Is there like a central control panel for it?
Speaker 2: Exactly Yeah. This entire packaging process is largely configured through
Speaker 2: just one single file called billdozer dot.
Speaker 1: Spec build dozer dot spec.
Speaker 2: Okay, it's like the DNA of your app. Inside you
Speaker 2: define crucial characteristics like your app's titles, say first app,
Speaker 2: and unique identifiers like package dot name and package dot domain.
Speaker 2: Those are absolutely vital for publishing later. You point it
Speaker 2: to your main Python file using source dot dr. And
Speaker 2: here's a really neat part the requirements proper. Right, You
Speaker 2: simply list all the Python libraries your app needs, KIV, NumPy, whatever,
Speaker 2: and Billdozer automatically downloads and links them, no manual fuss.
Speaker 2: You also specify visual assets, define screen orientation, and critically
Speaker 2: list the Android dot permissions your app requires, like Internet
Speaker 2: or camera. Builldozer translates these directly to the androm manifest
Speaker 2: dot xml file. It's incredibly efficient.
Speaker 1: Okay, we've talked about the building blocks KIV and Billdozer,
Speaker 1: but how do you truly bring your Python code to
Speaker 1: life like seeing it run on an actual Android device.
Speaker 1: Let's walk through that journey. Taking your very first Kidi
Speaker 1: app from your desktop right into your hands. How does
Speaker 1: that work?
Speaker 2: Right? Well, the best practice, and what the book recommends
Speaker 2: is to start simple. Build your kiv application first as
Speaker 2: a desktop app.
Speaker 1: Oh okay, desktop first.
Speaker 2: Yeah. This lets you quickly iterate, test your logic, make
Speaker 2: sure everything's working perfectly before you even think about mobile deployment.
Speaker 2: The desktop phase is basically your debugging sandbox that makes sense.
Speaker 1: And when you're mapping out that initial desktop app the
Speaker 1: UI part, where do you focus? Is there a specific
Speaker 1: kiv tool for separating the visual design from the actual code.
Speaker 2: Absolutely. Kivy has its own specialized design language. It's called
Speaker 2: kV language PD language. It's a declarative way to define
Speaker 2: your user interface. It lets you elegantly separate the visual
Speaker 2: design from your Python logic, which keeps your code clean
Speaker 2: and your UI flexible. So, for example, instead of writing
Speaker 2: lots of Python code to define every button's position and size,
Speaker 2: you can do most of that in the kV file,
Speaker 2: and within that you'll work with core UI concepts like
Speaker 2: box layout that's a container that organizes things neatly in
Speaker 2: rows or columns, and then common widgets like text input
Speaker 2: for user input, label for text, and of course button
Speaker 2: for interaction. kV handles the on press event for buttons
Speaker 2: letting you easily connect taps to your Python functions.
Speaker 1: Got it. So, once your desktop app is solid, looks good,
Speaker 1: the transition to Android sounds like the moment of truth.
Speaker 1: How smooth is that with Billdozer? Is it complicated?
Speaker 2: It's surprisingly seamless. Honestly, Billdozer offers a single, really powerful command,
Speaker 2: buildozer Android debug deploy run one command, one command. It
Speaker 2: handles the entire pipeline. It builds your APK. Then if
Speaker 2: you have a USB connected Android device with USB debugging enabled,
Speaker 2: that's important. It deploys the app directly to it and
Speaker 2: even launches it automatically. Anyone who's wrestled with manual APK
Speaker 2: transfers or complex build scripts before, well, this feels like magic.
Speaker 2: It really streamlines the whole process.
Speaker 1: That's incredibly efficient. So once you've tested it on your device,
Speaker 1: hammered out the bugs, and you're ready for the big stage. Right,
Speaker 1: how does publishing work? Getting it onto Google Play? Right?
Speaker 2: So publishing is the next logical step. For that, you'd
Speaker 2: use a slightly different command, buildozer Android release release.
Speaker 1: Okay.
Speaker 2: This command creates a release version of your APK, which
Speaker 2: is optimized for distribution. This release APK then needs to
Speaker 2: be digitally signed. That's a crucial step for security and
Speaker 2: identity verification. After signing, you can upload it to platforms
Speaker 2: like Google Play. The book also emphasizes setting your target
Speaker 2: API level properly, say API twenty six or higher now
Speaker 2: to ensure compatibility and meet platform requirements.
Speaker 1: That makes perfect sense. Okay, Now let's explore some more
Speaker 1: advanced kivvy stuff beyond basic UI. What about interacting with
Speaker 1: the device's hardware, like the camera.
Speaker 2: Yeah, intergra the vice camera is a pretty common requirement
Speaker 2: these days, right. Kiv provides a dedicated camera widget for
Speaker 2: this hiple enough, it's your direct getway to pulling in
Speaker 2: live video feeds. Now, there is a common hurdle. The
Speaker 2: Android camera output often comes rotated in ninety degrees by default.
Speaker 1: Thenoro oh right, I've seen that.
Speaker 2: Yeah, So the book explains how Kiv's canvas instances and
Speaker 2: context instructions are used to fix this. Think of the
Speaker 2: canvas as like a painter's workspace. For that specific widget,
Speaker 2: you can apply transformations directly to that canvas, things like
Speaker 2: rotate with an angle negat ninety along with color and
Speaker 2: rectangle instructions to make sure the camera feed displays correctly
Speaker 2: for the user, and to.
Speaker 1: Make sure those transformations only affect say, the camera view,
Speaker 1: and not everything else on the screen.
Speaker 2: Good point. Kiv offers push matrix and pop matrix instructions
Speaker 2: for that. These act like a temporary scope for your canvas.
Speaker 1: Instructions like parentheses for graphics.
Speaker 2: Exactly. You push matrix to start applying transformations, do your
Speaker 2: rotation or whatever, and then pop matrix this limit and
Speaker 2: it's their effect just to the widget you intended preventing,
Speaker 2: you know, weird unintended changes to other UI elements. It's
Speaker 2: precise control.
Speaker 1: Okay, precise control. Now, what about capturing images from that
Speaker 1: camera widget, especially if you need it fast, like for
Speaker 1: real time stuff? Saving to a file sounds slow.
Speaker 2: Yeah, saving to a file every frame is definitely too
Speaker 2: slow for real time. The book introduces Bellera read pixels
Speaker 2: and get region.
Speaker 1: Goal read pixels sounds low level.
Speaker 2: It is a bit but think of these as super
Speaker 2: fast direct memory grabs. Instead of writing an image to disk,
Speaker 2: they scoop up the raw pixel data directly into memory
Speaker 2: as biterer rays. This avoids all the file io overhead,
Speaker 2: making them vastly more efficient for processing video streams or
Speaker 2: doing things like continuous uploads.
Speaker 1: Ah okay, continuous uploads. That leads perfectly into the next bit.
Speaker 1: One really practical application discussed in the source material using
Speaker 1: these fast methods is continuously uploading captured images to an
Speaker 1: HTTP server. So you've got your crev app on the
Speaker 1: phone acting as a client, and maybe a Python flask
Speaker 1: gap running on a ser.
Speaker 2: Somewhere exactly, and the server communication flow described is quite clever.
Speaker 2: The Kiwi client first sends the image dimensions the width
Speaker 2: and height to the flask server just once in a
Speaker 2: preliminary post message. Why just once, Well, the image size
Speaker 2: is usually fixed, right, so sending it repeatedly is just
Speaker 2: wasted bandwidth. After that initial handshake, the client continuously uploads
Speaker 2: the actual image data as byte arrays. On the server side,
Speaker 2: the flask app receives these mit arrays, it processes them,
Speaker 2: maybe using something like the Python imaging library pil dot
Speaker 2: image dot from bytes, it might need to rotate them again,
Speaker 2: you know, image dot rotate nash nine d for consistency,
Speaker 2: and then it could display them maybe in an HTML
Speaker 2: page that auto refreshes showing the incoming frames. It's a
Speaker 2: pretty robust way to handle live data streams between device
Speaker 2: and server.
Speaker 1: Very cool. Okay, let's shift gears now to something really
Speaker 1: fun but also potentially quite complex, building a game. The
Speaker 1: book goes into detail on constructing a multi level adventure game.
Speaker 1: For game development, the float layout widget apparently becomes article.
Speaker 1: How does that change things compared to the box layout
Speaker 1: we mentioned earlier?
Speaker 2: Right, float layout is definitely a game changer for games. Literally.
Speaker 2: Unlike box layout, which kind of rigidly arranges widgets in lines,
Speaker 2: float layout gives you precise dynamic control over positioning and sizing.
Speaker 2: You place widgets using relative coordinates what kiv calls pautient
Speaker 2: for position and size hint for size. This lets elements
Speaker 2: overlap or be placed exactly where you need them on
Speaker 2: the screen, which is obviously essential for games.
Speaker 1: Makes sense. You need things flying around, not just sitting
Speaker 1: in neat.
Speaker 2: Rows exactly, controlling character movement, item placement, handling dynamic scenes.
Speaker 2: Float layout is built for that.
Speaker 1: And what about the core mechanics of a game animation
Speaker 1: Touch controls knowing when things bump into each other. How
Speaker 1: does kiv make that accessible for Python developers? Is it hard?
Speaker 2: Kivy actually makes these surprisingly intuitive For animation, you can
Speaker 2: animate pretty much any widget property think potent for movement,
Speaker 2: or even the source property of an image to change
Speaker 2: character spraites over time. You can set durations, transitions, even
Speaker 2: loop them easily.
Speaker 1: Okay, animation sounds doable. What about touch screen?
Speaker 2: Touch events are handled through simple methods like on touchdown
Speaker 2: attached to your main layout or even specific widgets. This
Speaker 2: gives you the coordinates of the tap, letting you translate
Speaker 2: that directly into character movement or interaction.
Speaker 1: And collisions, like knowing when the player hits a monster
Speaker 1: or grabs a coin.
Speaker 2: For collision detection, Kivy provides the collide widget function. It's
Speaker 2: efficient and simply tells you if the bounding boxes of
Speaker 2: two widgets are overlapping, perfect for detecting if your player
Speaker 2: character runs into a monster or collects a coin. The
Speaker 2: book shows examples changing character images based on movement direction,
Speaker 2: having monsters move randomly collecting uniformly distributed coins. It demonstrates
Speaker 2: how relatively straightforward these core mechanics are to implement in Kivy.
Speaker 1: That sounds like a really solid foundation for building almost
Speaker 1: any two D game. Now, how does kiv help structure
Speaker 1: a larger game, maybe one with multiple levels of menuscreen
Speaker 1: that sort of thing. Is it like Android activities?
Speaker 2: That's a perfect analogy. Kivy uses screen and screen manager
Speaker 2: classes for exactly this purpose.
Speaker 1: Green and screen manager okay.
Speaker 2: The screen manager acts like a controller, handling transitions between
Speaker 2: different screen instances. Each screen could represent a distinct part
Speaker 2: of your application, their main menu, level one, level two,
Speaker 2: a game over screen, and so on. Keeps everything organized
Speaker 2: and modular.
Speaker 1: Right prevents one massive code file exactly.
Speaker 2: The book also talks about screen life cycle events, things
Speaker 2: like on pre enter, one enter, on pre leave. These
Speaker 2: are crucial. They let you run code just before screen appears,
Speaker 2: right when it appears, or just before it disappears. Think
Speaker 2: about setting up a level when the player enters it,
Speaker 2: or resetting things when they leave. Very useful for managing
Speaker 2: game state per level. The game example also extensively uses
Speaker 2: custom widgets, things like a monster widget, a character widget,
Speaker 2: a coin widget. This encapsulates their specific look and behavior,
Speaker 2: making it really easy to reuse them across multiple levels
Speaker 2: and simplifying the overall development.
Speaker 1: And of course, what's a game without sound? The deep
Speaker 1: dive mentions adding background music, coin collection sounds, level completion fanfares,
Speaker 1: even character death sounds. Those details really add polish, don't they?
Speaker 2: Absolutely? Sound design is critical for immersion, Even simple sounds
Speaker 2: make a big difference, and for keeping track of progress.
Speaker 2: The book introduces using Python's built in Pickle.
Speaker 1: Library Pickle for saving game data.
Speaker 2: Yep, Pickle lets you easily serialized Python objects, so you
Speaker 2: can save things like the player's score, the last completed level,
Speaker 2: or maybe whether they've seen the final congratulations message. This
Speaker 2: ensures players don't lose their progress when they close the app.
Speaker 2: It also mentions creating a custom image button widget, specifically
Speaker 2: for the level selection screen, combining visuals with button functionality.
Speaker 1: Okay, this is all sounding incredibly capable, but let's pose
Speaker 1: a critical question. Now we've seen Kiv's power for UI
Speaker 1: games even server coms, But what if your Python KIV
Speaker 1: app needs to access really specific Android native features stuff
Speaker 1: it isn't easily done in pure Python, or maybe not
Speaker 1: covered by a kivi's core widgets. How do you get
Speaker 1: under the hood?
Speaker 2: Right? That's where things get really interesting and where the
Speaker 2: integration story deepens. The book first introduces a library.
Speaker 1: Called Plier Plier p l yer that's right.
Speaker 2: Plier is a Python library that aims to provide a
Speaker 2: simple high level cross platform interface to common native device features,
Speaker 2: think things like pushing notifications, reading battery status, controlling the flashlight,
Speaker 2: accessing accelerometer data. It's convenient for these kinds of basic interactions. However,
Speaker 2: it's important to note, as the book points out, that
Speaker 2: at the time it was written, some key features in Plier,
Speaker 2: like maybe more advanced camera control, specific audio functionalities, or
Speaker 2: detailed Wi Fi info, were still marked as unimplemented or
Speaker 2: maybe only worked on certain platforms.
Speaker 1: Ah okay, so Plier is good for some common stuff,
Speaker 1: but might have gaps if you need something really specific
Speaker 1: or advanced.
Speaker 2: Exactly, It's a good first step, often sufficient, but sometimes
Speaker 2: you need more more direct control.
Speaker 1: So if Plier isn't enough, if you truly need to
Speaker 1: go deep into the Android system, what's the next level?
Speaker 1: What's the tool that really lets Python talk directly to
Speaker 1: Android's core? And does using that power come with like
Speaker 1: extra complexity.
Speaker 2: That's where Paganius comes into play, and yes, this is
Speaker 2: incredibly powerful. Pygenis allows your Python can to directly reflect
Speaker 2: and interact with Java classes running on the Android system.
Speaker 1: Reflect What does that mean exactly?
Speaker 2: Think of reflection here as Python gaining a deep understanding
Speaker 2: of Java's internal structure. On the fly, it can look
Speaker 2: up Java classes by name, find their methods, check their parameters,
Speaker 2: create instances of Java objects, and call their methods all
Speaker 2: from Python code. Whoa, It's like Python suddenly learns to
Speaker 2: speak fluent Java. So, for example, you could directly call
Speaker 2: standard Java methods like Java dot laying a dot system,
Speaker 2: dot out, dot print in LN to print to the
Speaker 2: Android log or more usefully, you could instantiate and control
Speaker 2: the Android dot media dot media player Java class to
Speaker 2: play audio files, giving you finer control than maybe a
Speaker 2: simpler library offers. You can even display those little pop
Speaker 2: up tost messages the short notifications at the bottom of
Speaker 2: the screen by finding the current Android activity, which is
Speaker 2: often Python activity, and calling its Java methods directly using Pagenius, So.
Speaker 1: You're literally writing Python that calls Java code precisely.
Speaker 2: The trade off, as you hinted, is complexity. It's powerful,
Speaker 2: but you're now bridging two distinct programming environments. Debugging can
Speaker 2: be trickier, as an error might originate in your Python logic,
Speaker 2: in the pisenous bridge itself, or in the Java code
Speaker 2: you're calling. You need some understanding of both sides.
Speaker 1: That makes sense. Power comes with the responsibility, right, So
Speaker 1: Pagnius gives Python direct Java access, and the ultimate integration
Speaker 1: level discussed in the book seems to be actually working
Speaker 1: inside the Android studio project that Buildozer creates. This sounds
Speaker 1: like taking the training wheels off entirely. What are you
Speaker 1: actually looking at when you open that project and what
Speaker 1: can you do by diving into the Java side there?
Speaker 2: Exactly? That's where you roll up your sleeves and get
Speaker 2: full native control if you need it. When buildoser runs,
Speaker 2: it doesn't just make an APK out of thin air.
Speaker 2: It first generates a standard Android studio project structure. Inside
Speaker 2: that project you find all the familiar Android files, the
Speaker 2: Android manifests dot xml for permissions and app configuration, Python
Speaker 2: activity dot java, which is usually the main entry point
Speaker 2: activity that bootstraps the bike on environment, the build dot
Speaker 2: Greedle files for managing dependencies, and the build process strings,
Speaker 2: dot xml for text resources.
Speaker 1: And so on. So it's a real Android project.
Speaker 2: It's a completely standard Android studio project. And this raises
Speaker 2: that important question what can you do by modifying this?
Speaker 2: Well quite a lot. You could, for instance, add custom
Speaker 2: native job of us like an Android text view or
Speaker 2: button directly into the Android activity's layout file main dot xml. Usually,
Speaker 2: maybe you want some native UI elements visible even during
Speaker 2: the initial KIV loading screen. It helps you to understand
Speaker 2: that KIV typically runs on top of SDL, the Simple
Speaker 2: Direct Media Layer SDL is a cross platform library that
Speaker 2: provides it's a low level drawing surface and handles input.
Speaker 2: So the KIV interface is drawn onto an SDL surface
Speaker 2: within the Android activity. Touch events are captured by the
Speaker 2: Android system, passed to the SDL surfaces on touch method
Speaker 2: in Java, and then forward it into the KIV event loop.
Speaker 1: Okay, getting technical, but I see.
Speaker 2: The layers right, and the book is a really compelling
Speaker 2: example of leveraging this, integrating OpenCV, the big Computer Vision library.
Speaker 2: You could add the OpenCV library as a standard dependency
Speaker 2: in your build dug glidal file. Then you could write
Speaker 2: Java code within your Python activity or another Java class
Speaker 2: that performs OpenCV operations. Imagine having a button in your KIVUI.
Speaker 2: When you press it, it uses pugnius to call a
Speaker 2: custom Java method you wrote. That Java method then grabs
Speaker 2: a camera frame, uses OpenCV to apply, say a canny
Speaker 2: edge detection filter, and maybe displays the result in a
Speaker 2: native image view, or even sends the process data back
Speaker 2: to Python.
Speaker 1: Wow. Okay, so you can have KIV handling the main
Speaker 1: UI and logic, but delegate really heavy or platform specific
Speaker 1: tasks like advanced image processing directly to Java open CV
Speaker 1: running natively exactly.
Speaker 2: It demonstrates truly deep, seamless interoperability. You get the best
Speaker 2: of both worlds, Python's rapid development and kiv's cross platform UI,
Speaker 2: combined with the full power of native Android APIs and
Speaker 2: Java libraries when needed.
Speaker 1: So let's try to bring this all together. We've covered
Speaker 1: a lot today, haven't we. We've journeyed through how KIV,
Speaker 1: along with tools like bill Doozer, really empowers Python developers
Speaker 1: to build surprisingly sophisticated Android applications, not just a toy.
Speaker 1: We saw how you go from simple UIs and basic
Speaker 1: interactions all the way to building complex multi level games
Speaker 1: with animations, collisions, sound qv offers incredible versatility there, and
Speaker 1: then when pure Python our standard KiB widgets are quite enough,
Speaker 1: we explored how plier offers a simpler bridge for common tasks,
Speaker 1: and now Pivnius provides that really deep connection, letting Python
Speaker 1: directly call Java code, which culminates in the ability to
Speaker 1: modify the bill Dozer generated Android studio project itself, integrating
Speaker 1: powerful native libraries like OpenCV directly. It's quite a spectrum
Speaker 1: of possibilities.
Speaker 2: Yeah, this deep dive really hammers home a core message.
Speaker 2: Python's reach extends far, far beyond its traditional domains. Now
Speaker 2: it's not just for data science or web back ends anymore.
Speaker 2: It offers powerful, genuinely efficient solutions for cross platform mobile
Speaker 2: app development. And the tools we discussed KIV, Billdozer, Pygenius
Speaker 2: they make it truly accessible for the vast Python community
Speaker 2: to step into the mobile world. They can turn complex
Speaker 2: ideas into tangible apps without needing to completely abandon their
Speaker 2: existing skills.
Speaker 1: So what does this all mean for you listening right now?
Speaker 1: Imagine the possibilities for innovation when you can combine Python's
Speaker 1: rich ecosystem of libraries. It's ease of use with deep
Speaker 1: control over native mobile features. What kind of unique cross
Speaker 1: platform apps or maybe even games could you create next
Speaker 1: that truly stand out from the crowd. Something to think about.