DEV Community: Shai Almog

VideoIO, PCM Mixing And Timed Whisper Captions

Shai Almog — Wed, 15 Jul 2026 14:58:28 +0000

This release turns media from "play a file" into "build a file."

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

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.

Together, these APIs let Codename One generate proper videos across supported app platforms.

Encoding App-Rendered Frames

VideoIO is gated like other optional platform APIs:

if (!VideoIO.isSupported()) {
    return;
}

Then you build a writer. Frames are ordinary Image instances, so the pixels can come from your UI, a game renderer, an animation scrubber, a generated chart, or a custom drawing routine.

String out = FileSystemStorage.getInstance().getAppHomePath() + "/demo.mp4";

VideoWriter writer = new VideoWriterBuilder()
        .path(out)
        .container(VideoIO.CONTAINER_MP4)
        .width(720)
        .height(1280)
        .frameRate(30)
        .videoCodec(VideoIO.CODEC_H264)
        .videoBitRate(4000000)
        .hasAudio(true)
        .audioCodec(VideoIO.CODEC_AAC)
        .sampleRate(44100)
        .audioChannels(2)
        .build();

try {
    for (int i = 0; i < 90; i++) {
        Image frame = renderFrame(i);
        writer.writeFrame(frame, i * 1000L / 30L);
    }

    short[] pcm = renderAudioTrack();
    writer.writeAudio(pcm, 44100, 2, 0);
} finally {
    writer.close();
}

The exact codecs available are platform-dependent. VideoIO.getAvailableEncoders() and getAvailableDecoders() expose what the device actually supports, including hardware acceleration flags.

Frame-Accurate Decode

The old Media API is a player. It can seek, but playback seek is usually key-frame based. That is not enough when you are generating thumbnails, verifying a rendered animation, extracting frames for processing, or round-tripping a generated video in a test.

VideoReader.frameAt(ms) returns the exact frame at a timestamp:

VideoReader reader = VideoIO.getVideoIO().openReader(out);
try {
    VideoFrame oneSecond = reader.frameAt(1000);
    Image image = oneSecond.getImage();
} finally {
    reader.close();
}

You can also resample a whole clip to a constant frame rate:

reader.readFrames(10, frame -> {
    process(frame.getImage(), frame.getTimestampMillis());
    return true;
});

And when the backend supports it, readAudio() returns the audio track as an AudioBuffer:

AudioBuffer audio = reader.readAudio();

JavaScript currently supports frame decode and full encode, but decoded audio extraction is not wired there yet. TV, Watch and Car targets do not expose VideoIO.

PCM Mixing On One Clock

AudioMixer is intentionally small. It combines interleaved float PCM tracks in the normalized [-1, 1] range on a single sample clock.

AudioBuffer music = new AudioBuffer(musicPcm.length);
music.copyFrom(44100, 2, musicPcm);

AudioBuffer voice = new AudioBuffer(voicePcm.length);
voice.copyFrom(44100, 2, voicePcm);

AudioMixer mixer = new AudioMixer(44100, 2);
mixer.addTrack(music, 0, 0.65f);
mixer.addTrack(voice, 1200, 1.0f);

AudioBuffer mixed = mixer.mix();

If you already know exact sample-frame offsets, use addTrackAtFrame(...) instead of millisecond offsets. The output clips to [-1, 1] and can be written through WAVWriter or passed into a VideoWriter.

float[] pcm = new float[mixed.getSize()];
mixed.copyTo(pcm);

WAVWriter wav = new WAVWriter(new File("mix.wav"),
        mixed.getSampleRate(),
        mixed.getNumChannels(),
        16);
try {
    wav.write(pcm, 0, mixed.getSize());
} finally {
    wav.close();
}

Subtitles From Timed Whisper

The Whisper cn1lib already returned text. The new transcription API returns timed segments:

String modelPath = FileSystemStorage.getInstance().getAppHomePath()
        + "/ggml-base.en.bin";
Transcriber t = WhisperRecognizer.transcriber(modelPath);
TranscriptionResult result = t.transcribe(
        new TranscriptionRequest(audioPath).setLanguageTag("en-US")).get();

String srt = result.toSrt();
String vtt = result.toVtt();

That get() call is blocking, so run it off the EDT or use the returned AsyncResource callback. Those segment timestamps are the missing link between "we transcribed the video" and "the video has subtitles." A generated training clip, game replay, tutorial or support recording can now get caption files automatically.

The Whisper PR also fixed native packaging gaps: Android now ships a JNI AAR with native slices, iOS exposes timed segments, JavaSE keeps a fallback segment, Linux and Windows native bridge modules are packaged, and JavaScript is explicitly unsupported.

Where MorphTransition Fits

PR #5314 is listed as a smaller enhancement in the release post, but it connects directly to media generation. MorphTransition is now scrubbable:

MorphTransition transition = MorphTransition.create(300)
        .snapshotMode(true)
        .opacity("card", 0, 255)
        .scale("card", 0.8f, 1.0f)
        .rotation("card", -0.2f, 0);

transition.setProgress(0.5);

Scrubbing means a transition can be rendered deterministically at progress 0.0, 0.1, 0.2, and onward. That is exactly what a video export loop needs.

Platform Backends

The backends use native media stacks rather than one portable lowest-common-denominator codec:

JavaSE and the simulator use bundled ffmpeg/ffprobe.
iOS and macOS use AVFoundation.
Android uses MediaCodec, MediaMuxer, MediaExtractor and MediaMetadataRetriever.
Windows uses Media Foundation.
Linux uses GStreamer.
JavaScript uses HTML5 video/canvas decode and WebCodecs encode.

This gives each platform the codec set and acceleration it already has. App code still starts from the same VideoIO facade.

Wrapping Up

Video export used to be something a Codename One app handed off to a backend or a native library. Now the app can render frames, mix PCM, encode a video, decode it back for validation, and generate timed captions. That opens up tutorials, game clips, social exports, support recordings, animated explainers and media QA workflows from the same Java codebase.

No special revenue model is attached to that. The app generates the media. The app owns the output.

Versioned Builds Are Back, With Master Builds For Fast Verification

Shai Almog — Tue, 14 Jul 2026 14:43:46 +0000

Versioned builds are back.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

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.

The new model keeps the part developers actually need: a way to stabilize and diagnose builds without being forced onto the current server-side framework every time.

Pin A Released Version

By default, a cloud build uses the current Codename One release. With a versioned build, you can pin to a specific published version:

build.cn1Version=7.0.182

The build server fetches that version's framework artifacts and builds against them. If you also want the simulator and local compile classpath to match, set the matching cn1.version in your Maven project.

This is useful in three situations:

You are stabilizing a production release and want fewer moving parts.
A build started failing and you need to know whether the regression is in your app or in the framework/build server.
You are supporting an older customer app and need to reproduce the environment it last built with.

Build Against Master

The more interesting part is master:

build.cn1Version=master

This builds against the current development head of Codename One. Community developers recently asked for nightly or daily builds, but pushing nightly artifacts through Maven Central and support channels is messier than it sounds. A fixed nightly is also stale the moment the next fix lands.

Building against master is a faster developer loop for most verification cases. If a fix landed this morning and you need to verify it on a device, you do not wait for tomorrow's nightly. You ask the cloud build to use the current development head.

Use this for verification, not for shipping production builds. master is active development. It gives you speed, not a stability promise.

Why It Is Tiered

The small overhead of fetching versioned artifacts is noticeable, but that is not the real reason this is limited by account level.

The hard cost is support.

If a free user reports a build issue from six months ago, and another user reports one from yesterday, and an enterprise customer needs a diagnosis against a two-month-old version, support becomes a bisection problem across a moving build system. The further back the community goes, the harder every issue is to understand, reproduce, and fix.

That does not mean versioned builds should only exist at the top. The new approach opens them much further down than before, including limited access for basic/free usage. The longer windows still belong to higher tiers because those teams are the ones that need older reproducible builds and the support time that comes with them.

The principle is simple: the tier buys a support window and capacity, not a right to keep your app revenue.

A Practical Workflow

When a build starts failing after an update:

# First, verify the last known good release.
build.cn1Version=7.0.182

If that works, the regression is likely in the framework or build server. If it still fails, the issue is probably in your app, dependencies, native configuration, or a platform toolchain change that affects the old version too.

When a fix lands:

# Then verify the unreleased fix.
build.cn1Version=master

Once the fix is released, pin to the release you plan to ship with or remove the hint to follow the current default again.

What This Does Not Solve

