On Sat, May 11, 2013 at 2:29 AM, Dave Hylands <[email protected]> wrote:
> So bug 858416 has been landed on birch and it should make its way to
b2g18.
>
> I wanted to summarize the changes that have occurred in the device
storage API.
>
> In order to support both internal and external storage areas, we've added
support for what I call composite device storage objects.
> In the past a name like DCIM/car.jpg would be sufficient to uniquely
identify a file. However when there are multiple device storage areas, this
doesn't tell you which storage area the file is stored in.
>
> So, a "fully qualified" name now looks like
>
> /storageName/directory/file
>
> While storageName looks like a directory component, it isn't, it's the
name of a volume. Typical volume names might be sdcard and extsdcard, so a
fully qualified name would look like:
>
> /sdcard/directory/file
> /extsdcard/directory/file
>
> navigator.getDeviceStorage(type) now returns what I call a composite
device storage object.
>
> navigator.getDeviceStorages(type) returns an array of non-composite
storage objects. It is anticipated that this particular API would only be
used by the settings app for displaying free/used space for each volume.
Each non-composite device storage object has an attribute called
storageName which identifies the volume that the device storage area
corresponds to.
Wouldn't you also need to use getDeviceStorages if you don't know what
types of storage areas are available on the device? As is the case for all
3rd party apps. And might be the case for some of our built-in apps if we
want to make their code generic and work across multiple devices.
Seems like a common use case for getDeviceStorages("pictures") would be to
enumerate all locations where pictures are stored and display UI to the
user which explains in human understandable form where the various pictures
are stored.
Same thing when the user wanting to save a picture. The application would
likely want to use getDeviceStorages("pictures") and display a human
understandable picker which lets the user choose where the file should be
saved.
> When using the composite device storage object, If you call AddNamed and
were to specify "DCIM/foo.jpg" then it will use the default storage area
(set by the user in the settings app under Media Storage).
>
> The onsuccess method will be passed the fully qualified name of the
object (i.e. you'd probably get back something like /sdcard/DCIM/foo.jpg).
>
> Enumerate has changed slightly as well. Previously if you called
enumerate('DCIM') you'd get back just the portion of the filename below the
DCIM directory (so just foo.jpg). Now, you always get back a fully
qualified location (/sdcard/DCIM/foo.jpg). When you use enumerate on the
composite device storage object, it will return all of the files on all of
the storage areas.
What will enumerate("DCIM") do on the composite device storage object? Will
it return all files of the pattern "/*/DCIM/...", i.e. all files starting
with "/sdcard/DCIM" and "/extsdcard/DCIM", or will it return nothing since
all composite filenames start with either "/extsdcard/DCIM/" or
"/sdcard/DCIM/"?
In general I'm a bit worried about all the magic that's happening in the
composite storage space, but I don't have any concrete proposals for how to
get rid of it.
/ Jonas
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
