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.
This lesson takes the more useful route: study the native APIs, decide what the portable layer actually needs, and then shape a Codename One-facing API around that. In the original material, the portable surface is influenced heavily by an Android camera library. That is a reasonable way to get traction, but the deeper lesson is that the portable API should be owned by your application or library, not by whichever native SDK you happened to read first.
The wrapper class is crucial here. The raw native interface should remain a thin bridge, while the public Java API becomes the place where you handle defaults, constants, event listener management, simulator behavior, and build-hint concerns. That separation gives you the freedom to improve the native implementation later without breaking the rest of the app.
This is also where you can see why native interfaces are not a good place to expose callback-heavy behavior directly. Some platform APIs are naturally event-driven, but the portable layer still needs to present those events in a way that fits Codename One. Listener registration, singleton behavior, and platform capability checks all belong in the wrapper, not scattered around the app.
One modern point worth stating explicitly: if there is already a maintained Codename One camera library that covers the use case you need, prefer that first. This lesson is still valuable because it teaches how to think about a difficult native integration, but hand-rolling a bridge should usually be reserved for unsupported features, experiments, or library work.