Versioned builds are not a time machine for every external dependency. Apple, Google, OS SDKs, certificates, signing rules, app store requirements, Maven repositories and native tools all move. A six-month-old framework can still be affected by a current Xcode or Android requirement.

It also does not make master a nightly release channel. It is a verification channel.

That distinction keeps the feature useful without turning support into archaeology for every build ever made.

Commerce And Secrets Without An IAP Tax

Shai Almog — Mon, 13 Jul 2026 15:39:12 +0000

Commerce is the easiest feature in this release to misunderstand, so the first sentence has to be blunt:

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

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.

That backend work is real. Anyone who has shipped subscriptions knows the trap. Buying a SKU is not the same as knowing whether the user has the right to a feature right now. Renewals, grace periods, refunds, billing retry, product changes, trials, family sharing and store server notifications all show up later. The device has one view. The store has another. Your backend usually needs a third.

Commerce is the optional service that turns that mess into an entitlement.

Entitlements Instead Of SKU Branches

Your app should not need to know every SKU that grants pro. It should ask for pro.

CommerceManager cm = CommerceManager.getInstance();
cm.setAppUserId(accountId);

if (cm.isEntitled("pro")) {
    unlockProFeatures();
}

Purchases are still delegated to the existing Purchase API:

cm.subscribe("pro_monthly");
// or
cm.purchase("remove_ads");

After a purchase, or when the app starts, refresh off the EDT:

new Thread(() -> {
    CommerceManager cm = CommerceManager.getInstance();
    cm.refresh();

    CN.callSerially(() -> {
        if (cm.isEntitled("pro")) {
            unlockProFeatures();
        }
    });
}).start();

refresh() validates the current receipts with the cloud when the build has a build_key and commerce is enabled. In a local build or simulator, it safely falls back to the normal Purchase path.

What Happens When Quota Runs Out

This is the real question that matters most. If Commerce is tiered, what happens when a developer exceeds quota?

Validation degrades. Purchases do not stop.

CommerceManager.isDegraded() tells you the cloud did not return a server-validated answer. In that state, entitlement checks fall back to the platform's own receipt signal, treating the entitlement id as a subscription SKU when no cached cloud answer exists. That is less rich than server-side validation, but it is the right failure mode. A paying user should not be locked out because your account hit a validated-volume cap.

cm.refresh();
if (cm.isDegraded()) {
    Log.p("Commerce validation degraded; using store-direct fallback");
}

Commerce is tiered because it is a backend service that can be abused: receipt validation, store API calls, lifecycle processing, webhook delivery and revenue analytics cost real infrastructure. The degradation rule is what keeps that business reality from becoming user pain.

What Commerce Adds

The service can:

Validate receipts against Apple and Google.
Normalize subscription state across stores.
Track entitlements by your app user id.
Forward lifecycle webhooks to your backend with HMAC signatures.
Present revenue metrics such as MRR, ARR, ARPU, churn, trial conversion, cohort retention and realized LTV.

The app-facing API remains small because the complicated part lives server-side:

CommerceManager cm = CommerceManager.getInstance();
cm.setAppUserId(myAccountId);
cm.refresh();
boolean active = cm.isEntitled("remove_ads");

That split explains how Commerce complements IAP instead of replacing it. Purchase starts the transaction. Commerce answers the longer-term entitlement question.

Secrets

The same PR adds com.codename1.security.Secrets, which solves a different but related problem: API keys do not belong in source code or in the app binary.

// Run off the EDT; the first call may hit the network.
String mapsKey = Secrets.get("googlemaps.key");

The value is fetched from the Codename One Cloud vault over TLS and cached in SecureStorage. refresh(name) forces a fresh fetch after you rotate the value server-side, and clear(name) drops the cached copy.

String key = Secrets.refresh("googlemaps.key");
Secrets.clear("googlemaps.key");

Only app-readable secrets are served to the device. Server-only credentials, such as App Store Connect keys or Google Play service account JSON used for commerce validation, stay in the vault and are never reachable from client code.

That rule is non-negotiable: do not check API keys into source, do not paste them into snippets, and do not embed server credentials in the binary. If the app can read a secret, a determined attacker can eventually extract it. Secrets reduces exposure and makes rotation easier; it does not turn a client app into a secure server.

The Boundary

Commerce and Secrets are both cloud features, but they sit on different sides of the volume line. Secrets usage stays low enough to enable it for everyone. Commerce has tiers because validation and analytics can create real backend load.

The important boundary is not tiering. The boundary is lock-in. You can still use the raw Purchase API. You can still build your own receipt backend. You can still ship an app that sells subscriptions without giving Codename One a revenue share.

Commerce is there to remove backend pain, not to insert a toll booth.

Motion, Stylus, Trackpads And Foldables In The Core

Shai Almog — Sun, 12 Jul 2026 14:23:42 +0000

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.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

PR #5310 and PR #5309 make that hardware visible through core APIs instead of cn1libs and platform branches.

Motion Sensors And Gestures

The new com.codename1.sensors package exposes accelerometer, gyroscope and magnetometer readings. It also derives gravity, linear acceleration and orientation in the core when the platform does not provide them directly.

MotionSensorManager sensors = MotionSensorManager.getInstance();
MotionSensor accel = sensors.getSensor(MotionSensorManager.TYPE_ACCELEROMETER);

if (accel != null) {
    MotionSensorListener listener = new MotionSensorListener() {
        public void motionReceived(MotionEvent evt) {
            label.setText(evt.getX() + ", " + evt.getY() + ", " + evt.getZ());
            label.getParent().revalidate();
        }
    };
    accel.addListener(listener);
}

The manager itself is always available. Individual sensors return null when the hardware is unsupported, so the app can keep one code path with a small capability check.

Gestures are built on top of the sensor stream in the core:

MotionSensorManager.getInstance().addGestureListener(
        GestureEvent.TYPE_SHAKE,
        new GestureListener() {
            public void gestureDetected(GestureEvent evt) {
                Dialog.show("Shaken", "You shook the device", "OK", null);
            }
        });

The recognized set is practical rather than exotic: shake, flip face down, flip face up, tilt left, tilt right, tilt forward, tilt backward, pick up and free fall. Because recognition lives in GestureEngine, every port that exposes an accelerometer gets the same behavior.

Sampling is reference counted. The hardware powers on while listeners exist and powers down when they are removed. On iOS you still need ios.NSMotionUsageDescription with a user-facing reason for motion access.

Rich Pointer Detail

Classic pointer callbacks tell you where a press happened. Modern input asks more questions: was it a mouse, a finger, a stylus, or an eraser? Which button? What pressure? Was the pen tilted? Was the pointer hovering?

PointerEvent is the snapshot attached to pointer action events:

myComponent.addPointerPressedListener(e -> {
    PointerEvent pe = e.getPointerEvent();
    if (pe.isSecondaryButton()) {
        showContextMenu(pe.getX(), pe.getY());
    }
    drawPreview(pe.getX(), pe.getY(), pe.getPressure());
});

You can also poll the current dispatch state through CN:

int button = CN.getPointerButton();
float pressure = CN.getPointerPressure();
boolean pen = CN.isStylusPointer();
PointerEvent current = CN.getCurrentPointerEvent();

On plain touch screens these values have safe defaults: primary button, pressure 1.0, touch or unknown pointer type. Existing apps keep working.

Wheel, Trackpad And Context Menus

WheelEvent is now the cross-platform scroll-gesture event. It handles mouse wheels, precision trackpads, horizontal scrolling, iOS/iPadOS pointer devices and the Apple Watch Digital Crown through the same path.

canvas.addMouseWheelListener(e -> {
    WheelEvent w = (WheelEvent)e;
    if (w.isControlDown()) {
        zoom(w.getDeltaY());
        w.consume();
    }
});

Consuming the event suppresses the default scroll. That is the difference between "wheel scrolls the container" and "control plus wheel zooms a design surface."

For context menus, use the higher-level listener:

label.addContextMenuListener(e -> {
    e.consume();
    showMyContextMenu(e.getX(), e.getY());
});

It fires for right click, stylus barrel button and long press, which is exactly the kind of cross-platform behavior app code should not have to rediscover.

Trackpad magnify and rotate gestures route to component methods:

Container photo = new Container() {
    protected boolean pinch(float scale) {
        zoom(scale);
        return true;
    }

    protected boolean rotation(float radians) {
        rotate(radians);
        return true;
    }
};

Stylus And Foldables

Stylus support exposes pressure, tilt, contact size and eraser type. A drawing surface can listen only to stylus events:

