Courses

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, 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. ...

Module 1: Restaurant Server This course starts by bringing the server back into the picture. Earlier material focused heavily on the mobile side, but a real full-stack application only makes sense once the server responsibilities are clear as well. The good news is that most of the server code in this module is deliberately boring, and that is exactly what you want. A good backend is not usually interesting because of flashy implementation tricks. It is useful because it behaves predictably, enforces the rules the client should not be trusted to enforce, and keeps the application state coherent. ...

Module 1: Working with CSS This lesson explains how CSS fits into a modern Codename One project and how it should be used in day-to-day styling work. For most new Codename One projects, CSS is the first place to reach when you want to style the UI. It is the most practical way to control colors, borders, fonts, spacing, and component states without pushing visual concerns into Java code. The video introduces CSS as an optional plugin, but that part is out of date now. In current Codename One development, CSS is a normal part of the workflow rather than something experimental. ...

Module 1: Course Lessons 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. The best first project is a very small one. Create a Maven-based Codename One application using the 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. ...

Module 2: Working with Custom Web Services Sooner or later most non-trivial mobile apps need a server. That server might store data, authenticate users, send push notifications, validate business rules, or expose an API that several client applications share. In this course module, Spring Boot is used as the server-side counterpart because it is a straightforward way to build a Java backend without drowning in boilerplate. ...

Module 2: The App Maker The app maker in this course is a different kind of product from the restaurant app that came before it. The restaurant app had plenty of familiar reference points. The app maker does not. That means the design process has to start from structure and purpose rather than from an existing polished mockup. ...

Module 2: Working with Custom Web Services Once a backend exists, the mobile app needs a clean way to talk to it. In practice that usually means sending HTTP requests, receiving JSON responses, and converting those responses into application objects that the UI can work with. That process is simple in concept, but it becomes messy fast if networking code leaks everywhere. ...

Module 1: Course Lessons 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. ...

Module 2: The App Maker Once the high-level direction is clear, the next step is to turn that direction into actual screens and decide which ones belong in the first version. This is where many projects start drifting, because every missing form suddenly feels important. ...

Module 3: Initial UI Mockup Once the product direction is stable enough, the next question is architectural: what parts of the UI are common, and what parts belong to individual screens? This lesson starts answering that by defining the form hierarchy for the initial app-maker mockup. ...