Update docs: README
This commit is contained in:
parent
dcc6ea6f6b
commit
4ad6cc3d6a
@ -100,7 +100,7 @@ SecureStorageSample Watch App/
|
|||||||
|
|
||||||
## Storage Design Philosophy
|
## Storage Design Philosophy
|
||||||
|
|
||||||
This app intentionally uses a **Type-Safe Storage Design**. Unlike standard iOS development which uses string keys (e.g., `UserDefaults.standard.string(forKey: "user_name")`), this library requires you to define a `StorageKey` type.
|
This app intentionally uses a **Type-Safe Storage Design**. Unlike standard iOS development which uses string keys (e.g., `UserDefaults.standard.string(forKey: "user_name")`), this library requires you to define `StorageKey` values.
|
||||||
|
|
||||||
### Why types instead of strings?
|
### Why types instead of strings?
|
||||||
1. **Safety**: The compiler prevents typos. You can't accidentally load from `"user_name"` and save to `"username"`.
|
1. **Safety**: The compiler prevents typos. You can't accidentally load from `"user_name"` and save to `"username"`.
|
||||||
@ -144,7 +144,7 @@ The app demonstrates various storage configurations:
|
|||||||
- Global sync configuration (max file size) in app `init`
|
- Global sync configuration (max file size) in app `init`
|
||||||
|
|
||||||
### Data Migration
|
### Data Migration
|
||||||
- **Fallback**: Automatically moves data from `LegacyMigrationSourceKey` to `ModernMigrationDestinationKey` on first access using protocol-based migration.
|
- **Fallback**: Automatically moves data from `legacyMigrationSource` to `modernMigrationDestination` on first access using protocol-based migration.
|
||||||
- **Transforming**: Converts a legacy full-name string into a structured `ProfileName`.
|
- **Transforming**: Converts a legacy full-name string into a structured `ProfileName`.
|
||||||
- **Aggregating**: Combines legacy notification + theme settings into `UnifiedSettings`.
|
- **Aggregating**: Combines legacy notification + theme settings into `UnifiedSettings`.
|
||||||
- **Conditional**: Migrates app mode only when the version rule is met.
|
- **Conditional**: Migrates app mode only when the version rule is met.
|
||||||
@ -170,6 +170,7 @@ This approach centralizes infrastructure settings and avoids hardcoding environm
|
|||||||
## Notes
|
## Notes
|
||||||
|
|
||||||
- Storage keys are now split into one file per key and grouped by domain; platform-focused keys live in `StorageKeys/Platform` with comments calling out availability/sync focus.
|
- Storage keys are now split into one file per key and grouped by domain; platform-focused keys live in `StorageKeys/Platform` with comments calling out availability/sync focus.
|
||||||
|
- Keys are declared as `StorageKey<Value>` static properties via constrained extensions (e.g., `extension StorageKey where Value == String`).
|
||||||
- The shared model/constants live in `SharedPackage` (`SharedKit`) to keep the watch/iOS data contract centralized.
|
- The shared model/constants live in `SharedPackage` (`SharedKit`) to keep the watch/iOS data contract centralized.
|
||||||
- Keychain service IDs and App Group identifiers are centralized in `SharedKit/Constants/StorageServiceIdentifiers.swift` to avoid hardcoded strings in keys.
|
- Keychain service IDs and App Group identifiers are centralized in `SharedKit/Constants/StorageServiceIdentifiers.swift` to avoid hardcoded strings in keys.
|
||||||
- The watch app uses a handler-based WatchConnectivity layer so new payload types can be added in `Services/Handlers` without bloating the main service.
|
- The watch app uses a handler-based WatchConnectivity layer so new payload types can be added in `Services/Handlers` without bloating the main service.
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user