drawingArea.addStylusListener(e -> {
    PointerEvent pe = e.getPointerEvent();
    float width = 1f + pe.getPressure() * 9f;
    if (pe.isEraser()) {
        erase(pe.getX(), pe.getY());
    } else {
        drawPoint(pe.getX(), pe.getY(), width);
    }
});

Foldables use DevicePosture:

DevicePosture posture = CN.getDevicePosture();
if (posture.isFoldable() && posture.isTableTop()) {
    layoutForTableTop(posture.getFoldBounds(null));
}

CN.addPostureListener(e -> relayoutForPosture(CN.getDevicePosture()));

On Android, foldable support is opt-in with android.foldableSupport=true, so apps that do not need the AndroidX window library do not carry it. The simulator can generate posture changes for testing.

Wrapping Up

Input used to mean key codes, pointer coordinates, and maybe a scroll wheel. That model is too small now. A modern app has to reason about pointer type, pressure, hover, buttons, tilt, posture, trackpads, sensor sampling, and gestures that may or may not exist on the current device.

The new APIs do not make that complexity disappear. They put it behind capability checks and default-safe events, so the same component can handle a finger on a phone, a stylus on a tablet, a mouse on desktop, and a foldable hinge without turning every screen into platform-specific code.

CarPlay And Android Auto From One Codename One API

Shai Almog — Sat, 11 Jul 2026 14:27:46 +0000

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.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

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.

Codename One now gives you one portable way to describe those templates.

The Template Model

A car app registers a CarApplication. When a head unit connects, the application returns a root CarScreen. Each screen returns one CarTemplate: list, grid, pane, message, navigation, or now-playing.

import com.codename1.car.*;

public class MyApp {
    public void init(Object context) {
        Car.setApplication(new MyCarApplication());
    }
}

class MyCarApplication extends CarApplication {
    public CarScreen onCreateRootScreen(CarContext context) {
        return new LibraryScreen();
    }
}

class LibraryScreen extends CarScreen {
    protected CarTemplate onCreateTemplate() {
        return new CarListTemplate().setTitle("Library")
            .addRow(new CarRow("Now Playing")
                .setText("Daft Punk - Discovery")
                .setOnAction(ctx -> play()))
            .addRow(new CarRow("Albums")
                .setBrowsable(true)
                .setOnAction(ctx -> ctx.pushScreen(new AlbumsScreen())))
            .addRow(new CarRow("Playlists")
                .setBrowsable(true)
                .setOnAction(ctx -> ctx.pushScreen(new PlaylistsScreen())));
    }
}

That code maps to CPListTemplate on CarPlay and ListTemplate on Android Auto. Grid items map to CPGridButton and GridItem. The now-playing template routes to the system media surface. Navigation gets a template shell with controls and ETA strips; the moving map surface is scaffolded but still being completed.

Navigation And Lifecycle

CarContext gives you a head-unit stack:

context.pushScreen(new DetailScreen());
context.popScreen();
screen.invalidate();
context.showToast("Added to queue");

CarScreen has lifecycle hooks for create, resume, pause, and destroy. CarApplication receives connect and disconnect callbacks, and you can listen globally:

Car.addConnectionListener(new CarConnectionListener() {
    public void carConnected(CarContext ctx) {
        startLocationStream();
    }

    public void carDisconnected() {
        stopLocationStream();
    }
});

That is a good place to start and stop work that only exists while the dashboard is connected.

Zero Cost When Unused

The build system scans your bytecode. If it sees com.codename1.car, it injects the native wiring. If it does not, the app carries none of this.

That is especially important for a framework with one codebase. A normal shopping app, game, or business tool should not gain a CarPlay dependency just because the framework knows how to build one.

Build Hints And Approval

Car app categories matter. The build can inject wiring, but Apple and Google still decide whether an app is allowed into the car.

ios.carplay.audio=true
ios.carplay.navigation=true
android.androidAuto.navigation=true
android.androidAuto.poi=true

Audio is the default CarPlay category when no iOS car category is specified. Messaging, navigation and point-of-interest categories need the matching hints. Restricted Android Auto categories and real CarPlay deployment still require platform approval and, for iOS, the relevant CarPlay entitlement on your Apple App ID.

That is not a Codename One limitation. It is the safety model of the car platforms.

Simulator Head Units

The simulator has a Car menu now. Car > Connect CarPlay and Car > Connect Android Auto open a simulated head-unit window that renders the same portable template tree. It is not a pixel-perfect emulator, but it gives you a fast loop for stack navigation, row caps and action callbacks.

Selecting a browsable row pushes the next screen:

That is the right level of simulation. You can build the car experience while still working in the normal desktop loop, then use Apple's CarPlay simulator or Android's Desktop Head Unit when you need to test the native projection layer.

Wrapping Up

CarPlay and Android Auto support is a platform capability, not a revenue feature. There is no extra royalty because your podcast app, navigation app, or point-of-interest app reaches a dashboard. You still need Apple and Google approval for the categories they restrict, and you still need to design within the car template catalogue. Codename One now gives you the portable model and build wiring so that work lives in one codebase.

More Surfaces, Same Deal: Cars, Sensors, Commerce, Video And Builds

Shai Almog — Fri, 10 Jul 2026 15:27:50 +0000

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.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

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.

Commerce validates purchases and normalizes entitlements, but it does not replace IAP and it does not take a cut. If quota runs out, validation degrades; the Apple or Google purchase still goes through. Everyone gets the Secrets API because volume stays low, and keeping keys out of source code should not be a luxury feature. Versioned builds are back, including limited access lower down the account ladder, and master builds give the community a way to verify fixes without waiting for nightly artifacts.

That is the continuation of last week's deal: charge for services that cost money to run, but keep them optional, predictable, and as broadly useful as we can make them.

The rest of the release pushes the open source core outward: car projection, motion sensors, richer pointer input, foldable posture, frame-accurate video, sample-accurate PCM mixing, and timed subtitles. A phone screen is still the center of most apps, but it is no longer the whole app. A serious product may also need a CarPlay list, an Android Auto grid, a stylus drawing surface, trackpad zoom, motion gestures, a pinned production build, and a generated video clip for sharing or support.

Here is what shipped.

CarPlay and Android Auto

PR #5281 adds a portable com.codename1.car API for Apple CarPlay and Google Android Auto. The important caveat is that car platforms are template-based. They do not allow an app to draw an arbitrary Codename One Form on the dashboard. You describe a driver-safe list, grid, message, pane, navigation, or now-playing template, and Codename One maps that to CPTemplate on CarPlay and androidx.car.app templates on Android Auto.

The API is zero cost when unused. Referencing com.codename1.car is what tells the build to inject CarPlay scenes, entitlements, Android Auto services, and the AndroidX dependency. Apps that never touch the package do not carry that code. Tomorrow's post walks through the template model, the simulator head unit, and the approvals you still need from Apple and Google.

Motion, Input, And Real Hardware

PR #5310 adds com.codename1.sensors, a cross-platform motion API with accelerometer, gyroscope, magnetometer, derived gravity, linear acceleration, orientation, and common gestures such as shake, flip, tilt, pick up, and free fall. This replaces the old external sensors-codenameone cn1lib with a core API and a core gesture engine.

PR #5309 fills in the other side of modern hardware: rich pointer events, mouse buttons, wheel and trackpad scrolling, stylus pressure and tilt, foldable posture, desktop windowing, and external display awareness.

Together they make Codename One less phone-only. A canvas can tell the difference between a finger, a mouse, and a stylus. A foldable can split layout around a hinge. A trackpad pinch can zoom the same component as a mobile pinch. Sunday's post covers the full hardware story.

Commerce And Secrets

PR #5300 adds the Commerce SDK and the Secrets API.

Commerce is optional infrastructure around IAP. It answers the backend question apps usually end up writing themselves: "does this user have this entitlement right now?" It can validate receipts, normalize subscription state across Apple and Google, send lifecycle webhooks to your backend, and show revenue metrics. It does not replace Purchase, it delegates to it.

CommerceManager cm = CommerceManager.getInstance();
cm.setAppUserId(accountId);
cm.subscribe("pro_monthly");

new Thread(() -> {
    cm.refresh();
    if (cm.isEntitled("pro")) {
        unlockProFeatures();
    }
}).start();

The Secrets API has deliberately lower volume and is enabled for everyone. It fetches app-readable secrets from the cloud vault at runtime and caches them in SecureStorage, so API keys do not need to live in code or in the binary. Server-only credentials, such as App Store or Google Play keys used by commerce validation, stay server-side and are not served to the app.

