Support varies by platform and by OS version, so it cannot be a compile-time constant or a table in the README. Today the plugin silently returns fewer spans, which is why "DateTime is not supported on Android" lives in prose.
Keep the surface to one getter:
Set<ItemSpanType> get supportedTypes;
And one hard rule:
Requesting a type the current platform cannot detect throws UnsupportedError naming the type. Not a silent drop, not a logged warning.
// on Windows
await SmartTextFlutter.classifyText(text, types: {ItemSpanType.address});
// throws UnsupportedError: ItemSpanType.address is not supported on this platform.
// Supported: url, email, phone, hashtag, mentionCallers that want graceful degradation intersect with supportedTypes first. Callers that pass nothing keep today's behaviour of detecting everything available.
This is what turns "as many platforms as possible" from a compromise into a feature: the package never pretends.
Found during the v0.4.0 codebase audit.
Support varies by platform and by OS version, so it cannot be a compile-time constant or a table in the README. Today the plugin silently returns fewer spans, which is why "DateTime is not supported on Android" lives in prose.
Keep the surface to one getter:
And one hard rule:
Requesting a type the current platform cannot detect throws
UnsupportedErrornaming the type. Not a silent drop, not a logged warning.Callers that want graceful degradation intersect with
supportedTypesfirst. Callers that pass nothing keep today's behaviour of detecting everything available.This is what turns "as many platforms as possible" from a compromise into a feature: the package never pretends.
Found during the v0.4.0 codebase audit.