I've written summaries on the bug of storage locations that exist on iOS & Android. I'm wondering if any other platforms want to participate in this discussion before we start proposing new (maybe platform-specific) LocalFileSystem constants?
On Tue, Jan 22, 2013 at 9:58 AM, Andrew Grieve <[email protected]> wrote: > I'd like to put this change on the radar. Looks like it's already got a > bug: https://issues.apache.org/jira/browse/CB-285. Let's continue the > discussion there. > > > > > > On Fri, Dec 7, 2012 at 12:21 PM, Andrew Grieve <[email protected]>wrote: > >> I really like this idea of using LocalFileSystem.APP (and maybe >> LocalFileSystem.ASSETS). >> >> I don't know if it's a good idea to eventually merge APP with PERSISTENT >> though. Spec-wise, it's my understanding that PERSISTENT is supposed to >> give you a sandboxed place to keep files, and so it wouldn't make sense for >> there to be files already present there. >> >> >> On Fri, Dec 7, 2012 at 12:17 PM, Simon MacDonald < >> [email protected]> wrote: >> >>> We did at that. I was kinda resurrecting that discussion as a way of >>> migrating us to the internal storage on Android in such a way that our >>> users will have time to get used to it. >>> >>> Another issue is being able to read files from the Android asset >>> directory using the File API but that is a whole other thread. >>> >>> Simon Mac Donald >>> http://hi.im/simonmacdonald >>> >>> >>> On Fri, Dec 7, 2012 at 12:14 PM, Filip Maj <[email protected]> wrote: >>> > I think we had talked about a LocalFileSystem.APP target a while back: >>> > >>> > http://apache.markmail.org/thread/4meuygaovchrl2th >>> > >>> > >>> > On 12/7/12 6:29 AM, "Simon MacDonald" <[email protected]> >>> wrote: >>> > >>> >>Hey all, >>> >> >>> >>There is no reason why the FileWriter can't write to >>> >>/data/data/com.yourappnamespace/ in fact it does quite well. The root >>> >>cause of the problem, if I can read between the lines, is that there >>> >>is no good way for the app developer to find this directory without >>> >>doing some hard coding of the path. >>> >> >>> >>Here is my proposal for moving forward while not abandoning our >>> >>current user base. Please bear with me as it will not be W3C standard >>> >>but it will get there. >>> >> >>> >>1) Add a new LocalFileSystem type called APP: LocalFileSystem.APP >>> >>2) When you do a window.requestFileSystem() with the APP type the path >>> >>for the root directory should be "/data/data/com.yourappspacename/" on >>> >>Android, a similar path on BB and on iOS is should return the same >>> >>value as what you get when asking for a PERSISTENT file system. >>> >>3) Announce the hell out of the fact that PERSISTENT will become APP >>> >>in 6 months. >>> >>4) In May/June (PhoneGap 3.0 anyone) finally make it so requesting the >>> >>PERSISTENT or APP file system will give you the same path. >>> >> >>> >>What do you think? >>> >> >>> >>Also, if we move to writing everything to the "jail" then we will need >>> >>a solution where the developer will want to launch an intent to handle >>> >>a file from that directory. That can be a problem since the "jail" is >>> >>not accessible to other apps. We can set the file to be world readable >>> >>but then we'd need to provide a facility to allow them to control the >>> >>file permissions. Just something to think about. >>> >> >>> >>Simon Mac Donald >>> >>http://hi.im/simonmacdonald >>> >> >>> >> >>> >>On Thu, Dec 6, 2012 at 4:22 PM, Joe Bowser <[email protected]> wrote: >>> >>> Hey >>> >>> >>> >>> I'm looking at the FileWriter API and I have no idea how we could >>> >>> explicitly write to the app jail on Android >>> >>> (/data/data/com.yourappnamespace/). I feel like our FileWriter is >>> >>> pretty dated and that we should re-evaluate how it works, since many >>> >>> devices don't use SD Cards anymore for their storage due to the limit >>> >>> on SD Card storage? Also, it'd be good to allow users to have >>> >>> persistant, protected storage that other apps can't mess with. >>> >>> >>> >>> Thoughts? >>> >>> >>> >>> Joe >>> > >>> >> >> >