Monday's post is mostly a failure-mode pass over Commerce: what it does, what it refuses to do, what happens when quota is exhausted, and why optional validation is not an IAP tax.

Versioned Builds Are Back

Versioned builds are back, and the model is better suited to Maven than the old Ant-era point release scheme. You can pin a cloud build to a released Codename One version, or build against master when you need to verify an unreleased fix.

build.cn1Version=master

Community developers recently asked for nightly or daily builds. Building against master solves the same verification problem without waiting for an artificial daily package. You are asking the build server to use the current development head.

Subscription tiers limit versioned build access because old versions create support churn, not because fetching a few artifacts drives the business model. The further back a build goes, the harder it is to diagnose a regression against the current code. The new model still opens versioned builds much further down the account ladder than before, including limited access for basic/free usage, while giving paying teams the longer support windows they actually need. Tuesday's post covers the tradeoff.

Video, Audio, And Subtitles

PR #5315 adds VideoIO: cross-platform video encode and frame-accurate decode using native codecs. It can encode app-rendered frames plus audio into MP4/WebM/MOV/MKV style containers, enumerate codecs, decode exact frames, resample variable-frame-rate clips, and expose the audio track as PCM.

PR #5317 adds a sample-accurate AudioMixer for combining PCM tracks on one clock. PR #5319 adds timed Whisper transcription, so generated videos can get SRT or VTT captions instead of plain text transcripts.

Wednesday's post shows how these pieces fit: render frames, mix audio, encode a video, decode frames back out, and attach timed captions.

Smaller But Important

There are four smaller changes worth calling out:

JavaSE upstream JCEF and bundled ffmpeg media. PR #5294 moves the simulator away from our home-built Chromium 84 CEF fork and onto upstream prebuilt JCEF. We used to build our own CEF fork mostly to keep H.264 media working. That build was long, fragile and kept us behind. The new approach uses upstream JCEF for the browser and bundled ffmpeg for the Codename One Media API.
Skin Designer now builds with our JavaScript port. PR #5303 moves Skin Designer to the local ParparVM JavaScript target. Initializr and Playground already moved; the console is now the last TeaVM internal tool. This migration did expose a regression, but the JavaScript port is still moving toward production.
MorphTransition grew up. PR #5314 adds opacity, rotation, scale, deterministic scrubbing, and arbitrary rendered elements. This matters for UI polish and also for frame export, because scrubbing lets the same transition be rendered into generated video.
Timed Whisper transcription. PR #5319 also deserves a second mention because timed segments turn transcription into subtitles. The cn1lib can render SRT and VTT payloads from segment timestamps.

Upcoming Posts

Saturday. . PR #5281.
Sunday. . PRs #5310 and #5309.
Monday. . PR #5300.
Tuesday. .
Wednesday. . PRs #5315, #5317, and #5319.
Thursday. . The final part of the Game Builder tutorial series.

Wrapping Up

The release is large because the app surface is larger now. It reaches cars, foldables, desktops, sensors, stylus devices, media pipelines, cloud validation, and older build timelines.

The business side needs the same discipline as the API side. Cloud validation should help, not hold purchases hostage. Build tiers should buy capacity and support windows, not a license to keep your own revenue. Optional should mean optional, especially when the project stays open source.

Game Builder Tutorial 2: Build a Blackjack Card Game (Duke Jack)

Shai Almog — Thu, 09 Jul 2026 15:53:12 +0000

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.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

If you haven't set up a project yet, the project setup in Tutorial 1 applies verbatim — only the mode changes (board mode isn't the default, so the -Dmode=board flag is required here):

mvn cn1:create-game-scene -DclassName=com.example.dukejack.DukeJack -Dmode=board
mvn cn1:gamebuilder

Why board mode for cards?

Board mode is the Game Builder's grid mode: you place elements on a flat board of cells instead of a free-scrolling world. That's a natural fit for a card table — the felt is a tile layer, and each card is an element you position by hand, carrying its own rank, suit and faceUp data. There's no physics and no camera to chase; the layout is the game state, and your rules read it. (Board mode can also tilt the grid into an isometric view through IsoProjection for tabletop games — for cards we keep it flat and top-down.)

Step 1 — A card-table scene

Pick New scene → Board. You get a Board (tile) layer for the table surface and a Pieces (entity) layer for the cards. Keeping the felt and the cards on separate layers matters: the felt is static grid data, while the cards are objects your rules deal, flip, and clear. A small grid (here 8×5) is all a card table needs.

Step 2 — Lay the felt

Select the Board layer, pick the green tile from the palette, and paint the whole grid. That green surface is your table; everything else sits on top of it.

Step 3 — Deal the hands

Switch to the Pieces layer and place Card actors: a row for the dealer along the top and a row for Duke along the bottom. Each card carries three properties in the Inspector — rank (A, 2…10, J, Q, K), suit (Spades / Hearts / Diamonds / Clubs) and faceUp. Turn the dealer's second card face-down — that's the hole card the player can't see yet.

You can place cards by hand for a fixed layout, but a real game deals them from a shuffled deck at runtime — your companion creates the card elements from the engine below. The editor just lets you design the table, the card art and the seating; the deal is data your code produces.

Step 4 — Hit or stand

Duke's hand here is on 15 (and his Jack already wears the Duke mascot) — too low to stand on. He hits, and a third card brings him to 19, a total worth standing on. The companion spawns the new card element and lays it next to the others; the same faceUp/rank/suit data drives how it draws. The dealer's hole card stays face-down — it's still Duke's turn.

Where the card art comes from

Let's be exact about this, because "the faces are generated" explains nothing. There is no card generator in the framework. Your companion class draws each card itself with the ordinary Graphics API — the same one you'd use to custom-paint any Codename One component. When a card needs to be shown, your code is handed a Graphics and a rectangle and decides what goes in it.

A card element holds just two fields, rank and suit. One short method in your game turns that into a card — this is the actual routine the preview above uses:

void drawCard(Graphics g, int x, int y, int w, int h, String rank, String suit, boolean faceUp) {
    if (!faceUp) {                                  // the back: a blue card with the Duke mascot
        g.setColor(0x1B3A6B);
        g.fillRoundRect(x, y, w, h, 8, 8);
        g.drawImage(duke, x + (w - dw) / 2, y + (h - dh) / 2, dw, dh);
        return;
    }
    g.setColor(0xFFFFFF);                           // the face: a white card...
    g.fillRoundRect(x, y, w, h, 8, 8);
    g.setColor(isRed(suit) ? 0xC0392B : 0x1A1A1A);
    g.drawString(rank, x + 4, y + 4);               // ...rank in the corner...
    if (isFaceCard(rank)) {
        g.drawImage(duke, x + (w - dw) / 2, y + h / 4, dw, dh);   // Duke on the J, Q and K
    } else {
        drawSuitPip(g, x + w / 2, y + h / 2, suit);  // ...or a suit symbol in the middle
    }
}

duke here is the Duke mascot — the classic waving Duke (the BSD-licensed Java mascot), bundled with the game as an editable image. He rides the card back and every picture card (Jack, Queen, King), which is what actually makes it Duke Jack. The number cards are a rank label plus a drawn suit shape, so two pieces of art — the Duke image and the four suit symbols — cover the entire 52-card deck; everything else is text the code positions.

So, to answer "is it an image or is it drawn?" — both, and your code decides the mix:

Drawn from data (the default). Cheapest by far: one method, two images, 52 cards, and you restyle the whole deck by editing that method. To change the back, swap the Duke image or draw something else in the !faceUp branch.
Fully painted cards. Prefer a hand-illustrated King of Hearts? Import 52 images named by rank and suit and g.drawImage the matching one — it's the same method with a different branch.

Either way it's plain drawing code living in your companion class, not a black box you have to accept as-is.

And that's the quietly powerful part of building games this way. drawCard isn't using some games-only drawing layer — it's the very same Graphics API Codename One has painted every button, label and chart with for fourteen years. A GameView is an ordinary Codename One Component, so the entire mature graphics stack works inside your game: Image.createImage(w, h, argb) mutable-image buffers you draw a sprite into once and reuse, anti-aliased shapes, system fonts, affine transforms, even the chart and SVG libraries. The new gaming API didn't replace any of that — it plugged into it. So a "new" thing (a card game, a 3D dungeon) is really fourteen years of battle-tested API and tooling pointed at a game scene; the card faces here are just the smallest, clearest example of it.

The rules: a blackjack engine

The cards are just data; the game is the rules that read them. Here is a complete, self-contained blackjack engine — no Codename One dependency, so you can drop it straight into your companion (or unit-test it on its own). The only subtlety in blackjack is the Ace, which is worth 11 unless that would bust the hand, in which case it drops to 1:

