Component
Feature Description
Add Profiles to Formulus, in the same spirit as ODE Desktop: each profile is an isolated Synkronus context (URL, credentials, tokens, sync state, SQLite, attachments, app bundle, Formplayer drafts). The device starts on the last-used profile (or the single Default profile).
Problem Statement
Changing the Synkronus server today wipes local state and switches. That makes it hard to use one device for more than one project at a time, and it is easy to lose unsynced work.
Proposed Solution
- Dedicated Profiles screen (list, add, rename, switch, delete, login/QR). Connection fields move off Settings.
- After first successful login, the profile URL is locked. Username/password can be changed in place (same local data).
- Strict isolation: nothing from one profile is visible in another (including Formplayer drafts).
- Upgrading is non-breaking: existing config and data migrate into a Default profile.
- Deleting a profile also deletes its local data. The last remaining profile cannot be deleted.
- Changing project means add/switch profile, not wipe-and-switch.
Alternatives Considered
- Keep wipe-and-switch, but scoped to one profile — still destructive and easy to get wrong.
- Implicit “new URL creates a profile” with no Profiles screen — weaker UX than Desktop.
- Symlink “current profile” pointers — brittle on Android and with WatermelonDB’s SQLite location.
Additional Context
Planned storage: {docs}/profiles/{id}/ for attachments, app, forms, signatures; per-profile SQLite formulus_{id}; Keychain and AsyncStorage namespaced by profile id. Formplayer localStorage drafts/sticky fields keyed by profile id (bundled WebView origin is shared). Switch reloads the JS runtime so in-memory singletons cannot leak.
Related
Component
Feature Description
Add Profiles to Formulus, in the same spirit as ODE Desktop: each profile is an isolated Synkronus context (URL, credentials, tokens, sync state, SQLite, attachments, app bundle, Formplayer drafts). The device starts on the last-used profile (or the single Default profile).
Problem Statement
Changing the Synkronus server today wipes local state and switches. That makes it hard to use one device for more than one project at a time, and it is easy to lose unsynced work.
Proposed Solution
Alternatives Considered
Additional Context
Planned storage:
{docs}/profiles/{id}/for attachments, app, forms, signatures; per-profile SQLiteformulus_{id}; Keychain and AsyncStorage namespaced by profile id. FormplayerlocalStoragedrafts/sticky fields keyed by profile id (bundled WebView origin is shared). Switch reloads the JS runtime so in-memory singletons cannot leak.Related