cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Adding new LocalFileSystem constants.
Date Fri, 08 Feb 2013 14:09:40 GMT
Andrew: I like it. At some point, probably after 3.x, we need to take
all these non-standard findings back to the w3c. Grouping them in
their own plugins makes sense to me instead of gumming up the
standards "pure" implementations.

On Wed, Feb 6, 2013 at 8:14 AM, Andrew Grieve <agrieve@chromium.org> wrote:
> Good point about their being the possibility of multiple shared media. Last
> night I convinced myself that adding new constants may not be the best path
> forward, and instead proposed a new API (on the JIRA issue.).
>
>
> On Tue, Feb 5, 2013 at 2:50 PM, Bryan Higgins <bryan@bryanhiggins.net>wrote:
>
>> Thanks for the info Andrew!
>>
>> It seems like the main difference between Android and BB10 is that we
>> provide shared storage both internal and external. Apps like the camera
>> will prompt where files should be saved once an SD card is inserted. It's
>> also possible we could have multiple external sources (ie cloud storage,
>> usb).
>>
>> My 2 cents is that SHARED is probably a better name for the default target.
>> For platforms with removable media, constants are probably not the best way
>> to go. As a developer, I'd want a API to query available mount points and
>> go from there.
>>
>>
>>
>> On Tue, Feb 5, 2013 at 1:53 PM, Andrew Grieve <agrieve@chromium.org>
>> wrote:
>>
>> > Thanks for the input Bryan!
>> >
>> > Good ref's for storage locations:
>> > Android:
>> http://developer.android.com/guide/topics/data/data-storage.html
>> > ):
>> > iOS:
>> >
>> >
>> http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html
>> >
>> > Shared files:
>> > On Android, they go on /sdcard/Pictures, /sdcard/Music, etc.
>> > On iOS, Photos & Videos are shared via the AssetLibrary framework and
>> music
>> > through the MusicPlayer framework. Neither one is provides a
>> > filesystem-like interface.
>> >
>> >
>> > Would SHARED be different from EXTERNAL_ROOT? Maybe SHARED would be a
>> > better name for it?
>> >
>> >
>> > On Tue, Feb 5, 2013 at 1:31 PM, Bryan Higgins <bryan@bryanhiggins.net
>> > >wrote:
>> >
>> > > Hi Andrew,
>> > >
>> > > I really like this proposal. It's something we'd likely pick up for
>> > > BlackBerry WebWorks.
>> > >
>> > > Right now we have a separate API call which removes the sandbox and
>> > exposes
>> > > the full file system via PERSISTENT. We provide constants for paths to
>> > > things like application root, sd card and shared directories. Sandboxed
>> > > file systems are rooted in a subdirectory of the application. That
>> > approach
>> > > (plus our use of local:/// protocol) has caused some confusion with
>> > > developers.
>> > >
>> > > I think the list of android constants would work well for BB10, perhaps
>> > > with the addition of SHARED. I'm not too familiar with iOS and Android
>> > file
>> > > systems. Is there a single directory which contains shared documents,
>> > > music, etc?
>> > >
>> > > Thanks,
>> > > Bryan
>> > >
>> > >
>> > >
>> > > On Tue, Feb 5, 2013 at 11:52 AM, Andrew Grieve <agrieve@chromium.org>
>> > > wrote:
>> > >
>> > > > FYI - Still looking for feedback here!
>> > > >
>> > > > ---------- Forwarded message ----------
>> > > > From: Andrew Grieve (JIRA) <jira@apache.org>
>> > > > Date: Tue, Feb 5, 2013 at 11:38 AM
>> > > > Subject: [jira] [Commented] (CB-285) Add property returning root path
>> > of
>> > > > PhoneGap files
>> > > > To: callback-dev@incubator.apache.org
>> > > >
>> > > >
>> > > >
>> > > >     [
>> > > >
>> > > >
>> > >
>> >
>> https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571437#comment-13571437
>> > > > ]
>> > > >
>> > > > Andrew Grieve commented on CB-285:
>> > > > ----------------------------------
>> > > >
>> > > > I like the idea of switching PERSISTENT to be internal-only. The W3C
>> > spec
>> > > > intends this area to be sandboxed to the app, so shouldn't be on the
>> > > > sdcard.
>> > > >
>> > > > I think we need more than just an APP constant though, as there are
>> > many
>> > > > places where an app might want to put things.
>> > > >
>> > > > For iOS, You'd minimally want:
>> > > > 1. Application bundle,
>> > > > 2. <Application_Home>
>> > > >
>> > > >
>> > > > The other locations are all subdirectories of <Application_Home>,
so
>> > not
>> > > a
>> > > > big deal if we don't have constants for them
>> > > >
>> > > > For Android, You'd minimally want:
>> > > > 1. Assets directory (seems like a parallel to iOS Application Bundle)
>> > > > 2. Application data on internal storage
>> > (/data/data/$PACKAGE_NAME/files)
>> > > > 3. Application cache on internal storage
>> > (/data/data/$PACKAGE_NAME/cache)
>> > > > 4. External root: (/sdcard)
>> > > >
>> > > > We could maybe combine #2 and #3 into a single one that gave you
>> > > > /data/data/$PACKAGE_NAME, and document that Android wants files in
>> the
>> > > > "files" and "cache" directories.
>> > > >
>> > > >
>> > > >
>> > > > The Ideal iOS constants:
>> > > >  1. PERSISTENT changes from <Application_Home>/Documents -->
>> > > > <Application_Home>/Library/CdvPersistentStorage
>> > > >  2. TEMPORARY changes from <Application_Home>/tmp -->
>> > > > <Application_Home>/tmp/CdvTemporaryStorage
>> > > >  3. APP_ASSETS --> Application bundle
>> > > >  4. APP_DATA --> <Application_Home>
>> > > >
>> > > > The main reason for changing #1 is that iCloud treats Documents
>> > directory
>> > > > specially
>> > > > The main reason for adding subdirs under Library/tmp is that it keeps
>> > the
>> > > > storage areas separate from the rest of the app (apps that have
>> native
>> > > > components won't interfere with the webview's storage area).
>> > > >
>> > > > The ideal Android constants:
>> > > >  1. PERSISTENT -->
>> /data/data/$PACKAGE_NAME/files/CdvPersistentStorage
>> > > >  2. TEMPORARY --> /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage
>> > > >  3. APP_ASSETS --> assets directory
>> > > >  4. APP_DATA --> /data/data/$PACKAGE_NAME
>> > > >  5. EXTERNAL_APP_DATA --> /sdcard/Android/data/$PACKAGE_NAME
>> > > >  6. EXTERNAL_ROOT --> /sdcard
>> > > >
>> > > >
>> > > > I even think there would be merit in adding more constants (e.g.
>> > > DOCUMENTS,
>> > > > android resources) going forward, but one step at a time...
>> > > >
>> > > >
>> > > > == Transitioning to these new constants ==
>> > > >
>> > > > TEMPORARY:
>> > > > Use the new path right away. No need to transition since the files
>> > there
>> > > > are temporary anyways.
>> > > >
>> > > >
>> > > > PERSISTENT (iOS):
>> > > > - If new location directory exists, use that.
>> > > > - Else, if any files exist in the legacy location, use the legacy
>> > > location
>> > > > - Else, use the new path.
>> > > >
>> > > > PERSISTENT (Android):
>> > > > - PERSISTENT is currently /sdcard, so files will always exist :(
>> > > >
>> > > > In both cases, add a PERSISTENT_NEW constant to allow them to move
>> > their
>> > > > files over.
>> > > > In Cordova 3.0, change PERSISTENT to be PERSISTENT_NEW, and add
>> > > > PERSISTENT_LEGACY (in case apps have still not switched).
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > Side issue:
>> > > >
>> > > > The spec says PERSISTENT and TEMPORARY are constants on the window
>> > object
>> > > > (ugh). So far though, Cordova has exposed them not as globals, but
>> > > instead
>> > > > as LocalFileSystem.PERSISTENT and LocalFileSystem.TEMPORARY. I like
>> the
>> > > > idea of exposing them on LocalFileSystem, but we should also put
>> > > PERSISTENT
>> > > > and TEMPORARY on the window.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > > 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
>> > > >
>> > >
>> >
>>

Mime
View raw message