[DISCUSS] android cordova-plugin-file external storage support
Hi Team, I want to discuss a proposal of rather significant change to the file plugin. This is something I've already discussed over the last couple of months privately with a couple of others, but with the announced that the newer READ_MEDIA_* permissions now will require justification, I think it's time to get a formal community opinion. In short, I want to start saying that the file plugin no longer supports external storage paths. Here is why. 1. API 29 doesn't support the external filesystem whatsoever when scoped storage is enabled. API 29 only supports interacting with the external filesystem when interfacing with the MediaStore APIs. Direct File access via File APIs is completely blocked. Supporting for File APIs was only added in API 30 via FUSE[1]. 2. Even with FUSE on API 30 and later, Direct File access via Flie APIs are limited to reading images, audio and video files. Documents or other kinds of files are restricted. Additionally writing to files is also restricted. The only exception to this rule is if your app owns the file. 3. Currently the file plugin will use READ_MEDIA_* if declared, but it doesn't do any permission declaration itself. So it can be said this is a opt in. It however attempts to request all 3 permissions[3] which will be problematic. If the app only details with audio, it doesn't need IMAGES or VIDEO permission and definitely won't have the justification. We do have these restrictions documented on the File plugin README[2]. For API 24-28 devices, we also do not need `READ/WRITE_EXTERNAL_STORAGE` permissions to write to the app's external data directory, which was a change that as introduced back in API 19. These permissions were only necessary to read/write in other external filesystem directories. Introducing MediaStore interface into the file plugin is likely not feasible either. The android docs acknowledges the challenges in rewriting File APIs to a MediaStore API and that is the whole reason why they introduced the FUSE concept for API 30+ devices.[1] > This restriction impacted app developers' ability to adapt as it required substantial code changes to rewrite File API access to the MediaProvider API. So what does it mean to say the external filesystem is not supported? 1. Usage of internal filesystem remains unchanged. 2. File plugin will no longer use or attempt to request permissions for external storage. 3. It will be theoretically possible to still use external filesystem url and read/write to it, if the app has the permission declared & granted by that permission grant would be an external factor. 4. It will also be theoretically possible to still use the external file system on API 30+ devices without any permission, provided they are not attempting to write or overwrite an existing file owned by another application. At the end of the day, due to the API 29 caveat, using the external storage via Filesystem API should be completely discouraged unless if the app only supports API 30+ devices. Lastly, because READ_MEDIA_* permissions will require justification starting August 2024, we also need to stop using the `READ_MEDIA` permissions by default in other plugins, including camera and media/media-capture. Which means our other plugins that depends on the file plugin shouldn't be affected by this proposal, once they have been updated in a way that they won't depend on these permissions. If the user requires external storage compatiblity, there are third-party community plugins available that interfaces with the MediaStore APIs and this should be the preferred approach: https://www.npmjs.com/search?q=ecosystem%3Acordova%20storage%20access%20framework Applying this proposal will allow us to greatly simplify the android plugin code as well as the documentation by removing all the caveats related to using external storage and we can make it clear that the file plugin should only be used for internal data storage. If we do decide to move forward with this proposal, I'd also recommend adding in deprecation notices and creating a blog post with the intent of removing external storage support. This should give developers ample time to migrate to a media store plugin if they haven't already done so. Please let me know what are your thoughts and whether if you support this direction for the file plugin. Cheers, Norman Breautek [1] https://source.android.com/docs/core/storage/scoped#using-scoped-storage-with-fuse [2] https://github.com/apache/cordova-plugin-file#androids-external-storage-quirks [3] https://github.com/apache/cordova-plugin-file/blob/265a932f3b5d11739fd08c0437477f441f6212c7/src/android/FileUtils.java#L539 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Cordova sqlite storage plugin issue
There is extensive documentation, including quirks for windows. https://www.npmjs.com/package/cordova-sqlite-storage Please read through that, and if you still have issues contact the author Chris Brody @purplecabbage risingj.com On Thu, Dec 7, 2017 at 7:00 AM, julio cesar sanchez wrote: > Sorry, this mail list is for talking about the Cordova project development, > not for support or to post issues while using it. > > As it looks like a plugin issue, report it on the plugin github repository. > > > > 2017-12-07 13:48 GMT+01:00 p madhu : > > > Hi, > > > > Good Afternoon !!. > > > > I am used VS15 and created windows 8.1 application. > > > > My requirements are developing a sapui5 application with offline support. > > > > current I amusing platforms are. > > > > *List:* > > cordova-plugin-barcodescanner 0.7.3 "BarcodeScanner" > > cordova-plugin-camera 3.0.0 "Camera" > > cordova-plugin-compat 1.2.0 "Compat" > > cordova-plugin-crosswalk-webview 2.3.0 "Crosswalk WebView Engine" > > cordova-plugin-device 1.1.7 "Device" > > cordova-plugin-network-information 1.3.4 "Network Information" > > cordova-plugin-whitelist 1.3.3 "Whitelist" > > cordova-plugin-winstore-jscompat 0.0.4 "Windows Compatibility" > > *cordova-sqlite-storage 2.1.2 "Cordova sqlite storage plugin"* > > > > In this List sqlite plugin is not working in windows 8.1 if I am using > > VS17 windows 10 application then it working please help us to fix this > > issue. > > > > Error msg : *OPEN database: PlantMaintenance.db FAILED, aborting any > > pending transactions* > > > > [image: Inline image 1] > > > > [image: Inline image 2] > > > > -- > > > > *Thanks & Regards,* > > > > *Madhu.P,* > > > > *Enstrapp** IT Solutions Pvt Ltd | Bangalore | Singapore* > > > > [image: > > https://docs.google.com/uc?id=0Bwigz61e829yNWJrT3ZnUF9UZ00&; > export=download] > > > > Address : #1556/57, 2nd Floor, 19th Main, 1st Sector, HSR Layout, > > Bangalore-560102 > > > > Mobile: +91 9071004580 <+91%2090710%2004580> > > > > Web: http://www.enstrapp.com/ > > >
Re: Cordova sqlite storage plugin issue
Sorry, this mail list is for talking about the Cordova project development, not for support or to post issues while using it. As it looks like a plugin issue, report it on the plugin github repository. 2017-12-07 13:48 GMT+01:00 p madhu : > Hi, > > Good Afternoon !!. > > I am used VS15 and created windows 8.1 application. > > My requirements are developing a sapui5 application with offline support. > > current I amusing platforms are. > > *List:* > cordova-plugin-barcodescanner 0.7.3 "BarcodeScanner" > cordova-plugin-camera 3.0.0 "Camera" > cordova-plugin-compat 1.2.0 "Compat" > cordova-plugin-crosswalk-webview 2.3.0 "Crosswalk WebView Engine" > cordova-plugin-device 1.1.7 "Device" > cordova-plugin-network-information 1.3.4 "Network Information" > cordova-plugin-whitelist 1.3.3 "Whitelist" > cordova-plugin-winstore-jscompat 0.0.4 "Windows Compatibility" > *cordova-sqlite-storage 2.1.2 "Cordova sqlite storage plugin"* > > In this List sqlite plugin is not working in windows 8.1 if I am using > VS17 windows 10 application then it working please help us to fix this > issue. > > Error msg : *OPEN database: PlantMaintenance.db FAILED, aborting any > pending transactions* > > [image: Inline image 1] > > [image: Inline image 2] > > -- > > *Thanks & Regards,* > > *Madhu.P,* > > *Enstrapp** IT Solutions Pvt Ltd | Bangalore | Singapore* > > [image: > https://docs.google.com/uc?id=0Bwigz61e829yNWJrT3ZnUF9UZ00&export=download] > > Address : #1556/57, 2nd Floor, 19th Main, 1st Sector, HSR Layout, > Bangalore-560102 > > Mobile: +91 9071004580 <+91%2090710%2004580> > > Web: http://www.enstrapp.com/ >
Cordova sqlite storage plugin issue
Hi, Good Afternoon !!. I am used VS15 and created windows 8.1 application. My requirements are developing a sapui5 application with offline support. current I amusing platforms are. *List:* cordova-plugin-barcodescanner 0.7.3 "BarcodeScanner" cordova-plugin-camera 3.0.0 "Camera" cordova-plugin-compat 1.2.0 "Compat" cordova-plugin-crosswalk-webview 2.3.0 "Crosswalk WebView Engine" cordova-plugin-device 1.1.7 "Device" cordova-plugin-network-information 1.3.4 "Network Information" cordova-plugin-whitelist 1.3.3 "Whitelist" cordova-plugin-winstore-jscompat 0.0.4 "Windows Compatibility" *cordova-sqlite-storage 2.1.2 "Cordova sqlite storage plugin"* In this List sqlite plugin is not working in windows 8.1 if I am using VS17 windows 10 application then it working please help us to fix this issue. Error msg : *OPEN database: PlantMaintenance.db FAILED, aborting any pending transactions* [image: Inline image 1] [image: Inline image 2] -- *Thanks & Regards,* *Madhu.P,* *Enstrapp** IT Solutions Pvt Ltd | Bangalore | Singapore* [image: https://docs.google.com/uc?id=0Bwigz61e829yNWJrT3ZnUF9UZ00&export=download] Address : #1556/57, 2nd Floor, 19th Main, 1st Sector, HSR Layout, Bangalore-560102 Mobile: +91 9071004580 <+91%2090710%2004580> Web: http://www.enstrapp.com/
[GitHub] cordova-plugin-file pull request: Update Cordova storage guide loc...
Github user mbrookes closed the pull request at: https://github.com/apache/cordova-plugin-file/pull/139 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-docs pull request: Rewrite of storage guide.
Github user asfgit closed the pull request at: https://github.com/apache/cordova-docs/pull/531 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-docs pull request: Rewrite of storage guide.
Github user nikhilkh commented on the pull request: https://github.com/apache/cordova-docs/pull/531#issuecomment-193912293 LGTM. Ready to merge? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-docs pull request: Rewrite of storage guide.
GitHub user TimBarham opened a pull request: https://github.com/apache/cordova-docs/pull/531 Rewrite of storage guide. * Provides more details about each of the options. * Provides examples. * Describes pros and cons of each approach. You can merge this pull request into a Git repository by running: $ git pull https://github.com/TimBarham/cordova-docs storage Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-docs/pull/531.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #531 commit 61a8db59e83835abf5b9b6cd7a35bb58e8fee181 Author: Tim Barham Date: 2016-02-29T08:13:08Z Rewrite of storage guide. * Provides more details about each of the options. * Provides examples. * Describes pros and cons of each approach. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-file pull request: Update Cordova storage guide loc...
GitHub user mbrookes opened a pull request: https://github.com/apache/cordova-plugin-file/pull/139 Update Cordova storage guide location. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mbrookes/cordova-plugin-file patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-file/pull/139.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #139 commit e7c8c18a4307f1e47fba4031de16d392e8a4b520 Author: Matt Brookes Date: 2015-10-16T09:43:46Z Update Cordova storage guide location. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Make internal storage default on Android
I strongly object you are using 6 spaces for tabs :-) Kidding aside I thought was already in master. You got bonus points for using On Tue, Aug 11, 2015 at 1:30 PM Simon MacDonald wrote: > So if there are no objections to: > > https://github.com/apache/cordova-plugin-file/pull/127 > > I will merge later today and tag a new version. > > > Simon Mac Donald > http://hi.im/simonmacdonald > > On Mon, Jul 27, 2015 at 5:18 PM, Simon MacDonald < > simon.macdon...@gmail.com> > wrote: > > > Pull Request sent: > > > > https://github.com/apache/cordova-plugin-file/pull/127 > > > > Simon Mac Donald > > http://hi.im/simonmacdonald > > > > On Mon, Jul 27, 2015 at 10:55 AM, Simon MacDonald < > > simon.macdon...@gmail.com> wrote: > > > >> kk, I think this has enough support and I'll end up putting together a > >> pull request today. > >> > >> > >> Simon Mac Donald > >> http://hi.im/simonmacdonald > >> > >> On Mon, Jul 27, 2015 at 10:40 AM, Andrew Grieve > >> wrote: > >> > >>> Ian and I made the switch to internal (via the preference). > >>> > >>> - I thought at one point the default app template set the preference to > >>> internal, so that new apps would get the better behaviour and existing > >>> apps > >>> would continue to work. I don't see this happening now though :( > >>> - The duplicate files/files, although oddly names, was just meant to > give > >>> the HTML5 FS root a directory that isolated from the rest of the app's > >>> internal storage (so that it doesn't conflict with files put there by > >>> plugins) > >>> > >>> Anyways, +1 for just switching this default and bumping the version. > >>> > >>> On Wed, Jul 22, 2015 at 9:27 PM, Carlos Santana > >>> wrote: > >>> > >>> > ding ding ding we have a winner , Are the blackberry guys still > around > >>> on > >>> > this mailing list by the way? > >>> > On Wed, Jul 22, 2015 at 10:00 PM Simon MacDonald < > >>> > simon.macdon...@gmail.com> > >>> > wrote: > >>> > > >>> > > As near as I can tell Windows use internal private storage as well. > >>> > > > >>> > > Simon Mac Donald > >>> > > http://hi.im/simonmacdonald > >>> > > > >>> > > On Wed, Jul 22, 2015 at 5:32 PM, Carlos Santana < > >>> csantan...@gmail.com> > >>> > > wrote: > >>> > > > >>> > > > I think cross platform web developers would expect all platforms > to > >>> > have > >>> > > > same default. What the default for windows? > >>> > > > > >>> > > > +1 make default internal at least will have iOS and android with > >>> same > >>> > > > expectations > >>> > > > > >>> > > > We need to change the Major number (sever) for the version, it > >>> feels > >>> > like > >>> > > > is changing an API > >>> > > > > >>> > > > I like the explicit even if it's not needed because the default > is > >>> > > > internal. But if they see it there it reminds them that internal > is > >>> > being > >>> > > > used. > >>> > > > On Wed, Jul 22, 2015 at 4:02 PM Darryl Pogue > >>> wrote: > >>> > > > > >>> > > > > +1 because saving to the SD Card has added problems with other > >>> apps > >>> > > (such > >>> > > > > as photo and music apps) picking up files that they shouldn't. > >>> > > > > > >>> > > > > Nothing more annoying than accidentally unleashing 200 logos > and > >>> > icons > >>> > > > into > >>> > > > > the photos app of unsuspecting users. > >>> > > > > > >>> > > > > On 22 July 2015 at 12:47, Simon MacDonald < > >>> simon.macdon...@gmail.com > >>> > >>> > > > >>> > > > > wrote: > >>> > > > > > >>> > > > > > *TL;DR Summary* > >>> > > > > > > >>> > > &g
Re: Make internal storage default on Android
So if there are no objections to: https://github.com/apache/cordova-plugin-file/pull/127 I will merge later today and tag a new version. Simon Mac Donald http://hi.im/simonmacdonald On Mon, Jul 27, 2015 at 5:18 PM, Simon MacDonald wrote: > Pull Request sent: > > https://github.com/apache/cordova-plugin-file/pull/127 > > Simon Mac Donald > http://hi.im/simonmacdonald > > On Mon, Jul 27, 2015 at 10:55 AM, Simon MacDonald < > simon.macdon...@gmail.com> wrote: > >> kk, I think this has enough support and I'll end up putting together a >> pull request today. >> >> >> Simon Mac Donald >> http://hi.im/simonmacdonald >> >> On Mon, Jul 27, 2015 at 10:40 AM, Andrew Grieve >> wrote: >> >>> Ian and I made the switch to internal (via the preference). >>> >>> - I thought at one point the default app template set the preference to >>> internal, so that new apps would get the better behaviour and existing >>> apps >>> would continue to work. I don't see this happening now though :( >>> - The duplicate files/files, although oddly names, was just meant to give >>> the HTML5 FS root a directory that isolated from the rest of the app's >>> internal storage (so that it doesn't conflict with files put there by >>> plugins) >>> >>> Anyways, +1 for just switching this default and bumping the version. >>> >>> On Wed, Jul 22, 2015 at 9:27 PM, Carlos Santana >>> wrote: >>> >>> > ding ding ding we have a winner , Are the blackberry guys still around >>> on >>> > this mailing list by the way? >>> > On Wed, Jul 22, 2015 at 10:00 PM Simon MacDonald < >>> > simon.macdon...@gmail.com> >>> > wrote: >>> > >>> > > As near as I can tell Windows use internal private storage as well. >>> > > >>> > > Simon Mac Donald >>> > > http://hi.im/simonmacdonald >>> > > >>> > > On Wed, Jul 22, 2015 at 5:32 PM, Carlos Santana < >>> csantan...@gmail.com> >>> > > wrote: >>> > > >>> > > > I think cross platform web developers would expect all platforms to >>> > have >>> > > > same default. What the default for windows? >>> > > > >>> > > > +1 make default internal at least will have iOS and android with >>> same >>> > > > expectations >>> > > > >>> > > > We need to change the Major number (sever) for the version, it >>> feels >>> > like >>> > > > is changing an API >>> > > > >>> > > > I like the explicit even if it's not needed because the default is >>> > > > internal. But if they see it there it reminds them that internal is >>> > being >>> > > > used. >>> > > > On Wed, Jul 22, 2015 at 4:02 PM Darryl Pogue >>> wrote: >>> > > > >>> > > > > +1 because saving to the SD Card has added problems with other >>> apps >>> > > (such >>> > > > > as photo and music apps) picking up files that they shouldn't. >>> > > > > >>> > > > > Nothing more annoying than accidentally unleashing 200 logos and >>> > icons >>> > > > into >>> > > > > the photos app of unsuspecting users. >>> > > > > >>> > > > > On 22 July 2015 at 12:47, Simon MacDonald < >>> simon.macdon...@gmail.com >>> >>> > > >>> > > > > wrote: >>> > > > > >>> > > > > > *TL;DR Summary* >>> > > > > > >>> > > > > > We should switch the default for the Cordova Android File >>> System to >>> > > be >>> > > > on >>> > > > > > internal storage, not the SD Card (or emulated SD card). >>> > > > > > >>> > > > > > >>> > > > > > *Long Version* >>> > > > > > >>> > > > > > Currently in Cordova Android when you use this code "window. >>> > > > > > requestFileSystem(PERSISTENT, 0, win, fail);" the root file >>> system >>> > > path >>> > > > > > that is returned is "/storage/emulated/0" i.e. "/sdcard". &
Re: Make internal storage default on Android
Pull Request sent: https://github.com/apache/cordova-plugin-file/pull/127 Simon Mac Donald http://hi.im/simonmacdonald On Mon, Jul 27, 2015 at 10:55 AM, Simon MacDonald wrote: > kk, I think this has enough support and I'll end up putting together a > pull request today. > > > Simon Mac Donald > http://hi.im/simonmacdonald > > On Mon, Jul 27, 2015 at 10:40 AM, Andrew Grieve > wrote: > >> Ian and I made the switch to internal (via the preference). >> >> - I thought at one point the default app template set the preference to >> internal, so that new apps would get the better behaviour and existing >> apps >> would continue to work. I don't see this happening now though :( >> - The duplicate files/files, although oddly names, was just meant to give >> the HTML5 FS root a directory that isolated from the rest of the app's >> internal storage (so that it doesn't conflict with files put there by >> plugins) >> >> Anyways, +1 for just switching this default and bumping the version. >> >> On Wed, Jul 22, 2015 at 9:27 PM, Carlos Santana >> wrote: >> >> > ding ding ding we have a winner , Are the blackberry guys still around >> on >> > this mailing list by the way? >> > On Wed, Jul 22, 2015 at 10:00 PM Simon MacDonald < >> > simon.macdon...@gmail.com> >> > wrote: >> > >> > > As near as I can tell Windows use internal private storage as well. >> > > >> > > Simon Mac Donald >> > > http://hi.im/simonmacdonald >> > > >> > > On Wed, Jul 22, 2015 at 5:32 PM, Carlos Santana > > >> > > wrote: >> > > >> > > > I think cross platform web developers would expect all platforms to >> > have >> > > > same default. What the default for windows? >> > > > >> > > > +1 make default internal at least will have iOS and android with >> same >> > > > expectations >> > > > >> > > > We need to change the Major number (sever) for the version, it feels >> > like >> > > > is changing an API >> > > > >> > > > I like the explicit even if it's not needed because the default is >> > > > internal. But if they see it there it reminds them that internal is >> > being >> > > > used. >> > > > On Wed, Jul 22, 2015 at 4:02 PM Darryl Pogue >> wrote: >> > > > >> > > > > +1 because saving to the SD Card has added problems with other >> apps >> > > (such >> > > > > as photo and music apps) picking up files that they shouldn't. >> > > > > >> > > > > Nothing more annoying than accidentally unleashing 200 logos and >> > icons >> > > > into >> > > > > the photos app of unsuspecting users. >> > > > > >> > > > > On 22 July 2015 at 12:47, Simon MacDonald < >> simon.macdon...@gmail.com >> >> > > >> > > > > wrote: >> > > > > >> > > > > > *TL;DR Summary* >> > > > > > >> > > > > > We should switch the default for the Cordova Android File >> System to >> > > be >> > > > on >> > > > > > internal storage, not the SD Card (or emulated SD card). >> > > > > > >> > > > > > >> > > > > > *Long Version* >> > > > > > >> > > > > > Currently in Cordova Android when you use this code "window. >> > > > > > requestFileSystem(PERSISTENT, 0, win, fail);" the root file >> system >> > > path >> > > > > > that is returned is "/storage/emulated/0" i.e. "/sdcard". >> > > > > > >> > > > > > Why you may ask? Because back in 2010 or so Bryce Curtis and I >> > argued >> > > > > that >> > > > > > we should use the external storage location because internal >> > storage >> > > > was >> > > > > > not very large on Android 2.x and we didn't want to have >> developers >> > > > > filling >> > > > > > up the devices limited internal storage. Joe Bowser argued >> against >> > it >> > > > > > because of issues with the SD Card on Android but was eventually >> >
Re: Make internal storage default on Android
kk, I think this has enough support and I'll end up putting together a pull request today. Simon Mac Donald http://hi.im/simonmacdonald On Mon, Jul 27, 2015 at 10:40 AM, Andrew Grieve wrote: > Ian and I made the switch to internal (via the preference). > > - I thought at one point the default app template set the preference to > internal, so that new apps would get the better behaviour and existing apps > would continue to work. I don't see this happening now though :( > - The duplicate files/files, although oddly names, was just meant to give > the HTML5 FS root a directory that isolated from the rest of the app's > internal storage (so that it doesn't conflict with files put there by > plugins) > > Anyways, +1 for just switching this default and bumping the version. > > On Wed, Jul 22, 2015 at 9:27 PM, Carlos Santana > wrote: > > > ding ding ding we have a winner , Are the blackberry guys still around on > > this mailing list by the way? > > On Wed, Jul 22, 2015 at 10:00 PM Simon MacDonald < > > simon.macdon...@gmail.com> > > wrote: > > > > > As near as I can tell Windows use internal private storage as well. > > > > > > Simon Mac Donald > > > http://hi.im/simonmacdonald > > > > > > On Wed, Jul 22, 2015 at 5:32 PM, Carlos Santana > > > wrote: > > > > > > > I think cross platform web developers would expect all platforms to > > have > > > > same default. What the default for windows? > > > > > > > > +1 make default internal at least will have iOS and android with same > > > > expectations > > > > > > > > We need to change the Major number (sever) for the version, it feels > > like > > > > is changing an API > > > > > > > > I like the explicit even if it's not needed because the default is > > > > internal. But if they see it there it reminds them that internal is > > being > > > > used. > > > > On Wed, Jul 22, 2015 at 4:02 PM Darryl Pogue > wrote: > > > > > > > > > +1 because saving to the SD Card has added problems with other apps > > > (such > > > > > as photo and music apps) picking up files that they shouldn't. > > > > > > > > > > Nothing more annoying than accidentally unleashing 200 logos and > > icons > > > > into > > > > > the photos app of unsuspecting users. > > > > > > > > > > On 22 July 2015 at 12:47, Simon MacDonald < > simon.macdon...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > *TL;DR Summary* > > > > > > > > > > > > We should switch the default for the Cordova Android File System > to > > > be > > > > on > > > > > > internal storage, not the SD Card (or emulated SD card). > > > > > > > > > > > > > > > > > > *Long Version* > > > > > > > > > > > > Currently in Cordova Android when you use this code "window. > > > > > > requestFileSystem(PERSISTENT, 0, win, fail);" the root file > system > > > path > > > > > > that is returned is "/storage/emulated/0" i.e. "/sdcard". > > > > > > > > > > > > Why you may ask? Because back in 2010 or so Bryce Curtis and I > > argued > > > > > that > > > > > > we should use the external storage location because internal > > storage > > > > was > > > > > > not very large on Android 2.x and we didn't want to have > developers > > > > > filling > > > > > > up the devices limited internal storage. Joe Bowser argued > against > > it > > > > > > because of issues with the SD Card on Android but was eventually > > out > > > > > voted. > > > > > > > > > > > > Now, I'm prepared to admit that Bryce was wrong (see what I did > > > > there?). > > > > > I > > > > > > feel that the default behaviour for > > > > "window.requestFileSystem(PERSISTENT, > > > > > > 0, win, fail);" should be to resolve to a location on internal > > > storage > > > > > that > > > > > > meets the following requirements: > > > > > > > > > > > > a) private t
Re: Make internal storage default on Android
Ian and I made the switch to internal (via the preference). - I thought at one point the default app template set the preference to internal, so that new apps would get the better behaviour and existing apps would continue to work. I don't see this happening now though :( - The duplicate files/files, although oddly names, was just meant to give the HTML5 FS root a directory that isolated from the rest of the app's internal storage (so that it doesn't conflict with files put there by plugins) Anyways, +1 for just switching this default and bumping the version. On Wed, Jul 22, 2015 at 9:27 PM, Carlos Santana wrote: > ding ding ding we have a winner , Are the blackberry guys still around on > this mailing list by the way? > On Wed, Jul 22, 2015 at 10:00 PM Simon MacDonald < > simon.macdon...@gmail.com> > wrote: > > > As near as I can tell Windows use internal private storage as well. > > > > Simon Mac Donald > > http://hi.im/simonmacdonald > > > > On Wed, Jul 22, 2015 at 5:32 PM, Carlos Santana > > wrote: > > > > > I think cross platform web developers would expect all platforms to > have > > > same default. What the default for windows? > > > > > > +1 make default internal at least will have iOS and android with same > > > expectations > > > > > > We need to change the Major number (sever) for the version, it feels > like > > > is changing an API > > > > > > I like the explicit even if it's not needed because the default is > > > internal. But if they see it there it reminds them that internal is > being > > > used. > > > On Wed, Jul 22, 2015 at 4:02 PM Darryl Pogue wrote: > > > > > > > +1 because saving to the SD Card has added problems with other apps > > (such > > > > as photo and music apps) picking up files that they shouldn't. > > > > > > > > Nothing more annoying than accidentally unleashing 200 logos and > icons > > > into > > > > the photos app of unsuspecting users. > > > > > > > > On 22 July 2015 at 12:47, Simon MacDonald > > > > > wrote: > > > > > > > > > *TL;DR Summary* > > > > > > > > > > We should switch the default for the Cordova Android File System to > > be > > > on > > > > > internal storage, not the SD Card (or emulated SD card). > > > > > > > > > > > > > > > *Long Version* > > > > > > > > > > Currently in Cordova Android when you use this code "window. > > > > > requestFileSystem(PERSISTENT, 0, win, fail);" the root file system > > path > > > > > that is returned is "/storage/emulated/0" i.e. "/sdcard". > > > > > > > > > > Why you may ask? Because back in 2010 or so Bryce Curtis and I > argued > > > > that > > > > > we should use the external storage location because internal > storage > > > was > > > > > not very large on Android 2.x and we didn't want to have developers > > > > filling > > > > > up the devices limited internal storage. Joe Bowser argued against > it > > > > > because of issues with the SD Card on Android but was eventually > out > > > > voted. > > > > > > > > > > Now, I'm prepared to admit that Bryce was wrong (see what I did > > > there?). > > > > I > > > > > feel that the default behaviour for > > > "window.requestFileSystem(PERSISTENT, > > > > > 0, win, fail);" should be to resolve to a location on internal > > storage > > > > that > > > > > meets the following requirements: > > > > > > > > > > a) private to the application > > > > > > > > > > b) removed when the application is uninstalled > > > > > > > > > > c) lines up with what we have on iOS and WP > > > > > > > > > > In fact you can get this behaviour right now but setting the > > following > > > > > preference in config.xml: > > > > > > > > > > /> > > > > > > > > > > This gets you a root file path of "/data/data/ > > > > package>/files/files/". The double "files" is an issue but we can > > > > probably > > > > > ignore it for now. > > > > > > > > > > If a user wants the old behaviour they only need to make the > > > preference: > > > > > > > > > > > value="Compatibility" > > > /> > > > > > > > > > > and the original behaviour will be retained. > > > > > > > > > > What I'm advocating for is to make internal storage the default > > > behaviour > > > > > for Cordova Android. > > > > > > > > > > > > > > > *Code Changes* > > > > > > > > > > I've already taken a brief look into this and I feel the change is > > > > > extremely minor. We need only change the default return value from > > > > > "compatibility" to "internal" at line 156 of FileUtils.java ( > > > > > https://github > > > > > > > > > > > > > > > .com/apache/cordova-plugin-file/blob/master/src/android/FileUtils.java#L156 > > > > > ). > > > > > > > > > > If we wanted to make the change explicit to the user we could > change > > > > > plugin. > > > > > xml to add the preference to config.xml as well. > > > > > > > > > > Thoughts, comments, applause? > > > > > Simon Mac Donald > > > > > http://hi.im/simonmacdonald > > > > > > > > > > > > > > >
Re: Make internal storage default on Android
ding ding ding we have a winner , Are the blackberry guys still around on this mailing list by the way? On Wed, Jul 22, 2015 at 10:00 PM Simon MacDonald wrote: > As near as I can tell Windows use internal private storage as well. > > Simon Mac Donald > http://hi.im/simonmacdonald > > On Wed, Jul 22, 2015 at 5:32 PM, Carlos Santana > wrote: > > > I think cross platform web developers would expect all platforms to have > > same default. What the default for windows? > > > > +1 make default internal at least will have iOS and android with same > > expectations > > > > We need to change the Major number (sever) for the version, it feels like > > is changing an API > > > > I like the explicit even if it's not needed because the default is > > internal. But if they see it there it reminds them that internal is being > > used. > > On Wed, Jul 22, 2015 at 4:02 PM Darryl Pogue wrote: > > > > > +1 because saving to the SD Card has added problems with other apps > (such > > > as photo and music apps) picking up files that they shouldn't. > > > > > > Nothing more annoying than accidentally unleashing 200 logos and icons > > into > > > the photos app of unsuspecting users. > > > > > > On 22 July 2015 at 12:47, Simon MacDonald > > > wrote: > > > > > > > *TL;DR Summary* > > > > > > > > We should switch the default for the Cordova Android File System to > be > > on > > > > internal storage, not the SD Card (or emulated SD card). > > > > > > > > > > > > *Long Version* > > > > > > > > Currently in Cordova Android when you use this code "window. > > > > requestFileSystem(PERSISTENT, 0, win, fail);" the root file system > path > > > > that is returned is "/storage/emulated/0" i.e. "/sdcard". > > > > > > > > Why you may ask? Because back in 2010 or so Bryce Curtis and I argued > > > that > > > > we should use the external storage location because internal storage > > was > > > > not very large on Android 2.x and we didn't want to have developers > > > filling > > > > up the devices limited internal storage. Joe Bowser argued against it > > > > because of issues with the SD Card on Android but was eventually out > > > voted. > > > > > > > > Now, I'm prepared to admit that Bryce was wrong (see what I did > > there?). > > > I > > > > feel that the default behaviour for > > "window.requestFileSystem(PERSISTENT, > > > > 0, win, fail);" should be to resolve to a location on internal > storage > > > that > > > > meets the following requirements: > > > > > > > > a) private to the application > > > > > > > > b) removed when the application is uninstalled > > > > > > > > c) lines up with what we have on iOS and WP > > > > > > > > In fact you can get this behaviour right now but setting the > following > > > > preference in config.xml: > > > > > > > > > > > > > > > > This gets you a root file path of "/data/data/ > > > package>/files/files/". The double "files" is an issue but we can > > > probably > > > > ignore it for now. > > > > > > > > If a user wants the old behaviour they only need to make the > > preference: > > > > > > > > value="Compatibility" > > /> > > > > > > > > and the original behaviour will be retained. > > > > > > > > What I'm advocating for is to make internal storage the default > > behaviour > > > > for Cordova Android. > > > > > > > > > > > > *Code Changes* > > > > > > > > I've already taken a brief look into this and I feel the change is > > > > extremely minor. We need only change the default return value from > > > > "compatibility" to "internal" at line 156 of FileUtils.java ( > > > > https://github > > > > > > > > > > .com/apache/cordova-plugin-file/blob/master/src/android/FileUtils.java#L156 > > > > ). > > > > > > > > If we wanted to make the change explicit to the user we could change > > > > plugin. > > > > xml to add the preference to config.xml as well. > > > > > > > > Thoughts, comments, applause? > > > > Simon Mac Donald > > > > http://hi.im/simonmacdonald > > > > > > > > > >
Re: Make internal storage default on Android
As near as I can tell Windows use internal private storage as well. Simon Mac Donald http://hi.im/simonmacdonald On Wed, Jul 22, 2015 at 5:32 PM, Carlos Santana wrote: > I think cross platform web developers would expect all platforms to have > same default. What the default for windows? > > +1 make default internal at least will have iOS and android with same > expectations > > We need to change the Major number (sever) for the version, it feels like > is changing an API > > I like the explicit even if it's not needed because the default is > internal. But if they see it there it reminds them that internal is being > used. > On Wed, Jul 22, 2015 at 4:02 PM Darryl Pogue wrote: > > > +1 because saving to the SD Card has added problems with other apps (such > > as photo and music apps) picking up files that they shouldn't. > > > > Nothing more annoying than accidentally unleashing 200 logos and icons > into > > the photos app of unsuspecting users. > > > > On 22 July 2015 at 12:47, Simon MacDonald > > wrote: > > > > > *TL;DR Summary* > > > > > > We should switch the default for the Cordova Android File System to be > on > > > internal storage, not the SD Card (or emulated SD card). > > > > > > > > > *Long Version* > > > > > > Currently in Cordova Android when you use this code "window. > > > requestFileSystem(PERSISTENT, 0, win, fail);" the root file system path > > > that is returned is "/storage/emulated/0" i.e. "/sdcard". > > > > > > Why you may ask? Because back in 2010 or so Bryce Curtis and I argued > > that > > > we should use the external storage location because internal storage > was > > > not very large on Android 2.x and we didn't want to have developers > > filling > > > up the devices limited internal storage. Joe Bowser argued against it > > > because of issues with the SD Card on Android but was eventually out > > voted. > > > > > > Now, I'm prepared to admit that Bryce was wrong (see what I did > there?). > > I > > > feel that the default behaviour for > "window.requestFileSystem(PERSISTENT, > > > 0, win, fail);" should be to resolve to a location on internal storage > > that > > > meets the following requirements: > > > > > > a) private to the application > > > > > > b) removed when the application is uninstalled > > > > > > c) lines up with what we have on iOS and WP > > > > > > In fact you can get this behaviour right now but setting the following > > > preference in config.xml: > > > > > > > > > > > > This gets you a root file path of "/data/data/ > > package>/files/files/". The double "files" is an issue but we can > > probably > > > ignore it for now. > > > > > > If a user wants the old behaviour they only need to make the > preference: > > > > > > /> > > > > > > and the original behaviour will be retained. > > > > > > What I'm advocating for is to make internal storage the default > behaviour > > > for Cordova Android. > > > > > > > > > *Code Changes* > > > > > > I've already taken a brief look into this and I feel the change is > > > extremely minor. We need only change the default return value from > > > "compatibility" to "internal" at line 156 of FileUtils.java ( > > > https://github > > > > > > .com/apache/cordova-plugin-file/blob/master/src/android/FileUtils.java#L156 > > > ). > > > > > > If we wanted to make the change explicit to the user we could change > > > plugin. > > > xml to add the preference to config.xml as well. > > > > > > Thoughts, comments, applause? > > > Simon Mac Donald > > > http://hi.im/simonmacdonald > > > > > >
Re: Make internal storage default on Android
That's what I meant the plugin cordova-plugin-file@2.1.0 bump up to 3.x On Wed, Jul 22, 2015 at 5:38 PM Joe Bowser wrote: > This would change the major version of the plugin, not the platform, since > this is a plugin API change and isn't actually a core-platform change. > > On Wed, Jul 22, 2015 at 2:33 PM Carlos Santana > wrote: > > > I think cross platform web developers would expect all platforms to have > > same default. What the default for windows? > > > > +1 make default internal at least will have iOS and android with same > > expectations > > > > We need to change the Major number (sever) for the version, it feels like > > is changing an API > > > > I like the explicit even if it's not needed because the default is > > internal. But if they see it there it reminds them that internal is being > > used. > > On Wed, Jul 22, 2015 at 4:02 PM Darryl Pogue wrote: > > > > > +1 because saving to the SD Card has added problems with other apps > (such > > > as photo and music apps) picking up files that they shouldn't. > > > > > > Nothing more annoying than accidentally unleashing 200 logos and icons > > into > > > the photos app of unsuspecting users. > > > > > > On 22 July 2015 at 12:47, Simon MacDonald > > > wrote: > > > > > > > *TL;DR Summary* > > > > > > > > We should switch the default for the Cordova Android File System to > be > > on > > > > internal storage, not the SD Card (or emulated SD card). > > > > > > > > > > > > *Long Version* > > > > > > > > Currently in Cordova Android when you use this code "window. > > > > requestFileSystem(PERSISTENT, 0, win, fail);" the root file system > path > > > > that is returned is "/storage/emulated/0" i.e. "/sdcard". > > > > > > > > Why you may ask? Because back in 2010 or so Bryce Curtis and I argued > > > that > > > > we should use the external storage location because internal storage > > was > > > > not very large on Android 2.x and we didn't want to have developers > > > filling > > > > up the devices limited internal storage. Joe Bowser argued against it > > > > because of issues with the SD Card on Android but was eventually out > > > voted. > > > > > > > > Now, I'm prepared to admit that Bryce was wrong (see what I did > > there?). > > > I > > > > feel that the default behaviour for > > "window.requestFileSystem(PERSISTENT, > > > > 0, win, fail);" should be to resolve to a location on internal > storage > > > that > > > > meets the following requirements: > > > > > > > > a) private to the application > > > > > > > > b) removed when the application is uninstalled > > > > > > > > c) lines up with what we have on iOS and WP > > > > > > > > In fact you can get this behaviour right now but setting the > following > > > > preference in config.xml: > > > > > > > > > > > > > > > > This gets you a root file path of "/data/data/ > > > package>/files/files/". The double "files" is an issue but we can > > > probably > > > > ignore it for now. > > > > > > > > If a user wants the old behaviour they only need to make the > > preference: > > > > > > > > value="Compatibility" > > /> > > > > > > > > and the original behaviour will be retained. > > > > > > > > What I'm advocating for is to make internal storage the default > > behaviour > > > > for Cordova Android. > > > > > > > > > > > > *Code Changes* > > > > > > > > I've already taken a brief look into this and I feel the change is > > > > extremely minor. We need only change the default return value from > > > > "compatibility" to "internal" at line 156 of FileUtils.java ( > > > > https://github > > > > > > > > > > .com/apache/cordova-plugin-file/blob/master/src/android/FileUtils.java#L156 > > > > ). > > > > > > > > If we wanted to make the change explicit to the user we could change > > > > plugin. > > > > xml to add the preference to config.xml as well. > > > > > > > > Thoughts, comments, applause? > > > > Simon Mac Donald > > > > http://hi.im/simonmacdonald > > > > > > > > > >
Re: Make internal storage default on Android
This would change the major version of the plugin, not the platform, since this is a plugin API change and isn't actually a core-platform change. On Wed, Jul 22, 2015 at 2:33 PM Carlos Santana wrote: > I think cross platform web developers would expect all platforms to have > same default. What the default for windows? > > +1 make default internal at least will have iOS and android with same > expectations > > We need to change the Major number (sever) for the version, it feels like > is changing an API > > I like the explicit even if it's not needed because the default is > internal. But if they see it there it reminds them that internal is being > used. > On Wed, Jul 22, 2015 at 4:02 PM Darryl Pogue wrote: > > > +1 because saving to the SD Card has added problems with other apps (such > > as photo and music apps) picking up files that they shouldn't. > > > > Nothing more annoying than accidentally unleashing 200 logos and icons > into > > the photos app of unsuspecting users. > > > > On 22 July 2015 at 12:47, Simon MacDonald > > wrote: > > > > > *TL;DR Summary* > > > > > > We should switch the default for the Cordova Android File System to be > on > > > internal storage, not the SD Card (or emulated SD card). > > > > > > > > > *Long Version* > > > > > > Currently in Cordova Android when you use this code "window. > > > requestFileSystem(PERSISTENT, 0, win, fail);" the root file system path > > > that is returned is "/storage/emulated/0" i.e. "/sdcard". > > > > > > Why you may ask? Because back in 2010 or so Bryce Curtis and I argued > > that > > > we should use the external storage location because internal storage > was > > > not very large on Android 2.x and we didn't want to have developers > > filling > > > up the devices limited internal storage. Joe Bowser argued against it > > > because of issues with the SD Card on Android but was eventually out > > voted. > > > > > > Now, I'm prepared to admit that Bryce was wrong (see what I did > there?). > > I > > > feel that the default behaviour for > "window.requestFileSystem(PERSISTENT, > > > 0, win, fail);" should be to resolve to a location on internal storage > > that > > > meets the following requirements: > > > > > > a) private to the application > > > > > > b) removed when the application is uninstalled > > > > > > c) lines up with what we have on iOS and WP > > > > > > In fact you can get this behaviour right now but setting the following > > > preference in config.xml: > > > > > > > > > > > > This gets you a root file path of "/data/data/ > > package>/files/files/". The double "files" is an issue but we can > > probably > > > ignore it for now. > > > > > > If a user wants the old behaviour they only need to make the > preference: > > > > > > /> > > > > > > and the original behaviour will be retained. > > > > > > What I'm advocating for is to make internal storage the default > behaviour > > > for Cordova Android. > > > > > > > > > *Code Changes* > > > > > > I've already taken a brief look into this and I feel the change is > > > extremely minor. We need only change the default return value from > > > "compatibility" to "internal" at line 156 of FileUtils.java ( > > > https://github > > > > > > .com/apache/cordova-plugin-file/blob/master/src/android/FileUtils.java#L156 > > > ). > > > > > > If we wanted to make the change explicit to the user we could change > > > plugin. > > > xml to add the preference to config.xml as well. > > > > > > Thoughts, comments, applause? > > > Simon Mac Donald > > > http://hi.im/simonmacdonald > > > > > >
Re: Make internal storage default on Android
I think cross platform web developers would expect all platforms to have same default. What the default for windows? +1 make default internal at least will have iOS and android with same expectations We need to change the Major number (sever) for the version, it feels like is changing an API I like the explicit even if it's not needed because the default is internal. But if they see it there it reminds them that internal is being used. On Wed, Jul 22, 2015 at 4:02 PM Darryl Pogue wrote: > +1 because saving to the SD Card has added problems with other apps (such > as photo and music apps) picking up files that they shouldn't. > > Nothing more annoying than accidentally unleashing 200 logos and icons into > the photos app of unsuspecting users. > > On 22 July 2015 at 12:47, Simon MacDonald > wrote: > > > *TL;DR Summary* > > > > We should switch the default for the Cordova Android File System to be on > > internal storage, not the SD Card (or emulated SD card). > > > > > > *Long Version* > > > > Currently in Cordova Android when you use this code "window. > > requestFileSystem(PERSISTENT, 0, win, fail);" the root file system path > > that is returned is "/storage/emulated/0" i.e. "/sdcard". > > > > Why you may ask? Because back in 2010 or so Bryce Curtis and I argued > that > > we should use the external storage location because internal storage was > > not very large on Android 2.x and we didn't want to have developers > filling > > up the devices limited internal storage. Joe Bowser argued against it > > because of issues with the SD Card on Android but was eventually out > voted. > > > > Now, I'm prepared to admit that Bryce was wrong (see what I did there?). > I > > feel that the default behaviour for "window.requestFileSystem(PERSISTENT, > > 0, win, fail);" should be to resolve to a location on internal storage > that > > meets the following requirements: > > > > a) private to the application > > > > b) removed when the application is uninstalled > > > > c) lines up with what we have on iOS and WP > > > > In fact you can get this behaviour right now but setting the following > > preference in config.xml: > > > > > > > > This gets you a root file path of "/data/data/ > package>/files/files/". The double "files" is an issue but we can > probably > > ignore it for now. > > > > If a user wants the old behaviour they only need to make the preference: > > > > > > > > and the original behaviour will be retained. > > > > What I'm advocating for is to make internal storage the default behaviour > > for Cordova Android. > > > > > > *Code Changes* > > > > I've already taken a brief look into this and I feel the change is > > extremely minor. We need only change the default return value from > > "compatibility" to "internal" at line 156 of FileUtils.java ( > > https://github > > > .com/apache/cordova-plugin-file/blob/master/src/android/FileUtils.java#L156 > > ). > > > > If we wanted to make the change explicit to the user we could change > > plugin. > > xml to add the preference to config.xml as well. > > > > Thoughts, comments, applause? > > Simon Mac Donald > > http://hi.im/simonmacdonald > > >
Re: Make internal storage default on Android
+1 because saving to the SD Card has added problems with other apps (such as photo and music apps) picking up files that they shouldn't. Nothing more annoying than accidentally unleashing 200 logos and icons into the photos app of unsuspecting users. On 22 July 2015 at 12:47, Simon MacDonald wrote: > *TL;DR Summary* > > We should switch the default for the Cordova Android File System to be on > internal storage, not the SD Card (or emulated SD card). > > > *Long Version* > > Currently in Cordova Android when you use this code "window. > requestFileSystem(PERSISTENT, 0, win, fail);" the root file system path > that is returned is "/storage/emulated/0" i.e. "/sdcard". > > Why you may ask? Because back in 2010 or so Bryce Curtis and I argued that > we should use the external storage location because internal storage was > not very large on Android 2.x and we didn't want to have developers filling > up the devices limited internal storage. Joe Bowser argued against it > because of issues with the SD Card on Android but was eventually out voted. > > Now, I'm prepared to admit that Bryce was wrong (see what I did there?). I > feel that the default behaviour for "window.requestFileSystem(PERSISTENT, > 0, win, fail);" should be to resolve to a location on internal storage that > meets the following requirements: > > a) private to the application > > b) removed when the application is uninstalled > > c) lines up with what we have on iOS and WP > > In fact you can get this behaviour right now but setting the following > preference in config.xml: > > > > This gets you a root file path of "/data/data/ package>/files/files/". The double "files" is an issue but we can probably > ignore it for now. > > If a user wants the old behaviour they only need to make the preference: > > > > and the original behaviour will be retained. > > What I'm advocating for is to make internal storage the default behaviour > for Cordova Android. > > > *Code Changes* > > I've already taken a brief look into this and I feel the change is > extremely minor. We need only change the default return value from > "compatibility" to "internal" at line 156 of FileUtils.java ( > https://github > .com/apache/cordova-plugin-file/blob/master/src/android/FileUtils.java#L156 > ). > > If we wanted to make the change explicit to the user we could change > plugin. > xml to add the preference to config.xml as well. > > Thoughts, comments, applause? > Simon Mac Donald > http://hi.im/simonmacdonald >
Make internal storage default on Android
*TL;DR Summary* We should switch the default for the Cordova Android File System to be on internal storage, not the SD Card (or emulated SD card). *Long Version* Currently in Cordova Android when you use this code "window. requestFileSystem(PERSISTENT, 0, win, fail);" the root file system path that is returned is "/storage/emulated/0" i.e. "/sdcard". Why you may ask? Because back in 2010 or so Bryce Curtis and I argued that we should use the external storage location because internal storage was not very large on Android 2.x and we didn't want to have developers filling up the devices limited internal storage. Joe Bowser argued against it because of issues with the SD Card on Android but was eventually out voted. Now, I'm prepared to admit that Bryce was wrong (see what I did there?). I feel that the default behaviour for "window.requestFileSystem(PERSISTENT, 0, win, fail);" should be to resolve to a location on internal storage that meets the following requirements: a) private to the application b) removed when the application is uninstalled c) lines up with what we have on iOS and WP In fact you can get this behaviour right now but setting the following preference in config.xml: This gets you a root file path of "/data/data//files/files/". The double "files" is an issue but we can probably ignore it for now. If a user wants the old behaviour they only need to make the preference: and the original behaviour will be retained. What I'm advocating for is to make internal storage the default behaviour for Cordova Android. *Code Changes* I've already taken a brief look into this and I feel the change is extremely minor. We need only change the default return value from "compatibility" to "internal" at line 156 of FileUtils.java (https://github .com/apache/cordova-plugin-file/blob/master/src/android/FileUtils.java#L156 ). If we wanted to make the change explicit to the user we could change plugin. xml to add the preference to config.xml as well. Thoughts, comments, applause? Simon Mac Donald http://hi.im/simonmacdonald
Re: storage
I hope to fix some issues soon! There are some important issues but I do use the shim in our project at work and it does work pretty well (with the latest fixes). I use it on iOS 7, Android 2.3 with some manual fixes but I'm not really sure they are needed. Android 4.1 and a 4.3 device, I do have some custom things in my app to actually force the use of the shim because those versions of Android also have indexedDB but some older spec I believe. Maybe the shim should overwrite indexeddb in that case but it might break things so not really sure.. It definitely needs some more work on that part! Also, the above devices are from my work. I only have a Windows Phone 8 device and a Surface Pro tablet, but IE supports indexedDB on wp8 and windows 8(.1) so no shim needed here (not tested). I do own a Android tablet with Android 3 on it somewhere but not sure where it is 😊 So the only place I can test all devices is on my work. Maybe I take a device with me for some testing. I have some more fixes, but I don't have tests for them yet. Did a lot of manual testing but I want some unit tests for them… So yeah, the project is still going but not as fast as I want 😈 Verzonden met Windows Mail Van: Axel Nennker Verzonden: ‎zaterdag‎ ‎18‎ ‎januari‎ ‎2014 ‎14‎:‎41 Aan: Dick Van den Brink, Parashuram Narasimhan (MS OPEN TECH) CC: dev@cordova.apache.org Any news on the indexeddb plugin project? I saw that some issues were closed some days ago. https://github.com/axemclion/indexeddbshim/issues?page=1&state=open Although the list still locks long with some critical issues. cheers Axel 2014/1/3 Dick Van den Brink > I use this shim and use it for iOS and android and after patching it works > great! > > The latest build is completely broken without patches, see my pull reqs on > github and some others. > > I'm all for using this as a starting point but it has been broken for > almost 4 months now without manually applying patches. (I'm talking about > iterating over indexes and cursor.Update being broken). > > If we want to use this, we should never have such a situation again. > > > > Verzonden met Windows Mail > > > > > > Van: Parashuram Narasimhan (MS OPEN TECH) > Verzonden: vrijdag 3 januari 2014 20:27 > Aan: dev@cordova.apache.org > > > > > > I gave IndexedDB shim over websql a shot, but it is not 100% compliant and > has some bugs - http://github.com/axemclion/indexeddbshim. I am working > on fixing the bugs, but to the level it works, I tested and it works with > Cordova well !! > Could we use that as a starting point ? > > -Original Message- > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of > Brian LeRoux > Sent: Friday, January 3, 2014 10:37 AM > To: dev@cordova.apache.org > Subject: Re: storage > > an indexeddb plugin would be a rad thing for the community to create and > maintain ;) > > in seriousness: the file api is probably what you're really looking for if > you want to read/write json on phones (you could even use it as a basis for > an JS only plugin that polyfills indexeddb. > > > On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker > wrote: > > > Hi, > > > > I was wondering about the cross-platform experience of Storage. > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.htm > > l#Storage > > > > It seems that there is no cross platform solution in Cordova, right? > > > > There are indexeddb shims that implement indexeddb on "all" platforms. > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > My team is currently facing the problem that we implemented a project > > with Cordova's websql on Android and IOS but it is not supported on > FirefoxOS. > > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > > > I think the text on cross platform storage in > > cordova_storage_storage.mdis not really helping developers. > > > > Advice? > > > > Thanks > > Axel > > >
Re: storage
Any news on the indexeddb plugin project? I saw that some issues were closed some days ago. https://github.com/axemclion/indexeddbshim/issues?page=1&state=open Although the list still locks long with some critical issues. cheers Axel 2014/1/3 Dick Van den Brink > I use this shim and use it for iOS and android and after patching it works > great! > > The latest build is completely broken without patches, see my pull reqs on > github and some others. > > I'm all for using this as a starting point but it has been broken for > almost 4 months now without manually applying patches. (I'm talking about > iterating over indexes and cursor.Update being broken). > > If we want to use this, we should never have such a situation again. > > > > Verzonden met Windows Mail > > > > > > Van: Parashuram Narasimhan (MS OPEN TECH) > Verzonden: vrijdag 3 januari 2014 20:27 > Aan: dev@cordova.apache.org > > > > > > I gave IndexedDB shim over websql a shot, but it is not 100% compliant and > has some bugs - http://github.com/axemclion/indexeddbshim. I am working > on fixing the bugs, but to the level it works, I tested and it works with > Cordova well !! > Could we use that as a starting point ? > > -Original Message- > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of > Brian LeRoux > Sent: Friday, January 3, 2014 10:37 AM > To: dev@cordova.apache.org > Subject: Re: storage > > an indexeddb plugin would be a rad thing for the community to create and > maintain ;) > > in seriousness: the file api is probably what you're really looking for if > you want to read/write json on phones (you could even use it as a basis for > an JS only plugin that polyfills indexeddb. > > > On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker > wrote: > > > Hi, > > > > I was wondering about the cross-platform experience of Storage. > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.htm > > l#Storage > > > > It seems that there is no cross platform solution in Cordova, right? > > > > There are indexeddb shims that implement indexeddb on "all" platforms. > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > My team is currently facing the problem that we implemented a project > > with Cordova's websql on Android and IOS but it is not supported on > FirefoxOS. > > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > > > I think the text on cross platform storage in > > cordova_storage_storage.mdis not really helping developers. > > > > Advice? > > > > Thanks > > Axel > > >
Re: storage
The key win I think is simply having a consistent implementation. CanIUse reports that indexedDB is available on Android 4.4+ and every other of our supported platforms, with a very notable exception of Mobile Safari. Ultimately this is a plugin, and Parashuram is working on it, so I am sure he would appreciate help. To echo what Brian says, it is all currently possible, maybe just not as consistently as some would like, but ultimately Cordova is really just the bridge, the tools, and the container, so I don't think it is fair to call it incomplete ... and pull requests are always welcome. @purplecabbage risingj.com On Mon, Jan 6, 2014 at 9:43 AM, Brian LeRoux wrote: > I'm trying to not sound like a broken record but I still do not hear an > actual use cases that is unique to IndexedDB. I understand that you like > it, I do too, and the browsers will support it eventually in Cordova so > effort spent there is not really a demonstrable win (to me) unless I hear a > use case for it not currently possible (if not more appropriate) for > reading and writing plain old text, JSON, or Blobs. > > IndexedDB is a structured key/value store. Files have names (keys) and > values. IndexedDB provides a non blocking async read/write. So does our > File API. Transactional support is not built into our File API so that > might be something you'd want if reads/writes could conflict. > > > On Sun, Jan 5, 2014 at 10:02 AM, venkata kiran surapaneni < > svkir...@gmail.com> wrote: > > > +1 to Axel. > > > > Cordova is incomplete without providing support for indexeddb and > websql. I > > think most of the apps require local database. There are some frameworks > > which provide different level of implementations. But those > implementations > > are usually designed for browsers and then enhanced for mobile support > and > > so has several limitations like not working when the application is > > switched to background. > > > > Cordova should have a uniform wrapper on top of indexeddb and websql to > > actually allow developers to create a cross platform apps, which is what > > Cordova promises. > > >
Re: storage
I'm trying to not sound like a broken record but I still do not hear an actual use cases that is unique to IndexedDB. I understand that you like it, I do too, and the browsers will support it eventually in Cordova so effort spent there is not really a demonstrable win (to me) unless I hear a use case for it not currently possible (if not more appropriate) for reading and writing plain old text, JSON, or Blobs. IndexedDB is a structured key/value store. Files have names (keys) and values. IndexedDB provides a non blocking async read/write. So does our File API. Transactional support is not built into our File API so that might be something you'd want if reads/writes could conflict. On Sun, Jan 5, 2014 at 10:02 AM, venkata kiran surapaneni < svkir...@gmail.com> wrote: > +1 to Axel. > > Cordova is incomplete without providing support for indexeddb and websql. I > think most of the apps require local database. There are some frameworks > which provide different level of implementations. But those implementations > are usually designed for browsers and then enhanced for mobile support and > so has several limitations like not working when the application is > switched to background. > > Cordova should have a uniform wrapper on top of indexeddb and websql to > actually allow developers to create a cross platform apps, which is what > Cordova promises. >
Re: storage
+1 to Axel. Cordova is incomplete without providing support for indexeddb and websql. I think most of the apps require local database. There are some frameworks which provide different level of implementations. But those implementations are usually designed for browsers and then enhanced for mobile support and so has several limitations like not working when the application is switched to background. Cordova should have a uniform wrapper on top of indexeddb and websql to actually allow developers to create a cross platform apps, which is what Cordova promises.
Re: storage
Thanks for helping with the current project. But I am still not convinced. The current implementation stuffs the images (data urls) into the websql db. So we have no extra handling for them. The images are data like the other fields too. I do not want to implement a database using file because I think that databases are there for a reason. Regardless of the actual problem with my project: I still think that Cordova would profit big time from an indexeddb plugin that provides a database API for all platforms. -Axel 2014/1/5 Brian LeRoux > Ok, thats easier for me to reason about! (Easier to explain your problem > space in the form of a use case rather than presenting us with the solution > you arrived at b/c we do not have your context.) > > Anyhow, given you are reading/writing blobs (images) I'd say the File API > is absolutely the way to go. Unfortunately, FxOS Honestly, I'd write a > wrapper specific to your case and swap an adapter for the platform you are > running on. (Something like Lawnchair but modernized.) > > Another path would be to implement our File API on top of one of the FxOS > options. That would be a pull request we would welcome and maintain in > core. > > > > > On Sat, Jan 4, 2014 at 3:34 PM, Axel Nennker > wrote: > > > Hi Brian, > > we are building an applications that imports some data and stores that > data > > in a database. > > Each imported data is between 2k and 50k but can be bigger. It is a set > of > > images in different sizes and resolutions and some text, integer fields. > > We expect the total amount of data to exceed the limits of local storage. > > We display the images and other fields based/filtered on some of fields > > chosen by the user. > > We decided to go for websql because it is supported on IOS and Android. > Now > > we want to support FirefoxOS and have to face the fact that we have to > > invest many days to switch to another storage solution. Or to have > > different code bases on different platforms. Which we hoped to avoid by > > using Cordfova. > > I am not sure whether indexeddb is the right choice for this project. But > > websql is deprecated and not available on FirefoxOS. > > We could go the other way too: Find a websql/sqlite extension for FFOS... > > > > I think we will give indexeddb a shot. > > > > Best > > Axel > > On Jan 4, 2014 9:59 PM, "Brian LeRoux" wrote: > > > > > Well, I am not here to argue semantics but I am curious about your use > > > case. Right now im hearing a feature request for an API with no > tangible > > > story for us to rally behind. > > > > > > What are you writing (persisting)? How large? Does the write have to be > > > transactional? Asynchronous? > > > > > > The API is important but indexeddb is no different than opening a file > > > really. > > > On Jan 4, 2014 12:46 PM, "Axel Nennker" wrote: > > > > > > > File API could probably be used to implement all databases. So the > > answer > > > > is yes anyway, right? > > > > I think that indexeddb is the currently best API for developers using > > > > cordova and it is not good that they have no storage API that works > on > > > all > > > > platforms that Cordova supports. > > > > > > > > -Axel > > > > Am 04.01.2014 20:48 schrieb "Brian LeRoux" : > > > > > > > > > File API does not satisfy your use case? > > > > > On Jan 4, 2014 4:36 AM, "Axel Nennker" > > wrote: > > > > > > > > > > > I looked at the Aerogear Datamanger. Looks good but I am looking > > for > > > a > > > > > > really simple solution where developers don't have to strip away > > the > > > > > > Aerogear part. > > > > > > Something like: cordova plugin add indexeddb > > > > > > > > > > > > > > > > > > 2014/1/3 Lucas Holmquist > > > > > > > > > > > > > you should checkout the Datamanager stuff that we've been > working > > > on, > > > > > on > > > > > > > the aerogear project > > > > > https://github.com/aerogear/aerogear-js#datamanager > > > > > > > > > > > > > > It is designed to fallback to whatever is available on your > > > platform > > > > > > > > > > > > > > On Jan 3, 2014, at 8:30 AM, Axel Nennker < > ignisvul.
Re: storage
Ok, thats easier for me to reason about! (Easier to explain your problem space in the form of a use case rather than presenting us with the solution you arrived at b/c we do not have your context.) Anyhow, given you are reading/writing blobs (images) I'd say the File API is absolutely the way to go. Unfortunately, FxOS Honestly, I'd write a wrapper specific to your case and swap an adapter for the platform you are running on. (Something like Lawnchair but modernized.) Another path would be to implement our File API on top of one of the FxOS options. That would be a pull request we would welcome and maintain in core. On Sat, Jan 4, 2014 at 3:34 PM, Axel Nennker wrote: > Hi Brian, > we are building an applications that imports some data and stores that data > in a database. > Each imported data is between 2k and 50k but can be bigger. It is a set of > images in different sizes and resolutions and some text, integer fields. > We expect the total amount of data to exceed the limits of local storage. > We display the images and other fields based/filtered on some of fields > chosen by the user. > We decided to go for websql because it is supported on IOS and Android. Now > we want to support FirefoxOS and have to face the fact that we have to > invest many days to switch to another storage solution. Or to have > different code bases on different platforms. Which we hoped to avoid by > using Cordfova. > I am not sure whether indexeddb is the right choice for this project. But > websql is deprecated and not available on FirefoxOS. > We could go the other way too: Find a websql/sqlite extension for FFOS... > > I think we will give indexeddb a shot. > > Best > Axel > On Jan 4, 2014 9:59 PM, "Brian LeRoux" wrote: > > > Well, I am not here to argue semantics but I am curious about your use > > case. Right now im hearing a feature request for an API with no tangible > > story for us to rally behind. > > > > What are you writing (persisting)? How large? Does the write have to be > > transactional? Asynchronous? > > > > The API is important but indexeddb is no different than opening a file > > really. > > On Jan 4, 2014 12:46 PM, "Axel Nennker" wrote: > > > > > File API could probably be used to implement all databases. So the > answer > > > is yes anyway, right? > > > I think that indexeddb is the currently best API for developers using > > > cordova and it is not good that they have no storage API that works on > > all > > > platforms that Cordova supports. > > > > > > -Axel > > > Am 04.01.2014 20:48 schrieb "Brian LeRoux" : > > > > > > > File API does not satisfy your use case? > > > > On Jan 4, 2014 4:36 AM, "Axel Nennker" > wrote: > > > > > > > > > I looked at the Aerogear Datamanger. Looks good but I am looking > for > > a > > > > > really simple solution where developers don't have to strip away > the > > > > > Aerogear part. > > > > > Something like: cordova plugin add indexeddb > > > > > > > > > > > > > > > 2014/1/3 Lucas Holmquist > > > > > > > > > > > you should checkout the Datamanager stuff that we've been working > > on, > > > > on > > > > > > the aerogear project > > > > https://github.com/aerogear/aerogear-js#datamanager > > > > > > > > > > > > It is designed to fallback to whatever is available on your > > platform > > > > > > > > > > > > On Jan 3, 2014, at 8:30 AM, Axel Nennker > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I was wondering about the cross-platform experience of Storage. > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage > > > > > > > > > > > > > > It seems that there is no cross platform solution in Cordova, > > > right? > > > > > > > > > > > > > > There are indexeddb shims that implement indexeddb on "all" > > > > platforms. > > > > > > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > > > > > > > > > > > My team is currently facing the problem that we implemented a > > > project > > > > > > with > > > > > > > Cordova's websql on Android and IOS but it is not supported on > > > > > FirefoxOS. > > > > > > > Now I wish we had started with indexeddb and used a shim on > IOS. > > > > Argh. > > > > > > > > > > > > > > I think the text on cross platform storage in > > > > > cordova_storage_storage.mdis > > > > > > > not really helping developers. > > > > > > > > > > > > > > Advice? > > > > > > > > > > > > > > Thanks > > > > > > > Axel > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: storage
Hi Brian, we are building an applications that imports some data and stores that data in a database. Each imported data is between 2k and 50k but can be bigger. It is a set of images in different sizes and resolutions and some text, integer fields. We expect the total amount of data to exceed the limits of local storage. We display the images and other fields based/filtered on some of fields chosen by the user. We decided to go for websql because it is supported on IOS and Android. Now we want to support FirefoxOS and have to face the fact that we have to invest many days to switch to another storage solution. Or to have different code bases on different platforms. Which we hoped to avoid by using Cordfova. I am not sure whether indexeddb is the right choice for this project. But websql is deprecated and not available on FirefoxOS. We could go the other way too: Find a websql/sqlite extension for FFOS... I think we will give indexeddb a shot. Best Axel On Jan 4, 2014 9:59 PM, "Brian LeRoux" wrote: > Well, I am not here to argue semantics but I am curious about your use > case. Right now im hearing a feature request for an API with no tangible > story for us to rally behind. > > What are you writing (persisting)? How large? Does the write have to be > transactional? Asynchronous? > > The API is important but indexeddb is no different than opening a file > really. > On Jan 4, 2014 12:46 PM, "Axel Nennker" wrote: > > > File API could probably be used to implement all databases. So the answer > > is yes anyway, right? > > I think that indexeddb is the currently best API for developers using > > cordova and it is not good that they have no storage API that works on > all > > platforms that Cordova supports. > > > > -Axel > > Am 04.01.2014 20:48 schrieb "Brian LeRoux" : > > > > > File API does not satisfy your use case? > > > On Jan 4, 2014 4:36 AM, "Axel Nennker" wrote: > > > > > > > I looked at the Aerogear Datamanger. Looks good but I am looking for > a > > > > really simple solution where developers don't have to strip away the > > > > Aerogear part. > > > > Something like: cordova plugin add indexeddb > > > > > > > > > > > > 2014/1/3 Lucas Holmquist > > > > > > > > > you should checkout the Datamanager stuff that we've been working > on, > > > on > > > > > the aerogear project > > > https://github.com/aerogear/aerogear-js#datamanager > > > > > > > > > > It is designed to fallback to whatever is available on your > platform > > > > > > > > > > On Jan 3, 2014, at 8:30 AM, Axel Nennker > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I was wondering about the cross-platform experience of Storage. > > > > > > > > > > > > > > > > > > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage > > > > > > > > > > > > It seems that there is no cross platform solution in Cordova, > > right? > > > > > > > > > > > > There are indexeddb shims that implement indexeddb on "all" > > > platforms. > > > > > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > > > > > > > > > My team is currently facing the problem that we implemented a > > project > > > > > with > > > > > > Cordova's websql on Android and IOS but it is not supported on > > > > FirefoxOS. > > > > > > Now I wish we had started with indexeddb and used a shim on IOS. > > > Argh. > > > > > > > > > > > > I think the text on cross platform storage in > > > > cordova_storage_storage.mdis > > > > > > not really helping developers. > > > > > > > > > > > > Advice? > > > > > > > > > > > > Thanks > > > > > > Axel > > > > > > > > > > > > > > > > > > > >
Re: storage
Well, I am not here to argue semantics but I am curious about your use case. Right now im hearing a feature request for an API with no tangible story for us to rally behind. What are you writing (persisting)? How large? Does the write have to be transactional? Asynchronous? The API is important but indexeddb is no different than opening a file really. On Jan 4, 2014 12:46 PM, "Axel Nennker" wrote: > File API could probably be used to implement all databases. So the answer > is yes anyway, right? > I think that indexeddb is the currently best API for developers using > cordova and it is not good that they have no storage API that works on all > platforms that Cordova supports. > > -Axel > Am 04.01.2014 20:48 schrieb "Brian LeRoux" : > > > File API does not satisfy your use case? > > On Jan 4, 2014 4:36 AM, "Axel Nennker" wrote: > > > > > I looked at the Aerogear Datamanger. Looks good but I am looking for a > > > really simple solution where developers don't have to strip away the > > > Aerogear part. > > > Something like: cordova plugin add indexeddb > > > > > > > > > 2014/1/3 Lucas Holmquist > > > > > > > you should checkout the Datamanager stuff that we've been working on, > > on > > > > the aerogear project > > https://github.com/aerogear/aerogear-js#datamanager > > > > > > > > It is designed to fallback to whatever is available on your platform > > > > > > > > On Jan 3, 2014, at 8:30 AM, Axel Nennker > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I was wondering about the cross-platform experience of Storage. > > > > > > > > > > > > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage > > > > > > > > > > It seems that there is no cross platform solution in Cordova, > right? > > > > > > > > > > There are indexeddb shims that implement indexeddb on "all" > > platforms. > > > > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > > > > > > > My team is currently facing the problem that we implemented a > project > > > > with > > > > > Cordova's websql on Android and IOS but it is not supported on > > > FirefoxOS. > > > > > Now I wish we had started with indexeddb and used a shim on IOS. > > Argh. > > > > > > > > > > I think the text on cross platform storage in > > > cordova_storage_storage.mdis > > > > > not really helping developers. > > > > > > > > > > Advice? > > > > > > > > > > Thanks > > > > > Axel > > > > > > > > > > > > > >
Re: storage
File API could probably be used to implement all databases. So the answer is yes anyway, right? I think that indexeddb is the currently best API for developers using cordova and it is not good that they have no storage API that works on all platforms that Cordova supports. -Axel Am 04.01.2014 20:48 schrieb "Brian LeRoux" : > File API does not satisfy your use case? > On Jan 4, 2014 4:36 AM, "Axel Nennker" wrote: > > > I looked at the Aerogear Datamanger. Looks good but I am looking for a > > really simple solution where developers don't have to strip away the > > Aerogear part. > > Something like: cordova plugin add indexeddb > > > > > > 2014/1/3 Lucas Holmquist > > > > > you should checkout the Datamanager stuff that we've been working on, > on > > > the aerogear project > https://github.com/aerogear/aerogear-js#datamanager > > > > > > It is designed to fallback to whatever is available on your platform > > > > > > On Jan 3, 2014, at 8:30 AM, Axel Nennker > wrote: > > > > > > > Hi, > > > > > > > > I was wondering about the cross-platform experience of Storage. > > > > > > > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage > > > > > > > > It seems that there is no cross platform solution in Cordova, right? > > > > > > > > There are indexeddb shims that implement indexeddb on "all" > platforms. > > > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > > > > > My team is currently facing the problem that we implemented a project > > > with > > > > Cordova's websql on Android and IOS but it is not supported on > > FirefoxOS. > > > > Now I wish we had started with indexeddb and used a shim on IOS. > Argh. > > > > > > > > I think the text on cross platform storage in > > cordova_storage_storage.mdis > > > > not really helping developers. > > > > > > > > Advice? > > > > > > > > Thanks > > > > Axel > > > > > > > > >
Re: storage
File API does not satisfy your use case? On Jan 4, 2014 4:36 AM, "Axel Nennker" wrote: > I looked at the Aerogear Datamanger. Looks good but I am looking for a > really simple solution where developers don't have to strip away the > Aerogear part. > Something like: cordova plugin add indexeddb > > > 2014/1/3 Lucas Holmquist > > > you should checkout the Datamanager stuff that we've been working on, on > > the aerogear project https://github.com/aerogear/aerogear-js#datamanager > > > > It is designed to fallback to whatever is available on your platform > > > > On Jan 3, 2014, at 8:30 AM, Axel Nennker wrote: > > > > > Hi, > > > > > > I was wondering about the cross-platform experience of Storage. > > > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage > > > > > > It seems that there is no cross platform solution in Cordova, right? > > > > > > There are indexeddb shims that implement indexeddb on "all" platforms. > > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > > > My team is currently facing the problem that we implemented a project > > with > > > Cordova's websql on Android and IOS but it is not supported on > FirefoxOS. > > > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > > > > > I think the text on cross platform storage in > cordova_storage_storage.mdis > > > not really helping developers. > > > > > > Advice? > > > > > > Thanks > > > Axel > > > > >
Re: storage
I looked at the Aerogear Datamanger. Looks good but I am looking for a really simple solution where developers don't have to strip away the Aerogear part. Something like: cordova plugin add indexeddb 2014/1/3 Lucas Holmquist > you should checkout the Datamanager stuff that we've been working on, on > the aerogear project https://github.com/aerogear/aerogear-js#datamanager > > It is designed to fallback to whatever is available on your platform > > On Jan 3, 2014, at 8:30 AM, Axel Nennker wrote: > > > Hi, > > > > I was wondering about the cross-platform experience of Storage. > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage > > > > It seems that there is no cross platform solution in Cordova, right? > > > > There are indexeddb shims that implement indexeddb on "all" platforms. > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > My team is currently facing the problem that we implemented a project > with > > Cordova's websql on Android and IOS but it is not supported on FirefoxOS. > > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > > > I think the text on cross platform storage in cordova_storage_storage.mdis > > not really helping developers. > > > > Advice? > > > > Thanks > > Axel > >
Re: storage
Yes it is a plugin. Maybe some day it will be cordova-indexeddb... I think that the current info for cordova users in http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage is not really much helpful. I guess that most cordova apps need some storage and that doc basically says pick one yourself because there is not true cross platform thing. I think I would help tremendously to have one Cordova Storage API on all platforms. WebSQL is deprecated and Indexeddb seems to be the way to go. Too bad that Apple/webkit does not support it. Would be great to have a cordova indexeddb plugin for all platforms. cheers -Axel 2014/1/4 Brian LeRoux > Again: this is a plugin and really not a Cordova concern. > On Jan 4, 2014 2:14 AM, "Axel Nennker" wrote: > > > How about Parashuram Narasimhan reviewing Dick's patches and both of you > > writing some tests? > > Maybe some IOS experts can chime in and integrate the shim into cordova > so > > that indexeddb just works without a script tag to include the shim's code > > into the app? > > > > > > 2014/1/3 Dick Van den Brink > > > > > I use this shim and use it for iOS and android and after patching it > > works > > > great! > > > > > > The latest build is completely broken without patches, see my pull reqs > > on > > > github and some others. > > > > > > I'm all for using this as a starting point but it has been broken for > > > almost 4 months now without manually applying patches. (I'm talking > about > > > iterating over indexes and cursor.Update being broken). > > > > > > If we want to use this, we should never have such a situation again. > > > > > > > > > > > > Verzonden met Windows Mail > > > > > > > > > > > > > > > > > > Van: Parashuram Narasimhan (MS OPEN TECH) > > > Verzonden: vrijdag 3 januari 2014 20:27 > > > Aan: dev@cordova.apache.org > > > > > > > > > > > > > > > > > > I gave IndexedDB shim over websql a shot, but it is not 100% compliant > > and > > > has some bugs - http://github.com/axemclion/indexeddbshim. I am > working > > > on fixing the bugs, but to the level it works, I tested and it works > with > > > Cordova well !! > > > Could we use that as a starting point ? > > > > > > -Original Message- > > > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf > > Of > > > Brian LeRoux > > > Sent: Friday, January 3, 2014 10:37 AM > > > To: dev@cordova.apache.org > > > Subject: Re: storage > > > > > > an indexeddb plugin would be a rad thing for the community to create > and > > > maintain ;) > > > > > > in seriousness: the file api is probably what you're really looking for > > if > > > you want to read/write json on phones (you could even use it as a basis > > for > > > an JS only plugin that polyfills indexeddb. > > > > > > > > > On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker > > > wrote: > > > > > > > Hi, > > > > > > > > I was wondering about the cross-platform experience of Storage. > > > > > > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.htm > > > > l#Storage > > > > > > > > It seems that there is no cross platform solution in Cordova, right? > > > > > > > > There are indexeddb shims that implement indexeddb on "all" > platforms. > > > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > > > > > My team is currently facing the problem that we implemented a project > > > > with Cordova's websql on Android and IOS but it is not supported on > > > FirefoxOS. > > > > Now I wish we had started with indexeddb and used a shim on IOS. > Argh. > > > > > > > > I think the text on cross platform storage in > > > > cordova_storage_storage.mdis not really helping developers. > > > > > > > > Advice? > > > > > > > > Thanks > > > > Axel > > > > > > > > > >
RE: storage
Parashuram already emailed me, so we are working something out. Will write some extra tests next week. Parashuram already wrote some tests and with my patches they all pass! Sent from my Windows Phone From: Brian LeRoux<mailto:b...@brian.io> Sent: ‎1/‎4/‎2014 12:04 To: dev@cordova.apache.org<mailto:dev@cordova.apache.org> Subject: Re: storage Again: this is a plugin and really not a Cordova concern. On Jan 4, 2014 2:14 AM, "Axel Nennker" wrote: > How about Parashuram Narasimhan reviewing Dick's patches and both of you > writing some tests? > Maybe some IOS experts can chime in and integrate the shim into cordova so > that indexeddb just works without a script tag to include the shim's code > into the app? > > > 2014/1/3 Dick Van den Brink > > > I use this shim and use it for iOS and android and after patching it > works > > great! > > > > The latest build is completely broken without patches, see my pull reqs > on > > github and some others. > > > > I'm all for using this as a starting point but it has been broken for > > almost 4 months now without manually applying patches. (I'm talking about > > iterating over indexes and cursor.Update being broken). > > > > If we want to use this, we should never have such a situation again. > > > > > > > > Verzonden met Windows Mail > > > > > > > > > > > > Van: Parashuram Narasimhan (MS OPEN TECH) > > Verzonden: vrijdag 3 januari 2014 20:27 > > Aan: dev@cordova.apache.org > > > > > > > > > > > > I gave IndexedDB shim over websql a shot, but it is not 100% compliant > and > > has some bugs - http://github.com/axemclion/indexeddbshim. I am working > > on fixing the bugs, but to the level it works, I tested and it works with > > Cordova well !! > > Could we use that as a starting point ? > > > > -Original Message- > > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf > Of > > Brian LeRoux > > Sent: Friday, January 3, 2014 10:37 AM > > To: dev@cordova.apache.org > > Subject: Re: storage > > > > an indexeddb plugin would be a rad thing for the community to create and > > maintain ;) > > > > in seriousness: the file api is probably what you're really looking for > if > > you want to read/write json on phones (you could even use it as a basis > for > > an JS only plugin that polyfills indexeddb. > > > > > > On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker > > wrote: > > > > > Hi, > > > > > > I was wondering about the cross-platform experience of Storage. > > > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.htm > > > l#Storage > > > > > > It seems that there is no cross platform solution in Cordova, right? > > > > > > There are indexeddb shims that implement indexeddb on "all" platforms. > > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > > > My team is currently facing the problem that we implemented a project > > > with Cordova's websql on Android and IOS but it is not supported on > > FirefoxOS. > > > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > > > > > I think the text on cross platform storage in > > > cordova_storage_storage.mdis not really helping developers. > > > > > > Advice? > > > > > > Thanks > > > Axel > > > > > >
Re: storage
Again: this is a plugin and really not a Cordova concern. On Jan 4, 2014 2:14 AM, "Axel Nennker" wrote: > How about Parashuram Narasimhan reviewing Dick's patches and both of you > writing some tests? > Maybe some IOS experts can chime in and integrate the shim into cordova so > that indexeddb just works without a script tag to include the shim's code > into the app? > > > 2014/1/3 Dick Van den Brink > > > I use this shim and use it for iOS and android and after patching it > works > > great! > > > > The latest build is completely broken without patches, see my pull reqs > on > > github and some others. > > > > I'm all for using this as a starting point but it has been broken for > > almost 4 months now without manually applying patches. (I'm talking about > > iterating over indexes and cursor.Update being broken). > > > > If we want to use this, we should never have such a situation again. > > > > > > > > Verzonden met Windows Mail > > > > > > > > > > > > Van: Parashuram Narasimhan (MS OPEN TECH) > > Verzonden: vrijdag 3 januari 2014 20:27 > > Aan: dev@cordova.apache.org > > > > > > > > > > > > I gave IndexedDB shim over websql a shot, but it is not 100% compliant > and > > has some bugs - http://github.com/axemclion/indexeddbshim. I am working > > on fixing the bugs, but to the level it works, I tested and it works with > > Cordova well !! > > Could we use that as a starting point ? > > > > -Original Message- > > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf > Of > > Brian LeRoux > > Sent: Friday, January 3, 2014 10:37 AM > > To: dev@cordova.apache.org > > Subject: Re: storage > > > > an indexeddb plugin would be a rad thing for the community to create and > > maintain ;) > > > > in seriousness: the file api is probably what you're really looking for > if > > you want to read/write json on phones (you could even use it as a basis > for > > an JS only plugin that polyfills indexeddb. > > > > > > On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker > > wrote: > > > > > Hi, > > > > > > I was wondering about the cross-platform experience of Storage. > > > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.htm > > > l#Storage > > > > > > It seems that there is no cross platform solution in Cordova, right? > > > > > > There are indexeddb shims that implement indexeddb on "all" platforms. > > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > > > My team is currently facing the problem that we implemented a project > > > with Cordova's websql on Android and IOS but it is not supported on > > FirefoxOS. > > > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > > > > > I think the text on cross platform storage in > > > cordova_storage_storage.mdis not really helping developers. > > > > > > Advice? > > > > > > Thanks > > > Axel > > > > > >
Re: storage
How about Parashuram Narasimhan reviewing Dick's patches and both of you writing some tests? Maybe some IOS experts can chime in and integrate the shim into cordova so that indexeddb just works without a script tag to include the shim's code into the app? 2014/1/3 Dick Van den Brink > I use this shim and use it for iOS and android and after patching it works > great! > > The latest build is completely broken without patches, see my pull reqs on > github and some others. > > I'm all for using this as a starting point but it has been broken for > almost 4 months now without manually applying patches. (I'm talking about > iterating over indexes and cursor.Update being broken). > > If we want to use this, we should never have such a situation again. > > > > Verzonden met Windows Mail > > > > > > Van: Parashuram Narasimhan (MS OPEN TECH) > Verzonden: vrijdag 3 januari 2014 20:27 > Aan: dev@cordova.apache.org > > > > > > I gave IndexedDB shim over websql a shot, but it is not 100% compliant and > has some bugs - http://github.com/axemclion/indexeddbshim. I am working > on fixing the bugs, but to the level it works, I tested and it works with > Cordova well !! > Could we use that as a starting point ? > > -Original Message- > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of > Brian LeRoux > Sent: Friday, January 3, 2014 10:37 AM > To: dev@cordova.apache.org > Subject: Re: storage > > an indexeddb plugin would be a rad thing for the community to create and > maintain ;) > > in seriousness: the file api is probably what you're really looking for if > you want to read/write json on phones (you could even use it as a basis for > an JS only plugin that polyfills indexeddb. > > > On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker > wrote: > > > Hi, > > > > I was wondering about the cross-platform experience of Storage. > > > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.htm > > l#Storage > > > > It seems that there is no cross platform solution in Cordova, right? > > > > There are indexeddb shims that implement indexeddb on "all" platforms. > > Shouldn't storage be indexeddb only? websql is deprecated. > > > > My team is currently facing the problem that we implemented a project > > with Cordova's websql on Android and IOS but it is not supported on > FirefoxOS. > > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > > > I think the text on cross platform storage in > > cordova_storage_storage.mdis not really helping developers. > > > > Advice? > > > > Thanks > > Axel > > >
Re: storage
I use this shim and use it for iOS and android and after patching it works great! The latest build is completely broken without patches, see my pull reqs on github and some others. I'm all for using this as a starting point but it has been broken for almost 4 months now without manually applying patches. (I'm talking about iterating over indexes and cursor.Update being broken). If we want to use this, we should never have such a situation again. Verzonden met Windows Mail Van: Parashuram Narasimhan (MS OPEN TECH) Verzonden: ‎vrijdag‎ ‎3‎ ‎januari‎ ‎2014 ‎20‎:‎27 Aan: dev@cordova.apache.org I gave IndexedDB shim over websql a shot, but it is not 100% compliant and has some bugs - http://github.com/axemclion/indexeddbshim. I am working on fixing the bugs, but to the level it works, I tested and it works with Cordova well !! Could we use that as a starting point ? -Original Message- From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian LeRoux Sent: Friday, January 3, 2014 10:37 AM To: dev@cordova.apache.org Subject: Re: storage an indexeddb plugin would be a rad thing for the community to create and maintain ;) in seriousness: the file api is probably what you're really looking for if you want to read/write json on phones (you could even use it as a basis for an JS only plugin that polyfills indexeddb. On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker wrote: > Hi, > > I was wondering about the cross-platform experience of Storage. > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.htm > l#Storage > > It seems that there is no cross platform solution in Cordova, right? > > There are indexeddb shims that implement indexeddb on "all" platforms. > Shouldn't storage be indexeddb only? websql is deprecated. > > My team is currently facing the problem that we implemented a project > with Cordova's websql on Android and IOS but it is not supported on FirefoxOS. > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > I think the text on cross platform storage in > cordova_storage_storage.mdis not really helping developers. > > Advice? > > Thanks > Axel >
RE: storage
I gave IndexedDB shim over websql a shot, but it is not 100% compliant and has some bugs - http://github.com/axemclion/indexeddbshim. I am working on fixing the bugs, but to the level it works, I tested and it works with Cordova well !! Could we use that as a starting point ? -Original Message- From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian LeRoux Sent: Friday, January 3, 2014 10:37 AM To: dev@cordova.apache.org Subject: Re: storage an indexeddb plugin would be a rad thing for the community to create and maintain ;) in seriousness: the file api is probably what you're really looking for if you want to read/write json on phones (you could even use it as a basis for an JS only plugin that polyfills indexeddb. On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker wrote: > Hi, > > I was wondering about the cross-platform experience of Storage. > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.htm > l#Storage > > It seems that there is no cross platform solution in Cordova, right? > > There are indexeddb shims that implement indexeddb on "all" platforms. > Shouldn't storage be indexeddb only? websql is deprecated. > > My team is currently facing the problem that we implemented a project > with Cordova's websql on Android and IOS but it is not supported on FirefoxOS. > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > I think the text on cross platform storage in > cordova_storage_storage.mdis not really helping developers. > > Advice? > > Thanks > Axel >
Re: storage
you should checkout the Datamanager stuff that we've been working on, on the aerogear project https://github.com/aerogear/aerogear-js#datamanager It is designed to fallback to whatever is available on your platform On Jan 3, 2014, at 8:30 AM, Axel Nennker wrote: > Hi, > > I was wondering about the cross-platform experience of Storage. > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage > > It seems that there is no cross platform solution in Cordova, right? > > There are indexeddb shims that implement indexeddb on "all" platforms. > Shouldn't storage be indexeddb only? websql is deprecated. > > My team is currently facing the problem that we implemented a project with > Cordova's websql on Android and IOS but it is not supported on FirefoxOS. > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > I think the text on cross platform storage in cordova_storage_storage.md is > not really helping developers. > > Advice? > > Thanks > Axel
Re: storage
an indexeddb plugin would be a rad thing for the community to create and maintain ;) in seriousness: the file api is probably what you're really looking for if you want to read/write json on phones (you could even use it as a basis for an JS only plugin that polyfills indexeddb. On Fri, Jan 3, 2014 at 5:30 AM, Axel Nennker wrote: > Hi, > > I was wondering about the cross-platform experience of Storage. > > http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage > > It seems that there is no cross platform solution in Cordova, right? > > There are indexeddb shims that implement indexeddb on "all" platforms. > Shouldn't storage be indexeddb only? websql is deprecated. > > My team is currently facing the problem that we implemented a project with > Cordova's websql on Android and IOS but it is not supported on FirefoxOS. > Now I wish we had started with indexeddb and used a shim on IOS. Argh. > > I think the text on cross platform storage in cordova_storage_storage.mdis > not really helping developers. > > Advice? > > Thanks > Axel >
storage
Hi, I was wondering about the cross-platform experience of Storage. http://cordova.apache.org/docs/en/3.3.0/cordova_storage_storage.md.html#Storage It seems that there is no cross platform solution in Cordova, right? There are indexeddb shims that implement indexeddb on "all" platforms. Shouldn't storage be indexeddb only? websql is deprecated. My team is currently facing the problem that we implemented a project with Cordova's websql on Android and IOS but it is not supported on FirefoxOS. Now I wish we had started with indexeddb and used a shim on IOS. Argh. I think the text on cross platform storage in cordova_storage_storage.md is not really helping developers. Advice? Thanks Axel
Re: So, what to do about storage issues?
Great! Thanks for following up! On Wed, Oct 30, 2013 at 5:26 AM, Dick Van den Brink < d_vandenbr...@outlook.com> wrote: > A follow up on the issue, I had some time to check it today! Because we > are still on cordova 3.0.0 I made a custom build with the fix and it works > like a charm! Thanks :) > > To: dev@cordova.apache.org > From: d_vandenbr...@outlook.com > Subject: RE: So, what to do about storage issues? > Date: Fri, 25 Oct 2013 13:55:26 +0700 > > > > > > > > Wow, that would be awesome! Thanks! Hope I have time to check it next > week! Thanks! > > > > Sent from my Windows Phone > > > > From: > Andrew Grieve > > Sent: > 10/24/2013 22:12 > > To: > dev > > Subject: > Re: So, what to do about storage issues? > > > > > > Made a discovery today that Cordova's Quota logic was wrong. Filed this as > > https://issues.apache.org/jira/browse/CB-5193 and fixed it :). Multiple > > databases should work fine starting in 3.2 / 2.9.1. > > > > > > >
RE: So, what to do about storage issues?
A follow up on the issue, I had some time to check it today! Because we are still on cordova 3.0.0 I made a custom build with the fix and it works like a charm! Thanks :) To: dev@cordova.apache.org From: d_vandenbr...@outlook.com Subject: RE: So, what to do about storage issues? Date: Fri, 25 Oct 2013 13:55:26 +0700 Wow, that would be awesome! Thanks! Hope I have time to check it next week! Thanks! Sent from my Windows Phone From: Andrew Grieve Sent: ‎10/‎24/‎2013 22:12 To: dev Subject: Re: So, what to do about storage issues? Made a discovery today that Cordova's Quota logic was wrong. Filed this as https://issues.apache.org/jira/browse/CB-5193 and fixed it :). Multiple databases should work fine starting in 3.2 / 2.9.1.
RE: So, what to do about storage issues?
Wow, that would be awesome! Thanks! Hope I have time to check it next week! Thanks! Sent from my Windows Phone From: Andrew Grieve<mailto:agri...@chromium.org> Sent: ‎10/‎24/‎2013 22:12 To: dev<mailto:dev@cordova.apache.org> Subject: Re: So, what to do about storage issues? Made a discovery today that Cordova's Quota logic was wrong. Filed this as https://issues.apache.org/jira/browse/CB-5193 and fixed it :). Multiple databases should work fine starting in 3.2 / 2.9.1. On Thu, Oct 10, 2013 at 3:09 PM, Dick Van den Brink < d_vandenbr...@outlook.com> wrote: > Hi Andrew, > > Thanks for the input, hadn’t figured that out yet! I might try it tomorrow > if I have the time. Going on a vacation next week and got lots of work to > do. > > Again thanks for looking in to it! > > Regards, > > Dick van den Brink > > > From: agri...@chromium.org > > Date: Thu, 10 Oct 2013 14:45:45 -0400 > > Subject: Re: So, what to do about storage issues? > > To: dev@cordova.apache.org > > > > Tried out your sample. Certainly shows the problem well. > > > > After more playing, I know more about the problem than I think I'd like > :P. > > > > It's not that you can't open multiple databases, it's that you can create > > only one database. What I mean is, if you ever restart the app and use a > > different name for the database, it will fail as well. > > > > The only way I could get it to work was to use sqlite3 on the native side > > to pre-create a second database. If you do that, then you can open > multiple > > at a time. I did it by changing the db path to /sdcard/dbs and using adb > to > > move the files back and forth to my computer. > > > > So... I don't think I'm going to invest any more time into this. I just > > added caveats to the websql README about not being able to open multiple > > databases. If you really can't live without this feature, you might try > > writing a plugin that pre-creates a database for you so that you can > later > > open it with openDatabase() > > > > > > On Thu, Oct 10, 2013 at 5:02 AM, Dick Van den Brink < > > d_vandenbr...@outlook.com> wrote: > > > >> Not sure what the namespace issue is, but I created a quick example > >> project. > >> It might not be the best code but that doesn't really matter. :-)Code is > >> on: https://github.com/DickvdBrink/cordova-websql/ > >> after the checkout you might need to run "android update project --path > >> platforms/android"It always opens one db, with the name "firstDb" in the > >> deviceready event.When you click the the text: "Click here to load db > with > >> name "secondDb" I get a security error in the javascript alert box.If > you > >> don't get the error it changes the text to "Second db loaded". > >>> Date: Wed, 9 Oct 2013 08:44:08 -0700 > >>> Subject: Re: So, what to do about storage issues? > >>> From: bows...@gmail.com > >>> To: dev@cordova.apache.org > >>> > >>> I think this is the namespace issue. We need to make sure the plugin > >>> always overrides the default namespace. > >>> On Oct 9, 2013 8:00 AM, "Andrew Grieve" wrote: > >>> > >>>> Example project would be great! > >>>> > >>>> > >>>> On Wed, Oct 9, 2013 at 10:27 AM, Dick Van den Brink < > >>>> d_vandenbr...@outlook.com> wrote: > >>>> > >>>>> I don't think it is fixed with the org.apache.cordova.websql plugin.I > >>>>> still can open only one database. The second one is giving me a > >> security > >>>>> error on Android 4.1.2. > >>>>> I'm on Cordova 3.0 btw. I added some logging to the websql plugin > >> code to > >>>>> make sure it was using it and that seems to be the case. I can > >> create an > >>>>> example project if you want. > >>>>> > >>>>>> From: agri...@chromium.org > >>>>>> Date: Wed, 9 Oct 2013 10:04:14 -0400 > >>>>>> Subject: Re: So, what to do about storage issues? > >>>>>> To: dev@cordova.apache.org > >>>>>> > >>>>>> I think let's document the quirks (CB-4760), and close the other > >> two as > >>>>>> fixed (via org.apache.cordova.websql plugin) > >>>>>> > >&
Re: Deleting most of storage docs
Thanks for having a look Joe! And for the +9001 :P. Ian - I added a link right at the top to http://www.html5rocks.com/en/features/storage. It lists the same APIs and has articles with examples of them all. Probably this is the most helpful thing we can do :) I also added a note at the bottom about the File API being a storage option as well. Submitted. On Thu, Oct 24, 2013 at 12:15 PM, Ian Clelland wrote: > For consistency with the rest of our docs, should we preserve at least a > minimal working example of using each? > > On Thursday, October 24, 2013, Andrew Grieve wrote: > > > Since Cordova just uses the underlying webview's WebSQL / Localstorage / > > IDB, I think it's confusing to have such elaborate docs for them. > Instead, > > I'd like to replace the Storage docs with a short summary of the storage > > APIs that are available, and link to the relevant specs. > > > > https://reviews.apache.org/r/14908/ > > > > Good idea? > > >
Re: Review Request 14908: CB-4760 Remove docs for WebSQL and replace them with a Storage options overview.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14908/#review27476 --- Ship it! Ship It! - Joe Bowser On Oct. 24, 2013, 3:40 p.m., Andrew Grieve wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14908/ > --- > > (Updated Oct. 24, 2013, 3:40 p.m.) > > > Review request for cordova. > > > Repository: cordova-docs > > > Description > --- > > CB-4760 Remove docs for WebSQL and replace them with a Storage options > overview. > > > Remove reference to database from localstorage docs > > > Diffs > - > > docs/en/edge/config.json 76be7b73101fe8417799a81df8a080dad72ade13 > docs/en/edge/cordova/storage/database/database.md > c32adab9847a1fb1db4f8fea7763bb05e4934892 > docs/en/edge/cordova/storage/localstorage/localstorage.md > 82e380320fb62d89a631b3d0f2616a09e87d8a1b > docs/en/edge/cordova/storage/parameters/display_name.md > 7ea80ffbd0045eca72c426a16068c713d5cee64c > docs/en/edge/cordova/storage/parameters/name.md > 0e90c24f921db2e338d139002b1ee0789048a190 > docs/en/edge/cordova/storage/parameters/size.md > 106d730cd054a2e5b85d4593b34cffe3311a6b61 > docs/en/edge/cordova/storage/parameters/version.md > 68197bf59813fdcb068410048a4d76c578587bf2 > docs/en/edge/cordova/storage/sqlerror/sqlerror.md > 8fcbbbc2df31f7d21c6e4f4f36bed1076e848255 > docs/en/edge/cordova/storage/sqlresultset/sqlresultset.md > d2262bf86af4c43e00ef27e4e67f0d34aaabeeeb > docs/en/edge/cordova/storage/sqlresultsetrowlist/sqlresultsetrowlist.md > 68f7a5c2bc9cef30b7f770988c6f1668b5c337e7 > docs/en/edge/cordova/storage/sqltransaction/sqltransaction.md > 93901d6a02070874c3b6e0c5ff0bfd2c447e0a35 > docs/en/edge/cordova/storage/storage.md > b38ad4a01dbee5dd2828ca0eb1f02604fd3d7b51 > docs/en/edge/cordova/storage/storage.opendatabase.md > 310ba6c4e91326a4d829ce6d123c16f4d4ba5ec7 > > Diff: https://reviews.apache.org/r/14908/diff/ > > > Testing > --- > > > Thanks, > > Andrew Grieve > >
Re: Deleting most of storage docs
For consistency with the rest of our docs, should we preserve at least a minimal working example of using each? On Thursday, October 24, 2013, Andrew Grieve wrote: > Since Cordova just uses the underlying webview's WebSQL / Localstorage / > IDB, I think it's confusing to have such elaborate docs for them. Instead, > I'd like to replace the Storage docs with a short summary of the storage > APIs that are available, and link to the relevant specs. > > https://reviews.apache.org/r/14908/ > > Good idea? >
Re: Deleting most of storage docs
+9001 Seriously, those docs suck and should go away! We should definitely do this. On Thu, Oct 24, 2013 at 8:41 AM, Andrew Grieve wrote: > Since Cordova just uses the underlying webview's WebSQL / Localstorage / > IDB, I think it's confusing to have such elaborate docs for them. Instead, > I'd like to replace the Storage docs with a short summary of the storage > APIs that are available, and link to the relevant specs. > > https://reviews.apache.org/r/14908/ > > Good idea?
Deleting most of storage docs
Since Cordova just uses the underlying webview's WebSQL / Localstorage / IDB, I think it's confusing to have such elaborate docs for them. Instead, I'd like to replace the Storage docs with a short summary of the storage APIs that are available, and link to the relevant specs. https://reviews.apache.org/r/14908/ Good idea?
Review Request 14908: CB-4760 Remove docs for WebSQL and replace them with a Storage options overview.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14908/ --- Review request for cordova. Repository: cordova-docs Description --- CB-4760 Remove docs for WebSQL and replace them with a Storage options overview. Remove reference to database from localstorage docs Diffs - docs/en/edge/config.json 76be7b73101fe8417799a81df8a080dad72ade13 docs/en/edge/cordova/storage/database/database.md c32adab9847a1fb1db4f8fea7763bb05e4934892 docs/en/edge/cordova/storage/localstorage/localstorage.md 82e380320fb62d89a631b3d0f2616a09e87d8a1b docs/en/edge/cordova/storage/parameters/display_name.md 7ea80ffbd0045eca72c426a16068c713d5cee64c docs/en/edge/cordova/storage/parameters/name.md 0e90c24f921db2e338d139002b1ee0789048a190 docs/en/edge/cordova/storage/parameters/size.md 106d730cd054a2e5b85d4593b34cffe3311a6b61 docs/en/edge/cordova/storage/parameters/version.md 68197bf59813fdcb068410048a4d76c578587bf2 docs/en/edge/cordova/storage/sqlerror/sqlerror.md 8fcbbbc2df31f7d21c6e4f4f36bed1076e848255 docs/en/edge/cordova/storage/sqlresultset/sqlresultset.md d2262bf86af4c43e00ef27e4e67f0d34aaabeeeb docs/en/edge/cordova/storage/sqlresultsetrowlist/sqlresultsetrowlist.md 68f7a5c2bc9cef30b7f770988c6f1668b5c337e7 docs/en/edge/cordova/storage/sqltransaction/sqltransaction.md 93901d6a02070874c3b6e0c5ff0bfd2c447e0a35 docs/en/edge/cordova/storage/storage.md b38ad4a01dbee5dd2828ca0eb1f02604fd3d7b51 docs/en/edge/cordova/storage/storage.opendatabase.md 310ba6c4e91326a4d829ce6d123c16f4d4ba5ec7 Diff: https://reviews.apache.org/r/14908/diff/ Testing --- Thanks, Andrew Grieve
Re: So, what to do about storage issues?
Made a discovery today that Cordova's Quota logic was wrong. Filed this as https://issues.apache.org/jira/browse/CB-5193 and fixed it :). Multiple databases should work fine starting in 3.2 / 2.9.1. On Thu, Oct 10, 2013 at 3:09 PM, Dick Van den Brink < d_vandenbr...@outlook.com> wrote: > Hi Andrew, > > Thanks for the input, hadn’t figured that out yet! I might try it tomorrow > if I have the time. Going on a vacation next week and got lots of work to > do. > > Again thanks for looking in to it! > > Regards, > > Dick van den Brink > > > From: agri...@chromium.org > > Date: Thu, 10 Oct 2013 14:45:45 -0400 > > Subject: Re: So, what to do about storage issues? > > To: dev@cordova.apache.org > > > > Tried out your sample. Certainly shows the problem well. > > > > After more playing, I know more about the problem than I think I'd like > :P. > > > > It's not that you can't open multiple databases, it's that you can create > > only one database. What I mean is, if you ever restart the app and use a > > different name for the database, it will fail as well. > > > > The only way I could get it to work was to use sqlite3 on the native side > > to pre-create a second database. If you do that, then you can open > multiple > > at a time. I did it by changing the db path to /sdcard/dbs and using adb > to > > move the files back and forth to my computer. > > > > So... I don't think I'm going to invest any more time into this. I just > > added caveats to the websql README about not being able to open multiple > > databases. If you really can't live without this feature, you might try > > writing a plugin that pre-creates a database for you so that you can > later > > open it with openDatabase() > > > > > > On Thu, Oct 10, 2013 at 5:02 AM, Dick Van den Brink < > > d_vandenbr...@outlook.com> wrote: > > > >> Not sure what the namespace issue is, but I created a quick example > >> project. > >> It might not be the best code but that doesn't really matter. :-)Code is > >> on: https://github.com/DickvdBrink/cordova-websql/ > >> after the checkout you might need to run "android update project --path > >> platforms/android"It always opens one db, with the name "firstDb" in the > >> deviceready event.When you click the the text: "Click here to load db > with > >> name "secondDb" I get a security error in the javascript alert box.If > you > >> don't get the error it changes the text to "Second db loaded". > >>> Date: Wed, 9 Oct 2013 08:44:08 -0700 > >>> Subject: Re: So, what to do about storage issues? > >>> From: bows...@gmail.com > >>> To: dev@cordova.apache.org > >>> > >>> I think this is the namespace issue. We need to make sure the plugin > >>> always overrides the default namespace. > >>> On Oct 9, 2013 8:00 AM, "Andrew Grieve" wrote: > >>> > >>>> Example project would be great! > >>>> > >>>> > >>>> On Wed, Oct 9, 2013 at 10:27 AM, Dick Van den Brink < > >>>> d_vandenbr...@outlook.com> wrote: > >>>> > >>>>> I don't think it is fixed with the org.apache.cordova.websql plugin.I > >>>>> still can open only one database. The second one is giving me a > >> security > >>>>> error on Android 4.1.2. > >>>>> I'm on Cordova 3.0 btw. I added some logging to the websql plugin > >> code to > >>>>> make sure it was using it and that seems to be the case. I can > >> create an > >>>>> example project if you want. > >>>>> > >>>>>> From: agri...@chromium.org > >>>>>> Date: Wed, 9 Oct 2013 10:04:14 -0400 > >>>>>> Subject: Re: So, what to do about storage issues? > >>>>>> To: dev@cordova.apache.org > >>>>>> > >>>>>> I think let's document the quirks (CB-4760), and close the other > >> two as > >>>>>> fixed (via org.apache.cordova.websql plugin) > >>>>>> > >>>>>> > >>>>>> On Tue, Oct 8, 2013 at 5:55 PM, Shazron wrote: > >>>>>> > >>>>>>> Not sure you guys got Ray's message below if you were on Gmail -- > >>>>> since it > >>>>>>> filtered it out as spam (confi
RE: So, what to do about storage issues?
Hi Andrew, Thanks for the input, hadn’t figured that out yet! I might try it tomorrow if I have the time. Going on a vacation next week and got lots of work to do. Again thanks for looking in to it! Regards, Dick van den Brink > From: agri...@chromium.org > Date: Thu, 10 Oct 2013 14:45:45 -0400 > Subject: Re: So, what to do about storage issues? > To: dev@cordova.apache.org > > Tried out your sample. Certainly shows the problem well. > > After more playing, I know more about the problem than I think I'd like :P. > > It's not that you can't open multiple databases, it's that you can create > only one database. What I mean is, if you ever restart the app and use a > different name for the database, it will fail as well. > > The only way I could get it to work was to use sqlite3 on the native side > to pre-create a second database. If you do that, then you can open multiple > at a time. I did it by changing the db path to /sdcard/dbs and using adb to > move the files back and forth to my computer. > > So... I don't think I'm going to invest any more time into this. I just > added caveats to the websql README about not being able to open multiple > databases. If you really can't live without this feature, you might try > writing a plugin that pre-creates a database for you so that you can later > open it with openDatabase() > > > On Thu, Oct 10, 2013 at 5:02 AM, Dick Van den Brink < > d_vandenbr...@outlook.com> wrote: > >> Not sure what the namespace issue is, but I created a quick example >> project. >> It might not be the best code but that doesn't really matter. :-)Code is >> on: https://github.com/DickvdBrink/cordova-websql/ >> after the checkout you might need to run "android update project --path >> platforms/android"It always opens one db, with the name "firstDb" in the >> deviceready event.When you click the the text: "Click here to load db with >> name "secondDb" I get a security error in the javascript alert box.If you >> don't get the error it changes the text to "Second db loaded". >>> Date: Wed, 9 Oct 2013 08:44:08 -0700 >>> Subject: Re: So, what to do about storage issues? >>> From: bows...@gmail.com >>> To: dev@cordova.apache.org >>> >>> I think this is the namespace issue. We need to make sure the plugin >>> always overrides the default namespace. >>> On Oct 9, 2013 8:00 AM, "Andrew Grieve" wrote: >>> >>>> Example project would be great! >>>> >>>> >>>> On Wed, Oct 9, 2013 at 10:27 AM, Dick Van den Brink < >>>> d_vandenbr...@outlook.com> wrote: >>>> >>>>> I don't think it is fixed with the org.apache.cordova.websql plugin.I >>>>> still can open only one database. The second one is giving me a >> security >>>>> error on Android 4.1.2. >>>>> I'm on Cordova 3.0 btw. I added some logging to the websql plugin >> code to >>>>> make sure it was using it and that seems to be the case. I can >> create an >>>>> example project if you want. >>>>> >>>>>> From: agri...@chromium.org >>>>>> Date: Wed, 9 Oct 2013 10:04:14 -0400 >>>>>> Subject: Re: So, what to do about storage issues? >>>>>> To: dev@cordova.apache.org >>>>>> >>>>>> I think let's document the quirks (CB-4760), and close the other >> two as >>>>>> fixed (via org.apache.cordova.websql plugin) >>>>>> >>>>>> >>>>>> On Tue, Oct 8, 2013 at 5:55 PM, Shazron wrote: >>>>>> >>>>>>> Not sure you guys got Ray's message below if you were on Gmail -- >>>>> since it >>>>>>> filtered it out as spam (confirmed with another committer/Gmail >> user) >>>>> :/ >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 8, 2013 at 2:30 PM, Ray Camden >>>> wrote: >>>>>>> >>>>>>>> Hmm, from CB-4760: >>>>>>>> >>>>>>>> "The problem is that the Storage Guide documentation >>>>>>>> ( >>>>>>>> >>>>>>> >>>>> >>>> >> http://cordova.apache.org/docs/en/3.0.0/cordova_storage_storage.md.html#St >>>>>>>> orage) currently doesn't mention any Android Quirks at all, so >> as >>>>> far as >>>>>>>> user knows it should all work OK as per the API guide." >>>>>>>> >>>>>>>> Yeah - this is what worries me the most. Couldn't the docs be >>>> updated >>>>>>>> pretty quickly to let folks know about issues? >>>>>>>> >>>>>>>> >>>>>>>> On 10/8/13 4:05 PM, "Joe Bowser" wrote: >>>>>>>> >>>>>>>>>What should we do for Storage Plugin issues on Android? >> Should we >>>>> just >>>>>>>>>close them as "Won't Fix" and tell people to use the >> cordova-labs >>>>>>>>>plugins? Currently, we don't have a plugin repo for the >> storage >>>>>>>>>plugin, and it's been ripped out in 3.x. >>>>>>>>> >>>>>>>>>What should we do with these issues?? >>>>>>>>>https://issues.apache.org/jira/browse/CB-4506 >>>>>>>>>https://issues.apache.org/jira/browse/CB-4505 >>>>>>>>>https://issues.apache.org/jira/browse/CB-4760 >>>>>>>>> >>>>>>>>>Thoughts? >>>>>>>>> >>>>>>>>>Joe >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >> >>
Re: So, what to do about storage issues?
Tried out your sample. Certainly shows the problem well. After more playing, I know more about the problem than I think I'd like :P. It's not that you can't open multiple databases, it's that you can create only one database. What I mean is, if you ever restart the app and use a different name for the database, it will fail as well. The only way I could get it to work was to use sqlite3 on the native side to pre-create a second database. If you do that, then you can open multiple at a time. I did it by changing the db path to /sdcard/dbs and using adb to move the files back and forth to my computer. So... I don't think I'm going to invest any more time into this. I just added caveats to the websql README about not being able to open multiple databases. If you really can't live without this feature, you might try writing a plugin that pre-creates a database for you so that you can later open it with openDatabase() On Thu, Oct 10, 2013 at 5:02 AM, Dick Van den Brink < d_vandenbr...@outlook.com> wrote: > Not sure what the namespace issue is, but I created a quick example > project. > It might not be the best code but that doesn't really matter. :-)Code is > on: https://github.com/DickvdBrink/cordova-websql/ > after the checkout you might need to run "android update project --path > platforms/android"It always opens one db, with the name "firstDb" in the > deviceready event.When you click the the text: "Click here to load db with > name "secondDb" I get a security error in the javascript alert box.If you > don't get the error it changes the text to "Second db loaded". > > Date: Wed, 9 Oct 2013 08:44:08 -0700 > > Subject: Re: So, what to do about storage issues? > > From: bows...@gmail.com > > To: dev@cordova.apache.org > > > > I think this is the namespace issue. We need to make sure the plugin > > always overrides the default namespace. > > On Oct 9, 2013 8:00 AM, "Andrew Grieve" wrote: > > > > > Example project would be great! > > > > > > > > > On Wed, Oct 9, 2013 at 10:27 AM, Dick Van den Brink < > > > d_vandenbr...@outlook.com> wrote: > > > > > > > I don't think it is fixed with the org.apache.cordova.websql plugin.I > > > > still can open only one database. The second one is giving me a > security > > > > error on Android 4.1.2. > > > > I'm on Cordova 3.0 btw. I added some logging to the websql plugin > code to > > > > make sure it was using it and that seems to be the case. I can > create an > > > > example project if you want. > > > > > > > > > From: agri...@chromium.org > > > > > Date: Wed, 9 Oct 2013 10:04:14 -0400 > > > > > Subject: Re: So, what to do about storage issues? > > > > > To: dev@cordova.apache.org > > > > > > > > > > I think let's document the quirks (CB-4760), and close the other > two as > > > > > fixed (via org.apache.cordova.websql plugin) > > > > > > > > > > > > > > > On Tue, Oct 8, 2013 at 5:55 PM, Shazron wrote: > > > > > > > > > > > Not sure you guys got Ray's message below if you were on Gmail -- > > > > since it > > > > > > filtered it out as spam (confirmed with another committer/Gmail > user) > > > > :/ > > > > > > > > > > > > > > > > > > On Tue, Oct 8, 2013 at 2:30 PM, Ray Camden > > > wrote: > > > > > > > > > > > > > Hmm, from CB-4760: > > > > > > > > > > > > > > "The problem is that the Storage Guide documentation > > > > > > > ( > > > > > > > > > > > > > > > > > > > > > http://cordova.apache.org/docs/en/3.0.0/cordova_storage_storage.md.html#St > > > > > > > orage) currently doesn't mention any Android Quirks at all, so > as > > > > far as > > > > > > > user knows it should all work OK as per the API guide." > > > > > > > > > > > > > > Yeah - this is what worries me the most. Couldn't the docs be > > > updated > > > > > > > pretty quickly to let folks know about issues? > > > > > > > > > > > > > > > > > > > > > On 10/8/13 4:05 PM, "Joe Bowser" wrote: > > > > > > > > > > > > > > >What should we do for Storage Plugin issues on Android? > Should we > > > > just > > > > > > > >close them as "Won't Fix" and tell people to use the > cordova-labs > > > > > > > >plugins? Currently, we don't have a plugin repo for the > storage > > > > > > > >plugin, and it's been ripped out in 3.x. > > > > > > > > > > > > > > > >What should we do with these issues?? > > > > > > > >https://issues.apache.org/jira/browse/CB-4506 > > > > > > > >https://issues.apache.org/jira/browse/CB-4505 > > > > > > > >https://issues.apache.org/jira/browse/CB-4760 > > > > > > > > > > > > > > > >Thoughts? > > > > > > > > > > > > > > > >Joe > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
RE: So, what to do about storage issues?
Not sure what the namespace issue is, but I created a quick example project. It might not be the best code but that doesn't really matter. :-)Code is on: https://github.com/DickvdBrink/cordova-websql/ after the checkout you might need to run "android update project --path platforms/android"It always opens one db, with the name "firstDb" in the deviceready event.When you click the the text: "Click here to load db with name "secondDb" I get a security error in the javascript alert box.If you don't get the error it changes the text to "Second db loaded". > Date: Wed, 9 Oct 2013 08:44:08 -0700 > Subject: Re: So, what to do about storage issues? > From: bows...@gmail.com > To: dev@cordova.apache.org > > I think this is the namespace issue. We need to make sure the plugin > always overrides the default namespace. > On Oct 9, 2013 8:00 AM, "Andrew Grieve" wrote: > > > Example project would be great! > > > > > > On Wed, Oct 9, 2013 at 10:27 AM, Dick Van den Brink < > > d_vandenbr...@outlook.com> wrote: > > > > > I don't think it is fixed with the org.apache.cordova.websql plugin.I > > > still can open only one database. The second one is giving me a security > > > error on Android 4.1.2. > > > I'm on Cordova 3.0 btw. I added some logging to the websql plugin code to > > > make sure it was using it and that seems to be the case. I can create an > > > example project if you want. > > > > > > > From: agri...@chromium.org > > > > Date: Wed, 9 Oct 2013 10:04:14 -0400 > > > > Subject: Re: So, what to do about storage issues? > > > > To: dev@cordova.apache.org > > > > > > > > I think let's document the quirks (CB-4760), and close the other two as > > > > fixed (via org.apache.cordova.websql plugin) > > > > > > > > > > > > On Tue, Oct 8, 2013 at 5:55 PM, Shazron wrote: > > > > > > > > > Not sure you guys got Ray's message below if you were on Gmail -- > > > since it > > > > > filtered it out as spam (confirmed with another committer/Gmail user) > > > :/ > > > > > > > > > > > > > > > On Tue, Oct 8, 2013 at 2:30 PM, Ray Camden > > wrote: > > > > > > > > > > > Hmm, from CB-4760: > > > > > > > > > > > > "The problem is that the Storage Guide documentation > > > > > > ( > > > > > > > > > > > > > > > > http://cordova.apache.org/docs/en/3.0.0/cordova_storage_storage.md.html#St > > > > > > orage) currently doesn't mention any Android Quirks at all, so as > > > far as > > > > > > user knows it should all work OK as per the API guide." > > > > > > > > > > > > Yeah - this is what worries me the most. Couldn't the docs be > > updated > > > > > > pretty quickly to let folks know about issues? > > > > > > > > > > > > > > > > > > On 10/8/13 4:05 PM, "Joe Bowser" wrote: > > > > > > > > > > > > >What should we do for Storage Plugin issues on Android? Should we > > > just > > > > > > >close them as "Won't Fix" and tell people to use the cordova-labs > > > > > > >plugins? Currently, we don't have a plugin repo for the storage > > > > > > >plugin, and it's been ripped out in 3.x. > > > > > > > > > > > > > >What should we do with these issues?? > > > > > > >https://issues.apache.org/jira/browse/CB-4506 > > > > > > >https://issues.apache.org/jira/browse/CB-4505 > > > > > > >https://issues.apache.org/jira/browse/CB-4760 > > > > > > > > > > > > > >Thoughts? > > > > > > > > > > > > > >Joe > > > > > > > > > > > > > > > > > > > > > > > > >
Re: So, what to do about storage issues?
I think this is the namespace issue. We need to make sure the plugin always overrides the default namespace. On Oct 9, 2013 8:00 AM, "Andrew Grieve" wrote: > Example project would be great! > > > On Wed, Oct 9, 2013 at 10:27 AM, Dick Van den Brink < > d_vandenbr...@outlook.com> wrote: > > > I don't think it is fixed with the org.apache.cordova.websql plugin.I > > still can open only one database. The second one is giving me a security > > error on Android 4.1.2. > > I'm on Cordova 3.0 btw. I added some logging to the websql plugin code to > > make sure it was using it and that seems to be the case. I can create an > > example project if you want. > > > > > From: agri...@chromium.org > > > Date: Wed, 9 Oct 2013 10:04:14 -0400 > > > Subject: Re: So, what to do about storage issues? > > > To: dev@cordova.apache.org > > > > > > I think let's document the quirks (CB-4760), and close the other two as > > > fixed (via org.apache.cordova.websql plugin) > > > > > > > > > On Tue, Oct 8, 2013 at 5:55 PM, Shazron wrote: > > > > > > > Not sure you guys got Ray's message below if you were on Gmail -- > > since it > > > > filtered it out as spam (confirmed with another committer/Gmail user) > > :/ > > > > > > > > > > > > On Tue, Oct 8, 2013 at 2:30 PM, Ray Camden > wrote: > > > > > > > > > Hmm, from CB-4760: > > > > > > > > > > "The problem is that the Storage Guide documentation > > > > > ( > > > > > > > > > > > > http://cordova.apache.org/docs/en/3.0.0/cordova_storage_storage.md.html#St > > > > > orage) currently doesn't mention any Android Quirks at all, so as > > far as > > > > > user knows it should all work OK as per the API guide." > > > > > > > > > > Yeah - this is what worries me the most. Couldn't the docs be > updated > > > > > pretty quickly to let folks know about issues? > > > > > > > > > > > > > > > On 10/8/13 4:05 PM, "Joe Bowser" wrote: > > > > > > > > > > >What should we do for Storage Plugin issues on Android? Should we > > just > > > > > >close them as "Won't Fix" and tell people to use the cordova-labs > > > > > >plugins? Currently, we don't have a plugin repo for the storage > > > > > >plugin, and it's been ripped out in 3.x. > > > > > > > > > > > >What should we do with these issues?? > > > > > >https://issues.apache.org/jira/browse/CB-4506 > > > > > >https://issues.apache.org/jira/browse/CB-4505 > > > > > >https://issues.apache.org/jira/browse/CB-4760 > > > > > > > > > > > >Thoughts? > > > > > > > > > > > >Joe > > > > > > > > > > > > > > > > > > >
Re: So, what to do about storage issues?
Example project would be great! On Wed, Oct 9, 2013 at 10:27 AM, Dick Van den Brink < d_vandenbr...@outlook.com> wrote: > I don't think it is fixed with the org.apache.cordova.websql plugin.I > still can open only one database. The second one is giving me a security > error on Android 4.1.2. > I'm on Cordova 3.0 btw. I added some logging to the websql plugin code to > make sure it was using it and that seems to be the case. I can create an > example project if you want. > > > From: agri...@chromium.org > > Date: Wed, 9 Oct 2013 10:04:14 -0400 > > Subject: Re: So, what to do about storage issues? > > To: dev@cordova.apache.org > > > > I think let's document the quirks (CB-4760), and close the other two as > > fixed (via org.apache.cordova.websql plugin) > > > > > > On Tue, Oct 8, 2013 at 5:55 PM, Shazron wrote: > > > > > Not sure you guys got Ray's message below if you were on Gmail -- > since it > > > filtered it out as spam (confirmed with another committer/Gmail user) > :/ > > > > > > > > > On Tue, Oct 8, 2013 at 2:30 PM, Ray Camden wrote: > > > > > > > Hmm, from CB-4760: > > > > > > > > "The problem is that the Storage Guide documentation > > > > ( > > > > > > > > http://cordova.apache.org/docs/en/3.0.0/cordova_storage_storage.md.html#St > > > > orage) currently doesn't mention any Android Quirks at all, so as > far as > > > > user knows it should all work OK as per the API guide." > > > > > > > > Yeah - this is what worries me the most. Couldn't the docs be updated > > > > pretty quickly to let folks know about issues? > > > > > > > > > > > > On 10/8/13 4:05 PM, "Joe Bowser" wrote: > > > > > > > > >What should we do for Storage Plugin issues on Android? Should we > just > > > > >close them as "Won't Fix" and tell people to use the cordova-labs > > > > >plugins? Currently, we don't have a plugin repo for the storage > > > > >plugin, and it's been ripped out in 3.x. > > > > > > > > > >What should we do with these issues?? > > > > >https://issues.apache.org/jira/browse/CB-4506 > > > > >https://issues.apache.org/jira/browse/CB-4505 > > > > >https://issues.apache.org/jira/browse/CB-4760 > > > > > > > > > >Thoughts? > > > > > > > > > >Joe > > > > > > > > > > > > >
RE: So, what to do about storage issues?
I don't think it is fixed with the org.apache.cordova.websql plugin.I still can open only one database. The second one is giving me a security error on Android 4.1.2. I'm on Cordova 3.0 btw. I added some logging to the websql plugin code to make sure it was using it and that seems to be the case. I can create an example project if you want. > From: agri...@chromium.org > Date: Wed, 9 Oct 2013 10:04:14 -0400 > Subject: Re: So, what to do about storage issues? > To: dev@cordova.apache.org > > I think let's document the quirks (CB-4760), and close the other two as > fixed (via org.apache.cordova.websql plugin) > > > On Tue, Oct 8, 2013 at 5:55 PM, Shazron wrote: > > > Not sure you guys got Ray's message below if you were on Gmail -- since it > > filtered it out as spam (confirmed with another committer/Gmail user) :/ > > > > > > On Tue, Oct 8, 2013 at 2:30 PM, Ray Camden wrote: > > > > > Hmm, from CB-4760: > > > > > > "The problem is that the Storage Guide documentation > > > ( > > > > > http://cordova.apache.org/docs/en/3.0.0/cordova_storage_storage.md.html#St > > > orage) currently doesn't mention any Android Quirks at all, so as far as > > > user knows it should all work OK as per the API guide." > > > > > > Yeah - this is what worries me the most. Couldn't the docs be updated > > > pretty quickly to let folks know about issues? > > > > > > > > > On 10/8/13 4:05 PM, "Joe Bowser" wrote: > > > > > > >What should we do for Storage Plugin issues on Android? Should we just > > > >close them as "Won't Fix" and tell people to use the cordova-labs > > > >plugins? Currently, we don't have a plugin repo for the storage > > > >plugin, and it's been ripped out in 3.x. > > > > > > > >What should we do with these issues?? > > > >https://issues.apache.org/jira/browse/CB-4506 > > > >https://issues.apache.org/jira/browse/CB-4505 > > > >https://issues.apache.org/jira/browse/CB-4760 > > > > > > > >Thoughts? > > > > > > > >Joe > > > > > > > >
Re: So, what to do about storage issues?
I think let's document the quirks (CB-4760), and close the other two as fixed (via org.apache.cordova.websql plugin) On Tue, Oct 8, 2013 at 5:55 PM, Shazron wrote: > Not sure you guys got Ray's message below if you were on Gmail -- since it > filtered it out as spam (confirmed with another committer/Gmail user) :/ > > > On Tue, Oct 8, 2013 at 2:30 PM, Ray Camden wrote: > > > Hmm, from CB-4760: > > > > "The problem is that the Storage Guide documentation > > ( > > > http://cordova.apache.org/docs/en/3.0.0/cordova_storage_storage.md.html#St > > orage) currently doesn't mention any Android Quirks at all, so as far as > > user knows it should all work OK as per the API guide." > > > > Yeah - this is what worries me the most. Couldn't the docs be updated > > pretty quickly to let folks know about issues? > > > > > > On 10/8/13 4:05 PM, "Joe Bowser" wrote: > > > > >What should we do for Storage Plugin issues on Android? Should we just > > >close them as "Won't Fix" and tell people to use the cordova-labs > > >plugins? Currently, we don't have a plugin repo for the storage > > >plugin, and it's been ripped out in 3.x. > > > > > >What should we do with these issues?? > > >https://issues.apache.org/jira/browse/CB-4506 > > >https://issues.apache.org/jira/browse/CB-4505 > > >https://issues.apache.org/jira/browse/CB-4760 > > > > > >Thoughts? > > > > > >Joe > > > > >
Re: So, what to do about storage issues?
Not sure you guys got Ray's message below if you were on Gmail -- since it filtered it out as spam (confirmed with another committer/Gmail user) :/ On Tue, Oct 8, 2013 at 2:30 PM, Ray Camden wrote: > Hmm, from CB-4760: > > "The problem is that the Storage Guide documentation > ( > http://cordova.apache.org/docs/en/3.0.0/cordova_storage_storage.md.html#St > orage) currently doesn't mention any Android Quirks at all, so as far as > user knows it should all work OK as per the API guide." > > Yeah - this is what worries me the most. Couldn't the docs be updated > pretty quickly to let folks know about issues? > > > On 10/8/13 4:05 PM, "Joe Bowser" wrote: > > >What should we do for Storage Plugin issues on Android? Should we just > >close them as "Won't Fix" and tell people to use the cordova-labs > >plugins? Currently, we don't have a plugin repo for the storage > >plugin, and it's been ripped out in 3.x. > > > >What should we do with these issues?? > >https://issues.apache.org/jira/browse/CB-4506 > >https://issues.apache.org/jira/browse/CB-4505 > >https://issues.apache.org/jira/browse/CB-4760 > > > >Thoughts? > > > >Joe > >
Re: So, what to do about storage issues?
I like the idea of graduating stuff from cordova-labs to its own repos. It isn't a huge deal if plugin source lives in cordova-labs for now as people will be downloading it off the cordova registry and won't need to edit the source. Unless they are contributing back of course. On Tue, Oct 8, 2013 at 2:30 PM, Brian LeRoux wrote: > Kind of scared we're going to have a million branches in cordova-labs. Feel > we should should strive to graduate stuff from there into its own repos as > much as possible. Probably should be its own thing given how its been core > forever. > > > On Tue, Oct 8, 2013 at 2:05 PM, Joe Bowser wrote: > > > What should we do for Storage Plugin issues on Android? Should we just > > close them as "Won't Fix" and tell people to use the cordova-labs > > plugins? Currently, we don't have a plugin repo for the storage > > plugin, and it's been ripped out in 3.x. > > > > What should we do with these issues?? > > https://issues.apache.org/jira/browse/CB-4506 > > https://issues.apache.org/jira/browse/CB-4505 > > https://issues.apache.org/jira/browse/CB-4760 > > > > Thoughts? > > > > Joe > > >
Re: So, what to do about storage issues?
Kind of scared we're going to have a million branches in cordova-labs. Feel we should should strive to graduate stuff from there into its own repos as much as possible. Probably should be its own thing given how its been core forever. On Tue, Oct 8, 2013 at 2:05 PM, Joe Bowser wrote: > What should we do for Storage Plugin issues on Android? Should we just > close them as "Won't Fix" and tell people to use the cordova-labs > plugins? Currently, we don't have a plugin repo for the storage > plugin, and it's been ripped out in 3.x. > > What should we do with these issues?? > https://issues.apache.org/jira/browse/CB-4506 > https://issues.apache.org/jira/browse/CB-4505 > https://issues.apache.org/jira/browse/CB-4760 > > Thoughts? > > Joe >
Re: So, what to do about storage issues?
Hmm, from CB-4760: "The problem is that the Storage Guide documentation (http://cordova.apache.org/docs/en/3.0.0/cordova_storage_storage.md.html#St orage) currently doesn't mention any Android Quirks at all, so as far as user knows it should all work OK as per the API guide." Yeah - this is what worries me the most. Couldn't the docs be updated pretty quickly to let folks know about issues? On 10/8/13 4:05 PM, "Joe Bowser" wrote: >What should we do for Storage Plugin issues on Android? Should we just >close them as "Won't Fix" and tell people to use the cordova-labs >plugins? Currently, we don't have a plugin repo for the storage >plugin, and it's been ripped out in 3.x. > >What should we do with these issues?? >https://issues.apache.org/jira/browse/CB-4506 >https://issues.apache.org/jira/browse/CB-4505 >https://issues.apache.org/jira/browse/CB-4760 > >Thoughts? > >Joe
So, what to do about storage issues?
What should we do for Storage Plugin issues on Android? Should we just close them as "Won't Fix" and tell people to use the cordova-labs plugins? Currently, we don't have a plugin repo for the storage plugin, and it's been ripped out in 3.x. What should we do with these issues?? https://issues.apache.org/jira/browse/CB-4506 https://issues.apache.org/jira/browse/CB-4505 https://issues.apache.org/jira/browse/CB-4760 Thoughts? Joe
Re: Windows 8 phone STORAGE support
No. The spec is deprecated. If someone wants to make a plugin, have at it. WP8 supports indexedDB. Cheers, Jesse Sent from my iPhone5 On Jun 14, 2013, at 12:21 PM, William Fung wrote: Hi According to the Cordova STORAGE API reference below, Windows8 phone is not currently supported. http://cordova.apache.org/docs/en/2.8.0/cordova_storage_storage.md.html#Storage I wonder Cordova has any plan to support Windows8 phone in the near future. Thanks! William • Fung Senior Technical Product Manager Verivo Software, Inc. Office: +1 781.795.8255 Mobile: +1 978.790.5614 wf...@verivo.com www.verivo.com<http://www.verivo.com/>
Windows 8 phone STORAGE support
Hi According to the Cordova STORAGE API reference below, Windows8 phone is not currently supported. http://cordova.apache.org/docs/en/2.8.0/cordova_storage_storage.md.html#Storage I wonder Cordova has any plan to support Windows8 phone in the near future. Thanks! William • Fung Senior Technical Product Manager Verivo Software, Inc. Office: +1 781.795.8255 Mobile: +1 978.790.5614 wf...@verivo.com www.verivo.com<http://www.verivo.com/>
[jira] [Commented] (CB-2212) FileSystem getFile() call never finds file on WP8 as isolated storage is empty
[
https://issues.apache.org/jira/browse/CB-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555334#comment-13555334
]
Sergey Grebnov commented on CB-2212:
Hi Michael, you may try to access the file using XmlHttpRequest
var xhr = new XMLHttpRequest();
xhr.open('GET', 'readme.txt', false);
xhr.onreadystatechange = function () {
if (xhr.readyState == 4) {
if (xhr.status == 200) {
console.log(xhr.responseText);
}
}
}
xhr.send(null);
> FileSystem getFile() call never finds file on WP8 as isolated storage is empty
> --
>
> Key: CB-2212
> URL: https://issues.apache.org/jira/browse/CB-2212
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP8
>Affects Versions: 2.3.0
>Reporter: Michael Fry
>Assignee: Jesse MacFadyen
>
> In attempting read a file included in my www folder I was continually
> returned an error code of 0. In digging in it appears it was due to file not
> found.
> In the GapBrowser_Loaded handler there is a large chunk of commented out code
> that notes that in WP8 "isolated storage is no more required in WP8". It
> appears that this suppresses the loading of isolated storage because when I
> view my emulator using WP power tools it is empty.
> The file i/o code in File.cs reads/writes using isolated storage. Without
> the www files being loaded at startup it will never be able to make the reads
> from things like settings or readme files.
> After uncommenting the code and creating a CordovaSourceDictionary.xml file I
> was able to load isolated storage. File reads then worked as designed.
--
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
[jira] [Commented] (CB-2212) FileSystem getFile() call never finds file on WP8 as isolated storage is empty
[
https://issues.apache.org/jira/browse/CB-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555234#comment-13555234
]
Michael Fry commented on CB-2212:
-
Well, to demo it requires a bit of setup but it can be pretty easily replicated
following these steps.
# Create a new project using the Cordova 2.3.0 Standalone template.
# Add a file called readme.txt in the www directory with some random text in it.
# Replace the contents of index.js with this (a mix of the template code and
the file reader example from the documentation):
{code:JavaScript}
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/
var app = {
// Application Constructor
initialize: function() {
this.bindEvents();
},
// Bind Event Listeners
//
// Bind any events that are required on startup. Common events are:
// `load`, `deviceready`, `offline`, and `online`.
bindEvents: function() {
document.addEventListener('deviceready', this.onDeviceReady, false);
},
// deviceready Event Handler
//
// The scope of `this` is the event. In order to call the `receivedEvent`
// function, we must explicity call `app.receivedEvent(...);`
onDeviceReady: function() {
app.receivedEvent('deviceready');
window.requestFileSystem(LocalFileSystem.PERSISTENT, 0, app.gotFS,
app.fail);
},
// Update DOM on a Received Event
receivedEvent: function(id) {
var parentElement = document.getElementById(id);
var listeningElement = parentElement.querySelector('.listening');
var receivedElement = parentElement.querySelector('.received');
listeningElement.setAttribute('style', 'display:none;');
receivedElement.setAttribute('style', 'display:block;');
console.log('Received Event: ' + id);
},
gotFS: function (fileSystem) {
fileSystem.root.getFile("www/readme.txt", null, app.gotFileEntry,
app.fail);
},
gotFileEntry: function (fileEntry) {
fileEntry.file(app.gotFile, app.fail);
},
gotFile: function (file){
app.readAsText(file);
},
readAsText: function (file) {
var reader = new FileReader();
reader.onloadend = function(evt) {
console.log("Read as text");
console.log(evt.target.result);
};
reader.readAsText(file);
},
fail: function (evt) {
console.log(JSON.stringify(evt));
}
};
{code}
# Run the project... In the console you should see the error code: 1 (file not
found)
# Now, to fix the error we need to make sure files are added to isolated
storage.
# Create a CordovaSourceDictionary.xml in the project root and add the
following to it.
{code:xml}
{code}
# Open the code behind file CordovaView.xaml.cs and go to line 254. Uncomment
this large block of code so that the dictionary is parsed and files are added
to isolated storage.
# Run again... the contents of readme.txt will now be shown in the console.
The problem lies in the File.cs Command class. The call to GetFileOrDirectory
counts on the files being in IsolatedStorage. With the code commented out in
CordovaView.xaml.cs this is never created and then any attempts to use the
FileReader will not work.
> FileSystem getFile() call never finds file on WP8 as isolated storage is empty
> --
>
> Key: CB-2212
> URL: https://issues.apache.org/jira/browse/CB-2212
> Project: Apache Cordova
> Issue Type: Bug
> Components: WP8
>Affects Versions: 2.3.0
>Reporter: Michael Fry
>Assignee: Jesse MacFadyen
>
> In attempting read a file included in my www folder I was continually
> returned an error code of 0. In digging in it appears it was due to file not
> found.
> In the GapBrowser_Loaded handler there is a large chunk of commented out code
> that notes
[jira] [Commented] (CB-2212) FileSystem getFile() call never finds file on WP8 as isolated storage is empty
[ https://issues.apache.org/jira/browse/CB-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552959#comment-13552959 ] Jesse MacFadyen commented on CB-2212: - Thanks Michael Can you post a brief example demonstrating the issue? > FileSystem getFile() call never finds file on WP8 as isolated storage is empty > -- > > Key: CB-2212 > URL: https://issues.apache.org/jira/browse/CB-2212 > Project: Apache Cordova > Issue Type: Bug > Components: WP8 >Affects Versions: 2.3.0 >Reporter: Michael Fry >Assignee: Jesse MacFadyen > > In attempting read a file included in my www folder I was continually > returned an error code of 0. In digging in it appears it was due to file not > found. > In the GapBrowser_Loaded handler there is a large chunk of commented out code > that notes that in WP8 "isolated storage is no more required in WP8". It > appears that this suppresses the loading of isolated storage because when I > view my emulator using WP power tools it is empty. > The file i/o code in File.cs reads/writes using isolated storage. Without > the www files being loaded at startup it will never be able to make the reads > from things like settings or readme files. > After uncommenting the code and creating a CordovaSourceDictionary.xml file I > was able to load isolated storage. File reads then worked as designed. -- 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
[jira] [Created] (CB-2212) FileSystem getFile() call never finds file on WP8 as isolated storage is empty
Michael Fry created CB-2212: --- Summary: FileSystem getFile() call never finds file on WP8 as isolated storage is empty Key: CB-2212 URL: https://issues.apache.org/jira/browse/CB-2212 Project: Apache Cordova Issue Type: Bug Components: WP8 Affects Versions: 2.3.0 Reporter: Michael Fry Assignee: Jesse MacFadyen In attempting read a file included in my www folder I was continually returned an error code of 0. In digging in it appears it was due to file not found. In the GapBrowser_Loaded handler there is a large chunk of commented out code that notes that in WP8 "isolated storage is no more required in WP8". It appears that this suppresses the loading of isolated storage because when I view my emulator using WP power tools it is empty. The file i/o code in File.cs reads/writes using isolated storage. Without the www files being loaded at startup it will never be able to make the reads from things like settings or readme files. After uncommenting the code and creating a CordovaSourceDictionary.xml file I was able to load isolated storage. File reads then worked as designed. -- 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
Re: Query regarding Storage Class...
Hi Kumail, try a Google search for "phonegap sqllite plugin". Looks like one already exists. On Thu, Nov 8, 2012 at 6:50 AM, Kumail Raza wrote: > > Hi! > > Dear, > > First of all thanks to all the team mate of Apache Cordova Library, thats > really a great piece of work due to which developer could easily develop > application over vast platform. > > Coming to words my problem, > > I want to access SQLiteDatabase file which is located on my SDCARD, but I > did'nt find any of such example code for that over the Internet, please it > would be really helpful for me, If you add the section on your website with > the heading "Accessing SQLiteDB from SDCARD using your API". > > If in case this feature not added yet, in the library, I will be waiting > for this feature to be add as soon as possible. > > > Thanks. > > Regards, > Kumail Raza > +923343104692 >
Query regarding Storage Class...
Hi! Dear, First of all thanks to all the team mate of Apache Cordova Library, thats really a great piece of work due to which developer could easily develop application over vast platform. Coming to words my problem, I want to access SQLiteDatabase file which is located on my SDCARD, but I did'nt find any of such example code for that over the Internet, please it would be really helpful for me, If you add the section on your website with the heading "Accessing SQLiteDB from SDCARD using your API". If in case this feature not added yet, in the library, I will be waiting for this feature to be add as soon as possible. Thanks. Regards, Kumail Raza +923343104692
[jira] [Resolved] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Mocny resolved CB-1561. -- Resolution: Fixed Marking this as fixed since the original scope of this bug is no longer being discussed. If we think migration from 5.0 is still important, we can file another issue. If we want more fine grained customization of cloud backup, and file api setMetadata is insufficient, we can file another issue. > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486395#comment-13486395 ] Samuel Michelot commented on CB-1561: - Ok, sorry, you are right, WebKit/Databases for ios 5.0 With a large user base, you can be sure that every migration path will be used. I you don't want to handle that case, I will have to handle it in my AppDelegate. I am also testing by moving folders across iOS simulator folder. Thanks for your work Michal! > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486301#comment-13486301 ] Michal Mocny commented on CB-1561: -- 5.1->6.0 should work properly now. For some reason I was still getting proper backups locally even with the wrong patch -- I think that when you set the ios6 cloud backup user default it may automatically restore from the old location -- but the way I am testing is by moving folders around across ios simulator version app directories, not by actually upgrading. > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486283#comment-13486283 ] Michal Mocny commented on CB-1561: -- ios5.1: March 7, 2012 > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486277#comment-13486277 ] Michal Mocny commented on CB-1561: -- Samuel, Yes I agree about the first gen iPad, but anyway who would be updating to 5.1 on it would have done so months ago, right? > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[
https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486275#comment-13486275
]
Michal Mocny commented on CB-1561:
--
Samuel, I've just downloaded ios5.0 simulator and I see websql stores in
Library/WebKit/Databases/
My reading of the old migration patch suggests it never worked anyway, but I
haven't tried it yet.
Either way, I'm not sure that migration from 5.0 is something that needs
fixing. I will update the 5.1->6.0, however.
> Using Storage API - rejected by Apple
> -
>
> Key: CB-1561
> URL: https://issues.apache.org/jira/browse/CB-1561
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS
>Affects Versions: 2.0.0, 2.1.0, 2.2.0
> Environment: - Cordova 2.0 on iOS
>Reporter: Clemens Wyss
>Assignee: Michal Mocny
>Priority: Blocker
> Fix For: 2.2.0
>
> Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff
>
>
> our App uses the Sotrage-API to store data which is being loaded upon first
> launch.
> The app is rejected given the following reasoning:
> 'Your app does not follow the iOS Data Storage Guidelines, as required by the
> App Store Review Guidelines.
> Please be sure to set the "Do not back up" attribute for all data which is
> not generated or modified by the user. To check how much data your app is
> storing:
> - Install and launch your app
> - Go to Settings > iCloud > Storage and Backup > Manage Storage
> - If necessary, select "Show all apps"
> - Check your app's storage
> The iOS Data Storage Guidelines indicate that only content that the user
> creates using your app, (documents, new files, edits, etc.) may be stored in
> the /Documents directory - and backed up to iCloud.
> Temporary files used by your app should only be stored in the /tmp directory.
> Please remember to delete the files stored in this location when the user
> exits the app.
> Data that can be recreated but must persist for proper functioning of your
> app or because customers expect it to be available for offline use should be
> appended with the "do not back up" attribute. For NSURL objects, add the
> NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from
> being backed up. For CFURLRef objects, use the corresponding
> kCFURLIsExcludedFromBackupKey attribute.
> For more information, please see Technical Q&A 1719: How do I prevent files
> from being backed up to iCloud and iTunes?.
> Please revise your app so that it adheres to the iOS Data Storage Guidelines.'
> Is there a possibility to set this flag for the WebSQL Database file(s)?
> At least for us this is a blocker ...
--
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
[jira] [Comment Edited] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486268#comment-13486268 ] Samuel Michelot edited comment on CB-1561 at 10/29/12 7:33 PM: --- Michal : No, at least in the simulator, the location for WebSQL in iOS 5.0 is also WebKit/LocalStorage I can't say if it's was working before, because I was using an older version of phonegap with a migration patch (if it's help, here is the code : https://gist.github.com/3975955 ), basically it's only copying from WebKit to Cache. It's useful at least for the first gen iPad upgrading to 5.1 (their latest iOS version available :https://en.wikipedia.org/wiki/List_of_iOS_devices#iPad) was (Author: mosamich): Michal : No, at least in the simulator, the location for WebSQL in iOS 5.0 is also WebKit/LocalStorage I can't say if it's was working before, because I was using an older version of phonegap with a migration patch (if it's help, here is the code : https://gist.github.com/3975955 ), basically it's only copying from WebKit to Cache. > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Comment Edited] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486268#comment-13486268 ] Samuel Michelot edited comment on CB-1561 at 10/29/12 7:30 PM: --- Michal : No, at least in the simulator, the location for WebSQL in iOS 5.0 is also WebKit/LocalStorage I can't say if it's was working before, because I was using an older version of phonegap with a migration patch (if it's help, here is the code : https://gist.github.com/3975955 ), basically it's only copying from WebKit to Cache. was (Author: mosamich): Michal : No, at least in the simulator, the location for WebSQL in iOS 5.0 is also WebKit/LocalStorage I can't say if it's was working before, because I was using an older version of phonegap with a migration patch. > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Comment Edited] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486268#comment-13486268 ] Samuel Michelot edited comment on CB-1561 at 10/29/12 7:25 PM: --- Michal : No, at least in the simulator, the location for WebSQL in iOS 5.0 is also WebKit/LocalStorage I can't say if it's was working before, because I was using an older version of phonegap with a migration patch. was (Author: mosamich): Michal : No, at least in the simulator, the location for WebSQL in iOS 5.0 is also WebKit/LocalStorage > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486268#comment-13486268 ] Samuel Michelot commented on CB-1561: - Michal : No, at least in the simulator, the location for WebSQL in iOS 5.0 is also WebKit/LocalStorage > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[
https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486263#comment-13486263
]
Michal Mocny commented on CB-1561:
--
Aaron,
You are correct, this is all or nothing. The feature you request is not
supported, has not been, and would be difficult to do well given that the iOS6
UserDefaults value for cloud backup is also all-or-nothing.
However, I think there is another workaround for you: if you enable
local-backup-only, then you can use the File API to reset metadata on the
LocalStorage backups to re-enable cloud backup just for that.
(NSURLIsExcludedFromBackupKey on Documents/Backups/{localstorage file or
whichever you need} using File API's FileEntry.setMetadata function)
If the workaround is insufficient, please file a feature request, and patches
are welcome for 2.3 release.
> Using Storage API - rejected by Apple
> -
>
> Key: CB-1561
> URL: https://issues.apache.org/jira/browse/CB-1561
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS
>Affects Versions: 2.0.0, 2.1.0, 2.2.0
> Environment: - Cordova 2.0 on iOS
>Reporter: Clemens Wyss
>Assignee: Michal Mocny
>Priority: Blocker
> Fix For: 2.2.0
>
> Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff
>
>
> our App uses the Sotrage-API to store data which is being loaded upon first
> launch.
> The app is rejected given the following reasoning:
> 'Your app does not follow the iOS Data Storage Guidelines, as required by the
> App Store Review Guidelines.
> Please be sure to set the "Do not back up" attribute for all data which is
> not generated or modified by the user. To check how much data your app is
> storing:
> - Install and launch your app
> - Go to Settings > iCloud > Storage and Backup > Manage Storage
> - If necessary, select "Show all apps"
> - Check your app's storage
> The iOS Data Storage Guidelines indicate that only content that the user
> creates using your app, (documents, new files, edits, etc.) may be stored in
> the /Documents directory - and backed up to iCloud.
> Temporary files used by your app should only be stored in the /tmp directory.
> Please remember to delete the files stored in this location when the user
> exits the app.
> Data that can be recreated but must persist for proper functioning of your
> app or because customers expect it to be available for offline use should be
> appended with the "do not back up" attribute. For NSURL objects, add the
> NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from
> being backed up. For CFURLRef objects, use the corresponding
> kCFURLIsExcludedFromBackupKey attribute.
> For more information, please see Technical Q&A 1719: How do I prevent files
> from being backed up to iCloud and iTunes?.
> Please revise your app so that it adheres to the iOS Data Storage Guidelines.'
> Is there a possibility to set this flag for the WebSQL Database file(s)?
> At least for us this is a blocker ...
--
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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[
https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486245#comment-13486245
]
Aaron Moman commented on CB-1561:
-
It looks like the new configuration is all or nothing. Meaning both local
storage and WebSql databases are iCloud, local or no backup, but you can't have
separate settings for local storage and databases. Is that correct? If so,
can you change it so that each are configurable separately? I have data that
needs to be backed up in local storage, but a database that shouldn't be backed
up.
Sorry to make this even more complicated than it already is...
Thanks,
Aaron
> Using Storage API - rejected by Apple
> -
>
> Key: CB-1561
> URL: https://issues.apache.org/jira/browse/CB-1561
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS
>Affects Versions: 2.0.0, 2.1.0, 2.2.0
> Environment: - Cordova 2.0 on iOS
>Reporter: Clemens Wyss
>Assignee: Michal Mocny
>Priority: Blocker
> Fix For: 2.2.0
>
> Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff
>
>
> our App uses the Sotrage-API to store data which is being loaded upon first
> launch.
> The app is rejected given the following reasoning:
> 'Your app does not follow the iOS Data Storage Guidelines, as required by the
> App Store Review Guidelines.
> Please be sure to set the "Do not back up" attribute for all data which is
> not generated or modified by the user. To check how much data your app is
> storing:
> - Install and launch your app
> - Go to Settings > iCloud > Storage and Backup > Manage Storage
> - If necessary, select "Show all apps"
> - Check your app's storage
> The iOS Data Storage Guidelines indicate that only content that the user
> creates using your app, (documents, new files, edits, etc.) may be stored in
> the /Documents directory - and backed up to iCloud.
> Temporary files used by your app should only be stored in the /tmp directory.
> Please remember to delete the files stored in this location when the user
> exits the app.
> Data that can be recreated but must persist for proper functioning of your
> app or because customers expect it to be available for offline use should be
> appended with the "do not back up" attribute. For NSURL objects, add the
> NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from
> being backed up. For CFURLRef objects, use the corresponding
> kCFURLIsExcludedFromBackupKey attribute.
> For more information, please see Technical Q&A 1719: How do I prevent files
> from being backed up to iCloud and iTunes?.
> Please revise your app so that it adheres to the iOS Data Storage Guidelines.'
> Is there a possibility to set this flag for the WebSQL Database file(s)?
> At least for us this is a blocker ...
--
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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486235#comment-13486235 ] Michal Mocny commented on CB-1561: -- Okay, it looks like the location for websql was WebKit/Databases folder in 5.0, changed to Caches in 5.1, and then to WebKit/LocalStorage in 6.0. Working on confirmation (pulling 5.0 simulator), and updating plugin now. > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486214#comment-13486214 ] Michal Mocny commented on CB-1561: -- Samuel, seems you are right. Updating change now -- not sure how this used to work. > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486201#comment-13486201 ] Michal Mocny commented on CB-1561: -- migration from ios5.0 to 5.1 was not added -- this wasn't supported before either. I did add migration from 5.1 to 6.0 which is currently relevant. Is there any reason anyone is still on 5.0 and will be upgrading? > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486199#comment-13486199 ] Michal Mocny commented on CB-1561: -- Databases are stored in the LocalStorage directory? I took the WebKit/Databases path right from the cordova 2.0 release that supported migration from 5.0 to 5.1. Did migrating from 5.0 to 5.1 never work? > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486185#comment-13486185 ] Samuel Michelot commented on CB-1561: - And the migration from iOS 5.0 to iOS5.1 doesn't work either. The code should move the WebKit/LocalStorage to Caches/ folder. > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486183#comment-13486183 ] Samuel Michelot commented on CB-1561: - Hi Michal, I found a bug, the migration from iOS5.1 to iOS6 doesn't work, because the file are moved to Webkit/Databases directory instead of WebKit/LocalStorage. To fix the bug, just change the "Databases" refs to LocalStorage : // // WEBSQL MAIN DB original = [targetDir stringByAppendingPathComponent:targetDirNests ? @"WebKit/LocalStorage/Databases.db":@"Databases.db"]; backup = [backupDir stringByAppendingPathComponent:(backupDirNests ? @"WebKit/LocalStorage":@"")]; ... // // WEBSQL DATABASES original = [targetDir stringByAppendingPathComponent:targetDirNests ? @"WebKit/LocalStorage/file__0":@"file__0"]; backup = [backupDir stringByAppendingPathComponent:(backupDirNests ? @"WebKit/LocalStorage":@"")]; > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484993#comment-13484993 ] Michal Mocny commented on CB-1561: -- Sam, seems not officially yet, but close! Either way you could also grab tip of tree to test, if you are already set up to do that. Thanks. > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
[jira] [Commented] (CB-1561) Using Storage API - rejected by Apple
[ https://issues.apache.org/jira/browse/CB-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484988#comment-13484988 ] Samuel Michelot commented on CB-1561: - 2.2 RC2 still not released? I can help to test... > Using Storage API - rejected by Apple > - > > Key: CB-1561 > URL: https://issues.apache.org/jira/browse/CB-1561 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.0.0, 2.1.0, 2.2.0 > Environment: - Cordova 2.0 on iOS >Reporter: Clemens Wyss >Assignee: Michal Mocny >Priority: Blocker > Fix For: 2.2.0 > > Attachments: CDVLocalStorage.m.diff, disable_icloud_backup.diff > > > our App uses the Sotrage-API to store data which is being loaded upon first > launch. > The app is rejected given the following reasoning: > 'Your app does not follow the iOS Data Storage Guidelines, as required by the > App Store Review Guidelines. > Please be sure to set the "Do not back up" attribute for all data which is > not generated or modified by the user. To check how much data your app is > storing: > - Install and launch your app > - Go to Settings > iCloud > Storage and Backup > Manage Storage > - If necessary, select "Show all apps" > - Check your app's storage > The iOS Data Storage Guidelines indicate that only content that the user > creates using your app, (documents, new files, edits, etc.) may be stored in > the /Documents directory - and backed up to iCloud. > Temporary files used by your app should only be stored in the /tmp directory. > Please remember to delete the files stored in this location when the user > exits the app. > Data that can be recreated but must persist for proper functioning of your > app or because customers expect it to be available for offline use should be > appended with the "do not back up" attribute. For NSURL objects, add the > NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from > being backed up. For CFURLRef objects, use the corresponding > kCFURLIsExcludedFromBackupKey attribute. > For more information, please see Technical Q&A 1719: How do I prevent files > from being backed up to iCloud and iTunes?. > Please revise your app so that it adheres to the iOS Data Storage Guidelines.' > Is there a possibility to set this flag for the WebSQL Database file(s)? > At least for us this is a blocker ... -- 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
