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(label: "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.)

A component in the middle of a tree

Since 0.2.0-preview.18

public sealed class CopyButton : StatelessComponent

{

public override VisualNode Build(ComponentContext context) =>

context.GetService<ITextClipboard>() is { } clipboard

? IconButton(Icons.Copy, onPressed: () => clipboard.Write(_code))

: new Box(); // no clipboard here, so draw nothing rather than a dead button

}

Constructor injection stays the better answer where it fits: explicit, testable, readable in the signature. But it only reaches the PAGE. Everything below had to be handed the same thing by hand: a card with a Copy button needs an ITextClipboard, so the article above it carried one it never used, and the section above that carried it too. A component that gained a need forced an edit in every ancestor between it and the page.

context.GetService<T>() answers null when the target does not have the capability, which is the answer every capability's caller has to handle anyway.

Where it resolves FROM is the host's business: SSR uses the REQUEST's container (so a scoped registration works and a page's own registrations win), the browser uses what the boot registered, a Photon app uses the shell's. The component asks the same question everywhere.

On the WEB this arrived working only in 0.2.0-preview.21. The type argument was dropped in transpilation: the strategy that turns the call into a key recognised the older Core RenderContext and an IServiceProvider, and ComponentContext is neither, so the call fell through to the ordinary invocation path, which drops type arguments. Every page asked for a capability by no name at all and got null back, on the one target the feature exists to serve.

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.

PREVIOUSDesign System

NEXTStorage

ON THIS PAGE

Answers that do not hold still

Permissions

The web

A component in the middle of a tree

Rendering on the server