Introduction
State persistence is the ability to save your app's state (like user preferences, settings, or even data) to a local storage and restore it when the app is reopened. In GetX, the simplest way to achieve this is with GetStorage – a lightweight key‑value storage that integrates seamlessly with reactive variables and workers. This guide covers how to persist and restore state using GetX patterns.
Setting Up GetStorage
Add GetX to your pubspec.yaml (GetStorage is included). Initialize GetStorage in main() before running the app.
Basic Persistence with Workers
The most common pattern is to save a reactive variable's value to storage whenever it changes, using a worker. Then load the saved value in onInit.
Persisting Multiple Values
For multiple settings, you can create a method to load all at once, or use separate workers. A dedicated settings service can help organize.
Persisting Complex Data
GetStorage only supports primitive types, lists, and maps. To store custom objects, convert them to a map (JSON) first. You can also use a helper service.
Persisting Lists
You can store reactive lists as RxList and persist them using assignAll when loading, and save whenever the list changes.
Restoring State on App Start
You can also create a service that loads all persisted data before any controller is initialized. Use an initialBinding to load and then inject the data into controllers.
Using with StateMixin
You can combine persistence with StateMixin to manage loading/error states while restoring data.
Best Practices
- Initialize GetStorage early – Call
await GetStorage.init()beforerunApp. - Use workers to auto‑save –
eversaves on every change;debouncecan be used for less frequent saves. - Keep data small – GetStorage is not meant for large datasets; use Hive or SQLite for that.
- Handle null defaults – Provide fallback values when reading.
- Separate concerns – Create a service for persistence logic, not inside controllers if it becomes complex.
- Encapsulate persistence in a service – A
StorageServicecan provide methods likesaveTheme,loadTheme.
Common Mistakes
- ❌ Forgetting to call
GetStorage.init()– Causes runtime errors. ✅ Call it in main before runApp. - ❌ Storing large objects – May cause performance issues or disk limits. ✅ Use appropriate storage for large data.
- ❌ Not handling null when reading – Can cause exceptions.
✅ Use
??default values. - ❌ Saving on every tiny change without debounce – May cause unnecessary writes.
✅ Use
debouncefor fields like text inputs.
FAQ
- Q: Can I use SharedPreferences instead of GetStorage?
A: Yes, but GetStorage is faster and has a simpler API. It also works on web (localStorage). - Q: How do I clear all persisted data?
A: UseGetStorage().erase()to clear the entire storage box. - Q: Is it safe to persist user tokens?
A: Yes, but consider security. GetStorage stores in plain text; for sensitive data, consider encrypting or using FlutterSecureStorage. - Q: How to handle multiple storage boxes?
A: Use named boxes:GetStorage('settings')andGetStorage('user'). Initialize each withGetStorage.init('boxName'). - Q: Can I persist state across app updates?
A: Yes, GetStorage persists across updates as long as the storage file format remains compatible.
Conclusion
Persisting state with GetX and GetStorage is straightforward. By using workers to automatically save reactive variables and loading them in onInit, you can create apps that remember user preferences and data across sessions. For more complex data, you can serialize objects and combine with StateMixin for a full data layer.