SettingsScreenRole class final

The role of the settings screen: the screen of the app where the user changes what the modules of the app let them change, such as the theme or the language.

A module with a setting uses the role and contributes a SettingsEntry, which names the widget of the setting in a file that the module generates; the template of a role that uses this role may contribute one too. The contributor knows nothing of the screen: its widget requires no arguments, so it needs nothing from the provider, which only shows it.

A provider is a module with a route that shows the screen, which it names with a SettingsScreenRoute; the role requires the router. The screen shows every entry of entriesIn once, in that order: the entries of the modules, in the order of the modules, and then those of the templates of roles. It shows them one below the other in a list that scrolls, on a Material. The screen sets the width of each entry, the same for every entry, between the same left and right edges, and puts no limit on its height, so an entry is as tall as it takes. The entries need not reach the edges of the list, which may inset them.

The provider creates the widget of each entry in a file other than that of the widget, through an import of that file with a prefix that no import of another file has, such as entry0 for the first. So widgets of the same name in the files of different contributors never clash with each other or with the names of the file of the provider. The contract harness checks those imports and creations (the rule settings_screen.entries_rendered), so the tests of a module that contributes an entry check it through entriesIn, not in the files of a provider. What only a running app shows is for a test of the role in running apps: each entry once, their order, the list that scrolls, the Material, the width and the height of each.

How the user gets to the screen is up to the provider and the rest of the app: a provider may make its route a destination of the main navigation, which an app with a layout shows.

Inheritance

Properties

cardinality → RoleCardinality
How many providers of the role an app can have.
no setteroverride
description → String
What the role does, as a short noun phrase such as Router.
no setteroverride
hashCode → int
The hash code for this object.
no setterinherited
id → String
A unique id of the role in lower snake_case, such as router.
no setteroverride
interface → RoleInterface
The files the role's template generates and the symbols every provider must generate.
no setterinherited
moduleRules → List<ModuleRule<SettingsData>>
Checks of the data of modules that provide, require or use the role, run during validation with checkModule.
no setteroverride
openToAllModules → bool
Whether every module may use the role's sockets and symbols without declaring the role.
no setterinherited
options → List<RoleOption>
Command line options of the role, such as --start of the router.
no setterinherited
presenceFlag → String
The name of the brick variable that is true when the role is present: has_<id>.
no setterinherited
requires → Set<Role<Object>>
Roles that must be present whenever this role is present.
no setteroverride
runtimeType → Type
A representation of the runtime type of the object.
no setterinherited
socketFamilies → List<SocketFamily<Object?, SocketKind>>
The socket families of the role, such as the annotations of every screen of the router.
no setterinherited
sockets → List<SocketRef<SocketKind>>
The sockets of the role.
no setterinherited
structuralRules → List<StructuralRule<SettingsData>>
Checks of the generated code, run by the contract test harness with checkStructure.
no setteroverride
template → RoleTemplate<SettingsData>
The code the role itself contributes, independent of its provider, or null if it has none.
no setteroverride
uses → Set<Role<Object>>
Roles that this role works with when they are present.
no setterinherited
visibleRoles → Set<Role<Object>>
The roles whose data and presence the hooks of this role may read: requires and uses.
no setterinherited

Methods

accepts(Object? value) → bool
Whether value can be data of this role, that is, a D.
inherited
checkModule(ModuleRuleRequest request) → List<SmfIssue>
Runs the moduleRules for the module in request and returns the problems found.
inherited
checkStructure(StructuralRuleRequest request) → List<SmfIssue>
Runs the structuralRules over the app in request and returns the problems found.
inherited
choiceContext(RoleChoiceRequest request) → RoleChoiceContext<SettingsData>
Builds the input of RoleTemplate.choose from the pipeline's request; see hookInput.
inherited
data(SettingsData value, {Set<Role<Object>> when = const {}, Set<ChoiceCondition> whenChosen = const {}}) → RoleData<SettingsData>
Creates value as data for this role; see RoleData.
inherited
dataIn(RoleHookInput<Object> input) → List<RoleData<SettingsData>>
Returns the data of this role in input, the input of a hook of another role.
inherited
entriesIn(RoleHookInput<Object> input) → List<SettingsEntry>
The entries of the settings screen in input, the input of a hook of this role, of its provider, or of a role that requires or uses this role, in the order the screen shows them.
hookInput(RoleHookRequest request) → RoleHookInput<SettingsData>
Builds the input of this role's hooks and its providers' hooks from the pipeline's request.
inherited
noSuchMethod(Invocation invocation) → dynamic
Invoked when a nonexistent method or property is accessed.
inherited
screenIn(RoleHookInput<Object> input) → FacadeRoute?
The route of the settings screen in input, the input of a hook of this role or of its provider: the route that the provider names with its SettingsScreenRoute. It is null if no module names one, or if the module that does has no route of that name, which the module rule settings_screen.route reports.
toString() → String
The role as messages name it: its description followed by role, such as router role for Router.
inherited

Operators

operator ==(Object other) → bool
The equality operator.
inherited