Capabilities

Device capabilities

What the machine can do — camera, location, photos, biometrics, the network — as services taken through a constructor, realized per host. A component asks for a capability and never learns which target answered.

public sealed class ScanShell(ICamera? camera, ILocation? location) : StatefulComponent
{
    private async void LocateAsync()
    {
        if (location is null) return;             // this host has none
        var here = await location.GetCurrentAsync();
    }
}

Nullable, always. A host that cannot do something registers nothing, so the service resolves to null and the app shows the thing it already knows how to show. That is the framework's answer everywhere: report the absence rather than pretend with a stub that fails later, at a worse moment.

Capability	What it answers	Since
IPhotoLibrary	GetPermissionAsync(), PickImageAsync() — one picture the user chose	0.2.0-preview.1
ICamera	Capture() for a still, StartPreviewAsync() for an ICameraSession (a live texture)	0.2.0-preview.1
ILocation	GetCurrentAsync(), and Subscribe(…) for the stream of changes	0.2.0-preview.1
IBiometrics	IsAvailable, AuthenticateAsync(reason) — Face ID / Touch ID / the platform's own	0.2.0-preview.1
IMotionSensor	Subscribe(…) for device motion readings	0.2.0-preview.1
INetworkStatus	Current, and Subscribe(…) — reachability and what carries it	0.2.0-preview.1
ITextClipboard	Read() / Write(text), for a page's own Copy button	0.2.0-preview.1
IThemeController	The light/dark switch — see ServerIntegration	0.2.0-preview.1
IAppStorage / ISecretStore	Durable preferences and secrets — see Storage	0.2.0-preview.10

Answers that do not hold still

ILocation, IMotionSensor and INetworkStatus are the ones whose answer CHANGES, so they hand back an IDisposable from Subscribe rather than a value. Dispose it when the component goes away, or the subscription outlives what it was updating.

INetworkStatus reports reachability as the platform sees it, not a promise a specific host will answer. An app showing a stale "online" is worse than one that says nothing.

Permissions

PermissionState has four answers, and the third is the one apps forget:

• NotDetermined — never asked. Asking shows the system prompt.
• Granted.
• Denied — refused, and asking again does nothing. Only the system's settings can change it, so a button that re-asks is a button that does nothing; send them to settings instead.
• The platform may also report a restriction the user cannot lift at all.

On native, the strings the OS shows at the prompt come from the assembly:

[assembly: PhotonCapability("camera", "Scan a barcode to add an item.")]

The build reads those into the platform's manifest (Info.plist, the Android manifest), so the reason a user reads is stated once, in the app, next to the code that needs it.

Crosses by NAME, never by ordinal. The manifest matches the capability's string. Inserting a value into the middle of an enum once turned Location into Motion in a shipped manifest — the build was green and the app asked for the wrong permission.

The web

The browser realizes what it honestly can — photos through a file input, camera and location and network through their web APIs — and registers the rest as unavailable rather than absent, so a page that takes one still receives an object and shows its fallback instead of failing to construct.

A page takes what it needs through its constructor on every target:

public sealed class ProfilePage(IPhotoLibrary photos) : StatefulComponent
{
    public override VisualNode Build(ComponentContext context) =>
        photos.IsAvailable ? Button(title: "Choose a picture", onPressed: Pick) : Text("No library here");
}

Natively ActivatorUtilities resolves it. In the browser the transpiled constructor resolves it itself, by the interface's NAME — a C# type does not exist at run time there, but IPhotoLibrary as a string does, and both sides agree on it. The rule is asked of the model, not guessed from a name: a constructor parameter whose type is an INTERFACE is a dependency, everything else is data the caller passes. A component takes what it draws — a label, a variant, a callback — and none of those is ever an interface. (IReadOnlyList<T> and IEnumerable<T> are data, explicitly.)

Rendering on the server

Since 0.2.0-preview.13

The same page has to be server-renderable, and the server has no camera. Every capability resolves there to an ABSENT realization: it reports itself unavailable and hands back nothing.

Without it the page could not be constructed at all — no constructor the container could satisfy, and the request ended in a 500. The one page that does something was the one page a crawler never saw, and the visitor waited for JavaScript just to be told the page exists.

Absent, deliberately, and not simulated. There is no camera in a datacenter and the visitor's localStorage is on the visitor's machine, so a server-side fake would be worse than the failure: the page would render one thing, the browser would hydrate another, and the mismatch would be blamed on the reconciler. The page takes the availability branch it already has to have, and the client boot's real capability replaces the fallback on the first client render.

INetworkStatus is the exception, and the exception is the point: reporting offline would bake the offline banner into the markup every crawler and every first paint sees, for visitors who just proved they are online by fetching the page. It answers online.

Registered with TryAdd, so an app with a genuine server-side answer — a storage backed by the user's session — registers its own and wins.