Courses

Module 7: Style Form Customization is only useful if it survives. Once users start shaping the look of a generated app, those choices need to exist as real data, not just as temporary UI state. That is what this lesson is about. Style settings become first-class business data: something that can be stored locally, synchronized with the server, and reapplied later. That is the right abstraction for a builder product because appearance is part of the product definition, not just a visual side effect of the current screen. ...

Module 6: Native Interfaces - Billing Once the interface shape is settled and the native dependencies are in place, the remaining job is to implement the platform code without letting threading, lifecycle, and callback mechanics turn the integration into a black box. The most practical advice in the lesson is still the best advice today: if the integration is non-trivial, generate native sources and inspect the result in the platform IDE. That gives you real build feedback, better navigation, and a much easier debugging path than trying to reason about everything from the portable project alone. The include sources workflow is still the right tool for that job. ...

Module 7: Native Interfaces - Camera Camera integrations are a good example of why native interfaces need design, not just implementation. If you begin by copying every method from a platform SDK into your portable API, you usually end up with an awkward abstraction that is too platform-specific to be pleasant and too incomplete to be reliable. ...

Module 8: Push and In-App Purchase Push usually feels harder than it really is because the setup is split across several systems. You need Android-side configuration, iOS-side configuration, and project settings that tell Codename One how those pieces fit together. Once that groundwork is done, the rest of the push flow is much easier to understand. ...

Module 7: Native Interfaces - Camera Once the portable camera API exists, the Android side becomes a matter of mapping that API onto the native implementation without letting threading, lifecycle, and dependency details escape into the rest of the app. The lesson’s most practical recommendation is still correct: if you are new to native integration, generate native sources and work in Android Studio while developing the Android side. That gives you real tooling support, native compilation feedback, and a much faster path to understanding what the platform expects. ...

Module 8: Push and In-App Purchase Once the platform setup is done, the client side of push becomes a lifecycle problem. The app needs to register when it starts, store the push key when registration succeeds, and react sensibly when a message arrives. The first thing to get right is where the callback lives. In Codename One, push callbacks belong in the main application class, the one that owns init() and start(). That is not just convention. Push is tied to the application lifecycle, so the framework expects the callback implementation to live in the object that represents that lifecycle. ...

Module 7: Native Interfaces - Camera The iOS side of a camera integration tends to look more intimidating than the Android side because the API surface is different and the generated bridge code is less familiar to most Java developers. The right way to handle that is not to memorize every Objective-C detail. It is to understand the moving parts well enough to see where the bridge is actually doing work. ...

Module 8: Push and In-App Purchase On the server side, push is part of the result-delivery pipeline. The build finishes, the server decides what happened, and then it sends a short notification to the device so the app can react. That framing matters because this lesson is not really about building a generic push utility. It is about closing the loop in a product where the server builds an app on behalf of the user and needs a clean way to report the result back to the device. ...

Module 7: Native Interfaces - Camera Once the basic iOS camera bridge exists, the next challenge is not a new feature so much as learning how the native view and native memory model affect the implementation. This is where the integration stops being a thin method mapping and starts feeling like real platform work. ...

Module 8: Push and In-App Purchase Push is useful, but it should never be the only transport a feature depends on. Users can disable it, devices can fail to register, and platform delivery is not reliable enough to be the single mechanism that keeps an app functional. ...