[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571437#comment-13571437
 ] 

Andrew Grieve edited comment on CB-285 at 2/5/13 4:54 PM:
----------------------------------------------------------

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 :(
- Is there a way to detect new installs so that we can switch over for new 
installs at least?

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.






                
      was (Author: agrieve):
    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

Reply via email to