Module 1: Course Lessons Layouts are the reason a Codename One UI can survive different screen sizes, orientations, pixel densities, and languages. Components do not live at fixed coordinates. They live inside Container objects, and those containers use layout managers to decide how much space each child gets and where it should appear. ...
Module 3: Extracting a UI Design With the base form in place, the main menu screen becomes the first real test of the design system. This is where the shared shell has to support actual content: category filters, dish cards, images, buttons, and the spacing that makes the screen feel usable rather than crowded. ...
Module 4: App Maker Server API design becomes much easier once you stop asking what would be theoretically elegant and start asking what the client actually needs to do. That is the real value of this lesson. The tempting design for an app maker would be one giant “submit everything and build” request. It sounds simple on paper, but it does not fit the product well. The user is editing incrementally, uploading assets separately, previewing changes, and eventually asking for a build. Those are different operations with different reliability and security concerns, so they should not be collapsed into one oversized endpoint. ...
Module 1: Course Lessons Styling in Codename One starts with a simple question: are you trying to change how components look, or are you trying to change how the UI behaves structurally? If the answer is visual styling, the modern default is CSS. The video uses the older designer-centered theme workflow, and that still helps explain the underlying concepts, but for a new project you should usually start with CSS and treat the older theme editor as a lower-level tool rather than the main path. ...
Module 1: Course Lessons Adapting a UI design is never just a matter of copying pixels from a mockup into code. A design file shows you the visual intention. Your job is to translate that intention into a layout that survives different screen sizes, densities, font rendering differences, and real user interaction. ...
Module 3: Extracting a UI Design One of the more useful lessons in UI implementation is learning when something that looks like a dialog should really be a form. The checkout screen in this module is a good example. Visually it behaves like an overlay, but structurally it owns more of the screen than a simple dialog and has controls that sit outside the central receipt area. Treating it as a form gives you much more control. ...
Module 4: App Maker Server Once the server API exists, the client has to use it without making the product feel like a network admin console. That is the theme of this lesson. The first important client-side job is establishing or retrieving the secret associated with the current editing device or session. That is an infrastructure step, but the user should not experience it as a setup ritual. The app should just do the work and continue. ...
Module 4: UI Design From Scratch Working from an existing design is one skill. Continuing when the design is incomplete is another. This module starts from that second situation: some screens already exist, but the application still needs additional forms, navigation paths, and visual decisions that were never specified in the original mockup. ...
Module 5: SQLite and ORM Binding As soon as the app maker starts feeling real, local persistence becomes valuable. The point is not that SQLite is always the perfect storage choice. The point is that instant startup, local continuity, and reduced server dependency make the editing experience much better. ...
Module 1: Course Lessons Persistent data in Codename One usually starts with a choice between three levels of storage: Preferences for very small settings, Storage for simple app-private persisted objects or blobs, and SQL for data that needs real querying, sorting, or filtering. The file system sits beside those as a lower-level tool rather than the default answer to every persistence question. ...