8 changed files with 229 additions and 15 deletions
@ -0,0 +1,125 @@ |
|||||
|
/*! |
||||
|
@class QtMvvm::ISettingsAccessor |
||||
|
|
||||
|
This class is used by the SettingsViewModel and the @ref settings_generator "qsettingsgenerator" |
||||
|
to access settings. The interface is meant to be used as proxy for some kind of settings |
||||
|
backend (like QSettings), so access is kept generic and you can decide to use a different |
||||
|
storage if needed. While this class can be used directly, it is dsigned to only be used |
||||
|
as backend for a settings viewmodel or a generated settings instance, and thus lacks many |
||||
|
"comfort" methods one would otherwise expect. |
||||
|
|
||||
|
@note All the semantincs desribed below, except for the change signals, are exactly the same |
||||
|
as for QSettings, as this interface is modeled after QSettings, in other words, the same rules |
||||
|
for keys and values as for QSettings apply to the methods of this interface. |
||||
|
|
||||
|
@section ISettingsAccessor_keys Semantics of keys |
||||
|
Keys follow the following semantics. All keys are of the format `group/subgroup/key`. Keys |
||||
|
may or may not be case sensitive, depending on the plattform. The best approach is to assume |
||||
|
keys are case insensitive when storing, but case sensitive when loading. While the keys are |
||||
|
seperated into groups and keys, all groups can also serve as keys, i.e. `group/subgroup` is a |
||||
|
valid key as well. |
||||
|
|
||||
|
@section ISettingsAccessor_storing Storing data |
||||
|
You can assume that data passed to save() is serializable via QDataStream. In other words, to |
||||
|
convert the variant to binary data, you can simply use operator<< and operator>> of the |
||||
|
QVariant. Also, just like with QSettings, the saved data does not have to retain the type. The |
||||
|
only condition is, that whatever you load() for the same key as used for storing must be |
||||
|
convertible to the same type as the variant, that was passed to the save() method. |
||||
|
|
||||
|
Finally, saving data via this method does not have to immediatly store it permanently. However, |
||||
|
calling load() with the same key right after save() must always return the same value as |
||||
|
passed to it. Permanent storing can be done asynchronously, but should happen automatically |
||||
|
without to much time passing after the save() (or remove()), and must always happen before |
||||
|
the destruction of this object. Furthermore, users can use the sync() method to immediatly store |
||||
|
data permanently and load all changes done externally. |
||||
|
|
||||
|
@section ISettingsAccessor_signals Change signals |
||||
|
Another specialty of this class are the change signals. They must be emitted whenever save() |
||||
|
or remove() are called, to ensure at least changes done within the same instance trigger the |
||||
|
according change signals. Changes done externally should lead to change signals, but don't have |
||||
|
to, if not supported. For example, the DataSyncSettingsAccessor can indeed detect changes as |
||||
|
they occur on other instances or externally, and thus emits the signals. QSettings however does |
||||
|
not support change signals of any kind, and thus external changes do change the data that can |
||||
|
be loaded, but do not emit any signals. |
||||
|
|
||||
|
@section ISettingsAccessor_impl Available implementations |
||||
|
Currently, the following backends are supported: |
||||
|
|
||||
|
- QSettingsAccessor: Wraps QSettings |
||||
|
- DataSyncSettingsAccessor: Part of mvvm datasync core, allows to store and sync settings via datasync |
||||
|
- AndroidSettingsAccessor: Wraps the SharedPreferences of the android API |
||||
|
|
||||
|
@sa #QtMvvm_ISettingsAccessorIID, QSettingsAccessor, DataSyncSettingsAccessor, |
||||
|
AndroidSettingsAccessor, SettingsViewModel, DataSyncSettingsViewModel, @ref settings_generator |
||||
|
*/ |
||||
|
|
||||
|
/*! |
||||
|
@fn QtMvvm::ISettingsAccessor::contains |
||||
|
|
||||
|
@param key The key of the settings entry to be checked for existance |
||||
|
@returns true, if a value for that key was stored, false if not |
||||
|
|
||||
|
This should only check for values, not for groups, i.e. if key referes to a group that has |
||||
|
child keys, but no value by itself, you should still return false. |
||||
|
|
||||
|
@sa ISettingsAccessor::load |
||||
|
*/ |
||||
|
|
||||
|
/*! |
||||
|
@fn QtMvvm::ISettingsAccessor::load |
||||
|
|
||||
|
@param key The key of the settings entry to be loaded |
||||
|
@param defaultValue A alternative value to be returned if there is no data stored for that key |
||||
|
@returns The data loaded for the key, or the default value |
||||
|
|
||||
|
If the given value does exist, it should be loaded and returned. If the is on data stored for |
||||
|
that key, simply return whatever is passed as the default value. |
||||
|
|
||||
|
@sa @ref ISettingsAccessor_storing, ISettingsAccessor::contains, ISettingsAccessor::save |
||||
|
*/ |
||||
|
|
||||
|
/*! |
||||
|
@fn QtMvvm::ISettingsAccessor::save |
||||
|
|
||||
|
@param key The key of the settings entry to be saved |
||||
|
@param value The data to be stored under that key |
||||
|
|
||||
|
Should simply store the passed data under the given key. You dont have to check if the variant |
||||
|
is actually serializable, as the meta system will automatically warn the user if thats not the |
||||
|
case. Permanent storing is done asynchronously, but can be forced via sync(). |
||||
|
|
||||
|
Any implementation of this method *must* emit the entryChanged() signal with the passed data and |
||||
|
key. |
||||
|
|
||||
|
@sa @ref ISettingsAccessor_storing, ISettingsAccessor::entryChanged, ISettingsAccessor::load, |
||||
|
ISettingsAccessor::remove, ISettingsAccessor::sync |
||||
|
*/ |
||||
|
|
||||
|
/*! |
||||
|
@fn QtMvvm::ISettingsAccessor::remove |
||||
|
|
||||
|
@param key The key of the settings entry to be removed |
||||
|
|
||||
|
This method should remove the given key and all of its subkeys. If for example the settings |
||||
|
contained the values `group/subgroup` and `group/subgroup/key`, after this method, both must |
||||
|
have been removed. Permanent storing is done asynchronously, but can be forced via sync(). |
||||
|
|
||||
|
Any implementation of this method *must* emit the entryRemoved() signal for **all** the removed |
||||
|
entries. I.e. for the example above, it must be emitted for both, `group/subgroup` and |
||||
|
`group/subgroup/key`. |
||||
|
|
||||
|
@sa @ref ISettingsAccessor_storing, ISettingsAccessor::entryRemoved, ISettingsAccessor::save, |
||||
|
ISettingsAccessor::sync |
||||
|
*/ |
||||
|
|
||||
|
/*! |
||||
|
@fn QtMvvm::ISettingsAccessor::sync |
||||
|
|
||||
|
You can call this method to immediatly store any changed data to permanent store. This exists |
||||
|
because typically, calls to save() and remove() only "cache" the changes, and then later write |
||||
|
them to the permanent store in a single transaction, as this can be an expensive operation. |
||||
|
Normally, you don't have to care about this, as this happens automatically, but sometimes you |
||||
|
might want to manually perform this step. Thats what this method is for. |
||||
|
|
||||
|
@sa ISettingsAccessor::save, ISettingsAccessor::remove, QSettings::sync |
||||
|
*/ |
Loading…
Reference in new issue