public int handValue(List<Card> hand) {
    int total = 0, aces = 0;
    for (Card c : hand) {
        total += c.value();           // face cards 10, Ace 11 (for now)
        if (c.isAce()) aces++;
    }
    while (total > 21 && aces > 0) {  // soften Aces until we stop busting
        total -= 10;
        aces--;
    }
    return total;
}

public void hit() {                   // player draws
    player.add(draw());
    if (handValue(player) >= 21) stand();   // 21 stands, a bust ends the round
}

public void stand() {                 // player done — dealer plays, then settle
    if (handValue(player) <= 21) {
        while (handValue(dealer) < 17) dealer.add(draw());   // dealer hits below 17
    }
    settle();
}

private void settle() {
    int p = handValue(player), d = handValue(dealer);
    if (p > 21)                                   outcome = DEALER_WIN;   // player bust
    else if (isBlackjack(player) && !isBlackjack(dealer)) outcome = PLAYER_BLACKJACK;
    else if (d > 21 || p > d)                     outcome = PLAYER_WIN;   // dealer bust / higher
    else if (p < d)                               outcome = DEALER_WIN;
    else                                          outcome = PUSH;         // equal totals
}

The deck is a shuffled list of 52 Cards (rank 1–13, suit 0–3); draw() pops the next one. A two-card 21 is a natural that wins immediately and pays before the dealer draws. That's the whole game — everything else is presentation.

Wiring it into the companion

The companion is the same shape as Tutorial 1 — a GameSceneView with a generated loadLevel() and your onUpdate. You deal in onSetup, then read taps (or on-screen Hit / Stand buttons) and turn them into engine calls, re-laying the card elements after each move:

private final Blackjack game = new Blackjack(new Random());

@Override
protected void onUpdate(double deltaSeconds) {
    GameInput in = getInput();
    if (game.phase() == Blackjack.Phase.PLAYER_TURN && in.wasPointerPressed()) {
        // tap the top half of the screen to hit, the bottom half to stand
        if (in.getPointerY() < getHeight() / 2) game.hit();
        else                                    game.stand();
        layoutCards();                          // re-place the card sprites from the hands
        if (game.phase() == Blackjack.Phase.DONE) {
            Dialog.show("Duke Jack", game.resultText(), "Deal again", null);
        }
    }
}

