Great, that will be a very useful addition to the File API. Simon Mac Donald http://hi.im/simonmacdonald
On Mon, Jan 7, 2013 at 6:30 PM, Braden Shepherdson <bra...@chromium.org> wrote: > I've recently been implementing support for Blob.slice() for FileReader > files (sort of). With real native File and Blob objects, they actually hold > the binary data. Cordova File objects are just records passed to > FileReaders. Regardless, the API for File.slice() is identical: it takes a > start and optional end position, and returns a new File. Asking FileReader > to fetch that new file will return just the specified segment of the file. > > Some examples are in order. Suppose the file we're reading contains the > text: > "All that is gold does not glitter, not all those who wander are lost." > Then > f.slice(4, 8) would result in "that" > f.slice(9) would be "is gold does not glitter, not all those who wander are > lost." > f.slice(-5, -1) would be "lost" > > This is implemented on Android and iOS for both reading text and reading > data URLs. It's straightforward to implement on other platforms, and I > encourage maintainers of other platforms to add this. > > I'll be updating the docs tomorrow, including the following quirk on iOS. > > > That quirk is that iOS encodes the response to readAsText using %-escapes, > so that spaces become %20 and so on. This breaks a handful of spec tests > including mine. It seems very puzzling, since a quick test with that > encoding removed shows that all the specs are now passing. I didn't commit > that, I just wanted to see if the bridge code would die horribly or > something. This has been in the codebase as far back as Github's history > goes (the name change to Cordova), so I was unable to discover the original > reason for it. > > Shaz, Andrew, any idea what's going on here? Is this a relic of an old > bridge that can be removed? I'm not sure whether this is a breaking change > for iOS, since Android and presumably other platforms do not do this. > > Braden
