Where a document too large or too binary for Storage lives.
Why a second interface rather than base64 through Storage. A model
project can be megabytes; localStorage — Storage's own backing on the
web — is capped at a few of them per origin for every document an
application keeps there combined, and base64 costs another third on top
of that budget for nothing. IndexedDB has no such ceiling in practice and
stores bytes as bytes, which is what an autosave of a real document needs.
Asynchronous, unlike Storage, because read and write both are on
the web. There is no synchronous IndexedDB from a page's own thread —
only from a worker — so an interface promising otherwise would be a
promise the web implementation could not keep. A caller on a native
platform pays nothing for this: FileBinaryStorage's own I/O is already
asynchronous underneath dart:io.
- Implementers
Properties
- hashCode → int
-
The hash code for this object.
no setterinherited
- runtimeType → Type
-
A representation of the runtime type of the object.
no setterinherited
Methods
-
noSuchMethod(
Invocation invocation) → dynamic -
Invoked when a nonexistent method or property is accessed.
inherited
-
read(
String name) → Future< Uint8List?> -
The document called
name, or null if there is not one. -
remove(
String name) → Future< void> -
Forgets
name, if it is there. -
toString(
) → String -
A string representation of this object.
inherited
-
write(
String name, Uint8List contents) → Future< bool> -
Writes
contents, and says whether it managed to. Never throws, for the same reason Storage.write does not.
Operators
-
operator ==(
Object other) → bool -
The equality operator.
inherited