A root contains statistics about itself and the stores, as well as information for the bulk download Recovery system, and access to the import/export functionality.
Roots are unnamed, and the current root is accessed through FMTCRoot:
To manage the root, use the methods on the backend.
FMTCRoot.stats allows access to statistics, as well as listing of all existing stores, and the watching of changes in multiple/all stores.
Remember that the size and length statistics in the root may not be equal to the sum of the same statistics of all available stores, because tiles may belong to many stores, and these statistics do not count any tile multiple times.
Stores maintain references to all tiles which belong to it, and also contain customizable metadata and cached statistics.
They are referenced by name, the single argument of FMTCStore.
Ensure names of stores are consistent across every access. "Typed"/code-generated stores are not provided, to maintain flexibility.
Construction of an FMTCStore object does create the underlying store, as this is an asynchronous task. It must be created before it may be used.
FMTCStore().manage allows control over the store and its contents.
FMTCStore().stats allows access to:
statistics
retrieval of a recent tile (as an image)
watching of changes to the store
FMTCStore().metadata allows access and control over a simple persistent storage mechanism, designed for use with custom data/properties/fields tied to the store. For example, in some apps, it could store the BrowseStoreStrategy or URL template/source.
Data is interpreted in key-value pair form, where both the key and value are Strings. Internally, the default backend stores it as a flat JSON structure. The metadata is stored directly on the store: if the store is deleted, it is deleted, and an exported store retains its metadata. More advanced requirements will require use of a separate persistence mechanism.
Remember that metadata does not have any effect on internal logic: it is simply an auxiliary method of storing any data that might need to be kept alongside a store.
FMTC uses a root and stores to structure its data. In general, a single root exists (which uses a single ), which contains multiple named stores. Cached tiles can belong to multiple stores, which reduces duplication and maximizes flexibility.
The structures use the ambient backend when a method is invoked on it, not at construction time.
Therefore, it is possible to construct an FMTCStore/FMTCRoot before initialisation, but 'using' any methods on it will throw RootUnavailable.
