Everything else here hangs off one call. `SmartHome.getInstance()` never returns null [10]. On a port with no smart-home backend you get a fallback object that reports `NOT_SUPPORTED`, and on a supported port you get more specific states, so an empty accessory graph is not mistaken for a configured home with no devices [10]. A never-null singleton that answers `NOT_SUPPORTED` is duller than a null check and considerably harder to forget.
The availability read is deliberately awkward. Codename One tells you to read it from the completion path even when `refresh()` fails [11]. On iOS the initial value is `NOT_STARTED`, because connecting to HomeKit is what reveals the authorization and home state [12]. There is no synchronous way to ask whether you are allowed in. The published sample routes six availability values into five remediation calls: provider setup, authorization request, home settings, the ecosystem app, and an add-device-only UI [13][14].
The arithmetic explains why the layer exists. Matter brightness is a 0 to 254 level [4], and the API turns proportional values into percentages [8]. Divide 254 by 100 and you get roughly 2.54 Matter levels per percentage point [22], which means a percentage cannot round-trip back to the level you started from. That is why `TraitValue` keeps the platform ordinal alongside the canonical value wherever the conversion loses detail [8]. Air quality gets the same treatment, because HomeKit and Matter do not agree on how many levels there are [7]. Temperature getters go further and require the expected unit, so a Celsius reading cannot be picked up as Fahrenheit by accident [9].
Not every question has an answer, and the API reports that state rather than guessing. Matter has no single thermostat setpoint in automatic mode [6], and the post is explicit that the model reports cases where the platforms cannot give the same answer [23]. Writes inherit the same honesty. Turning off every light can succeed for three accessories and fail for one unreachable bulb, and the result carries each row instead of collapsing into one boolean [19].
The portability claim is still a claim about someone else's application. It transfers if your feature list is expressible as traits and services, and if you are content to drive UI from what the port models. It does not transfer if you need a platform-specific characteristic the trait vocabulary does not cover, because then you are back to two code paths plus an abstraction in the middle. The argument the post makes is narrower than "write once": application code should ask for brightness rather than carry both platform identifiers and two sets of value rules [24].
On Android, the practical shape of this release is commissioning. `COMMISSIONING_ONLY` is the normal result without Google Home developer setup, and Play services can still add a Matter accessory to the user's Google Home [15]. So you can onboard hardware today and read it later.
One asymmetry still comes through the abstraction. HomeKit can push trait changes while the application is in the foreground, other backends require polling, and `TraitSubscription.isPushDelivery()` tells you which model you were handed [21]. The UI needs a refresh path that works under both, and you write that path once whether or not anyone is pushing.
