Latest posts from Codename One.
Blog
Insights, release updates, tutorials, and engineering notes from the Codename One team.
Game Builder Tutorial 3: Build a First-Person 3D Dungeon
The final tutorial takes the same data-driven pattern from Tutorial 1 and Tutorial 2 into 3D. Duke’s last adventure sends him underground: Crypt Walk, a first-person dungeon of stone corridors where the tea cups have invaded his coffee break. He hunts them through the maze and fires coffee beans to smash them, while the walls box him in. The headline difference from the 2D tutorial is what happens at runtime — instead of sprites in a Scene, each element becomes a GPU-rendered Model under a perspective camera with lighting. You author the same way; the runtime renders it in 3D. ...
VideoIO, PCM Mixing And Timed Whisper Captions
This release turns media from “play a file” into “build a file.” PR #5315 adds VideoIO, a cross-platform video subsystem that can encode app-rendered frames and audio into a standard video file, then decode an existing clip back into exact RGBA frames and PCM audio. PR #5317 adds AudioMixer, a sample-accurate PCM timeline. PR #5319 adds timed Whisper transcription segments with SRT and VTT output. ...
Versioned Builds Are Back, With Master Builds For Fast Verification
Versioned builds are back. The old versioned-build story came from the Ant era. Codename One had point releases every few months, and versioning meant “build against that point release.” It made sense at the time, but the platform and the build infrastructure moved on. Maven Central, faster releases, more build targets, and a much larger code surface made the old model hard to maintain. ...
Commerce And Secrets Without An IAP Tax
Commerce is the easiest feature in this release to misunderstand, so the first sentence has to be blunt: Commerce does not replace IAP and never will. Purchases still go through Apple, Google, or the payment processor you chose. Codename One does not process the payment, does not touch the money, and does not take a percentage. PR #5300 adds infrastructure around the annoying backend work that comes after a purchase: validation, entitlement checks, subscription lifecycle, webhooks, and reporting. ...
Motion, Stylus, Trackpads And Foldables In The Core
For a long time, mobile meant a touch screen and a few platform-specific escape hatches. That is no longer enough. A Codename One app can run on phones, tablets, desktops, watches, TVs, browsers, foldables, touch laptops, external displays, cars, and devices with pens, mice, and trackpads. PR #5310 and PR #5309 make that hardware visible through core APIs instead of cn1libs and platform branches. ...
CarPlay And Android Auto From One Codename One API
Yesterday’s release post was about the bigger business line we will not cross: no royalties on IAP, ads, commerce or app revenue. This post is about one of the most concrete platform additions in that release. PR #5281 adds Apple CarPlay and Google Android Auto support under com.codename1.car. The first thing to know is what this is not. CarPlay and Android Auto are not second screens where your normal Codename One Form is drawn. They are driver-safe, template-based systems. Apple and Google decide which templates are legal in a car, how many rows can appear, which app categories are allowed, and which interactions are safe while driving. ...
More Surfaces, Same Deal: Cars, Sensors, Commerce, Video And Builds
Last week’s release post was about funding open source without the bait and switch. This week’s release tests that idea again, because two of the new features touch paid infrastructure directly: Commerce and versioned builds. That kind of expansion often makes the model slippery. A platform adds something developers need, puts it behind an account tier, and over time the open part gets worse or the paid part starts taxing success. We do not want to drift into that, so the useful question for this week is not just what shipped, but how the paid pieces behave. ...
Game Builder Tutorial 2: Build a Blackjack Card Game (Duke Jack)
In Tutorial 1 Duke dashed for coffee with arcade physics. Now he sets the cup down for a calmer contest: Duke Jack, a game of blackjack. A card game has none of that arcade motion — cards sit on the felt and the rules decide who wins. This tutorial shows how the same Game Builder pattern (visual data + an onUpdate companion) handles a card game, where your code reads the cards and runs the table instead of simulating movement. We’ll build a felt table, deal a real hand, and wire up the complete blackjack rules: hit, stand, the dealer’s draw, and the win/lose decision. ...
Device Integrity And App Review: RASP, Attestation, And Asking For Ratings Right
Friday’s post on funding open source without the bait-and-switch covered the model behind this week’s releases. Here are two more features from it. Both ship this week. Both are small. Both live in core: no cn1lib to add, no native interface for you to write. They follow the same pattern you have seen across Codename One for years. There is a portable Java API, it calls through to native behavior where the platform supports it, and it falls back to something reasonable everywhere else. ...
Apple TV And Android TV: One Codebase, And CSS @media For The Living Room
This is the Tuesday follow-up to Friday’s funding open source without the bait and switch, and it picks up right where last week’s Apple Watch port left off. The watch work gave us the pattern for a new form factor: a shared API to detect it, resource overrides to theme it, and a builder path to ship it. PR #5261 applies that same pattern to the television. You can now detect a TV at runtime, restyle for it from CSS, ship a single Android APK that also runs on Google TV, and generate a separate Apple TV target from the same project. ...
A Privacy-First Analytics API: One Facade, A Provider SPI, And A Consent Gate
On Friday I wrote about funding open source without the bait and switch, and the analytics API in PR #5266 is the clearest example of the model in that post: an open seam anyone can plug into, with our paid implementation as one optional choice. This is the Monday follow-up that gets into how the API actually works. ...
Rich Text And Code Editing: RichTextArea And A Syntax-Highlighting CodeEditor
Friday’s post covered how we fund this work without the bait-and-switch; today is the engineering side of the same week, with two new visual editors. PR #5272 adds two components: RichTextArea, a WYSIWYG rich text editor, and CodeEditor, an IDE-style code editor with syntax highlighting. They are different on the surface and identical underneath, which is the part worth explaining first. ...