layoutCards() is the bridge from rules to pixels: clear the old card sprites and, for each card in game.dealerHand() and game.playerHand(), place a card element with that rank/suit (and the dealer's hole card face-down until game.phase() leaves PLAYER_TURN). Because cards are just elements, dealing, hitting and clearing the table are the same add/remove operations you used for coins in Tutorial 1.

Play it

Press Live. The table comes up, Duke stands on his 19, and the dealer turns over the hole card and draws up to 18 — Duke wins the hand:

Dealing a card is just creating its element and sliding it onto the felt:

What got saved, and how it renders

Save writes src/main/resources/games/DukeJack.game (loaded at runtime as /DukeJack.game — Codename One's resource namespace is flat). The felt and any cards you placed by hand live there as data; the dealt cards are created by your companion at runtime:

{
  "mode": "board", "cols": 8, "rows": 5, "tileSize": 64,
  "layers": [
    { "name": "Board",  "kind": "tile",   "tiles": { "0,0": "start", "1,0": "start" } },
    { "name": "Pieces", "kind": "entity" }
  ],
  "elements": [
    { "id": "d1", "assetId": "card", "layer": "Pieces", "x": 217, "y": 96,  "props": { "rank": "6", "suit": "Hearts", "faceUp": true } },
    { "id": "d2", "assetId": "card", "layer": "Pieces", "x": 295, "y": 96,  "props": { "rank": "2", "suit": "Spades", "faceUp": false } }
  ]
}

A turn-based card game leans even harder on Codename One's UI than an action game does — and that's exactly where Codename One shines. A running-total label is a Label in the toolbar; the Hit/Stand controls are two Buttons; the result is a Dialog.show(...) with a "Deal again" option. As Tutorial 1's menu section shows, all of it is the standard UI toolkit wrapped around your GameSceneView — no separate game-UI layer to learn.

Variations and next steps

The card pattern generalizes to most table games:

Betting and a bankroll — track chips, pay 3:2 on a natural, and let the player raise before the deal.
Split and double-down — both are just more engine states over the same hands and card elements.
Other games — the Card element plus a rules class gives you solitaire, poker or war; only the rules change, the table and the deal don't.
Multiplayer — deal extra hands as more rows of card elements and loop the turn over them.

Next: Tutorial 3 — a first-person 3D dungeon, where the same data drives a 3D GameView with walls, terrain, lighting, and Duke fighting tea cups with coffee beans.

Device Integrity And App Review: RASP, Attestation, And Asking For Ratings Right

Shai Almog — Wed, 08 Jul 2026 15:12:56 +0000

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.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

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.

One handles security. The other handles asking users for a rating without annoying them. They are unrelated features that happened to land in the same week, so I am covering them together.

Device integrity

com.codename1.security.DeviceIntegrity is a portable runtime self-protection (RASP) and attestation API. It exists for the apps that actually need it: banking, payments, anything where you have to detect a hostile runtime and react to it. We already serve several customers in banking, and Codename One is hardened to meet the requirements they bring; this API is part of that work. If your app is a recipe browser, you can skip this section.

There are four capabilities. Each one has a zero-code build hint that turns it on, and a runtime API you call when you want to make decisions in Java.

Need	Build hint (zero-code)	Runtime API
Play Integrity launch gate	`android.playIntegrity` (+ `.verifyUrl`)	`requestIntegrityToken(nonce)`
iOS App Attest	`ios.appAttest` (+ `.environment`)	`requestIntegrityToken(nonce)`
RASP root/jailbreak/Frida	`android.rootCheck`, `android.fridaDetection`, `ios.detectJailbreak`	`isDeviceCompromised()`, `getCompromiseReasons()`
Accessibility-abuse guard	`android.accessibilityGuard` (+ `.allow`, + `.mode`)	`getEnabledAccessibilityServices()`, `hasUntrustedAccessibilityService(...)`, `setSecureScreen(bool)`

The design mirrors the existing isJailbrokenDevice() chain. The API surfaces through Display, defaults to "unsupported" in CodenameOneImplementation, and gets overridden in the Android and iOS ports. On Android, Play Integrity and RootBeer are invoked via reflection so the port jar stays dependency-free; the SDK is only on the classpath when the build hint bundles it. On iOS, App Attest goes through DCAppAttestService, gated behind a CN1_USE_APP_ATTEST macro with a stub #else so a build without attestation neither imports nor links DeviceCheck.framework. The async result comes back through static callbacks, the same shape as IOSBiometrics.

Requesting a token looks like this. The nonce comes from your server, and the token goes straight back to your server.

String nonce = myBackend.fetchIntegrityNonce();
DeviceIntegrity.requestIntegrityToken(nonce).ready(token -> {
    // token is opaque to the client; only the server can read it
    myBackend.verifyIntegrity(token);
});

A cheaper signal, no round trip:

if (DeviceIntegrity.isDeviceCompromised()) {
    for (String reason : DeviceIntegrity.getCompromiseReasons()) {
        Log.p("RASP signal: " + reason);
    }
}

The most important sentence in this section: the client is not the security boundary. An attestation token is opaque. The API hands the signed token to your app, but the block-or-allow decision has to happen on your backend, because the verification keys live there and the device does not get a vote. If you treat isDeviceCompromised() returning false as proof the device is clean, you have built nothing. A determined attacker who controls the device can tamper with what your app sees. RASP signals are defense-in-depth that raise the cost of an attack. They are not a guarantee!

The accessibility-abuse guard deserves a note because it is the newest of the four. Overlay and accessibility-service malware is a real vector for reading and driving banking apps. getEnabledAccessibilityServices() tells you what is active, hasUntrustedAccessibilityService(...) evaluates that list against an allow-list you configure with android.accessibilityGuard.allow, and setSecureScreen(true) blocks screen capture on sensitive forms. The allow-list evaluation is exactly what DeviceIntegrityTest exercises across its six tests.

There is also a new security chapter section in the developer guide that walks through wiring the token verification on the server side.

App review

com.codename1.appreview solves a smaller problem: asking for a rating at the right moment, through the right channel. It uses the platform's native store-review prompt when one exists, falls back to a built-in Codename One widget where it does not, and leaves the decision of when to ask entirely up to you.

There are two ways to use it. The manual style asks whenever your code decides it makes sense:

AppReview.getInstance().requestReview();

The scheduled style lets you set thresholds and then forget about them. You call registerSession() on every launch, and the scheduler decides whether the moment is right:

AppReview review = AppReview.getInstance();
review.setMinimumLaunches(5);
review.setMinimumDaysInstalled(7);
review.setDaysBetweenPrompts(60);
review.registerSession();

State lives in Preferences. Once a user rates or opts out, they are never prompted again. That is the whole point of the defaults: they stop you from over-asking.

The fallback widget does something the native prompts cannot. It splits feedback by sentiment. A high rating (at or above highRatingThreshold) routes the user to the store. A low rating routes to a pluggable FeedbackListener, and an email helper ships in the box. So an unhappy user reaches you privately instead of leaving a one-star public review you can do nothing about. The widget itself is RatingDialog, package-private, stars plus a feedback field.

The built-in fallback shown on platforms without a native in-app review prompt. On iOS and Android the native sheet is used instead.

Here is the decision flow end to end:

The native plumbing mirrors share() and dial(). CodenameOneImplementation.isNativeInAppReviewSupported() and requestNativeInAppReview(SuccessCallback<Boolean>) are exposed through Display and CN. On iOS it calls SKStoreReviewController.requestReview (iOS 10.3 and up), guarded by a CN1_USE_APPREVIEW macro. On Android it drives the Play In-App Review flow via reflection, so the port compiles without the extra dependency present.

The dependency part is what I like most here, because you do not configure it. The Android and iOS builders already scan your compiled classes to auto-enable native deps, and this extends that scan. Merely referencing com.codename1.appreview (or the CN/Display review methods) auto-injects com.google.android.play:review on Android, and links StoreKit.framework plus flips CN1_USE_APPREVIEW on iOS. An app that never asks for a review carries no extra weight. There is no build hint to remember and no checkbox to forget. The scheduler logic that decides all this is covered by eight JUnit 5 tests, and there is a new App-Review chapter in the developer guide.

The tradeoff to keep in mind: nagging users for ratings backfires. A prompt at the wrong moment costs you a rating and some goodwill. The scheduler defaults and the never-re-prompt rule exist precisely so the easy path is the restrained one. If you fight them by manually firing requestReview() on every launch, you will earn those one-star reviews.

Wrapping up

Two features, same shape. A portable Java API in core, native behavior where the platform offers it, a sane fallback where it does not, and no native interface for you to write. DeviceIntegrity gives high-security apps the attestation and RASP signals they need, as long as you remember the verification belongs on your server. AppReview gets you ratings without turning into the app everyone mutes. Pull the latest build and try them.

Apple TV And Android TV: One Codebase, And CSS @media For The Living Room

Shai Almog — Tue, 07 Jul 2026 15:40:57 +0000

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.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

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.

All of it is driven by the build. You set a flag or two and the builders generate and build the TV targets for you. The screenshots later in this post are real Codename One UI running on the Apple TV simulator, pulled straight from the tvOS screenshot test suite.

Why TV is its own form factor

A phone and a TV are both screens, but the interaction model is not the same. You sit ten feet away from a TV, so text and focus rings that look fine on a handset become unreadable. There's no touchscreen, so every bit of navigation runs through a remote and a focus cursor. The aspect ratio is fixed and wide. The "ten-foot UI" is a real constraint, not a skin.

The goal is to keep this one codebase while still respecting those differences. Most of the adaptation is visual, so most of it belongs in your theme rather than in Java branches. A smaller set of behaviors -- the things CSS can't express -- get a runtime check.

The form-factor API and the @media styling story

The detection API mirrors the existing isWatch(). You get CN.isTV(), Display.isTV(), and CodenameOneImplementation.isTV(). On iOS that's backed by a new isRunningOnTV() native call wired to TARGET_OS_TV. On Android it checks the television/leanback feature with a UiModeManager fallback. Resource and theme platform overrides follow the same scheme as the rest of the framework: {tv, ios, appletv} on iOS and {tv, android, android-tv} on Android.

The part with the widest reach is the styling. Resources.loadTheme now selects device-tv and device-watch @media variants at runtime. So you adapt to the living room or the wrist inside your CSS instead of forking layout code in Java:

/* Base style for everything */
Title {
    font-size: 3mm;
    color: #ffffff;
    padding: 1mm;
}

/* Ten-foot UI: bigger type, heavier focus treatment */
@media device-tv {
    Title {
        font-size: 9mm;
        padding: 4mm;
    }
    Button.selected {
        border: 3px solid #ffcc00;
        padding: 5mm;
    }
}

/* The wrist: shrink everything down */
@media device-watch {
    Title {
        font-size: 2mm;
        padding: 0.5mm;
    }
}

That same change finally completed @media for the watch port, which had the override slots but never had the query wired in. Both form factors now read from the same path. It's covered by CSSDeviceFormFactorMediaQueryTest, which runs against the real CSS compiler rather than a mock, and it's documented in css.asciidoc.

For the cases CSS can't reach -- behavior, not appearance -- you branch in Java:

Form f = new Form("Home", BoxLayout.y());

if (CN.isTV()) {
    // No touch: make the first item focused so the remote has a target
    Button first = new Button("Watch Now");
    f.add(first);
    f.addShowListener(e -> first.requestFocus());
} else {
    f.add(new Button("Watch Now"));
}

f.show();

Keep these branches small. Anything that's purely a size or color difference should live in the @media block above, not here.

Android TV: one APK, one build hint

Android TV is the low-code switch. You don't build a separate artifact. The same APK runs on phones, tablets, and the TV. You turn it on with a build hint:

# Build hints
android.tv=true
android.tv.banner=tv_banner.png

When android.tv is set, AndroidGradleBuilder adds the LEANBACK_LAUNCHER intent category so the app shows up on the TV home screen, declares the android.software.leanback uses-feature, marks the touchscreen optional so non-touch devices still qualify, and generates a 320×180 tv_banner (overridable via android.tv.banner). One build, three device classes.

Apple TV: a separate Metal target

Apple TV can't ride the same binary. tvOS needs its own Xcode target, the same way Mac Catalyst does. The new TvNativeBuilder adds an appletvos target with TARGETED_DEVICE_FAMILY=3, renders through Metal, and excludes the OpenGL-only .m files (tvOS has Metal and most of the iOS APIs, but no OpenGL ES). It reuses the shared UIApplicationMain entry point and is modeled directly on MacNativeBuilder. It's wired into IPhoneBuilder, the build mojo via the codename1.tvMain build property, and the build-hint schema.

Here's how one source maps to the three outputs:

I built the tvOS target end-to-end against the Xcode 26 / tvOS 26 SDK, and the framework's screenshot suite runs the full component set on the Apple TV simulator. Here is a ChatView screen rendering at the Apple TV's native 4K, the same Codename One UI the framework draws on every other target:

Turning it on

There is no separate SDK to learn. On Android you set android.tv=true and the same APK gains a TV launcher; on iOS you point the build at the tvOS target with codename1.tvMain and TvNativeBuilder generates the appletvos target. Then you restyle for the ten-foot screen with an @media device-tv block and branch the few behaviors CSS can't reach on CN.isTV(). The same project, the same code, three more screens.

Wrapping up

The television is now a Codename One form factor, detected with CN.isTV(), themed with @media device-tv, and built with a flag. Set android.tv=true for Google TV and point codename1.tvMain at your tvOS target for Apple TV, and the screens you already wrote show up in the living room.

A Privacy-First Analytics API: One Facade, A Provider SPI, And A Consent Gate

Shai Almog — Mon, 06 Jul 2026 16:14:46 +0000

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.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

The problem with the old service

Codename One shipped a single AnalyticsService wired to Google Analytics v1. You called AnalyticsService.init with your tracking id, and that was the whole story. One vendor, one protocol, baked into the framework.

That design has aged badly for two reasons. Google Analytics v1 itself is gone, so the integration points at a dead endpoint. And the API has no consent story at all. It starts reporting the moment you initialize it, which is exactly the behavior GDPR and CCPA make untenable. You cannot retrofit "ask the user first" onto an API whose only mode is "send everything now."

So instead of patching the old service, the new code separates the three concerns that were tangled together: what you report, where it goes, and whether you are allowed to send it.

One facade, a provider SPI, a consent gate that runs first

Analytics is the facade your app calls. You register one or more AnalyticsProvider implementations against it, and it fans every screen, event, setUserProperty and crash call out to all of them. The important word is after: every reporting call passes through a consent check before any provider sees it.

The gate is opt-in by default. Until the user grants the matching category, the facade silently drops reporting calls and no provider is invoked. The consent choice and the pseudonymous client id both persist in Preferences, so they survive restarts. The client id is not derived from any hardware identifier, and resetClientId() issues a fresh one to honor an erasure request.

Here is the consent-first ordering in code. Note that the provider is registered, but nothing is reported until consent arrives:

// Register providers up front -- still silent at this point.
Analytics.addProvider(new MatomoAnalyticsProvider("https://stats.example.com", 7));

// Opt-in is the default: this call is dropped because no consent is recorded yet.
Analytics.screen("Home", null);

// The user accepts your privacy prompt. Grant the categories you asked for.
Analytics.setConsent(AnalyticsConsent.builder()
        .analytics(true)
        .crashReporting(true)
        .build());

// Now reporting flows to every registered provider.
Analytics.screen("Home", null);
Analytics.event(AnalyticsEvent.create("purchase")
        .category("commerce")
        .param("sku", "abc-123")
        .param("value", 9.99)
        .build());

Consent is granular, not a single on/off switch. A user can allow crash reporting while declining behavioral analytics, and the facade honors each category independently. AnalyticsConsent.all() unblocks everything in one line if your app already collected consent through its own prompt or a consent-management platform. If the user later asks to be forgotten:

Analytics.resetClientId();   // new pseudonymous id, providers re-initialized
Analytics.setConsent(AnalyticsConsent.none());

The five providers, and mixing them

Five providers ship in the com.codename1.analytics package:

CodenameOneAnalyticsProvider batches to the Codename One cloud; it is included with every paid subscription, and the tier sets your data-retention window.
GoogleAnalyticsProvider speaks the GA4 Measurement Protocol.
MatomoAnalyticsProvider targets a self-hosted, non-Google backend.
FirebaseAnalyticsProvider routes through the native Firebase SDK (Android via reflection, iOS via dynamic dispatch on FIRAnalytics); the builders inject the Firebase dependency only when you set the android.firebaseAnalytics / ios.firebaseAnalytics build hints.
LoggingAnalyticsProvider prints to the log for development.

Because the facade fans out to every registered provider, mixing them is just two addProvider calls:

Analytics.addProvider(new LoggingAnalyticsProvider());          // see it locally
Analytics.addProvider(new GoogleAnalyticsProvider("G-XXXX", "api-secret"));

Writing your own backend is small. Extend AbstractAnalyticsProvider, which gives every SPI method an empty body, and override only what you support:

public class CountingProvider extends AbstractAnalyticsProvider {
    private int events;

    @Override
    public String getName() {
        return "counting";
    }

    @Override
    public void trackEvent(AnalyticsEvent event) {
        events++;
        // event.getName(), event.getCategory(), event.getParameters() are all here.
    }

    @Override
    public boolean supports(AnalyticsCapability capability) {
        return capability == AnalyticsCapability.EVENTS;
    }
}

AnalyticsCapability lets a caller ask a provider what it actually honors (SCREEN_VIEWS, EVENTS, CRASH_REPORTING, FUNNELS, RAW_EXPORT, among others) instead of guessing.

The first-party backend: events, goals, and a console

CodenameOneAnalyticsProvider is the one provider that needs no third-party account. It batches events to the Build Cloud, where they show up in an analytics console next to your builds. An app appears on its own once it sends data, so there is no dashboard to provision first.

The console is more than a raw event log. The Overview gives you headline numbers, active users, form views and events, over a 7-, 30- or 90-day window, and the left nav opens Trends, Forms, Events, Segments, User flow, Goals, and Reports. Common events are understood out of the box: screen and form views are tracked for you, and a purchase event carrying a value parameter feeds revenue and funnel reporting without a custom dashboard. Goals let you mark the events that matter and track conversion against them, while the segment and user-flow views answer more involved questions than a flat counter can. All of it is in the console today.

An app only shows up after it sends data, which only happens after the on-device consent gate opens:

The first-party provider is included with every paid Codename One subscription, down to the basic tier. What your plan changes is how long your data is retained, not whether you get analytics at all.

Migrating from the old service

The old AnalyticsService still works. It is deprecated, and it now delegates to the new API rather than carrying its own Google Analytics code, so existing apps keep running without a change. The UIBuilder analytics hook is unchanged too.

One detail you need to know: AnalyticsService.init() flips the facade to opt-out mode. The legacy API always reported immediately, and silently switching it to opt-in would have stopped data flowing for every app that relied on it. So legacy callers keep their old always-on behavior, while new code written against Analytics gets opt-in by default. Do not assume the new default applies to a project still calling the deprecated service.

The business-model thread

This is the shape every paid Codename One service takes, and Friday's post is the longer argument for why. The analytics API is an open SPI in a framework that stays open, licensed under GPL with the Classpath Exception: point it at Matomo, at GA4, at Firebase, or at a provider you wrote in twenty lines, and the framework does not care. CodenameOneAnalyticsProvider is one optional implementation of that contract, batched to our cloud and included with every paid subscription down to the basic tier, and choosing it is what helps fund the next port and the next API. It is a better default for people who want consent handling done for them, not a toll gate on the open framework. If you would rather self-host Matomo, you lose nothing.

A tradeoff worth saying out loud

A consent gate that is off by default means you will measure less than an always-on tracker does. Some users will decline, and their sessions will not show up in your reports. That is the deliberate cost of the privacy posture, and if you need every event you should expect a gap versus the old behavior. The mechanisms here are concrete and limited: opt-in by default, a pseudonymous resettable client id, no hardware identifiers, and an on-device gate that runs before any provider. That is what the API gives you, and it is all it claims to give you.

Wrapping up

The new analytics API is one facade, a provider SPI, and a consent gate that runs first. It ships with five providers, keeps the deprecated service working through delegation, and is covered by 25 unit tests across consent gating, the providers, client id handling and the legacy facade. Pick the backend that fits your privacy stance, register it, and ask for consent before you report.

Rich Text And Code Editing: RichTextArea And A Syntax-Highlighting CodeEditor

Shai Almog — Sun, 05 Jul 2026 14:34:58 +0000

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.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

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.

One abstraction, two backends

Both editors extend AbstractEditorComponent. That base class does not draw anything itself. It speaks a small semantic channel of commands ("apply bold", "set language to java"), queries ("give me the current HTML") and events ("the text changed") to whatever backend is attached. The component never assumes how the editor is rendered, only what it can ask for and what it gets told back.

There are two backends behind that channel, and they are interchangeable.

The first is a cross-platform engine built on BrowserComponent. The editor's HTML and JavaScript ship inside the core jar, so there is nothing to download at runtime. It renders through whatever web view the platform already provides: WKWebView on iOS, WebView on Android, CEF on the desktop simulator, and an iframe on the web target. Going through a real web view means the editor gets correct virtual-keyboard behavior and physical-keyboard handling for free, instead of us re-implementing text input per platform.

The second backend is optional and supplied by a port. A platform implementation can return a native editor peer through CodenameOneImplementation#createNativeEditorPeer, then handle editorPeerCommand and editorPeerQuery. The same semantic channel drives it, so the component code does not change. CodeEditor#setEngineURL(...) is the application-level version of the same idea: point the editor at a richer engine, such as a full Monaco or CodeMirror build you host yourself.

CodeEditor

CodeEditor highlights eight languages: java, kotlin, js, python, css, xml, json, and c. It draws a line-number gutter, ships light and dark themes, and auto-closes brackets and quotes as you type.

CodeEditor editor = new CodeEditor();
editor.setLanguage("java");
editor.setTheme("dark");
editor.setText("public class Main {\n\n}");

Form f = new Form("Editor", new BorderLayout());
f.add(BorderLayout.CENTER, editor);
f.show();

Code completion is asynchronous, which matters because a real completion source may have to look something up. You register a CodeCompletionProvider, and it hands results back through a callback rather than returning them inline, so the editor never blocks while you compute suggestions:

editor.setCompletionProvider((ed, code, cursorPosition, results) -> {
    // Inspect code up to cursorPosition, build suggestions, then deliver.
    List<CodeCompletion> out = new ArrayList<>();
    out.add(new CodeCompletion("println", "println(String x)"));
    out.add(new CodeCompletion("print", "print(String x)"));
    // Hand them back when ready, on or off the EDT (onSucess is CN1's spelling).
    results.onSucess(out);
});

Diagnostics work the same way. You push CodeDiagnostic entries at the editor and it renders them as squiggly underlines, gutter markers, and tooltips on hover:

editor.setDiagnostics(Arrays.asList(
    new CodeDiagnostic(3, 5, 3, 12, "cannot find symbol: prinln")
        .setSeverity(CodeDiagnostic.ERROR)
));

Here is the editor with Java highlighting, the gutter, and the completion popup offering println and print:

The dark theme is a one-line switch, not a separate component:

RichTextArea

RichTextArea is the WYSIWYG side. It edits formatted text and gives you HTML in and out. You get bold, italic and underline, ordered and unordered lists, links, foreground and highlight colors, and headings. It fires change events as the user edits, and it shows a placeholder when empty.

The content model is HTML, so you load and save with two calls:

RichTextArea rich = new RichTextArea();
rich.setPlaceholder("Trip notes...");
rich.setHtml("<p>Itinerary: <b>Day 1</b> arrive, see "
    + "<a href=\"https://example.com\">the museum</a></p>");

rich.addChangeListener(e -> rich.getHtml(html -> {
    // getHtml is async; the markup arrives in the callback.
    Storage.getInstance().writeObject("note", html);
}));

The toolbar drives the same command channel described earlier; pressing the bold button sends an "apply bold" command to the backend rather than editing a string directly:

You only pay for it if you use it

CodeEditor can be backed by a heavier engine, and CodeMirror assets are not free weight to carry around. So the Android and iOS builders scan your app for use of com.codename1.ui.CodeEditor. The optional CodeMirror assets are bundled only when that API actually appears, gated by CN1_USE_CODEMIRROR. An app that never touches CodeEditor ships nothing extra.

The Playground already uses CodeEditor for its editor pane, so it is dogfooded rather than demo-ware. There are 33 deterministic unit tests across RichTextAreaTest and CodeEditorTest, backed by an editor SPI in the test implementation so they run without a real web view, plus new developer-guide sections with screenshots.

The tradeoff

The default engine is web-view-backed. That is what makes it portable, and it is also the limit: it needs a web view to exist on the platform. iOS, Android, the desktop and the web all have one, so all four are covered. Apple Watch and tvOS do not have a usable web view, so the editors are not enabled there. If a port supplies a native editor peer, that constraint goes away for that port, which is exactly why the second backend exists.

Wrapping up

Two editors, one abstraction. The shared AbstractEditorComponent is the reason a WYSIWYG HTML editor and a syntax-highlighting code editor could land in the same PR: the hard part was the command/query/event channel and the cross-platform engine behind it, and both components reuse it. The web-view engine gives you something that works everywhere a web view exists, and the native peer hook gives a port room to do better when it can. Try CodeEditor and RichTextArea in the next build and tell us where they fall short.

Maps You Control: A Pure-Vector MapView And Pluggable Native Providers

Shai Almog — Sat, 04 Jul 2026 14:24:26 +0000

Yesterday's funding post covered the model behind this week's releases. Here is the first one. PR #5264 brings mapping back into core with two components: a MapView that draws an entire map through Graphics with no native peer, and a NativeMap that embeds the platform's own map. Both sit behind one MapSurface API, so you can switch between them by changing a class name.

What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com.

What was wrong with the old maps

For years the answer to "how do I show a map" was one of two things. The deprecated tile-based MapComponent fetched raster tiles and painted them, which worked but was frozen in time. Or you added the external codenameone-google-maps cn1lib, which embedded the actual Google Maps SDK as a native peer.

The cn1lib approach worked, but it locked you to one vendor. It embedded the Google Maps SDK specifically, so a device without Google Play, such as a Huawei phone, was a porting problem rather than a build setting. Being a native peer, the map was also a separate platform surface that only existed where the provider shipped, so it looked different on every platform, because it was a different map on every platform, and it did not exist at all in the simulator or on the web. None of that makes native maps wrong; it makes them one tool among two, which is exactly what this PR gives you.

The MapView vector engine

MapView is the part I find most interesting. It is a pure-vector map. Nothing about it is a native peer. Every road, water body, and park boundary is drawn through Graphics using GeneralPath and Stroke, the same drawing pipeline that paints every other CN1 component.

The data comes from Mapbox Vector Tiles (MVT). I wrote a new MVT engine on top of the framework's existing ProtoReader and GZIPInputStream, so decoding a tile is decompressing gzip, reading protobuf, and turning the geometry commands into paths. There is no third-party parser involved. Because the output is just drawing calls, the map composes cleanly with the rest of your UI. You can put a Button over it, scroll it inside a Container, or animate it, and there are no snapshot tricks, because there is no separate platform surface behind the map at all.

Tile sources are pluggable. The default is raster OSM tiles, but you can switch to the MVT vector source, a bundled source you ship inside the app, or the deterministic DemoTileSource used by the screenshot tests. Styling is a MapLibre-subset JSON, and two styles ship in the box: light and dark.

Form hi = new Form("Map", new BorderLayout());

// A vector tile source (vector=true, zoom 0..14) and the built-in dark style.
TileSource tiles = new HttpTileSource(
        "https://example.com/tiles/{z}/{x}/{y}.pbf", true, 0, 14);
MapView map = new MapView(tiles, MapStyle.dark());

map.setCameraPosition(new CameraPosition(new LatLng(37.7749, -122.4194), 13));

map.addMarker(new MarkerOptions()
        .position(new LatLng(37.7749, -122.4194))
        .title("San Francisco"));

hi.add(BorderLayout.CENTER, map);
hi.show();

The default constructor uses a raster OSM source and the light style; pass a TileSource and MapStyle when you want something else, or switch later with setTileSource(...) and setStyle(...).

San Francisco rendered entirely through Graphics in the light style. No native peer is involved; these are paths and strokes.

The same tiles with MapStyle.dark() applied. The style is a MapLibre-subset JSON, so switching themes is data, not new code.

Marker, Polyline, Polygon, and Circle are drawn in the same pass as the map, so a marker is just another shape in the scene rather than an overlay glued on top.

Because the whole thing is Graphics, it renders identically everywhere: simulator, device, and the web target included. You host your own tiles and metadata offline if you want, and you control every pixel that gets drawn.

NativeMap and the build-hint provider model

Sometimes you want the platform's map, with its road data, its traffic, and its look. That is what NativeMap is for. It embeds the actual platform map, Apple MapKit or Google Maps, behind the same MapSurface API. When no provider is wired in, or none is available at runtime, NativeMap falls back to an embedded MapView so the code still works.

The interesting design decision is that the public API never names a provider. There is no GoogleMapsImpl to import, no NativeInterface, and no CodenameOneImplementation hook. You select a provider with the maps.provider build hint, set to apple, google, or another supported value. At build time a MapsProviderInjector in the builders drops that provider's native implementation into your app's com.codename1.maps package. Core and the ports carry no map SDK at all, so a provider you do not use costs zero project size.

This moves a hard problem from a fork to a build hint. Supporting a device without Google Play stops being "maintain a separate branch" and becomes "set maps.provider to something else." The provider SPI lives in com.codename1.maps.spi.MapProvider, and registrations go through MapProviderRegistry, both covered by the unit tests.

With maps.provider=apple, NativeMap renders a live MapKit map with a marker. The screenshot below is from the native Mac desktop build, which supports the Apple provider:

NativeMap with maps.provider=apple on the native Mac desktop build, showing a real MapKit map and a marker. This is the platform's map embedded, not the vector engine.

The tradeoff

The vector engine is new, and the style format is a subset of a full MapLibre style, not the whole specification. If you bring a complex upstream style it may reference layer or expression features the subset does not implement yet. Labeling and coverage also depend on the tile data you point it at. The default OSM source is fine for general use, but if your tiles lack a layer, the map will not draw what is not there. NativeMap sidesteps both concerns by deferring to the platform, at the cost of the native-peer behavior the vector path was built to avoid. Pick the one that matches what you are building.

For confidence there are 29 unit tests in core-unittests, all green, covering the value types, the model, the provider SPI registry, the MVT decoder across all its value types, the styles, color and zoom handling, cache internals, and the Web Mercator math. The hellocodenameone screenshot tests run against the deterministic DemoTileSource so the pixels are reproducible offline, and there is a new Maps.asciidoc chapter in the developer guide.

Wrapping up

Two components, one MapSurface API. Reach for MapView when you want a map that draws like the rest of your UI, renders the same on every target including the web, and lets you carry your own tiles. Reach for NativeMap when you want the platform's own map and are happy to accept a native peer to get it. The provider for that peer is a build hint, so the choice of Apple versus Google versus none never leaks into your source.