[jira] [Commented] (CB-1754) Enable changing iOS setStatusBarHidden:withAnimation: from JavaScript
[ https://issues.apache.org/jira/browse/CB-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486654#comment-13486654 ] Shazron Abdullah commented on CB-1754: -- Not sure about support for this feature on the other platforms for this to be a first-class API. In any case, a third-party plugin would be best for this: http://docs.phonegap.com/en/2.1.0/guide_plugin-development_index.md.html#Plugin%20Development%20Guide > Enable changing iOS setStatusBarHidden:withAnimation: from JavaScript > - > > Key: CB-1754 > URL: https://issues.apache.org/jira/browse/CB-1754 > Project: Apache Cordova > Issue Type: New Feature > Components: iOS >Affects Versions: 2.1.0 >Reporter: Stephen McKamey >Assignee: Shazron Abdullah > Labels: iOS,, statusbar > > While it is easy to set the initial value of > setStatusBarHidden:withAnimation: for a Cordova project, it would be really > convenient at times to be able to change its setting from JavaScript. > Even if it was an iOS specific call via the Native-JS bridge, it would make > the user experience better in a lot of apps. Obviously, if other platforms > allow similar functionality then it would be great if it were a first-class > concept like the rest of the API. -- 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: Rename Jira?
I agree, leave it as a legacy of the branding attempt that shall not be named > IMHO it is not worth the bother. Leave it as and if anyone ask what CB > stands for tell them "Cordova Bug" an elegant solution On Mon, Oct 29, 2012 at 7:55 PM, Michael Brooks wrote: > Agree. Leave it as CB. > > Michael > > On Mon, Oct 29, 2012 at 5:32 PM, Simon MacDonald > wrote: > > > IMHO it is not worth the bother. Leave it as and if anyone ask what CB > > stands for tell them "Cordova Bug" > > > > Simon Mac Donald > > http://hi.im/simonmacdonald > > > > > > On Mon, Oct 29, 2012 at 8:09 PM, Shazron wrote: > > > > > In my opinion, let's not bother (it'll be Github > > > PhoneGap/Callback/Cordova issues all over again -- all issue links in > > > Google would die, unless we can re-direct). > > > > > > CB could (in our heads at least) be the abbreviation for Cordóba the > > > Spanish version of Cordova ;) > > > > > > On Mon, Oct 29, 2012 at 4:58 PM, Steven Gill > > > wrote: > > > > Wondering if it is worth changing > > > https://issues.apache.org/jira/browse/CB > > > > to https://issues.apache.org/jira/browse/CORDOVA > > > > > > > > Infra says we would have to create a new project and bulk move > > everything > > > > over. You can view the ticket at > > > > https://issues.apache.org/jira/browse/INFRA-5435. > > > > > > > > I'm leaning towards not bothering with this. > > > > > > > > Thoughts? > > > > -Steve > > > > > >
Re: tagging 2.2.0
Waiting on confirmation for https://issues.apache.org/jira/browse/CB-1561 And will land patch for on resign event working with less quirks tomorrow. Since thats been borked already the whole time, its not a high risk item. On Mon, Oct 29, 2012 at 9:57 PM, Marcel Kinard wrote: > +1, but I'd like to see a resolution to the license issue included. > > -- Marcel Kinard > > On 10/29/2012 4:27 PM, Brian LeRoux wrote: >> >> EOD tmrw? > >
Re: [ios] Evaluating JS during onAppWillResignActive
Yes, and I forgot I filed that already, so thanks ;) I'll put up the patch tomorrow. Its still limited what you can do, nothing async that uses setTimeout etc, but its nice to be able to use console log and so make certain plugin calls, such as notifications. On Mon, Oct 29, 2012 at 7:22 PM, Shazron wrote: > Great Michal! > I assume it's related to this: https://issues.apache.org/jira/browse/CB-1746 > Since its a blocker I assume we want to make this in before releasing 2.2.0. > > On Mon, Oct 29, 2012 at 12:21 PM, Michal Mocny wrote: >> Success! >> >> After some debugging with Andrew, we have been able to make the exec >> bridge work even in resign event. (Testing pause event, too). >> >> I've uncovered a few bugs in the process and patches will be up soon, >> but long story short, I've got local notifications being scheduled on >> app resign, huzzah! >> >> On Sat, Oct 27, 2012 at 4:36 PM, Michal Mocny wrote: >>> Thanks for the link, Shaz. >>> >>> On Fri, Oct 26, 2012 at 10:40 PM, Shazron wrote: This is something we encountered when playing with the pause and resume events. More details in the iOS Quirks of http://docs.phonegap.com/en/2.1.0/cordova_events_events.md.html#pause On Fri, Oct 26, 2012 at 8:29 AM, Michal Mocny wrote: > Local Notifications, especially on ios, are most useful when app is in > the background. It would be handy to be able to schedule them during > the window of time allotted during onAppWillResignActive. > > We even already have handlers for js document events 'resign' and > 'pause' (this one is for a > onAppDidEnterBackground event). (There are some issues with the > javascript here, seems the events aren't properly defined, will file > separately). > > However, no matter how I try, I cannot get more then a trivial amount > of js to execute during the time window before app pauses -- far less > than the allowed 5 seconds. > > According to the only (unreliable) source I've found on the subject, > its simply not possible to use the webview during > onAppWillResignActive: > http://stackoverflow.com/questions/4865742/iphone-webview-onbackground-event > > Does anyone have a better answer here? > > Thanks, > -Michal
Re: Rename Jira?
Agree. Leave it as CB. Michael On Mon, Oct 29, 2012 at 5:32 PM, Simon MacDonald wrote: > IMHO it is not worth the bother. Leave it as and if anyone ask what CB > stands for tell them "Cordova Bug" > > Simon Mac Donald > http://hi.im/simonmacdonald > > > On Mon, Oct 29, 2012 at 8:09 PM, Shazron wrote: > > > In my opinion, let's not bother (it'll be Github > > PhoneGap/Callback/Cordova issues all over again -- all issue links in > > Google would die, unless we can re-direct). > > > > CB could (in our heads at least) be the abbreviation for Cordóba the > > Spanish version of Cordova ;) > > > > On Mon, Oct 29, 2012 at 4:58 PM, Steven Gill > > wrote: > > > Wondering if it is worth changing > > https://issues.apache.org/jira/browse/CB > > > to https://issues.apache.org/jira/browse/CORDOVA > > > > > > Infra says we would have to create a new project and bulk move > everything > > > over. You can view the ticket at > > > https://issues.apache.org/jira/browse/INFRA-5435. > > > > > > I'm leaning towards not bothering with this. > > > > > > Thoughts? > > > -Steve > > >
Re: tagging 2.2.0
+1, but I'd like to see a resolution to the license issue included. -- Marcel Kinard On 10/29/2012 4:27 PM, Brian LeRoux wrote: EOD tmrw?
[jira] [Created] (CB-1754) Enable changing iOS setStatusBarHidden:withAnimation: from JavaScript
Stephen McKamey created CB-1754: --- Summary: Enable changing iOS setStatusBarHidden:withAnimation: from JavaScript Key: CB-1754 URL: https://issues.apache.org/jira/browse/CB-1754 Project: Apache Cordova Issue Type: New Feature Components: iOS Affects Versions: 2.1.0 Reporter: Stephen McKamey Assignee: Shazron Abdullah While it is easy to set the initial value of setStatusBarHidden:withAnimation: for a Cordova project, it would be really convenient at times to be able to change its setting from JavaScript. Even if it was an iOS specific call via the Native-JS bridge, it would make the user experience better in a lot of apps. Obviously, if other platforms allow similar functionality then it would be great if it were a first-class concept like the rest of the API. -- 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: Rename Jira?
IMHO it is not worth the bother. Leave it as and if anyone ask what CB stands for tell them "Cordova Bug" Simon Mac Donald http://hi.im/simonmacdonald On Mon, Oct 29, 2012 at 8:09 PM, Shazron wrote: > In my opinion, let's not bother (it'll be Github > PhoneGap/Callback/Cordova issues all over again -- all issue links in > Google would die, unless we can re-direct). > > CB could (in our heads at least) be the abbreviation for Cordóba the > Spanish version of Cordova ;) > > On Mon, Oct 29, 2012 at 4:58 PM, Steven Gill > wrote: > > Wondering if it is worth changing > https://issues.apache.org/jira/browse/CB > > to https://issues.apache.org/jira/browse/CORDOVA > > > > Infra says we would have to create a new project and bulk move everything > > over. You can view the ticket at > > https://issues.apache.org/jira/browse/INFRA-5435. > > > > I'm leaning towards not bothering with this. > > > > Thoughts? > > -Steve >
Re: Rename Jira?
In my opinion, let's not bother (it'll be Github PhoneGap/Callback/Cordova issues all over again -- all issue links in Google would die, unless we can re-direct). CB could (in our heads at least) be the abbreviation for Cordóba the Spanish version of Cordova ;) On Mon, Oct 29, 2012 at 4:58 PM, Steven Gill wrote: > Wondering if it is worth changing https://issues.apache.org/jira/browse/CB > to https://issues.apache.org/jira/browse/CORDOVA > > Infra says we would have to create a new project and bulk move everything > over. You can view the ticket at > https://issues.apache.org/jira/browse/INFRA-5435. > > I'm leaning towards not bothering with this. > > Thoughts? > -Steve
Re: Rename Jira?
Agree to solving this by marking it resolved. On Mon, Oct 29, 2012 at 4:58 PM, Steven Gill wrote: > Wondering if it is worth changing https://issues.apache.org/jira/browse/CB > to https://issues.apache.org/jira/browse/CORDOVA > > Infra says we would have to create a new project and bulk move everything > over. You can view the ticket at > https://issues.apache.org/jira/browse/INFRA-5435. > > I'm leaning towards not bothering with this. > > Thoughts? > -Steve
Rename Jira?
Wondering if it is worth changing https://issues.apache.org/jira/browse/CB to https://issues.apache.org/jira/browse/CORDOVA Infra says we would have to create a new project and bulk move everything over. You can view the ticket at https://issues.apache.org/jira/browse/INFRA-5435. I'm leaning towards not bothering with this. Thoughts? -Steve
Re: [ios] Evaluating JS during onAppWillResignActive
Great Michal! I assume it's related to this: https://issues.apache.org/jira/browse/CB-1746 Since its a blocker I assume we want to make this in before releasing 2.2.0. On Mon, Oct 29, 2012 at 12:21 PM, Michal Mocny wrote: > Success! > > After some debugging with Andrew, we have been able to make the exec > bridge work even in resign event. (Testing pause event, too). > > I've uncovered a few bugs in the process and patches will be up soon, > but long story short, I've got local notifications being scheduled on > app resign, huzzah! > > On Sat, Oct 27, 2012 at 4:36 PM, Michal Mocny wrote: >> Thanks for the link, Shaz. >> >> On Fri, Oct 26, 2012 at 10:40 PM, Shazron wrote: >>> This is something we encountered when playing with the pause and >>> resume events. More details in the iOS Quirks of >>> http://docs.phonegap.com/en/2.1.0/cordova_events_events.md.html#pause >>> >>> On Fri, Oct 26, 2012 at 8:29 AM, Michal Mocny wrote: Local Notifications, especially on ios, are most useful when app is in the background. It would be handy to be able to schedule them during the window of time allotted during onAppWillResignActive. We even already have handlers for js document events 'resign' and 'pause' (this one is for a onAppDidEnterBackground event). (There are some issues with the javascript here, seems the events aren't properly defined, will file separately). However, no matter how I try, I cannot get more then a trivial amount of js to execute during the time window before app pauses -- far less than the allowed 5 seconds. According to the only (unreliable) source I've found on the subject, its simply not possible to use the webview during onAppWillResignActive: http://stackoverflow.com/questions/4865742/iphone-webview-onbackground-event Does anyone have a better answer here? Thanks, -Michal
[jira] [Updated] (CB-1406) HTTP-Get via XHR in Web Workers always return status 0 under iOS 6 (Beta 4)
[ https://issues.apache.org/jira/browse/CB-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-1406: - Fix Version/s: (was: 2.2.0) 2.3.0 Punt to 2.3.0 > HTTP-Get via XHR in Web Workers always return status 0 under iOS 6 (Beta 4) > --- > > Key: CB-1406 > URL: https://issues.apache.org/jira/browse/CB-1406 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.1.0 > Environment: all iOS devices and simulators >Reporter: Jochen Magnus >Assignee: Michal Mocny > Labels: HTTP, WebWorker, XHR > Fix For: 2.3.0 > > Attachments: testworker.js, workertest2.tar.bz2, workertest.html, > xhr_tests.png > > > HTTPRequests in the Web Workers ending always with http.readyState==4 > (that's the ready state) but with http.status==0, which is an undefined > status (normal is 200 for "o.k."). The file is requested from and fully > deliverd by the webserver. > This happens under iOS 6 Beta 4 but not under iOS 5.x where the same app with > the same Cordova version works well. > The problem did not occur with XHR in the native programs main thread nor in > non-native HTML5-apps (WebApps without the use of Cordova). > A Xcode test project is available. -- 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] [Updated] (CB-1547) onReset and onHandleOpenUrl are wrongly called when there are two CDVWebViews present at the same time.
[ https://issues.apache.org/jira/browse/CB-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-1547: - Fix Version/s: (was: 2.2.0) 2.3.0 Punt to 2.3.0 > onReset and onHandleOpenUrl are wrongly called when there are two CDVWebViews > present at the same time. > --- > > Key: CB-1547 > URL: https://issues.apache.org/jira/browse/CB-1547 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: Master >Reporter: Andrew Grieve >Assignee: Andrew Grieve >Priority: Minor > Fix For: 2.3.0 > > > The issue here is that we are using NSNotificationCenter to broadcast & > listen to events, but plugins to not restrict to their associated webview. > We can fix this by not using NotificationCenter, or by restricting the > listener to the webview object. -- 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] [Updated] (CB-1603) Compass / Geolocation issue on iOS 6 (iPhone)
[ https://issues.apache.org/jira/browse/CB-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-1603: - Fix Version/s: (was: 2.2.0) 2.3.0 Punt to 2.3.0 > Compass / Geolocation issue on iOS 6 (iPhone) > - > > Key: CB-1603 > URL: https://issues.apache.org/jira/browse/CB-1603 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.1.0 > Environment: iPhone 5, iOS 6 >Reporter: Martin Ambrus >Assignee: Michal Mocny >Priority: Minor > Labels: geolocation, location > Fix For: 2.3.0 > > Attachments: index.html > > > Applications targeted for iPhone (iOS 4.3+) using Cordova 2.1 and developed > in XCode 4.5 automatically turn on Compass / Geolocation. This is true only > for devices that have iOS 6 installed. User is never asked if they want to > reveal their location to the app, so it's probably the Compass plugin kicking > in. > What we see is the compass arrow on the right-hand top side of iPhone screen > (status bar). When the application closes, arrow disappears. > This is an issue for us, as it drains considerably more battery than version > running on iOS 5.1, where this problem does not exist. > We have tried to remove all - Location, Compass and GeoLocation plugins from > the Cordova.plist to no avail. -- 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] [Updated] (CB-1738) PhoneGap iOS 6 - network.connection.type issue when turning OFF airplane mode
[
https://issues.apache.org/jira/browse/CB-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shazron Abdullah updated CB-1738:
-
Fix Version/s: (was: 2.2.0)
2.3.0
Punt to 2.3.0
> PhoneGap iOS 6 - network.connection.type issue when turning OFF airplane mode
> --
>
> Key: CB-1738
> URL: https://issues.apache.org/jira/browse/CB-1738
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS
>Affects Versions: 1.5.0, 2.0.0
> Environment: i am testing on two iPhone4 one running OS5 ,and one on
> OS6
>Reporter: Jasper
>Assignee: Shazron Abdullah
>Priority: Minor
> Labels: ios, network.connection
> Fix For: 2.3.0
>
>
> update on 26Oct, 2012
> After more investigation I think this probably is an iOS6 issue
> The PhoneGap API returns "wifi" when the wifi symbol actually shows up ( the
> radio status probably doesn't matter ) on banner
> My application will invoke an RPC , which will fail due to error "A server
> with specified hostname could not be found" Code= 1003
> So I think the problem is iOS6 lies about the status, It says wifi is ready
> while it is not entirely. From my observation error occurs within 15s after
> wifi symbol shows up. After 15s almost for sure there will be no network
> error.
> This issue cannot be reproduced on iOS5. It could be a problem within a LAN
> environment too ( I am hitting a server within company domain )
> PhoneGap probably got tricked by the iOS network status too. Maybe there is
> something else PhoneGap can check, but not sure.
> Meanwhile I will lower the bug priority and report an issue to Apple.
>
> 24Oct 2012
> I have an app that talks to a server. Before making an RPC I use the PG API
> to check for connectivity:
> http://docs.phonegap.com/en/2.1.0/cordova_connection_connection.md.html#Connection
> code snippet:
> var networkState = navigator.network.connection.type
> if (networkState == "none" || networkState == "unknown")
> {
> //DO NOT make connection
> }
> Scenario: ( i am testing on two iPhone4 , one running OS5 ,and one on OS6)
> 1. Turn ON airplane mode from setting. wait until the radio and wifi are
> fully OFF
> 2. Turn OFF airplane, quickly switch to my app and make an RPC, make sure on
> the top left of the banner the connectivity status is showing "searching..."
> 3. Expect to see networkState as "unknown" (iOS5 behavior). but it returns
> "wifi" (iOS6)
> another minor observation - on iOS6 it takes double time to turn off the
> airplane mode.
> iOS5 it takes like around 3 seconds to have the connectivity reestablished,
> before i finish the following actions: toggle the mode button, close the
> setting app. foreground my app, click on a button.
> iOS6 it takes like 6 seconds, which makes the bug more easy to reproduce.
> -
--
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-1752) GPS position.speed is 0 in background tracking
[ https://issues.apache.org/jira/browse/CB-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486477#comment-13486477 ] Shazron Abdullah commented on CB-1752: -- Not enough information. What do you mean by "database table", are you talking about WebSQL? > GPS position.speed is 0 in background tracking > -- > > Key: CB-1752 > URL: https://issues.apache.org/jira/browse/CB-1752 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.1.0 > Environment: iPhone 4 > iOS 5.1 > CDV 2.1 >Reporter: Bernhard Bezdek >Assignee: Shazron Abdullah > Labels: callback, gps, watchposition > Fix For: 2.3.0 > > > In an App latitude, longitude, altitude, speed and timestamp is stored into a > database table. > As long as the App is in foreground everything works fine. > If App is going into background mode (location) and is reopened a time later > everything without the speed is going into table. > There's only one codebase for tracking (navigator.geolocation.watchPosition) -- 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] [Updated] (CB-1752) GPS position.speed is 0 in background tracking
[ https://issues.apache.org/jira/browse/CB-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-1752: - Fix Version/s: 2.3.0 > GPS position.speed is 0 in background tracking > -- > > Key: CB-1752 > URL: https://issues.apache.org/jira/browse/CB-1752 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.1.0 > Environment: iPhone 4 > iOS 5.1 > CDV 2.1 >Reporter: Bernhard Bezdek >Assignee: Shazron Abdullah > Labels: callback, gps, watchposition > Fix For: 2.3.0 > > > In an App latitude, longitude, altitude, speed and timestamp is stored into a > database table. > As long as the App is in foreground everything works fine. > If App is going into background mode (location) and is reopened a time later > everything without the speed is going into table. > There's only one codebase for tracking (navigator.geolocation.watchPosition) -- 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
Re: tagging 2.2.0
SGTM On Mon, Oct 29, 2012 at 5:13 PM, Filip Maj wrote: > Yes? > > On 10/29/12 1:27 PM, "Brian LeRoux" wrote: > > >EOD tmrw? > >
[jira] [Commented] (CB-1753) Some web servers generate a 503 error with FileTransfer.upload
[ https://issues.apache.org/jira/browse/CB-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486374#comment-13486374 ] Andrew Grieve commented on CB-1753: --- Also note that there were some fixes to FileTransfer in 2.0. It's possible that just updating your Cordova version would fix the problem. > Some web servers generate a 503 error with FileTransfer.upload > -- > > Key: CB-1753 > URL: https://issues.apache.org/jira/browse/CB-1753 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 1.9.0 > Environment: Client: Galaxy Nexus running 4.0.3 > Server: Nginx/Varnish/PHP 5.3.x (I can get the software versions from the > admin) >Reporter: Ronald Partridge >Assignee: Joe Bowser > Fix For: Master > > > See: > https://github.com/apache/incubator-cordova-android/blob/master/framework/src/org/apache/cordova/FileTransfer.java > private void upload(final String source, final String target, JSONArray args, > CallbackContext callbackContext) > Cordova Android may have a bug with the way files are being sent. The Android > source code appears to use the built in java HttpURLConnection and > the developer who wrote the functionality decided to write the logic to > assemble the post data to be transfered. I examined two different post dumps > being sent to a web server running Nginx and Varnish. Notice how the headers > are different between iOS and Android. > I would suggest using > http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html > Here are the two post dumps: > Android: > POST /service/claim/photo/75?api_key=123ab > c HTTP/1.1 > Connection: Keep-Alive > Content-Type: multipart/form-data;boundary=* > User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.1.1; Nexus S Build/JRO03E) > Host: sit.service.app.mydomain.ca > Accept-Encoding: gzip > Transfer-Encoding: chunked > o<8A>P9)^B^@6^@^@^@6^@^@^@^@^@^L^G^@PV<8E>^A^@E^@^@(e@^@@^FESC^_[&c<88>^@P%&<9C>WĘP^P^Y > ^^@^@o<8A>P<93>,^B^@^D^@ > ^@^D^@^@^@^@^L^G^@PV<8E>^A^@E^@^Df@^@@^F:ESC^_[&c<88>^@P%&<9C>WĘP^X^Y > ^?I^@^@HTTP/1.1 503 Service Unavailable > Server: Varnish > Content-Type: text/html; charset=utf-8 > Content-Length: 932 > Accept-Ranges: bytes > Date: Fri, 26 Oct 2012 20:15:43 GMT > X-Varnish: 409357173 > Age: 0 > Via: 1.1 varnish > Connection: close > X-Cache: MISS > iOS: > POST /service/claim/photo/73?api_key=123abc HTTP/1.1 > Host: sit.service.app.mydomain.ca > User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) > AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206 > Content-Length: 139038 > Accept: */* > Content-Type: multipart/form-data; > boundary=*org.apache.cordova.formBoundary > X-Requested-With: XMLHttpRequest > Accept-Language: en-us > Accept-Encoding: gzip, deflate > Connection: keep-alive > 4<8A>P;^F^A^@6^@^@^@6^@^@^@^@^@^L^G^@PV<8E>^A^@E^@^@(}1@^@@^FC^SESC^_[&c<88>^@P<8F>^^^_P^P^Y > ^X`^@^@4<8A>P^K^A^@ > <9A>^E^@^@<9A>^E^@^@^@PV<8E>^A:^@^U~^Z^H^@E^@^E<8C>C@^@)^F<9C>&c<88>ESC^_[<8F>^@P^^^_P^P^@^@--*org.apache.cordova.formBoundary > Content-Disposition: form-data; name="description" > Photo > --*org.apache.cordova.formBoundary > Content-Disposition: form-data; name="userfile"; filename="cdv_photo_002.jpg" > Content-Type: image/jpeg > Content-Length: 138722 -- 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: tagging 2.2.0
Yes? On 10/29/12 1:27 PM, "Brian LeRoux" wrote: >EOD tmrw?
[jira] [Commented] (CB-1753) Some web servers generate a 503 error with FileTransfer.upload
[ https://issues.apache.org/jira/browse/CB-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486358#comment-13486358 ] Ronald Partridge commented on CB-1753: -- Yes I just did that and it worked. Perhaps you could add this to PhoneGap documentation. Thank You Ronald > Some web servers generate a 503 error with FileTransfer.upload > -- > > Key: CB-1753 > URL: https://issues.apache.org/jira/browse/CB-1753 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 1.9.0 > Environment: Client: Galaxy Nexus running 4.0.3 > Server: Nginx/Varnish/PHP 5.3.x (I can get the software versions from the > admin) >Reporter: Ronald Partridge >Assignee: Joe Bowser > Fix For: Master > > > See: > https://github.com/apache/incubator-cordova-android/blob/master/framework/src/org/apache/cordova/FileTransfer.java > private void upload(final String source, final String target, JSONArray args, > CallbackContext callbackContext) > Cordova Android may have a bug with the way files are being sent. The Android > source code appears to use the built in java HttpURLConnection and > the developer who wrote the functionality decided to write the logic to > assemble the post data to be transfered. I examined two different post dumps > being sent to a web server running Nginx and Varnish. Notice how the headers > are different between iOS and Android. > I would suggest using > http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html > Here are the two post dumps: > Android: > POST /service/claim/photo/75?api_key=123ab > c HTTP/1.1 > Connection: Keep-Alive > Content-Type: multipart/form-data;boundary=* > User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.1.1; Nexus S Build/JRO03E) > Host: sit.service.app.mydomain.ca > Accept-Encoding: gzip > Transfer-Encoding: chunked > o<8A>P9)^B^@6^@^@^@6^@^@^@^@^@^L^G^@PV<8E>^A^@E^@^@(e@^@@^FESC^_[&c<88>^@P%&<9C>WĘP^P^Y > ^^@^@o<8A>P<93>,^B^@^D^@ > ^@^D^@^@^@^@^L^G^@PV<8E>^A^@E^@^Df@^@@^F:ESC^_[&c<88>^@P%&<9C>WĘP^X^Y > ^?I^@^@HTTP/1.1 503 Service Unavailable > Server: Varnish > Content-Type: text/html; charset=utf-8 > Content-Length: 932 > Accept-Ranges: bytes > Date: Fri, 26 Oct 2012 20:15:43 GMT > X-Varnish: 409357173 > Age: 0 > Via: 1.1 varnish > Connection: close > X-Cache: MISS > iOS: > POST /service/claim/photo/73?api_key=123abc HTTP/1.1 > Host: sit.service.app.mydomain.ca > User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) > AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206 > Content-Length: 139038 > Accept: */* > Content-Type: multipart/form-data; > boundary=*org.apache.cordova.formBoundary > X-Requested-With: XMLHttpRequest > Accept-Language: en-us > Accept-Encoding: gzip, deflate > Connection: keep-alive > 4<8A>P;^F^A^@6^@^@^@6^@^@^@^@^@^L^G^@PV<8E>^A^@E^@^@(}1@^@@^FC^SESC^_[&c<88>^@P<8F>^^^_P^P^Y > ^X`^@^@4<8A>P^K^A^@ > <9A>^E^@^@<9A>^E^@^@^@PV<8E>^A:^@^U~^Z^H^@E^@^E<8C>C@^@)^F<9C>&c<88>ESC^_[<8F>^@P^^^_P^P^@^@--*org.apache.cordova.formBoundary > Content-Disposition: form-data; name="description" > Photo > --*org.apache.cordova.formBoundary > Content-Disposition: form-data; name="userfile"; filename="cdv_photo_002.jpg" > Content-Type: image/jpeg > Content-Length: 138722 -- 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: Duplicate commits in Cordova Android
I *think* it's fine (not broken). If you look at the history with: git log --graph --oneline --all you can see more detail about the merge history. If you rebase, and only merge using --ff-only, then you'll avoid the complicated history (it will be linear). I find the merges hard to follow, and the git web interface is not good at showing it either. On Mon, Oct 29, 2012 at 4:34 PM, Simon MacDonald wrote: > Hey, > > My last fix ended up duplicating a bunch of check in's. Not sure what I did > wrong but if anyone who's git-fu is strong than mine knows how to fix it > I'd be happy to get the info. > > Thanks... > > Simon Mac Donald > http://hi.im/simonmacdonald >
[jira] [Commented] (CB-1753) Some web servers generate a 503 error with FileTransfer.upload
[ https://issues.apache.org/jira/browse/CB-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486319#comment-13486319 ] Simon MacDonald commented on CB-1753: - I would have loved to have used the Apache HttpClient package but we are trying to stay away from external dependencies. Have you tried setting chunkedMode to false? > Some web servers generate a 503 error with FileTransfer.upload > -- > > Key: CB-1753 > URL: https://issues.apache.org/jira/browse/CB-1753 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 1.9.0 > Environment: Client: Galaxy Nexus running 4.0.3 > Server: Nginx/Varnish/PHP 5.3.x (I can get the software versions from the > admin) >Reporter: Ronald Partridge >Assignee: Joe Bowser > Fix For: Master > > > See: > https://github.com/apache/incubator-cordova-android/blob/master/framework/src/org/apache/cordova/FileTransfer.java > private void upload(final String source, final String target, JSONArray args, > CallbackContext callbackContext) > Cordova Android may have a bug with the way files are being sent. The Android > source code appears to use the built in java HttpURLConnection and > the developer who wrote the functionality decided to write the logic to > assemble the post data to be transfered. I examined two different post dumps > being sent to a web server running Nginx and Varnish. Notice how the headers > are different between iOS and Android. > I would suggest using > http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html > Here are the two post dumps: > Android: > POST /service/claim/photo/75?api_key=123ab > c HTTP/1.1 > Connection: Keep-Alive > Content-Type: multipart/form-data;boundary=* > User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.1.1; Nexus S Build/JRO03E) > Host: sit.service.app.mydomain.ca > Accept-Encoding: gzip > Transfer-Encoding: chunked > o<8A>P9)^B^@6^@^@^@6^@^@^@^@^@^L^G^@PV<8E>^A^@E^@^@(e@^@@^FESC^_[&c<88>^@P%&<9C>WĘP^P^Y > ^^@^@o<8A>P<93>,^B^@^D^@ > ^@^D^@^@^@^@^L^G^@PV<8E>^A^@E^@^Df@^@@^F:ESC^_[&c<88>^@P%&<9C>WĘP^X^Y > ^?I^@^@HTTP/1.1 503 Service Unavailable > Server: Varnish > Content-Type: text/html; charset=utf-8 > Content-Length: 932 > Accept-Ranges: bytes > Date: Fri, 26 Oct 2012 20:15:43 GMT > X-Varnish: 409357173 > Age: 0 > Via: 1.1 varnish > Connection: close > X-Cache: MISS > iOS: > POST /service/claim/photo/73?api_key=123abc HTTP/1.1 > Host: sit.service.app.mydomain.ca > User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) > AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206 > Content-Length: 139038 > Accept: */* > Content-Type: multipart/form-data; > boundary=*org.apache.cordova.formBoundary > X-Requested-With: XMLHttpRequest > Accept-Language: en-us > Accept-Encoding: gzip, deflate > Connection: keep-alive > 4<8A>P;^F^A^@6^@^@^@6^@^@^@^@^@^L^G^@PV<8E>^A^@E^@^@(}1@^@@^FC^SESC^_[&c<88>^@P<8F>^^^_P^P^Y > ^X`^@^@4<8A>P^K^A^@ > <9A>^E^@^@<9A>^E^@^@^@PV<8E>^A:^@^U~^Z^H^@E^@^E<8C>C@^@)^F<9C>&c<88>ESC^_[<8F>^@P^^^_P^P^@^@--*org.apache.cordova.formBoundary > Content-Disposition: form-data; name="description" > Photo > --*org.apache.cordova.formBoundary > Content-Disposition: form-data; name="userfile"; filename="cdv_photo_002.jpg" > Content-Type: image/jpeg > Content-Length: 138722 -- 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
tagging 2.2.0
EOD tmrw?
Re: FYI new convienance redirect on issues.cordova.io
omg I never noticed that search box. awesome dude thank you! On Mon, Oct 29, 2012 at 10:55 AM, Andrew Grieve wrote: > I added a bug search box to cordova.io a while ago, which is what I use > whenever I want to search for bugs. The main thing it does is require each > of the words you type instead of OR'ing them. It also filters by platform > if it sees the word "android", "windows", etc. > > Michal pointed out to me that likely JIRA uses wether or not a match > contains all the words in its ranking, but usually I want to just know if a > bug exists with these words or not, so the extra results slow me down. > > > On Mon, Oct 29, 2012 at 1:42 PM, Shazron Abdullah wrote: > >> Yup they have an API if not BugBox on iOS and Android won't work >> >> On 2012-10-29, at 10:32 AM, Filip Maj wrote: >> >> > Jira has an API I'm pretty sure! We're pretty good at implementing shims >> > ya? Let's fill the JIRA gap. >> > >> > On 10/29/12 10:19 AM, "Brian LeRoux" wrote: >> > >> >> At some point I'd like to make both searching and submitting bugs to >> >> Cordova easier for sure. =/ >> >> >> >> >> >> On Mon, Oct 29, 2012 at 7:31 AM, Braden Shepherdson < >> bra...@chromium.org> >> >> wrote: >> >>> +1! >> >>> >> >>> JIRA search is so bad that my approach to finding bugs by keywords is >> to >> >>> search on Gmail and then click the link. Yeah. >> >>> >> >>> Braden >> >>> >> >>> >> >>> On Fri, Oct 26, 2012 at 5:56 PM, Dave Johnson >> >>> wrote: >> >>> >> I thought the jira/browse/CB-xyz was really intuitive :( >> >> On Fri, Oct 26, 2012 at 10:05 PM, Michal Mocny >> wrote: >> > +1. Big Time. >> > >> > On Fri, Oct 26, 2012 at 3:58 PM, Brian LeRoux wrote: >> >> issues.cordova.io ---> >> https://issues.apache.org/jira/browse/CB >> >> issues.cordova.io/1234 ---> >> https://issues.apache.org/jira/browse/CB-1234 >> >> > >>
[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
Re: [ios] Evaluating JS during onAppWillResignActive
sick! On Mon, Oct 29, 2012 at 8:32 PM, Kerri Shotts wrote: > Fantastic! > > _~Kerri Shotts, photo > (http://www.photokandy.com/)Kandy (http://www.photokandy.com/) Studios LLC > (http://www.photokandy.com/) >Wanna be our neighbor? Our Facebook page > (http://www.facebook.com/pages/photoKandy-Studios/87979941601) & Twitter feed > (http://www.twitter.com/photokandy). > > > On Monday, October 29, 2012 at 2:21 PM, Michal Mocny wrote: > >> Success! >> >> After some debugging with Andrew, we have been able to make the exec >> bridge work even in resign event. (Testing pause event, too). >> >> I've uncovered a few bugs in the process and patches will be up soon, >> but long story short, I've got local notifications being scheduled on >> app resign, huzzah! >> >> On Sat, Oct 27, 2012 at 4:36 PM, Michal Mocny > (mailto:mmo...@chromium.org)> wrote: >> > Thanks for the link, Shaz. >> > >> > On Fri, Oct 26, 2012 at 10:40 PM, Shazron > > (mailto:shaz...@gmail.com)> wrote: >> > > This is something we encountered when playing with the pause and >> > > resume events. More details in the iOS Quirks of >> > > http://docs.phonegap.com/en/2.1.0/cordova_events_events.md.html#pause >> > > >> > > On Fri, Oct 26, 2012 at 8:29 AM, Michal Mocny > > > (mailto:mmo...@google.com)> wrote: >> > > > Local Notifications, especially on ios, are most useful when app is in >> > > > the background. It would be handy to be able to schedule them during >> > > > the window of time allotted during onAppWillResignActive. >> > > > >> > > > We even already have handlers for js document events 'resign' and >> > > > 'pause' (this one is for a >> > > > onAppDidEnterBackground event). (There are some issues with the >> > > > javascript here, seems the events aren't properly defined, will file >> > > > separately). >> > > > >> > > > However, no matter how I try, I cannot get more then a trivial amount >> > > > of js to execute during the time window before app pauses -- far less >> > > > than the allowed 5 seconds. >> > > > >> > > > According to the only (unreliable) source I've found on the subject, >> > > > its simply not possible to use the webview during >> > > > onAppWillResignActive: >> > > > http://stackoverflow.com/questions/4865742/iphone-webview-onbackground-event >> > > > >> > > > Does anyone have a better answer here? >> > > > >> > > > Thanks, >> > > > -Michal >> > > > >> > > >> > > >> > >> > >> >> >> > >
[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
Re: [ios] Evaluating JS during onAppWillResignActive
Fantastic! _~Kerri Shotts, photo (http://www.photokandy.com/)Kandy (http://www.photokandy.com/) Studios LLC (http://www.photokandy.com/) Wanna be our neighbor? Our Facebook page (http://www.facebook.com/pages/photoKandy-Studios/87979941601) & Twitter feed (http://www.twitter.com/photokandy). On Monday, October 29, 2012 at 2:21 PM, Michal Mocny wrote: > Success! > > After some debugging with Andrew, we have been able to make the exec > bridge work even in resign event. (Testing pause event, too). > > I've uncovered a few bugs in the process and patches will be up soon, > but long story short, I've got local notifications being scheduled on > app resign, huzzah! > > On Sat, Oct 27, 2012 at 4:36 PM, Michal Mocny (mailto:mmo...@chromium.org)> wrote: > > Thanks for the link, Shaz. > > > > On Fri, Oct 26, 2012 at 10:40 PM, Shazron > (mailto:shaz...@gmail.com)> wrote: > > > This is something we encountered when playing with the pause and > > > resume events. More details in the iOS Quirks of > > > http://docs.phonegap.com/en/2.1.0/cordova_events_events.md.html#pause > > > > > > On Fri, Oct 26, 2012 at 8:29 AM, Michal Mocny > > (mailto:mmo...@google.com)> wrote: > > > > Local Notifications, especially on ios, are most useful when app is in > > > > the background. It would be handy to be able to schedule them during > > > > the window of time allotted during onAppWillResignActive. > > > > > > > > We even already have handlers for js document events 'resign' and > > > > 'pause' (this one is for a > > > > onAppDidEnterBackground event). (There are some issues with the > > > > javascript here, seems the events aren't properly defined, will file > > > > separately). > > > > > > > > However, no matter how I try, I cannot get more then a trivial amount > > > > of js to execute during the time window before app pauses -- far less > > > > than the allowed 5 seconds. > > > > > > > > According to the only (unreliable) source I've found on the subject, > > > > its simply not possible to use the webview during > > > > onAppWillResignActive: > > > > http://stackoverflow.com/questions/4865742/iphone-webview-onbackground-event > > > > > > > > Does anyone have a better answer here? > > > > > > > > Thanks, > > > > -Michal > > > > > > > > > > > > > > > > >
[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
Re: [ios] Evaluating JS during onAppWillResignActive
Success! After some debugging with Andrew, we have been able to make the exec bridge work even in resign event. (Testing pause event, too). I've uncovered a few bugs in the process and patches will be up soon, but long story short, I've got local notifications being scheduled on app resign, huzzah! On Sat, Oct 27, 2012 at 4:36 PM, Michal Mocny wrote: > Thanks for the link, Shaz. > > On Fri, Oct 26, 2012 at 10:40 PM, Shazron wrote: >> This is something we encountered when playing with the pause and >> resume events. More details in the iOS Quirks of >> http://docs.phonegap.com/en/2.1.0/cordova_events_events.md.html#pause >> >> On Fri, Oct 26, 2012 at 8:29 AM, Michal Mocny wrote: >>> Local Notifications, especially on ios, are most useful when app is in >>> the background. It would be handy to be able to schedule them during >>> the window of time allotted during onAppWillResignActive. >>> >>> We even already have handlers for js document events 'resign' and >>> 'pause' (this one is for a >>> onAppDidEnterBackground event). (There are some issues with the >>> javascript here, seems the events aren't properly defined, will file >>> separately). >>> >>> However, no matter how I try, I cannot get more then a trivial amount >>> of js to execute during the time window before app pauses -- far less >>> than the allowed 5 seconds. >>> >>> According to the only (unreliable) source I've found on the subject, >>> its simply not possible to use the webview during >>> onAppWillResignActive: >>> http://stackoverflow.com/questions/4865742/iphone-webview-onbackground-event >>> >>> Does anyone have a better answer here? >>> >>> Thanks, >>> -Michal
[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
RE: license issue in incubator-cordova-wp7
* The code was added by me so I CAN handle this and re-write copy-paste. Would like to fix this licensing issue. -Original Message- From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] Sent: Monday, October 29, 2012 11:06 PM To: dev@cordova.apache.org Subject: RE: license issue in incubator-cordova-wp7 The code was added by me so I can't handle this and re-write copy-paste. -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Monday, October 29, 2012 10:29 PM To: dev@cordova.apache.org Subject: Re: license issue in incubator-cordova-wp7 a) Have you posted an issue with Legal-Discuss list for clarification to know for sure? On Mon, Oct 29, 2012 at 11:25 AM, Jesse wrote: > a) is not an option, as I believe the licenses are not compatible > > private void WriteWavHeader(Stream stream, int sampleRate) > - would be hard to write any other way as it is just a step by step > implementation of the header spec. > > private void UpdateWavHeader(Stream stream) > - will need to be rewritten > > > > > > > On Mon, Oct 29, 2012 at 10:36 AM, Marcel Kinard wrote: >> I was looking at >> incubator-cordova-wp7/templates/standalone/cordovalib/Commands/AudioP >> layer.cs and noticed on line 529 a URL to someone's blog. I looked at >> the blog, and it is a code sample for writing a WAV audio header. I >> looked back at the cordova source file and realized that two methods >> in the cordova source are a straight copy-and-paste from the blog. >> >> The blog indicates that samples provided fall under the Microsoft >> Public License (Ms-PL). So I think some action here is necessary, such as: >> >> a) the terms of the Ms-PL need to be followed, such as including a >> full copy of the Ms-PL in the cordova distribution, or >> b) rewrite these 2 methods with unique code. >> >> Given that these 2 methods are following a spec to write out a WAV >> header, doing a rewrite would seem to be easy. What does the group >> here think, and who could correct this issue? It would seem this >> needs to get taken care of before the final release of 2.2.0. >> >> Also looks like the exact same issue exists in another source file, >> incubator-cordova-wp7/templates/standalone/cordovalib/UI/AudioRecorde >> r.xaml.cs >> >> -- Marcel Kinard > > > > -- > @purplecabbage > risingj.com
[jira] [Created] (CB-1753) Some web servers generate a 503 error with FileTransfer.upload
Ronald Partridge created CB-1753: Summary: Some web servers generate a 503 error with FileTransfer.upload Key: CB-1753 URL: https://issues.apache.org/jira/browse/CB-1753 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 1.9.0 Environment: Client: Galaxy Nexus running 4.0.3 Server: Nginx/Varnish/PHP 5.3.x (I can get the software versions from the admin) Reporter: Ronald Partridge Assignee: Joe Bowser Fix For: Master See: https://github.com/apache/incubator-cordova-android/blob/master/framework/src/org/apache/cordova/FileTransfer.java private void upload(final String source, final String target, JSONArray args, CallbackContext callbackContext) Cordova Android may have a bug with the way files are being sent. The Android source code appears to use the built in java HttpURLConnection and the developer who wrote the functionality decided to write the logic to assemble the post data to be transfered. I examined two different post dumps being sent to a web server running Nginx and Varnish. Notice how the headers are different between iOS and Android. I would suggest using http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpClient.html Here are the two post dumps: Android: POST /service/claim/photo/75?api_key=123ab c HTTP/1.1 Connection: Keep-Alive Content-Type: multipart/form-data;boundary=* User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.1.1; Nexus S Build/JRO03E) Host: sit.service.app.mydomain.ca Accept-Encoding: gzip Transfer-Encoding: chunked o<8A>P9)^B^@6^@^@^@6^@^@^@^@^@^L^G^@PV<8E>^A^@E^@^@(e@^@@^FESC^_[&c<88>^@P%&<9C>WĘP^P^Y ^^@^@o<8A>P<93>,^B^@^D^@ ^@^D^@^@^@^@^L^G^@PV<8E>^A^@E^@^Df@^@@^F:ESC^_[&c<88>^@P%&<9C>WĘP^X^Y ^?I^@^@HTTP/1.1 503 Service Unavailable Server: Varnish Content-Type: text/html; charset=utf-8 Content-Length: 932 Accept-Ranges: bytes Date: Fri, 26 Oct 2012 20:15:43 GMT X-Varnish: 409357173 Age: 0 Via: 1.1 varnish Connection: close X-Cache: MISS iOS: POST /service/claim/photo/73?api_key=123abc HTTP/1.1 Host: sit.service.app.mydomain.ca User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206 Content-Length: 139038 Accept: */* Content-Type: multipart/form-data; boundary=*org.apache.cordova.formBoundary X-Requested-With: XMLHttpRequest Accept-Language: en-us Accept-Encoding: gzip, deflate Connection: keep-alive 4<8A>P;^F^A^@6^@^@^@6^@^@^@^@^@^L^G^@PV<8E>^A^@E^@^@(}1@^@@^FC^SESC^_[&c<88>^@P<8F>^^^_P^P^Y ^X`^@^@4<8A>P^K^A^@ <9A>^E^@^@<9A>^E^@^@^@PV<8E>^A:^@^U~^Z^H^@E^@^E<8C>C@^@)^F<9C>&c<88>ESC^_[<8F>^@P^^^_P^P^@^@--*org.apache.cordova.formBoundary Content-Disposition: form-data; name="description" Photo --*org.apache.cordova.formBoundary Content-Disposition: form-data; name="userfile"; filename="cdv_photo_002.jpg" Content-Type: image/jpeg Content-Length: 138722 -- 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: license issue in incubator-cordova-wp7
The code was added by me so I can't handle this and re-write copy-paste. -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Monday, October 29, 2012 10:29 PM To: dev@cordova.apache.org Subject: Re: license issue in incubator-cordova-wp7 a) Have you posted an issue with Legal-Discuss list for clarification to know for sure? On Mon, Oct 29, 2012 at 11:25 AM, Jesse wrote: > a) is not an option, as I believe the licenses are not compatible > > private void WriteWavHeader(Stream stream, int sampleRate) > - would be hard to write any other way as it is just a step by step > implementation of the header spec. > > private void UpdateWavHeader(Stream stream) > - will need to be rewritten > > > > > > > On Mon, Oct 29, 2012 at 10:36 AM, Marcel Kinard wrote: >> I was looking at >> incubator-cordova-wp7/templates/standalone/cordovalib/Commands/AudioP >> layer.cs and noticed on line 529 a URL to someone's blog. I looked at >> the blog, and it is a code sample for writing a WAV audio header. I >> looked back at the cordova source file and realized that two methods >> in the cordova source are a straight copy-and-paste from the blog. >> >> The blog indicates that samples provided fall under the Microsoft >> Public License (Ms-PL). So I think some action here is necessary, such as: >> >> a) the terms of the Ms-PL need to be followed, such as including a >> full copy of the Ms-PL in the cordova distribution, or >> b) rewrite these 2 methods with unique code. >> >> Given that these 2 methods are following a spec to write out a WAV >> header, doing a rewrite would seem to be easy. What does the group >> here think, and who could correct this issue? It would seem this >> needs to get taken care of before the final release of 2.2.0. >> >> Also looks like the exact same issue exists in another source file, >> incubator-cordova-wp7/templates/standalone/cordovalib/UI/AudioRecorde >> r.xaml.cs >> >> -- Marcel Kinard > > > > -- > @purplecabbage > risingj.com
[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
Re: license issue in incubator-cordova-wp7
a) Have you posted an issue with Legal-Discuss list for clarification to know for sure? On Mon, Oct 29, 2012 at 11:25 AM, Jesse wrote: > a) is not an option, as I believe the licenses are not compatible > > private void WriteWavHeader(Stream stream, int sampleRate) > - would be hard to write any other way as it is just a step by step > implementation of the header spec. > > private void UpdateWavHeader(Stream stream) > - will need to be rewritten > > > > > > > On Mon, Oct 29, 2012 at 10:36 AM, Marcel Kinard wrote: >> I was looking at >> incubator-cordova-wp7/templates/standalone/cordovalib/Commands/AudioPlayer.cs >> and noticed on line 529 a URL to someone's blog. I looked at the blog, and >> it is a code sample for writing a WAV audio header. I looked back at the >> cordova source file and realized that two methods in the cordova source are >> a straight copy-and-paste from the blog. >> >> The blog indicates that samples provided fall under the Microsoft Public >> License (Ms-PL). So I think some action here is necessary, such as: >> >> a) the terms of the Ms-PL need to be followed, such as including a full copy >> of the Ms-PL in the cordova distribution, or >> b) rewrite these 2 methods with unique code. >> >> Given that these 2 methods are following a spec to write out a WAV header, >> doing a rewrite would seem to be easy. What does the group here think, and >> who could correct this issue? It would seem this needs to get taken care of >> before the final release of 2.2.0. >> >> Also looks like the exact same issue exists in another source file, >> incubator-cordova-wp7/templates/standalone/cordovalib/UI/AudioRecorder.xaml.cs >> >> -- Marcel Kinard > > > > -- > @purplecabbage > risingj.com
[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
Re: license issue in incubator-cordova-wp7
a) is not an option, as I believe the licenses are not compatible private void WriteWavHeader(Stream stream, int sampleRate) - would be hard to write any other way as it is just a step by step implementation of the header spec. private void UpdateWavHeader(Stream stream) - will need to be rewritten On Mon, Oct 29, 2012 at 10:36 AM, Marcel Kinard wrote: > I was looking at > incubator-cordova-wp7/templates/standalone/cordovalib/Commands/AudioPlayer.cs > and noticed on line 529 a URL to someone's blog. I looked at the blog, and > it is a code sample for writing a WAV audio header. I looked back at the > cordova source file and realized that two methods in the cordova source are > a straight copy-and-paste from the blog. > > The blog indicates that samples provided fall under the Microsoft Public > License (Ms-PL). So I think some action here is necessary, such as: > > a) the terms of the Ms-PL need to be followed, such as including a full copy > of the Ms-PL in the cordova distribution, or > b) rewrite these 2 methods with unique code. > > Given that these 2 methods are following a spec to write out a WAV header, > doing a rewrite would seem to be easy. What does the group here think, and > who could correct this issue? It would seem this needs to get taken care of > before the final release of 2.2.0. > > Also looks like the exact same issue exists in another source file, > incubator-cordova-wp7/templates/standalone/cordovalib/UI/AudioRecorder.xaml.cs > > -- Marcel Kinard -- @purplecabbage risingj.com
[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
Re: FYI new convienance redirect on issues.cordova.io
I added a bug search box to cordova.io a while ago, which is what I use whenever I want to search for bugs. The main thing it does is require each of the words you type instead of OR'ing them. It also filters by platform if it sees the word "android", "windows", etc. Michal pointed out to me that likely JIRA uses wether or not a match contains all the words in its ranking, but usually I want to just know if a bug exists with these words or not, so the extra results slow me down. On Mon, Oct 29, 2012 at 1:42 PM, Shazron Abdullah wrote: > Yup they have an API if not BugBox on iOS and Android won't work > > On 2012-10-29, at 10:32 AM, Filip Maj wrote: > > > Jira has an API I'm pretty sure! We're pretty good at implementing shims > > ya? Let's fill the JIRA gap. > > > > On 10/29/12 10:19 AM, "Brian LeRoux" wrote: > > > >> At some point I'd like to make both searching and submitting bugs to > >> Cordova easier for sure. =/ > >> > >> > >> On Mon, Oct 29, 2012 at 7:31 AM, Braden Shepherdson < > bra...@chromium.org> > >> wrote: > >>> +1! > >>> > >>> JIRA search is so bad that my approach to finding bugs by keywords is > to > >>> search on Gmail and then click the link. Yeah. > >>> > >>> Braden > >>> > >>> > >>> On Fri, Oct 26, 2012 at 5:56 PM, Dave Johnson > >>> wrote: > >>> > I thought the jira/browse/CB-xyz was really intuitive :( > > On Fri, Oct 26, 2012 at 10:05 PM, Michal Mocny > wrote: > > +1. Big Time. > > > > On Fri, Oct 26, 2012 at 3:58 PM, Brian LeRoux wrote: > >> issues.cordova.io ---> > https://issues.apache.org/jira/browse/CB > >> issues.cordova.io/1234 ---> > https://issues.apache.org/jira/browse/CB-1234 > > > >
Re: 2.2.0rc2 Monday?
Yeah, I have just been grabbing the source for the webos repo and throwing that into the release. It would be good cordova-js file was included in the webOS repo. -Steve On Mon, Oct 29, 2012 at 10:50 AM, Herm Wong wrote: > Go for it. > > > From: markus.leutwy...@hp.com > > To: dev@cordova.apache.org > > Subject: RE: 2.2.0rc2 Monday? > > Date: Mon, 29 Oct 2012 08:37:49 + > > > > Any reason the webOS Part of 2.2.0rc2 doesn't include the updated > cordova-js for webOS? Should I go ahead an include cordova-js, update the > Makefile etc.? > > > > Markus > > > > -Original Message- > > From: Herm Wong [mailto:kingoftheo...@hotmail.com] > > Sent: Samstag, 27. Oktober 2012 00:49 > > To: dev@cordova.apache.org > > Subject: RE: 2.2.0rc2 Monday? > > > > updated the issue tracker. > > everything was merged and tested a couple of days ago. > > > > > From: f...@adobe.com > > > To: dev@cordova.apache.org > > > Date: Fri, 26 Oct 2012 13:42:20 -0700 > > > Subject: Re: 2.2.0rc2 Monday? > > > > > > How is webos tagged but the Javascript not updated? Im assuming the > > > issue was not resolved? comeon people! > > > > > > On 10/26/12 1:40 PM, "Steven Gill" wrote: > > > > > > >WP7 & docs haven't been tagged yet. > > > > > > > >-Steve > > > > > > > >On Fri, Oct 26, 2012 at 1:38 PM, Filip Maj wrote: > > > > > > > >> All the tasks are done. Steve did you make the release? Let's make > > > >> some noise about it. > > > >> > > > >> On 10/26/12 1:14 PM, "Andrew Grieve" wrote: > > > >> > > > >> >Okay, Simon, Bryce and I worked through the (final?) issue they > > > >> >were seeing with CB-1745. > > > >> > > > > >> >I've re-tagged the JS and Android again. Let's get this release > > > >>rolling! > > > >> > > > > >> > > > > >> >On Fri, Oct 26, 2012 at 1:37 PM, Gord Tanner > > > >>wrote: > > > >> > > > > >> >> thanks :) > > > >> >> > > > >> >> Teach a man to fish! > > > >> >> > > > >> >> retagged blackberry > > > >> >> > > > >> >> On Fri, Oct 26, 2012 at 1:14 PM, Andrew Grieve > > > >> >> > > > >> >> wrote: > > > >> >> > > > >> >> > FYI - the problem I was facing was not knowing the git foo for > > > >>pushing > > > >> >> > tags. To re-tag: > > > >> >> > > > > >> >> > git fetch apache # Fetch tags > > > >> >> > git tag --force 2.2.0rc2 # Re-tag locally git push apache > > > >> >> > master --tag # Push tags > > > >> >> > > > > >> >> > I'll put this on the CuttingReleases wiki page. > > > >> >> > > > > >> >> > > > > >> >> > On Fri, Oct 26, 2012 at 1:11 PM, Gord Tanner > > > >> >> > > > > >> >> wrote: > > > >> >> > > > > >> >> > > anyone have any objections of getting this fix into > > > >> >> > > blackberry > > > >>for > > > >> >>2.2? > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > >> >> > > > >> >> > > > >> > > > >>https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackber > > > >>ry-we > > > >> >>bworks.git;a=commit;h=6ae80d9ac480f01c2d5734656a7f33c044d11139 > > > >> >> > > > > > >> >> > > also I fail at teh git so if there is no objections could > > > >> >> > > someone > > > >> >>retag > > > >> >> > > blackberry for me? > > > >> >> > > > > > >> >> > > On Fri, Oct 26, 2012 at 10:42 AM, Andrew Grieve > > > >> >> > > >> >> > > >wrote: > > > >> >> > > > > > >> >> > > > Sounds good. I've now re-tagged the JS and Android. > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > On Thu, Oct 25, 2012 at 10:56 PM, Simon MacDonald < > > > >> >> > > > simon.macdon...@gmail.com > > > >> >> > > > > wrote: > > > >> >> > > > > > > >> >> > > > > I'm still seeing the bug but I don't think it should > > > >> >> > > > > hold up > > > >>the > > > >> >> > > tagging > > > >> >> > > > of > > > >> >> > > > > 2.2.0rc2 at this point. I created a small sync Plugin > > > >> >> > > > > for > > > >> >>testing > > > >> >> and > > > >> >> > > it > > > >> >> > > > > runs fine in my mobile spec test case. Now the same > > > >> >> > > > > plugin > > > >> >>called > > > >> >> in > > > >> >> > > the > > > >> >> > > > > downstream app which uses the same Android library > > > >> >> > > > > project > > > >>for > > > >> >> > Cordova > > > >> >> > > > and > > > >> >> > > > > the same .js file returns the wrong value when I call > > > >> >> > > > > the > > > >> >>plugin. > > > >> >> At > > > >> >> > > this > > > >> >> > > > > point I'm not convinced it is a Cordova issue. > > > >> >> > > > > > > > >> >> > > > > Simon Mac Donald > > > >> >> > > > > http://hi.im/simonmacdonald > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > On Thu, Oct 25, 2012 at 8:56 PM, Andrew Grieve < > > > >> >> agri...@chromium.org > > > >> >> > > > > > >> >> > > > > wrote: > > > >> >> > > > > > > > >> >> > > > > > Joe - my thinking here is that it's fine to re-tag and > > > >>re-tag > > > >> >> until > > > >> >> > > we > > > >> >> > > > > > actually produce an RC with everything tagged. rc2 is > > > >>still in > > > >> >> the > > > >> >> > > > > process > > > >> >> > > > > > of being tagged, and until the tagging is all done, it > > > >> >> > > > >
[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
RE: 2.2.0rc2 Monday?
Go for it. > From: markus.leutwy...@hp.com > To: dev@cordova.apache.org > Subject: RE: 2.2.0rc2 Monday? > Date: Mon, 29 Oct 2012 08:37:49 + > > Any reason the webOS Part of 2.2.0rc2 doesn't include the updated cordova-js > for webOS? Should I go ahead an include cordova-js, update the Makefile etc.? > > Markus > > -Original Message- > From: Herm Wong [mailto:kingoftheo...@hotmail.com] > Sent: Samstag, 27. Oktober 2012 00:49 > To: dev@cordova.apache.org > Subject: RE: 2.2.0rc2 Monday? > > updated the issue tracker. > everything was merged and tested a couple of days ago. > > > From: f...@adobe.com > > To: dev@cordova.apache.org > > Date: Fri, 26 Oct 2012 13:42:20 -0700 > > Subject: Re: 2.2.0rc2 Monday? > > > > How is webos tagged but the Javascript not updated? Im assuming the > > issue was not resolved? comeon people! > > > > On 10/26/12 1:40 PM, "Steven Gill" wrote: > > > > >WP7 & docs haven't been tagged yet. > > > > > >-Steve > > > > > >On Fri, Oct 26, 2012 at 1:38 PM, Filip Maj wrote: > > > > > >> All the tasks are done. Steve did you make the release? Let's make > > >> some noise about it. > > >> > > >> On 10/26/12 1:14 PM, "Andrew Grieve" wrote: > > >> > > >> >Okay, Simon, Bryce and I worked through the (final?) issue they > > >> >were seeing with CB-1745. > > >> > > > >> >I've re-tagged the JS and Android again. Let's get this release > > >>rolling! > > >> > > > >> > > > >> >On Fri, Oct 26, 2012 at 1:37 PM, Gord Tanner > > >>wrote: > > >> > > > >> >> thanks :) > > >> >> > > >> >> Teach a man to fish! > > >> >> > > >> >> retagged blackberry > > >> >> > > >> >> On Fri, Oct 26, 2012 at 1:14 PM, Andrew Grieve > > >> >> > > >> >> wrote: > > >> >> > > >> >> > FYI - the problem I was facing was not knowing the git foo for > > >>pushing > > >> >> > tags. To re-tag: > > >> >> > > > >> >> > git fetch apache # Fetch tags > > >> >> > git tag --force 2.2.0rc2 # Re-tag locally git push apache > > >> >> > master --tag # Push tags > > >> >> > > > >> >> > I'll put this on the CuttingReleases wiki page. > > >> >> > > > >> >> > > > >> >> > On Fri, Oct 26, 2012 at 1:11 PM, Gord Tanner > > >> >> > > > >> >> wrote: > > >> >> > > > >> >> > > anyone have any objections of getting this fix into > > >> >> > > blackberry > > >>for > > >> >>2.2? > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > >> >> > > >> > > >>https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackber > > >>ry-we > > >> >>bworks.git;a=commit;h=6ae80d9ac480f01c2d5734656a7f33c044d11139 > > >> >> > > > > >> >> > > also I fail at teh git so if there is no objections could > > >> >> > > someone > > >> >>retag > > >> >> > > blackberry for me? > > >> >> > > > > >> >> > > On Fri, Oct 26, 2012 at 10:42 AM, Andrew Grieve > > >> >> > >> >> > > >wrote: > > >> >> > > > > >> >> > > > Sounds good. I've now re-tagged the JS and Android. > > >> >> > > > > > >> >> > > > > > >> >> > > > On Thu, Oct 25, 2012 at 10:56 PM, Simon MacDonald < > > >> >> > > > simon.macdon...@gmail.com > > >> >> > > > > wrote: > > >> >> > > > > > >> >> > > > > I'm still seeing the bug but I don't think it should > > >> >> > > > > hold up > > >>the > > >> >> > > tagging > > >> >> > > > of > > >> >> > > > > 2.2.0rc2 at this point. I created a small sync Plugin > > >> >> > > > > for > > >> >>testing > > >> >> and > > >> >> > > it > > >> >> > > > > runs fine in my mobile spec test case. Now the same > > >> >> > > > > plugin > > >> >>called > > >> >> in > > >> >> > > the > > >> >> > > > > downstream app which uses the same Android library > > >> >> > > > > project > > >>for > > >> >> > Cordova > > >> >> > > > and > > >> >> > > > > the same .js file returns the wrong value when I call > > >> >> > > > > the > > >> >>plugin. > > >> >> At > > >> >> > > this > > >> >> > > > > point I'm not convinced it is a Cordova issue. > > >> >> > > > > > > >> >> > > > > Simon Mac Donald > > >> >> > > > > http://hi.im/simonmacdonald > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > On Thu, Oct 25, 2012 at 8:56 PM, Andrew Grieve < > > >> >> agri...@chromium.org > > >> >> > > > > >> >> > > > > wrote: > > >> >> > > > > > > >> >> > > > > > Joe - my thinking here is that it's fine to re-tag and > > >>re-tag > > >> >> until > > >> >> > > we > > >> >> > > > > > actually produce an RC with everything tagged. rc2 is > > >>still in > > >> >> the > > >> >> > > > > process > > >> >> > > > > > of being tagged, and until the tagging is all done, it > > >> >> > > > > > just > > >> >> causes > > >> >> > > more > > >> >> > > > > > work to scratch it and have to re-tag all of the other > > >>repos. > > >> >> Once > > >> >> > we > > >> >> > > > > > create an rc2 archive though, no more adjusting. > > >> >> > > > > > > > >> >> > > > > > Marcel - yes, my intention is to retag the JS with the > > >>Android > > >> >> > > changes, > > >> >> > > > > and > > >> >> > > > > > to update the JS in android repo and then re-tag that > > >> >> > > > > > as > > >>well. > > >> >> >
Re: FYI new convienance redirect on issues.cordova.io
Yup they have an API if not BugBox on iOS and Android won't work On 2012-10-29, at 10:32 AM, Filip Maj wrote: > Jira has an API I'm pretty sure! We're pretty good at implementing shims > ya? Let's fill the JIRA gap. > > On 10/29/12 10:19 AM, "Brian LeRoux" wrote: > >> At some point I'd like to make both searching and submitting bugs to >> Cordova easier for sure. =/ >> >> >> On Mon, Oct 29, 2012 at 7:31 AM, Braden Shepherdson >> wrote: >>> +1! >>> >>> JIRA search is so bad that my approach to finding bugs by keywords is to >>> search on Gmail and then click the link. Yeah. >>> >>> Braden >>> >>> >>> On Fri, Oct 26, 2012 at 5:56 PM, Dave Johnson >>> wrote: >>> I thought the jira/browse/CB-xyz was really intuitive :( On Fri, Oct 26, 2012 at 10:05 PM, Michal Mocny wrote: > +1. Big Time. > > On Fri, Oct 26, 2012 at 3:58 PM, Brian LeRoux wrote: >> issues.cordova.io ---> https://issues.apache.org/jira/browse/CB >> issues.cordova.io/1234 ---> https://issues.apache.org/jira/browse/CB-1234 >
[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
license issue in incubator-cordova-wp7
I was looking at incubator-cordova-wp7/templates/standalone/cordovalib/Commands/AudioPlayer.cs and noticed on line 529 a URL to someone's blog. I looked at the blog, and it is a code sample for writing a WAV audio header. I looked back at the cordova source file and realized that two methods in the cordova source are a straight copy-and-paste from the blog. The blog indicates that samples provided fall under the Microsoft Public License (Ms-PL). So I think some action here is necessary, such as: a) the terms of the Ms-PL need to be followed, such as including a full copy of the Ms-PL in the cordova distribution, or b) rewrite these 2 methods with unique code. Given that these 2 methods are following a spec to write out a WAV header, doing a rewrite would seem to be easy. What does the group here think, and who could correct this issue? It would seem this needs to get taken care of before the final release of 2.2.0. Also looks like the exact same issue exists in another source file, incubator-cordova-wp7/templates/standalone/cordovalib/UI/AudioRecorder.xaml.cs -- Marcel Kinard
[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
Re: FYI new convienance redirect on issues.cordova.io
Jira has an API I'm pretty sure! We're pretty good at implementing shims ya? Let's fill the JIRA gap. On 10/29/12 10:19 AM, "Brian LeRoux" wrote: >At some point I'd like to make both searching and submitting bugs to >Cordova easier for sure. =/ > > >On Mon, Oct 29, 2012 at 7:31 AM, Braden Shepherdson >wrote: >> +1! >> >> JIRA search is so bad that my approach to finding bugs by keywords is to >> search on Gmail and then click the link. Yeah. >> >> Braden >> >> >> On Fri, Oct 26, 2012 at 5:56 PM, Dave Johnson >>wrote: >> >>> I thought the jira/browse/CB-xyz was really intuitive :( >>> >>> On Fri, Oct 26, 2012 at 10:05 PM, Michal Mocny >>> wrote: >>> > +1. Big Time. >>> > >>> > On Fri, Oct 26, 2012 at 3:58 PM, Brian LeRoux wrote: >>> >> issues.cordova.io ---> >>>https://issues.apache.org/jira/browse/CB >>> >> issues.cordova.io/1234 ---> >>> https://issues.apache.org/jira/browse/CB-1234 >>>
Re: FYI new convienance redirect on issues.cordova.io
At some point I'd like to make both searching and submitting bugs to Cordova easier for sure. =/ On Mon, Oct 29, 2012 at 7:31 AM, Braden Shepherdson wrote: > +1! > > JIRA search is so bad that my approach to finding bugs by keywords is to > search on Gmail and then click the link. Yeah. > > Braden > > > On Fri, Oct 26, 2012 at 5:56 PM, Dave Johnson wrote: > >> I thought the jira/browse/CB-xyz was really intuitive :( >> >> On Fri, Oct 26, 2012 at 10:05 PM, Michal Mocny >> wrote: >> > +1. Big Time. >> > >> > On Fri, Oct 26, 2012 at 3:58 PM, Brian LeRoux wrote: >> >> issues.cordova.io ---> https://issues.apache.org/jira/browse/CB >> >> issues.cordova.io/1234 ---> >> https://issues.apache.org/jira/browse/CB-1234 >>
[jira] [Updated] (CB-1748) Building for BlackBerry 10 doesn't work on Windows
[ https://issues.apache.org/jira/browse/CB-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gord updated CB-1748: - Fix Version/s: (was: 2.3.0) 2.2.0 This made it into 2.2 > Building for BlackBerry 10 doesn't work on Windows > -- > > Key: CB-1748 > URL: https://issues.apache.org/jira/browse/CB-1748 > Project: Apache Cordova > Issue Type: Bug > Components: BlackBerry >Affects Versions: 2.1.0 >Reporter: Gord >Assignee: Gord >Priority: Minor > Fix For: 2.2.0 > > > Complains that it can't find bbwp.exe: > https://twitter.com/Gerii92/status/261847756186996738 -- 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-1752) GPS position.speed is 0 in background tracking
Bernhard Bezdek created CB-1752: --- Summary: GPS position.speed is 0 in background tracking Key: CB-1752 URL: https://issues.apache.org/jira/browse/CB-1752 Project: Apache Cordova Issue Type: Bug Components: iOS Affects Versions: 2.1.0 Environment: iPhone 4 iOS 5.1 CDV 2.1 Reporter: Bernhard Bezdek Assignee: Shazron Abdullah In an App latitude, longitude, altitude, speed and timestamp is stored into a database table. As long as the App is in foreground everything works fine. If App is going into background mode (location) and is reopened a time later everything without the speed is going into table. There's only one codebase for tracking (navigator.geolocation.watchPosition) -- 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: FYI new convienance redirect on issues.cordova.io
+1! JIRA search is so bad that my approach to finding bugs by keywords is to search on Gmail and then click the link. Yeah. Braden On Fri, Oct 26, 2012 at 5:56 PM, Dave Johnson wrote: > I thought the jira/browse/CB-xyz was really intuitive :( > > On Fri, Oct 26, 2012 at 10:05 PM, Michal Mocny > wrote: > > +1. Big Time. > > > > On Fri, Oct 26, 2012 at 3:58 PM, Brian LeRoux wrote: > >> issues.cordova.io ---> https://issues.apache.org/jira/browse/CB > >> issues.cordova.io/1234 ---> > https://issues.apache.org/jira/browse/CB-1234 >
[jira] [Commented] (CB-604) doesn't work in strict mode
[ https://issues.apache.org/jira/browse/CB-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486031#comment-13486031 ] Peter Paul Elfferich commented on CB-604: - Thanks Walter and Jay! Patched my target-script-min.js with the try-catch workaround and have been able to use Weinre again ever since (though I'm sure some things will not be fully functional anymore). > doesn't work in strict mode > --- > > Key: CB-604 > URL: https://issues.apache.org/jira/browse/CB-604 > Project: Apache Cordova > Issue Type: Bug > Components: weinre > Environment: ubuntu/windows >Reporter: hongbo lu >Assignee: Patrick Mueller > > weinre doesn't work in strict mode ,because it trys to access "func.caller" > which isn't allowed in strict mode -- 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: iOS changes in 2.2.0
Woot, go shame! On 28 October 2012 09:37, Simon MacDonald wrote: > You have shamed me into it. I will put something together this week. > > Simon Mac Donald > http://hi.im/simonmacdonald > > > On Sat, Oct 27, 2012 at 2:53 PM, Andrew Lunny wrote: > >> This is awesome Shaz - thanks for writing this up every release. >> >> It would be even awesomer if one of the Android devs could do the same >> thing - I know Simon does similar things with individual features, but it >> would be great to have this kind of roundup for Android. >> >> On 27 October 2012 09:50, Shazron wrote: >> >> > >> > >> http://shazronatadobe.wordpress.com/2012/10/27/whats-new-in-cordova-ios-2-2-0/ >> > >> > On Mon, Oct 22, 2012 at 2:28 PM, Shazron wrote: >> > > Thanks Andrew, I'll incorporate those in. >> > > >> > > On Mon, Oct 22, 2012 at 6:51 AM, Andrew Grieve >> > wrote: >> > >> Sounds great Shaz! Might also be worth mentioning the bridge >> > improvements: >> > >> -No longer broken for non file:// pages >> > >> -No longer shows failed requests in the remote web inspector >> > >> -15% speed improvement in benchmarks >> > >> >> > >> >> > >> On Mon, Oct 22, 2012 at 3:57 AM, Shazron wrote: >> > >> >> > >>> I'm preparing a blog post. Here is the outline of what I have so >> far: >> > >>> >> > >>> 1. CordovaLib multiple architecture support (across all versions of >> > iOS) >> > >>> 2. Added Capture API microphone image for iPhone 5 dimensions and >> > >>> orientation fix >> > >>> 3. Adde dFileTransfer API progress events, abort function >> > >>> 4. Cordova.plist - added two new iOS 6 properties >> > >>> (SuppressesIncrementalRendering, KeyboardDisplayRequiresUserAction) >> > >>> 5. Added Globalization Core Plugin >> > >>> 6. Fixed iOS 6 orientation issues >> > >>> 7. Added iOS 6 LocalStorage changes (backup flag) >> > >>> 8. bin/create changes for shared and CordovaLib copying >> > >>> 9. uncrustify hook for committers >> > >>> 10. onReset() override for plugins >> > >>> >> > >>> Link: >> > >>> >> > >>> >> > >> https://github.com/apache/incubator-cordova-ios/blob/b74752f42da53532150d17aab80c0c6ae36a1a69/RELEASENOTES.md >> > >>> >> > >> > >
RE: 2.2.0rc2 Monday?
Any reason the webOS Part of 2.2.0rc2 doesn't include the updated cordova-js for webOS? Should I go ahead an include cordova-js, update the Makefile etc.? Markus -Original Message- From: Herm Wong [mailto:kingoftheo...@hotmail.com] Sent: Samstag, 27. Oktober 2012 00:49 To: dev@cordova.apache.org Subject: RE: 2.2.0rc2 Monday? updated the issue tracker. everything was merged and tested a couple of days ago. > From: f...@adobe.com > To: dev@cordova.apache.org > Date: Fri, 26 Oct 2012 13:42:20 -0700 > Subject: Re: 2.2.0rc2 Monday? > > How is webos tagged but the Javascript not updated? Im assuming the > issue was not resolved? comeon people! > > On 10/26/12 1:40 PM, "Steven Gill" wrote: > > >WP7 & docs haven't been tagged yet. > > > >-Steve > > > >On Fri, Oct 26, 2012 at 1:38 PM, Filip Maj wrote: > > > >> All the tasks are done. Steve did you make the release? Let's make > >> some noise about it. > >> > >> On 10/26/12 1:14 PM, "Andrew Grieve" wrote: > >> > >> >Okay, Simon, Bryce and I worked through the (final?) issue they > >> >were seeing with CB-1745. > >> > > >> >I've re-tagged the JS and Android again. Let's get this release > >>rolling! > >> > > >> > > >> >On Fri, Oct 26, 2012 at 1:37 PM, Gord Tanner > >>wrote: > >> > > >> >> thanks :) > >> >> > >> >> Teach a man to fish! > >> >> > >> >> retagged blackberry > >> >> > >> >> On Fri, Oct 26, 2012 at 1:14 PM, Andrew Grieve > >> >> > >> >> wrote: > >> >> > >> >> > FYI - the problem I was facing was not knowing the git foo for > >>pushing > >> >> > tags. To re-tag: > >> >> > > >> >> > git fetch apache # Fetch tags > >> >> > git tag --force 2.2.0rc2 # Re-tag locally git push apache > >> >> > master --tag # Push tags > >> >> > > >> >> > I'll put this on the CuttingReleases wiki page. > >> >> > > >> >> > > >> >> > On Fri, Oct 26, 2012 at 1:11 PM, Gord Tanner > >> >> > > >> >> wrote: > >> >> > > >> >> > > anyone have any objections of getting this fix into > >> >> > > blackberry > >>for > >> >>2.2? > >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> > >> >> > >> > >>https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackber > >>ry-we > >> >>bworks.git;a=commit;h=6ae80d9ac480f01c2d5734656a7f33c044d11139 > >> >> > > > >> >> > > also I fail at teh git so if there is no objections could > >> >> > > someone > >> >>retag > >> >> > > blackberry for me? > >> >> > > > >> >> > > On Fri, Oct 26, 2012 at 10:42 AM, Andrew Grieve > >> >> >> >> > > >wrote: > >> >> > > > >> >> > > > Sounds good. I've now re-tagged the JS and Android. > >> >> > > > > >> >> > > > > >> >> > > > On Thu, Oct 25, 2012 at 10:56 PM, Simon MacDonald < > >> >> > > > simon.macdon...@gmail.com > >> >> > > > > wrote: > >> >> > > > > >> >> > > > > I'm still seeing the bug but I don't think it should > >> >> > > > > hold up > >>the > >> >> > > tagging > >> >> > > > of > >> >> > > > > 2.2.0rc2 at this point. I created a small sync Plugin > >> >> > > > > for > >> >>testing > >> >> and > >> >> > > it > >> >> > > > > runs fine in my mobile spec test case. Now the same > >> >> > > > > plugin > >> >>called > >> >> in > >> >> > > the > >> >> > > > > downstream app which uses the same Android library > >> >> > > > > project > >>for > >> >> > Cordova > >> >> > > > and > >> >> > > > > the same .js file returns the wrong value when I call > >> >> > > > > the > >> >>plugin. > >> >> At > >> >> > > this > >> >> > > > > point I'm not convinced it is a Cordova issue. > >> >> > > > > > >> >> > > > > Simon Mac Donald > >> >> > > > > http://hi.im/simonmacdonald > >> >> > > > > > >> >> > > > > > >> >> > > > > On Thu, Oct 25, 2012 at 8:56 PM, Andrew Grieve < > >> >> agri...@chromium.org > >> >> > > > >> >> > > > > wrote: > >> >> > > > > > >> >> > > > > > Joe - my thinking here is that it's fine to re-tag and > >>re-tag > >> >> until > >> >> > > we > >> >> > > > > > actually produce an RC with everything tagged. rc2 is > >>still in > >> >> the > >> >> > > > > process > >> >> > > > > > of being tagged, and until the tagging is all done, it > >> >> > > > > > just > >> >> causes > >> >> > > more > >> >> > > > > > work to scratch it and have to re-tag all of the other > >>repos. > >> >> Once > >> >> > we > >> >> > > > > > create an rc2 archive though, no more adjusting. > >> >> > > > > > > >> >> > > > > > Marcel - yes, my intention is to retag the JS with the > >>Android > >> >> > > changes, > >> >> > > > > and > >> >> > > > > > to update the JS in android repo and then re-tag that > >> >> > > > > > as > >>well. > >> >> > Simon > >> >> > > > was > >> >> > > > > > still seeing a bug with one of his projects though, > >> >> > > > > > even > >>after > >> >> the > >> >> > > fix, > >> >> > > > > so > >> >> > > > > > I'd like to wait for his verification before continuing. > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > On Thu, Oct 25, 2012 at 5:13 PM, Michael Brooks < > >> >> > > > > mich...@michaelbrooks.ca > >> >> > > > > > >wrote: > >> >> > > > > > > >> >> > > > > > > Sorry, just c
RE: 2.2.0rc2 Monday?
Any reason the webOS Part of 2.2.0rc2 doesn't include the updated cordova-js for webOS? Markus -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Samstag, 27. Oktober 2012 00:20 To: dev@cordova.apache.org Subject: Re: 2.2.0rc2 Monday? PhoneGap 2.2.0RC2 - https://github.com/phonegap/phonegap/zipball/2.2.0rc2 I will get Cordova up shortly on http://people.apache.org/~steven/. On Fri, Oct 26, 2012 at 2:12 PM, Jesse wrote: > wp7 is tagged, working out some deets on windows8, but it does not > need to be packaged in this RC, so go ahead. > > Sorry for the delay on my end, I have been out for parental leave, > back at it now. > > Good thing the subject didn't say which Monday ... > Cheers, > Jesse > > On Fri, Oct 26, 2012 at 1:50 PM, Michael Brooks > wrote: > > Docs are now tagged. > > > > On Fri, Oct 26, 2012 at 1:42 PM, Filip Maj wrote: > > > >> How is webos tagged but the Javascript not updated? Im assuming the > issue > >> was not resolved? comeon people! > >> > >> On 10/26/12 1:40 PM, "Steven Gill" wrote: > >> > >> >WP7 & docs haven't been tagged yet. > >> > > >> >-Steve > >> > > >> >On Fri, Oct 26, 2012 at 1:38 PM, Filip Maj wrote: > >> > > >> >> All the tasks are done. Steve did you make the release? Let's > >> >> make > some > >> >> noise about it. > >> >> > >> >> On 10/26/12 1:14 PM, "Andrew Grieve" wrote: > >> >> > >> >> >Okay, Simon, Bryce and I worked through the (final?) issue they > >> >> >were seeing with CB-1745. > >> >> > > >> >> >I've re-tagged the JS and Android again. Let's get this release > >> >>rolling! > >> >> > > >> >> > > >> >> >On Fri, Oct 26, 2012 at 1:37 PM, Gord Tanner > >> >> > > >> >>wrote: > >> >> > > >> >> >> thanks :) > >> >> >> > >> >> >> Teach a man to fish! > >> >> >> > >> >> >> retagged blackberry > >> >> >> > >> >> >> On Fri, Oct 26, 2012 at 1:14 PM, Andrew Grieve < > agri...@chromium.org > >> > > >> >> >> wrote: > >> >> >> > >> >> >> > FYI - the problem I was facing was not knowing the git foo > >> >> >> > for > >> >>pushing > >> >> >> > tags. To re-tag: > >> >> >> > > >> >> >> > git fetch apache # Fetch tags git tag --force 2.2.0rc2 # > >> >> >> > Re-tag locally git push apache master --tag # Push tags > >> >> >> > > >> >> >> > I'll put this on the CuttingReleases wiki page. > >> >> >> > > >> >> >> > > >> >> >> > On Fri, Oct 26, 2012 at 1:11 PM, Gord Tanner < > g...@tinyhippos.com> > >> >> >> wrote: > >> >> >> > > >> >> >> > > anyone have any objections of getting this fix into > >> >> >> > > blackberry > >> >>for > >> >> >>2.2? > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > >> >> >> > >> >> >> > >> >> > >> >> > >> > https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry > -we > >> >> >>bworks.git;a=commit;h=6ae80d9ac480f01c2d5734656a7f33c044d11139 > >> >> >> > > > >> >> >> > > also I fail at teh git so if there is no objections could > someone > >> >> >>retag > >> >> >> > > blackberry for me? > >> >> >> > > > >> >> >> > > On Fri, Oct 26, 2012 at 10:42 AM, Andrew Grieve > >> >> >> >> >> >> > > >wrote: > >> >> >> > > > >> >> >> > > > Sounds good. I've now re-tagged the JS and Android. > >> >> >> > > > > >> >> >> > > > > >> >> >> > > > On Thu, Oct 25, 2012 at 10:56 PM, Simon MacDonald < > >> >> >> > > > simon.macdon...@gmail.com > >> >> >> > > > > wrote: > >> >> >> > > > > >> >> >> > > > > I'm still seeing the bug but I don't think it should > >> >> >> > > > > hold > up > >> >>the > >> >> >> > > tagging > >> >> >> > > > of > >> >> >> > > > > 2.2.0rc2 at this point. I created a small sync Plugin > >> >> >> > > > > for > >> >> >>testing > >> >> >> and > >> >> >> > > it > >> >> >> > > > > runs fine in my mobile spec test case. Now the same > >> >> >> > > > > plugin > >> >> >>called > >> >> >> in > >> >> >> > > the > >> >> >> > > > > downstream app which uses the same Android library > >> >> >> > > > > project > >> >>for > >> >> >> > Cordova > >> >> >> > > > and > >> >> >> > > > > the same .js file returns the wrong value when I call > >> >> >> > > > > the > >> >> >>plugin. > >> >> >> At > >> >> >> > > this > >> >> >> > > > > point I'm not convinced it is a Cordova issue. > >> >> >> > > > > > >> >> >> > > > > Simon Mac Donald > >> >> >> > > > > http://hi.im/simonmacdonald > >> >> >> > > > > > >> >> >> > > > > > >> >> >> > > > > On Thu, Oct 25, 2012 at 8:56 PM, Andrew Grieve < > >> >> >> agri...@chromium.org > >> >> >> > > > >> >> >> > > > > wrote: > >> >> >> > > > > > >> >> >> > > > > > Joe - my thinking here is that it's fine to re-tag > >> >> >> > > > > > and > >> >>re-tag > >> >> >> until > >> >> >> > > we > >> >> >> > > > > > actually produce an RC with everything tagged. rc2 > >> >> >> > > > > > is > >> >>still in > >> >> >> the > >> >> >> > > > > process > >> >> >> > > > > > of being tagged, and until the tagging is all done, > >> >> >> > > > > > it > just > >> >> >> causes > >> >> >> > > more > >> >> >> > > > > > work to scratch it and have to re-tag all of the > >> >> >> >
