[
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571724#comment-13571724
]
Andrew Grieve commented on CB-285:
----------------------------------
Thanks for the feedback Becky!
Moving from Documents -> Library: My thought here was that it's more common to
use it for app data than for user-generated content. Users should be able to
understand what each file in their Documents directory is for. That's not a
distinction that the LocalFileSystem API makes.
Agree that a USER_DATA might make sense, but that doesn't map as well
x-platform, and so wanted to punt on it for the first go-around. If you (or
someone else) wants to propose something for it though, now's not a bad time to
discuss! :)
I suggest exposing <Application_Home> only to avoid exposing every
sub-directory of it as different constants. Maybe this would be better though?
I can also imagine third-party plugins wanting to be able to chose a
sub-directory to use for plugin-specific files that does not show up to the app
within their PERSISTENT / TEMPORARY spaces. e.g. /tmp/my-plugin or
/Library/my-plugin/. Exposing the root (<Application_Home> makes this possible.
For assets - it's not currently possible to create a FileEntry() to a file in
the www/ directory (unless you call the constructor directly with the full
path, which is not really a supported API). There can also be siblings of www/
on both iOS and Android. I figured it would be useful to expose these (through
our non-standard additions), but I can't actually think of a reason right now
why you'd want to. It would only make your life harder, no? Maybe instead of
APP_ASSETS, we should just have a CORDOVA_WWW constant? wdyt? The reason we
want to expose it via the FileSystem API even though it's read-only, is that it
makes it enumerable.
I *think* I agree with what you said about relative paths. They should be
treated as relative URLs, so should be relative to the html file you're
currently on.
For CB-571, I don't know that it's safe to assume Documents directory. It could
be the app is a shazam-like app and the sound-clip is really just temporary app
data. The best thing would be if the apps passed in absolute URLs for where
they want the file. According to what you (and I agree) suggest for handling
relative URLs, passing in just a filename should resolve to a file in the www/
directory, and be read-only. This would be my expected behaviour if I created
the Media object with the intention of calling .play() on it.
> Add property returning root path of PhoneGap files
> --------------------------------------------------
>
> Key: CB-285
> URL: https://issues.apache.org/jira/browse/CB-285
> Project: Apache Cordova
> Issue Type: Improvement
> Components: CordovaJS
> Affects Versions: 1.4.0
> Environment: Both PhoneGap SDK and PhoneGap Build
> Reporter: Ashley Gullen
> Assignee: Andrew Grieve
> Labels: features
>
> There needs to be a property in PhoneGap that returns the root path to the
> general files added to the PhoneGap project (i.e. the directory index.html is
> in). For example, if I add 'music.mp3' to my project, in Android it will be
> located in:
> /android_asset/www/music.mp3
> On iOS after being built with PhoneGap Build it will be located in some path
> like this:
> /var/mobile/Applications/<app_ID>/<name>.app/www/music.mp3
> However, there does not appear to be a programmatic way to determine both
> <app_ID> and <name>.app.
> This has two side effects:
> 1. Paths to audio for Media must be hard-coded separately depending on the
> platform, which is inconvenient.
> 2. Paths to audio for Media cannot be known if developing a framework that
> uses PhoneGap. Since a framework does not know the App ID or name in
> advance, it's impossible for the framework to determine the correct path.
> This is actively blocking audio from working on iOS in PhoneGap projects
> exported by Construct 2 (www.scirra.com), a HTML5 game creator. Also, it
> seems like kind of an important function to make available anyway, since
> hard-coding paths for each platform is a pain.
> This PhoneGap Support thread led to this issue:
> http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
