The Platform.current object exposes one (or potentially more) of a NativePlatform (based on dart:io), BrowserPlatform (based on JS window.navigator or anything else relevant), and WasmPlatform (currently not possible to end up with).
Each has its own API, and the current platform determines whether a value of these types is available or not. On unsupported platforms, the value is just null.
Provides a platform_testing.dart library which exposes FakeNativePlatform, FakeBrowserPlatform and
FakeWasmPlatform, which are customizable classes that can be used for testing.
It's possible to run code with such a fake value as the current platform (Platform.current is temporarily updated to a value which exposes the, fx, FakeNativePlatform as its Platform.nativePlatform).
Has a legacy_adapter.dart that existing uses of
the Platform package on native platforms can use.
It's currently not possible to have more than one
non-null platform-value, but it's not impossible that, fx, a Wasm runtime can report both that it's Wasm, and that it's running in a browser, providing information about that browser as well. Or running in a Wasm runtime on a native platform and exposing that native platform as well (if encapsulation allows).
(But currently it can't even detect running in a Wasm runtime at all, because it uses library detection, and there is no Wasm-only library. We should make some compilation environment variables available which tells which target we're compiling for, and even make them usable for configurable imports.)
(The "four libraries with the same part file" hack should be avoidable if we get configurable-URI
augmentations, or if we're willing to make some more internal classes public. The current design is trying very hard to be impossible to fool.)
The
Platform.currentobject exposes one (or potentially more) of aNativePlatform(based ondart:io),BrowserPlatform(based on JSwindow.navigatoror anything else relevant), andWasmPlatform(currently not possible to end up with).Each has its own API, and the current platform determines whether a value of these types is available or not. On unsupported platforms, the value is just
null.Provides a
platform_testing.dartlibrary which exposesFakeNativePlatform,FakeBrowserPlatformandFakeWasmPlatform, which are customizable classes that can be used for testing. It's possible to run code with such a fake value as the current platform (Platform.currentis temporarily updated to a value which exposes the, fx,FakeNativePlatformas itsPlatform.nativePlatform).Has a
legacy_adapter.dartthat existing uses of thePlatformpackage on native platforms can use.It's currently not possible to have more than one non-
nullplatform-value, but it's not impossible that, fx, a Wasm runtime can report both that it'sWasm, and that it's running in a browser, providing information about that browser as well. Or running in a Wasm runtime on a native platform and exposing that native platform as well (if encapsulation allows). (But currently it can't even detect running in a Wasm runtime at all, because it uses library detection, and there is no Wasm-only library. We should make some compilation environment variables available which tells which target we're compiling for, and even make them usable for configurable imports.)(The "four libraries with the same
partfile" hack should be avoidable if we get configurable-URI augmentations, or if we're willing to make some more internal classes public. The current design is trying very hard to be impossible to fool.)