Re: [Android] Explicitly writing to the jail

[Andrew Grieve <ag...@chromium.org>]

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 <ag...@chromium.org> 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 <
> simon.macdonald@gmail.com> 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 <fi...@adobe.com> 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" <si...@gmail.com>
>> 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 <bo...@gmail.com> 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
>> >
>>
>
>

Re: [Android] Explicitly writing to the jail

[Andrew Grieve <ag...@chromium.org>]

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 <ag...@chromium.org> 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 <ag...@chromium.org>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 <
>> simon.macdonald@gmail.com> 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 <fi...@adobe.com> 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" <si...@gmail.com>
>>> 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 <bo...@gmail.com> 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
>>> >
>>>
>>
>>
>