Skip to main content

Goal

You want users to be able to disable/enable parts of UI from Settings. But you also want something stronger:
If a feature disappears from your data source, it should disappear from Settings and from everywhere else automatically.
This recipe shows a clean pattern using Presentum:
  • A server-driven feature catalog (what toggles exist)
  • A user preference store (which features are enabled)
  • A guard that projects candidates → slots and enforces catalog + prefs
  • A settings surface that renders toggle rows declaratively

1) Surfaces + variants


2) Feature catalog (data source → “these toggles exist”)

This is the source of truth for what should be visible in Settings.
When the server removes a feature, replaceAll(...) removes it from the map ⇒ it “doesn’t exist” anymore.

3) User preferences (per-user enabled/disabled)

You usually want these toggles to persist across app restarts.

3.1 Repository interface (swap storage later)

3.2 Example persistence with shared_preferences


4) Presentum modeling (payload / option / item)

We’ll use one payload type for both:
  • “real UI presentations” (e.g. homeHeader banners)
  • “settings toggle rows” (rendered in a list)

5) Provider: emit candidates for both Settings and real UI

This provider is the bridge:
  • It reads the catalog to know what exists
  • It emits settings toggle row items for all features
  • It optionally emits some real UI items that depend on those features

6) Guard: candidates → slots + enforce catalog + user prefs

setCandidatesWithDiff(...) updates candidates. A guard decides what becomes active and what goes to the queue. In this recipe, we treat the Settings surface as a “list slot”:
  • active = first row
  • queue = the rest of the rows
PresentumOutlet$Composition then reads active + queue and gives you a normal list for rendering.

7) Settings UI: render many toggle rows from one surface

Presentum slots are “active + queue”, but Settings wants a list. Use PresentumOutlet$Composition with OutletGroupMode.custom and a resolver that returns all items.
Now the requirements are met:
  • Remove feature from server catalog ⇒ provider stops emitting the settings row ⇒ it disappears from Settings.
  • The same removal also stops emitting/allowing any other UI belonging to that feature ⇒ it disappears across the app.
And now it also works mechanically:
  • candidates are scheduled into slots
  • the Settings list comes from active + queue