Website video docs refresh

.gitignore

@@ -22,6 +22,8 @@
 *.skin
 *.jar
 *.class
+*.pyc
+**/__pycache__/
 **/private/*
 **/.idea/*
 **/build/*
@@ -91,3 +93,6 @@ dependency-reduced-pom.xml
 /docs/website/.cache/
 /docs/website/.venv/
 /docs/website/.venv-pagefind/
+/docs/website/.venv-video-refresh/
+/docs/website/.youtube-oauth-token.json
+/docs/website/client_secret.json

docs/website/content/courses/course-01-java-for-mobile-devices/001-introduction.md

@@ -9,7 +9,24 @@ module_order: 1
 lesson_order: 1
 weight: 1
 is_course_lesson: true
-description: "Watch the lesson and follow the accompanying resources."
+description: "An introduction to the course and the modern Codename One workflow."
 ---
 
 > Module 1: Course Lessons
+
+This course is about learning how mobile applications are built in Codename One without treating the framework as magic. The goal is not just to get an app on screen. It is to understand what mobile development asks of you, how Codename One fits into that world, and how to build habits that will still make sense once the project grows beyond a toy example.
+
+If you are starting fresh today, the right place to begin is with the current Maven-based workflow. Create projects with [Initializr](/initializr/), open them in the IDE you already use, and rely on the generated project structure instead of the legacy plugin-based setup shown in some of the older course material. That modern setup is simpler, easier to version, and much closer to the way current Codename One projects are maintained.
+
+The early lessons in this course focus on the fundamentals that keep coming back throughout real projects: how mobile devices differ from desktop environments, how a Codename One application is structured, how layouts and styling work, why the event dispatch thread matters, and how device builds fit into the development loop. Those are the things that make the rest of the framework easier to understand.
+
+You should expect some of the videos in this course to show older tooling. When that happens, use the written lesson as the current source of truth. The important concepts are still worth learning, but the practical workflow has evolved. In particular, modern projects usually start with Maven, use CSS as the primary styling workflow, and use l10n property bundles for localization instead of treating the designer and resource editor as the center of the project.
+
+The best way to use this course is to keep a project open while you read. Run the simulator often, change one thing at a time, and make sure you understand why the framework behaves the way it does before moving on. That feedback loop is what turns the lessons into working knowledge.
+
+## Further Reading
+
+- [Getting Started](/getting-started/)
+- [Initializr](/initializr/)
+- [Developer Guide](/developer-guide/)
+- [Hello World](/hello-world/)

docs/website/content/courses/course-01-java-for-mobile-devices/002-creating-a-hello-world-app.md

@@ -9,12 +9,33 @@ module_order: 1
 lesson_order: 2
 weight: 2
 is_course_lesson: true
-description: "Note: This is the old approach. I suggest checking out the newer approach here."
+description: "Create a first Codename One application using the current Maven-based workflow."
 ---
-
 > Module 1: Course Lessons
 
-
-Note: This is the old approach. I suggest checking out the newer approach here.
+This lesson shows how to build a small but complete Codename One application: an app that starts cleanly, shows a form, responds to input, and is ready to be sent to a device once the basics are working.
 
 {{< youtube 73d65cvyQv4 >}}
+
+The best first project is a very small one. [Create a Maven-based Codename One application using the initializr](/initializr/), open it in your IDE, and spend a few minutes understanding the generated app before you start customizing it. The video covers the same first milestone, but this is one place where it is out of date because it starts with the old IDE plugin flow instead of the current Maven-based setup. At this stage you are not trying to design the final architecture of your product. You are trying to learn the basic rhythm of a Codename One app and confirm that your development environment is working.
+
+One of the first things worth getting right is the package name. In Codename One it becomes part of the app's identity and eventually touches signing, native packaging, and store submission. Choose a stable reverse-domain package name at the beginning instead of treating it as a temporary placeholder.
+
+Once the project is generated, the application class shows you the lifecycle that every Codename One app follows. `init()` is where one-time application setup belongs. `start()` is where the first UI is created and shown. `stop()` is called when the app goes into the background, and `destroy()` is there for shutdown cleanup when needed. That lifecycle is still the backbone of the framework, and understanding it early saves a lot of confusion later.
+
+The actual hello world UI should stay simple. Create a form, add a button, attach an action listener, and show a dialog or some other small response when the user taps it. That single exercise teaches several important things at once. It shows how a form is displayed, how components are added to it, how event listeners are wired, and how the UI responds to interaction. Once that works, you have a real application, even if it is still visually plain.
+
+Run that first version in the simulator and use it as your main feedback loop. The simulator is still the fastest place to confirm that the lifecycle is behaving correctly and that the UI looks sane across different device skins. Only after that loop feels stable should you send a native build. For most teams Android is the easiest first checkpoint. iOS usually comes later because certificates and provisioning need to be in place before the build becomes useful.
+
+Once the app is running, the next step is usually to improve the look and feel. This is one place where the video is out of date. It moves toward the older theme designer and resource-editor workflow. For most current Codename One projects, CSS is the better default for styling and l10n property bundles are the better default for localization. The designer and resource editor still exist, but they are no longer the workflow most new projects should start with.
+
+By the time you have a form on screen, a button responding to taps, and a simulator session you can trust, you already have the foundation you need. From there you can style the app with CSS, add localization with property bundles, and start growing the project without having to relearn the basics later.
+
+## Further Reading
+
+- [Getting Started](/getting-started/)
+- [Hello World](/hello-world/)
+- [Development Environment](/development-environment/)
+- [Build Server](/build-server/)
+- [Themeing](/themeing/)
+- [Moving To Maven](/blog/moving-to-maven/)

docs/website/content/courses/course-01-java-for-mobile-devices/003-core-concepts-of-mobile-development.md

@@ -9,9 +9,30 @@ module_order: 1
 lesson_order: 3
 weight: 3
 is_course_lesson: true
-description: "Watch the lesson and follow the accompanying resources."
+description: "Understand the mobile constraints that shape layout, images, memory usage, and device builds."
 ---
-
 > Module 1: Course Lessons
 
 {{< youtube hwsWdhJHl8Q >}}
+
+Mobile development feels different from desktop development because the constraints are different. Screens vary wildly in size and density, memory is tighter, interaction is touch-first, and native platforms impose rules around packaging, signing, and distribution. If those constraints feel annoying at first, that is normal. The key is to design with them instead of fighting them.
+
+The first concept to get comfortable with is the difference between resolution and density. Resolution tells you how many pixels are on a screen. Density tells you how tightly packed those pixels are. Two devices can have similar resolutions and still look very different because one has far more pixels per inch. That is why a UI that seems fine on one device can suddenly look too small, blurry, or badly balanced on another. In Codename One, this is one of the reasons layouts matter so much. Hard-coded sizes age badly across real devices.
+
+Images are where density becomes expensive. If you ship only one low-resolution asset, it will look soft or pixelated on modern devices. If you ship only very large assets, the app pays in download size and memory use. The practical answer is to be selective. Use vector-friendly approaches where you can, especially for icons, and use raster images only where they genuinely add value. Codename One's multi-image support exists to help match assets to device density, but that should not become an excuse to dump huge image libraries into the app.
+
+For icons and simple symbolic graphics, built-in material icons and font-based icons are often the better choice. They scale cleanly, work well with theme colors, and avoid the asset explosion that comes from exporting multiple bitmap versions of the same shape. For photos and more detailed artwork, regular image assets still make sense, but you should think carefully about where the sharpest version is really needed.
+
+Another mobile concept that surprises people is that shipping an app is not just a matter of compiling code. Native platforms require signing and, in some cases, provisioning. On Android, signing establishes the identity of the app and controls who can publish updates to it. On iOS, certificates and provisioning profiles are part of both development and distribution. That complexity is not specific to Codename One. It is part of mobile development itself, and understanding it early makes later build and release work much less mysterious.
+
+The video spends a fair amount of time on signing and provisioning, and that material is still relevant. What has changed is the workflow around the project. Today you will usually create a Maven project first and then send builds through the current Codename One tooling. But the native platform rules have not gone away. If anything, they are the reason Codename One's build tooling is valuable in the first place.
+
+The broader lesson is that mobile work rewards adaptability. You do not control the screen, the density, the store requirements, the operating system policies, or the amount of memory on the user's device. A good mobile framework helps you live with those constraints. A good mobile developer learns to expect them.
+
+## Further Reading
+
+- [Developer Guide](/developer-guide/)
+- [Build Server](/build-server/)
+- [How Do I Fetch An Image From The Resource File, Add A Multiimage](/how-do-i/how-do-i-fetch-an-image-from-the-resource-file-add-a-multiimage/)
+- [How Do I Create A 9 Piece Image Border](/how-do-i/how-do-i-create-a-9-piece-image-border/)
+- [How Do I Create An iOS Provisioning Profile](/how-do-i/how-do-i-create-an-ios-provisioning-profile/)

docs/website/content/courses/course-01-java-for-mobile-devices/004-what-is-codename-one.md

@@ -9,9 +9,29 @@ module_order: 1
 lesson_order: 4
 weight: 4
 is_course_lesson: true
-description: "Watch the lesson and follow the accompanying resources."
+description: "Understand Codename One as a cross-platform Java application framework and build system."
 ---
-
 > Module 1: Course Lessons
 
 {{< youtube XSztvFzQAr0 >}}
+
+The shortest description of Codename One is that it lets you build cross-platform applications in Java. The longer and more useful answer is that Codename One is a combination of framework APIs, platform ports, build tooling, and a development workflow that turns one codebase into applications that run on multiple targets.
+
+That combination matters because Codename One is not just a widget library. It provides a portable UI toolkit, portable device APIs, a simulator, native build infrastructure, and the glue that keeps those parts working together. When you create a project, write Java code, run it in the simulator, and later send a native build, you are using several layers of the system at once even if you do not think about them separately.
+
+At the application level, you mostly work with the public Codename One API. That is the part that gives you forms, layouts, networking, storage, media, and the rest of the framework surface. Underneath that is a porting layer that maps the framework behavior onto each platform. That is one of the reasons Codename One can behave consistently across platforms while still producing native builds.
+
+The video goes into the history from LWUIT through the early Codename One years, and that background helps explain some design decisions that are still visible in the framework. It also spends time on the old IDE plugin flow and older toolchain assumptions. That part is out of date. Today the practical entry point is a Maven-based project created with [Initializr](/initializr/), not a legacy IDE plugin wizard. The underlying idea is the same, though: the tooling exists to assemble the framework, your application code, and the native build pipeline into one working system.
+
+Another important part of the Codename One model is that the framework is versioned with the application. That means the app you ship carries the framework code it was built with. In practice this gives shipped apps stability and lets you choose when to adopt framework changes. It also makes versioned builds and controlled upgrades much more practical than they would be if every running app depended on one mutable shared runtime.
+
+Codename One also makes a deliberate trade-off in its UI architecture. It uses a lightweight component model so the framework can keep behavior more consistent across targets and so the simulator can behave meaningfully. That design choice is a big part of why the same application logic can run across the supported targets without being rewritten for each platform.
+
+If you are trying to decide whether Codename One is "just Java for mobile", the answer is no. It is a full cross-platform application stack with Java at the center. The more accurate way to think about it is this: Codename One gives you one framework, one language, and one application model, then handles the platform-specific work needed to turn that into real applications.
+
+## Further Reading
+
+- [Developer Guide](/developer-guide/)
+- [Getting Started](/getting-started/)
+- [Build Server](/build-server/)
+- [Moving To Maven](/blog/moving-to-maven/)

docs/website/content/courses/course-01-java-for-mobile-devices/005-anatomy-of-a-codename-one-application.md

@@ -9,9 +9,30 @@ module_order: 1
 lesson_order: 5
 weight: 5
 is_course_lesson: true
-description: "Watch the lesson and follow the accompanying resources."
+description: "Understand the structure of a modern Codename One project and the files that matter."
 ---
-
 > Module 1: Course Lessons
 
 {{< youtube 8fxZVc1hw6Q >}}
+
+Every framework has a moment where the generated project stops feeling friendly and starts feeling like a pile of mysterious files. This lesson is about getting past that point. A Codename One project is much easier to work with once you know which files define the application, which files are generated, and which parts are just build output that you can ignore.
+
+The video walks through the old IDE-plugin project layout and spends a lot of time on `build.xml`, `lib`, and other files that were central to the older Ant-based workflow. That part is out of date for new projects. Today you will usually start from a Maven project, so the file and directory structure looks different. Even so, the important ideas from the lesson still translate well: some files define the app, some define the build, some are caches or artifacts, and some exist only to support a specific toolchain.
+
+In a modern Codename One project, the first files worth understanding are the Maven build files and the application source itself. The Java application class still expresses the lifecycle of the app. Resource directories still contain the assets and configuration the app depends on. Build-related files still describe how the project is packaged and how platform-specific work is triggered. The main difference is that Maven now owns the overall build structure instead of the old plugin-generated Ant layout.
+
+One file that remains conceptually important is `codenameone_settings.properties`. It still acts as the central configuration point for many application-specific settings, including identifiers, build hints, and platform-specific options. You do not need to hand-edit it for everything, and in many cases it is better to use the supported tooling, but you do need to know it exists and what role it plays. When something about the application's identity or native configuration changes, this file is often involved.
+
+Build output should be treated as disposable. Whether it is a Maven `target` directory or older `build` and `dist` folders from the plugin era, generated artifacts are there to support a build or a simulator run. They are useful for debugging packaging problems, checking what assets ended up in the final jar, or understanding why an application became unexpectedly large, but they are not the place to make source-level changes.
+
+That distinction becomes especially important when you start troubleshooting. If the final package is too large, inspect the generated artifact and see what actually got bundled. If a build behaves differently from what you expect, check whether the configuration lives in source files, properties, or generated output. A lot of confusion disappears once you stop treating every file in the project tree as equally important.
+
+So the real anatomy of a Codename One application is simpler than it first appears. There is the app code you write, the project configuration that describes how it should be built, the assets it depends on, and the generated output produced along the way. Learn those boundaries early and the rest of the project becomes much easier to reason about.
+
+## Further Reading
+
+- [Developer Guide](/developer-guide/)
+- [Getting Started](/getting-started/)
+- [Build Server](/build-server/)
+- [Hello World](/hello-world/)
+- [How Do I Get Repeatable Builds, Build Against A Consistent Version Of Codename One & Use The Versioning Feature](/how-do-i/how-do-i-get-repeatable-builds-build-against-a-consistent-version-of-codename-one-use-the-versioning-feature/)