[jira] [Commented] (CB-2154) navigator.splashscreen.show() broken in Phonegap 2.2 and 2.3.0rc2
[
https://issues.apache.org/jira/browse/CB-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550814#comment-13550814
]
Ismael Olusola Jimoh commented on CB-2154:
--
Hi Simon,
Thanks for having a look at this.
Please in the scenario which I had intended to use this, I wanted to show the
splashscreen while waiting for a video to load.
So I will need it to show both at launch(loadUrl) and after that.
Would appreciate the help.
Ismael
> navigator.splashscreen.show() broken in Phonegap 2.2 and 2.3.0rc2
> -
>
> Key: CB-2154
> URL: https://issues.apache.org/jira/browse/CB-2154
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Android, Phonegap 2.2 and 2.3rc2
>Reporter: Ismael Olusola Jimoh
>Assignee: Simon MacDonald
> Fix For: 2.4.0
>
>
> I tested the navigator.splashscreen.show() function as documented and
> realised that it is broken.
> The Splash-screen works as expected when app launched but a button call to
> show splashscreen doesn't work.
> I had tested this same thing on Phonegap 2.1 and it worked alright so was
> surprised it didn't work on 2.2. I then tested on Phonegap 2.3 and realised
> it was also broken.
> Below is the code I used:
>
>
>
> Splashscreen Example
> src="cordova-2.3.0rc2.js">
>
> // Wait for Cordova to load
> //
> document.addEventListener("deviceready", onDeviceReady, false);
> // Cordova is ready
> //
> function onDeviceReady() {
> //navigator.splashscreen.show();
> }
> function showSplash() {
> setTimeout(function() {
> navigator.splashscreen.show();
> }, 2000);
> }
> function hideSplash() {
> setTimeout(function() {
> navigator.splashscreen.hide();
> }, 2000);
> }
>
>
>
> Example
> Show
> Hide
>
>
> It doesn't work as mentioned on neither 2.2 nor 2.3.
> Thanks.
> Ismael
--
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-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse
[ https://issues.apache.org/jira/browse/CB-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550802#comment-13550802 ] William Wong commented on CB-2183: -- According to Apple doc, 4 types of protocol need to be handled: http, https, ftp, and file. > [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse > -- > > Key: CB-2183 > URL: https://issues.apache.org/jira/browse/CB-2183 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.2.0 > Environment: Tested on iOS 5.1 and 6.0 >Reporter: William Wong >Assignee: Shazron Abdullah >Priority: Critical > Labels: File, FileTransfer > Fix For: 2.4.0 > > > When FileTransfer.download() is downloading a file from file:///, > NSURLConnection did not return with NSHTTPURLResponse. This will fail for > apps that copy files from www/, e.g. apps that initialize its database from a > pre-built cache packaged in IPA. > In CB-1600 (fixed in 2.2.0), the fix assumes all response must be > NSHTTPURLResponse. So when FileTransfer.download() is downloading from a > file:/// URL (e.g. copying file from www/ folder to Documents/), FileTransfer > assumed the download operation failed and returned 403. > Tested if we comment out CB-1600, downloading from file:/// works again. > We need to find out a better fix instead of commenting out CB-1600. > According to > http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html#//apple_ref/doc/uid/1165i, > URL of file:/// is supported. > You can test FileTransfer.download() by calling it with > "encodeURI(document.location.href)" as the "source" parameter. -- 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: Moving plugin JS files around
On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner wrote:
> Ideally the require paths should stay true to the following rules (not that
> we follow them exactly now but we are close):
>
> 1. should always start with cordova (in case we ever share a require
> framework)
> 2. should follow as close as possible to the folder structure.
>
> We don't really do this now (but we are close). It is mainly to help with
> navigation of the project from a require statement:
>
> var foo = require('cordova/plugin/foo/submodule')
>
> Ideally I should be able to navigate to a file that lives in:
>
> ~/cordova.js/plugin/foo/submodule.js
>
> But realistically we are probably going to see:
>
> ~/cordova.js/plugin/foo/js/submodule.js
>
> Assuming we are dumping everything into a js folder here is the "mapping"
> off the top of my head:
>
> var foo = require('cordova/plugin/foo')
> ~/cordova.js/plugin/foo/js/index.js
>
> var foo = require('cordova/plugin/foo/ios')
> ~/cordova.js/plugin/foo/js/ios.js
>
> var foo = require('cordova/plugin/foo/blackberry/qnx')
> ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>
> What does a plugin (native and js code) folder structure look like?
>
Have a look at this plugin: https://github.com/shazron/KeychainPlugin
With the JS changes I'm proposing, it would look like:
/src/ios/*.h, *.m
/www <- empty!
/src/js/common/keychain.js
or
/src/js/ios/keychain.js
So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
within cordova-js, is that when they move out, there will be the mapping:
cordova-js/plugin/$PLUGIN_NAME ---> $PLUGIN_REPO/src/js
When a plugin is installed into a project via cordova-cli, I suggest that
we get a structure like this:
MyApp/platforms/ios/... same as before ...
MyApp/cordova-js/... copy of cordova-js
MyApp/cordova-js/plugin/keychain/common/keychain.js
MyApp/plugins/keychain/plugin.xml
MyApp/www
So, the idea here is that the cordova-js will have no top-level plugin/
directory, but one will be added when plugins are added.
Also, like other sources, .js file should be listed in the plugin.xml so
that they can be reliably removed.
About the require paths. I think for files in cordova-js, the prefix should
be "cordova/", but for plugin files, it should be "plugin/" (or maybe
"cordovaplugin/"?), so that plugin JS doesn't accidentally clobber core
cordova modules.
For the keychain example: require('cordovaplugin/keychain/keychain')
In terms of changes to the builder, we'd need to add the idea of multiple
roots. Instead of just 'lib', there will also be 'plugin' as a root.
>
> On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve wrote:
>
> > I'd like to take a first step towards moving plugin JS into separate
> repos
> > by first moving them around within cordova-js.
> >
> > Here is my proposal:
> >
> > Current structure:
> > lib/common/plugin/*.js
> > lib/$PLATFORM/plugin/*.js
> >
> > New structure:
> > plugin/$PLUGIN_NAME/js/common/*.js
> > plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> >
> > The require path will need to change. Going from:
> > cordova.require('cordova/plugin/FileTransferError')
> > To:
> > cordova.require('plugin/file/FileTransferError')
> >
> >
> > I'll obviously need to update the builder scripts accordingly. The idea
> > here is that we:
> > 1. "cordova plugin add" will copy files into a project's plugins
> > directory
> > 2. "cordova build ios" will use the cordova-js packager and pass
> it
> > the plugin/ directory to use
> >
> > This will not involve changing how we export modules onto namespaces in
> > common.js / platform.js. That will come next though.
> >
> >
> > The resulting structure will look like:
> >
> > plugin/accelerometer/js/common/Acceleration.js
> > plugin/accelerometer/js/common/accelerometer.js
> > plugin/battery/js/common/battery.js
> > plugin/compass/js/common/Compass*.js
> > plugin/contacts/js/common/Contact*.js
> > plugin/device/js/common/device.js
> > plugin/geolocation/js/common/Coordinates.js
> > plugin/geolocation/js/common/Position*.js
> > plugin/globalization/js/common/Globalization*.js
> > plugin/inappbrowser/js/common/InAppBrowser.js
> > plugin/logger/js/common/logger.js
> > plugin/logger/js/common/console-via-logger.js
> > plugin/media/js/common/Capture*.js
> > plugin/media/js/common/ConfigurationData.js
> > plugin/media/js/common/Media*.js
> > plugin/network/js/common/Connection.js
> > plugin/notification/js/common/notification.js
> > plugin/camera/js/common/Camera*.js
> > plugin/echo/js/common/echo.js
> > plugin/file/js/common/Directory*.js
> > plugin/file/js/common/Entry.js
> > plugin/file/js/common/File*.js
> > plugin/file/js/common/Flags.js
> > plugin/file/js/common/LocalFileSystem.js
> > plugin/file/js/common/Metadata.js
> > plugin/file/js/common/ProgressEvent.js
> > plugin/splashscreen/js/common/splashscreen.js
> >
>
[jira] [Resolved] (CB-2154) navigator.splashscreen.show() broken in Phonegap 2.2 and 2.3.0rc2
[
https://issues.apache.org/jira/browse/CB-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon MacDonald resolved CB-2154.
-
Resolution: Fixed
Fix Version/s: 2.4.0
Fixed the splashscreen so it will show for a minimum of 3 seconds if the user
has not called loadUrl with a timeout in their main activity.
> navigator.splashscreen.show() broken in Phonegap 2.2 and 2.3.0rc2
> -
>
> Key: CB-2154
> URL: https://issues.apache.org/jira/browse/CB-2154
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Android, Phonegap 2.2 and 2.3rc2
>Reporter: Ismael Olusola Jimoh
>Assignee: Simon MacDonald
> Fix For: 2.4.0
>
>
> I tested the navigator.splashscreen.show() function as documented and
> realised that it is broken.
> The Splash-screen works as expected when app launched but a button call to
> show splashscreen doesn't work.
> I had tested this same thing on Phonegap 2.1 and it worked alright so was
> surprised it didn't work on 2.2. I then tested on Phonegap 2.3 and realised
> it was also broken.
> Below is the code I used:
>
>
>
> Splashscreen Example
> src="cordova-2.3.0rc2.js">
>
> // Wait for Cordova to load
> //
> document.addEventListener("deviceready", onDeviceReady, false);
> // Cordova is ready
> //
> function onDeviceReady() {
> //navigator.splashscreen.show();
> }
> function showSplash() {
> setTimeout(function() {
> navigator.splashscreen.show();
> }, 2000);
> }
> function hideSplash() {
> setTimeout(function() {
> navigator.splashscreen.hide();
> }, 2000);
> }
>
>
>
> Example
> Show
> Hide
>
>
> It doesn't work as mentioned on neither 2.2 nor 2.3.
> Thanks.
> Ismael
--
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: Cordova Activity Code Changes
On Thu, Jan 10, 2013 at 6:31 PM, Andrew Grieve wrote: > I'd like to verify if this is the scenario: > 1. We invoke an intent that causes another app to take the foreground. > 2. Our app is forced to close by the OS due to memory pressures > 3. The other app finishes and sends an intent back to us > 4. Our app re-initializes, finds the plugin that started the request, and > gives it the result > That's the exact scenario! In theory this should work. In practice, it sort-of works, except that the Camera doesn't pass data back if you don't allow background processes (I tested it by restricting the background processes). > Assuming I've got this straight, I think there is value in adding in this > code. *if* apps design themselves such that their state is always stored, > then they should have a chance at restoring their state when they > re-launch. > > Uncertainties I have: > 1. Do we have a chance to give JS some time to run > within onSaveInstanceState? Perhaps we can send a message to the webkit > thread and then just sleep for a second? Perhaps even let it store things > in the Bundle? I don't know. I'm hoping that this stops when we save the WebKit state, but I'd have to go spelunking in the Android WebKit code to figure this out. > 2. Upon re-launch, can we signal to the JS that it is "restarting" instead > of starting from scratch? We could easily do this, since we have to watch for the bundle in the activity in the first place. From my tests, restoring the state is the same as hitting the refresh button on the page. I have no idea what happens to session variables or anything else that is present at that time. Joe
[jira] [Commented] (CB-2154) navigator.splashscreen.show() broken in Phonegap 2.2 and 2.3.0rc2
[
https://issues.apache.org/jira/browse/CB-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550734#comment-13550734
]
Simon MacDonald commented on CB-2154:
-
[~bennmapes] You don't need to look into it as I'm about to push a fix.
> navigator.splashscreen.show() broken in Phonegap 2.2 and 2.3.0rc2
> -
>
> Key: CB-2154
> URL: https://issues.apache.org/jira/browse/CB-2154
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Android, Phonegap 2.2 and 2.3rc2
>Reporter: Ismael Olusola Jimoh
>Assignee: Simon MacDonald
>
> I tested the navigator.splashscreen.show() function as documented and
> realised that it is broken.
> The Splash-screen works as expected when app launched but a button call to
> show splashscreen doesn't work.
> I had tested this same thing on Phonegap 2.1 and it worked alright so was
> surprised it didn't work on 2.2. I then tested on Phonegap 2.3 and realised
> it was also broken.
> Below is the code I used:
>
>
>
> Splashscreen Example
> src="cordova-2.3.0rc2.js">
>
> // Wait for Cordova to load
> //
> document.addEventListener("deviceready", onDeviceReady, false);
> // Cordova is ready
> //
> function onDeviceReady() {
> //navigator.splashscreen.show();
> }
> function showSplash() {
> setTimeout(function() {
> navigator.splashscreen.show();
> }, 2000);
> }
> function hideSplash() {
> setTimeout(function() {
> navigator.splashscreen.hide();
> }, 2000);
> }
>
>
>
> Example
> Show
> Hide
>
>
> It doesn't work as mentioned on neither 2.2 nor 2.3.
> Thanks.
> Ismael
--
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: Cordova Activity Code Changes
I'd like to verify if this is the scenario: 1. We invoke an intent that causes another app to take the foreground. 2. Our app is forced to close by the OS due to memory pressures 3. The other app finishes and sends an intent back to us 4. Our app re-initializes, finds the plugin that started the request, and gives it the result Assuming I've got this straight, I think there is value in adding in this code. *if* apps design themselves such that their state is always stored, then they should have a chance at restoring their state when they re-launch. Uncertainties I have: 1. Do we have a chance to give JS some time to run within onSaveInstanceState? Perhaps we can send a message to the webkit thread and then just sleep for a second? Perhaps even let it store things in the Bundle? 2. Upon re-launch, can we signal to the JS that it is "restarting" instead of starting from scratch? On Thu, Jan 10, 2013 at 8:18 PM, Joe Bowser wrote: > BTW: This isn't a JS API change at all. > > On Thu, Jan 10, 2013 at 5:18 PM, Joe Bowser wrote: > > Blargh! Making things merge cleanly has reduced readibility: > > > > > https://github.com/infil00p/cordova-android/commit/5ca233779d11177ec2bef97afa2910d383d6d4a2 > > > > That's the meat of it. I'm sure there's more in here, but I mostly > > want to get the state change code working. For CordovaWebView, we're > > probably going to figure out some helper methods to allow users to > > restore their states, but when you're working on your own Android App > > with custom views, I think it's safe to say that your intents and > > states are your own responsibility. > > > > On Thu, Jan 10, 2013 at 4:48 PM, Brian LeRoux wrote: > >> Love the functionality conceptually speaking but where is this code > >> exactly so I can have a look Joe? (There's like a 1000 commits on that > >> branch and I'm abjectly lazy.) > >> > >> On Thu, Jan 10, 2013 at 4:40 PM, Filip Maj wrote: > >>> If it works, don't see why not! > >>> > >>> On 1/10/13 4:29 PM, "Joe Bowser" wrote: > >>> > Hey > > I'm wanting to merge some of the state code that I was working on > before the break in. Are people still cool with this? > > https://github.com/infil00p/cordova-android/tree/CordovaActivity > > Basically, this lets us restore our state if we got the app killed > while we were in Camera. Assuming that the Camera can store the data, > this should get around the Camera issue. It was called > CordovaActivity because I thought we were going to implement the > Activity. This turned out not to be the case. > > Thoughts? > > Joe > >>> >
[jira] [Resolved] (CB-2204) ./bin/create script should exit out with non-zero code if fails
[ https://issues.apache.org/jira/browse/CB-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filip Maj resolved CB-2204. --- Resolution: Fixed Assignee: Filip Maj (was: Joe Bowser) Fixed in [dc94fc3|https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=dc94fc39ec8bac1cb09eaa264a74266538a1b9c4]. > ./bin/create script should exit out with non-zero code if fails > --- > > Key: CB-2204 > URL: https://issues.apache.org/jira/browse/CB-2204 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.3.0 >Reporter: Filip Maj >Assignee: Filip Maj > Fix For: 2.4.0 > > > I noticed this problem when setting up medic with android. > In this commit: 25aef94 > (https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=25aef945d14eae7167ece73c11e32d8471114bee), > the jar fails to compile, and as such the create script fails. > However, it exits with code 0. I believe this line is the culprit: > https://github.com/apache/cordova-android/blob/master/bin/create#L72 > I suggest patching it so it just exits with a code of 1, instead of trying to > be fancy. Thoughts? -- 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-2204) ./bin/create script should exit out with non-zero code if fails
[ https://issues.apache.org/jira/browse/CB-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550706#comment-13550706 ] Andrew Grieve commented on CB-2204: --- Another option is to just "exit 1" instead of trying to preserve the exit code. If the trap stuff works, it looks like it'll be quite useful (prints out last two commands) > ./bin/create script should exit out with non-zero code if fails > --- > > Key: CB-2204 > URL: https://issues.apache.org/jira/browse/CB-2204 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.3.0 >Reporter: Filip Maj >Assignee: Joe Bowser > Fix For: 2.4.0 > > > I noticed this problem when setting up medic with android. > In this commit: 25aef94 > (https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=25aef945d14eae7167ece73c11e32d8471114bee), > the jar fails to compile, and as such the create script fails. > However, it exits with code 0. I believe this line is the culprit: > https://github.com/apache/cordova-android/blob/master/bin/create#L72 > I suggest patching it so it just exits with a code of 1, instead of trying to > be fancy. Thoughts? -- 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-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse
[ https://issues.apache.org/jira/browse/CB-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550699#comment-13550699 ] Andrew Grieve commented on CB-2183: --- I think Patrick's patch means to address the same issue that's surfacing here. V1 of the code - Assumes response is NSHTTPURLResponse V2 of the code (Patrick's patch) - Check if it's not an NSHTTPURLResponse, and if not, return an error What we want to do in this case is to continue to check if it's not a NSHTTPURLResponse, and if not and it's a file:///, then use NSFileManager to figure out bytesExpected and set the response to 200. > [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse > -- > > Key: CB-2183 > URL: https://issues.apache.org/jira/browse/CB-2183 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.2.0 > Environment: Tested on iOS 5.1 and 6.0 >Reporter: William Wong >Assignee: Shazron Abdullah >Priority: Critical > Labels: File, FileTransfer > Fix For: 2.4.0 > > > When FileTransfer.download() is downloading a file from file:///, > NSURLConnection did not return with NSHTTPURLResponse. This will fail for > apps that copy files from www/, e.g. apps that initialize its database from a > pre-built cache packaged in IPA. > In CB-1600 (fixed in 2.2.0), the fix assumes all response must be > NSHTTPURLResponse. So when FileTransfer.download() is downloading from a > file:/// URL (e.g. copying file from www/ folder to Documents/), FileTransfer > assumed the download operation failed and returned 403. > Tested if we comment out CB-1600, downloading from file:/// works again. > We need to find out a better fix instead of commenting out CB-1600. > According to > http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html#//apple_ref/doc/uid/1165i, > URL of file:/// is supported. > You can test FileTransfer.download() by calling it with > "encodeURI(document.location.href)" as the "source" parameter. -- 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: too long to package a release?
I'm not clear on the difference between dev and unstable. If something is so shaky that we're considering not putting it in the next release, then I'd think that would go on a named feature branch (e.g. array_buffers). Unless... is the purpose of dev to be where we put together a release candidate? If so, maybe a better name would be "staging" On Thu, Jan 10, 2013 at 8:13 PM, Filip Maj wrote: > On 1/10/13 5:07 PM, "Brian LeRoux" wrote: > > >Thank you. I lean to agreement w/ Andrew that more meaningful pull > >reqs are better and having named branches for what they do makes > >sense. Also agree that tags are for points in time---but I take no > >exception to a branch for those as well for dev purposes. > > > >Let me try to capture the conversation to this point: > > > >Branches: > >- Master gets deleted. We want meaningful pull requests and this will > >force folks to pick a branch to dev against. > >- Stable: This is stable and frozen on the last tagged release. > >- Dev: The next release to be tagged. Feature branches merged from > >master when confident. This should build cleanly. > > ^^ merged from master? > > >- Unstable: the current working branch. Feature branches merged as > >needed for collaboration. No guarantee it builds. > > > >Tags: > >- Happen on the Stable branch. > > > >Workflow > >- Everyone works from local feature branch rebasing and committing to > >Unstable as neccessary. > >- When that feature branch is considered good enough, it is merged into > >Dev. > >- On release date whatever is Dev is rebased to Stable. Tagged. Released. > > > >Thoughts? > >
Re: Cordova Activity Code Changes
BTW: This isn't a JS API change at all. On Thu, Jan 10, 2013 at 5:18 PM, Joe Bowser wrote: > Blargh! Making things merge cleanly has reduced readibility: > > https://github.com/infil00p/cordova-android/commit/5ca233779d11177ec2bef97afa2910d383d6d4a2 > > That's the meat of it. I'm sure there's more in here, but I mostly > want to get the state change code working. For CordovaWebView, we're > probably going to figure out some helper methods to allow users to > restore their states, but when you're working on your own Android App > with custom views, I think it's safe to say that your intents and > states are your own responsibility. > > On Thu, Jan 10, 2013 at 4:48 PM, Brian LeRoux wrote: >> Love the functionality conceptually speaking but where is this code >> exactly so I can have a look Joe? (There's like a 1000 commits on that >> branch and I'm abjectly lazy.) >> >> On Thu, Jan 10, 2013 at 4:40 PM, Filip Maj wrote: >>> If it works, don't see why not! >>> >>> On 1/10/13 4:29 PM, "Joe Bowser" wrote: >>> Hey I'm wanting to merge some of the state code that I was working on before the break in. Are people still cool with this? https://github.com/infil00p/cordova-android/tree/CordovaActivity Basically, this lets us restore our state if we got the app killed while we were in Camera. Assuming that the Camera can store the data, this should get around the Camera issue. It was called CordovaActivity because I thought we were going to implement the Activity. This turned out not to be the case. Thoughts? Joe >>>
Re: Cordova Activity Code Changes
Blargh! Making things merge cleanly has reduced readibility: https://github.com/infil00p/cordova-android/commit/5ca233779d11177ec2bef97afa2910d383d6d4a2 That's the meat of it. I'm sure there's more in here, but I mostly want to get the state change code working. For CordovaWebView, we're probably going to figure out some helper methods to allow users to restore their states, but when you're working on your own Android App with custom views, I think it's safe to say that your intents and states are your own responsibility. On Thu, Jan 10, 2013 at 4:48 PM, Brian LeRoux wrote: > Love the functionality conceptually speaking but where is this code > exactly so I can have a look Joe? (There's like a 1000 commits on that > branch and I'm abjectly lazy.) > > On Thu, Jan 10, 2013 at 4:40 PM, Filip Maj wrote: >> If it works, don't see why not! >> >> On 1/10/13 4:29 PM, "Joe Bowser" wrote: >> >>>Hey >>> >>>I'm wanting to merge some of the state code that I was working on >>>before the break in. Are people still cool with this? >>> >>>https://github.com/infil00p/cordova-android/tree/CordovaActivity >>> >>>Basically, this lets us restore our state if we got the app killed >>>while we were in Camera. Assuming that the Camera can store the data, >>>this should get around the Camera issue. It was called >>>CordovaActivity because I thought we were going to implement the >>>Activity. This turned out not to be the case. >>> >>>Thoughts? >>> >>>Joe >>
Re: too long to package a release?
On 1/10/13 5:07 PM, "Brian LeRoux" wrote: >Thank you. I lean to agreement w/ Andrew that more meaningful pull >reqs are better and having named branches for what they do makes >sense. Also agree that tags are for points in time---but I take no >exception to a branch for those as well for dev purposes. > >Let me try to capture the conversation to this point: > >Branches: >- Master gets deleted. We want meaningful pull requests and this will >force folks to pick a branch to dev against. >- Stable: This is stable and frozen on the last tagged release. >- Dev: The next release to be tagged. Feature branches merged from >master when confident. This should build cleanly. ^^ merged from master? >- Unstable: the current working branch. Feature branches merged as >needed for collaboration. No guarantee it builds. > >Tags: >- Happen on the Stable branch. > >Workflow >- Everyone works from local feature branch rebasing and committing to >Unstable as neccessary. >- When that feature branch is considered good enough, it is merged into >Dev. >- On release date whatever is Dev is rebased to Stable. Tagged. Released. > >Thoughts?
Re: too long to package a release?
Thank you. I lean to agreement w/ Andrew that more meaningful pull reqs are better and having named branches for what they do makes sense. Also agree that tags are for points in time---but I take no exception to a branch for those as well for dev purposes. Let me try to capture the conversation to this point: Branches: - Master gets deleted. We want meaningful pull requests and this will force folks to pick a branch to dev against. - Stable: This is stable and frozen on the last tagged release. - Dev: The next release to be tagged. Feature branches merged from master when confident. This should build cleanly. - Unstable: the current working branch. Feature branches merged as needed for collaboration. No guarantee it builds. Tags: - Happen on the Stable branch. Workflow - Everyone works from local feature branch rebasing and committing to Unstable as neccessary. - When that feature branch is considered good enough, it is merged into Dev. - On release date whatever is Dev is rebased to Stable. Tagged. Released. Thoughts? On Thu, Jan 10, 2013 at 7:02 AM, Marcel Kinard wrote: > Poking this thread. So is there consensus on how to do this? If so, can this > be summarized and written up, perhaps on the ContributorWorkflow / > CommiterWorkflow wiki pages? > > And when would we want to start operating with this, 2.4/now or later? > > -- Marcel Kinard
Re: Cordova Activity Code Changes
Love the functionality conceptually speaking but where is this code exactly so I can have a look Joe? (There's like a 1000 commits on that branch and I'm abjectly lazy.) On Thu, Jan 10, 2013 at 4:40 PM, Filip Maj wrote: > If it works, don't see why not! > > On 1/10/13 4:29 PM, "Joe Bowser" wrote: > >>Hey >> >>I'm wanting to merge some of the state code that I was working on >>before the break in. Are people still cool with this? >> >>https://github.com/infil00p/cordova-android/tree/CordovaActivity >> >>Basically, this lets us restore our state if we got the app killed >>while we were in Camera. Assuming that the Camera can store the data, >>this should get around the Camera issue. It was called >>CordovaActivity because I thought we were going to implement the >>Activity. This turned out not to be the case. >> >>Thoughts? >> >>Joe >
Re: Cordova Activity Code Changes
If it works, don't see why not! On 1/10/13 4:29 PM, "Joe Bowser" wrote: >Hey > >I'm wanting to merge some of the state code that I was working on >before the break in. Are people still cool with this? > >https://github.com/infil00p/cordova-android/tree/CordovaActivity > >Basically, this lets us restore our state if we got the app killed >while we were in Camera. Assuming that the Camera can store the data, >this should get around the Camera issue. It was called >CordovaActivity because I thought we were going to implement the >Activity. This turned out not to be the case. > >Thoughts? > >Joe
[jira] [Created] (CB-2204) ./bin/create script should exit out with non-zero code if fails
Filip Maj created CB-2204: - Summary: ./bin/create script should exit out with non-zero code if fails Key: CB-2204 URL: https://issues.apache.org/jira/browse/CB-2204 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 2.3.0 Reporter: Filip Maj Assignee: Joe Bowser Fix For: 2.4.0 I noticed this problem when setting up medic with android. In this commit: 25aef94 (https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=25aef945d14eae7167ece73c11e32d8471114bee), the jar fails to compile, and as such the create script fails. However, it exits with code 0. I believe this line is the culprit: https://github.com/apache/cordova-android/blob/master/bin/create#L72 I suggest patching it so it just exits with a code of 1, instead of trying to be fancy. Thoughts? -- 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
Cordova Activity Code Changes
Hey I'm wanting to merge some of the state code that I was working on before the break in. Are people still cool with this? https://github.com/infil00p/cordova-android/tree/CordovaActivity Basically, this lets us restore our state if we got the app killed while we were in Camera. Assuming that the Camera can store the data, this should get around the Camera issue. It was called CordovaActivity because I thought we were going to implement the Activity. This turned out not to be the case. Thoughts? Joe
[jira] [Resolved] (CB-2155) getDeviceInfo never parses Settings.plist file
[
https://issues.apache.org/jira/browse/CB-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shazron Abdullah resolved CB-2155.
--
Resolution: Fixed
Indirectly fixed through CB-1946 -- the selector has been changed back to
JSONString
> getDeviceInfo never parses Settings.plist file
> --
>
> Key: CB-2155
> URL: https://issues.apache.org/jira/browse/CB-2155
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS
>Affects Versions: 2.2.0
>Reporter: Becky Gibson
>Assignee: Shazron Abdullah
> Fix For: 2.4.0
>
>
> The @selector check in CDVDevice.m getDeviceInfo needs to be updated to check
> for @selector(cdvjk_JSONString) rather than just JSONString. Currently the
> Settings.plist is never parsed.
> //current code that needs to be fixed:
> NSDictionary* temp = [CDVViewController getBundlePlist:@"Settings"];
> if ([temp respondsToSelector:@selector(JSONString)]) {
> NSString* js = [NSString stringWithFormat:@"window.Settings = %@;",
> [temp cdvjk_JSONString]];
> [self.commandDelegate evalJs:js];
> }
--
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] [Resolved] (CB-2188) Remove OpenAllWhitelistURLsInWebView from iOS Project Settings
[ https://issues.apache.org/jira/browse/CB-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-2188. -- Resolution: Fixed Fix commit - http://git-wip-us.apache.org/repos/asf/cordova-docs/commit/9699ada4 > Remove OpenAllWhitelistURLsInWebView from iOS Project Settings > -- > > Key: CB-2188 > URL: https://issues.apache.org/jira/browse/CB-2188 > Project: Apache Cordova > Issue Type: Bug > Components: Docs, iOS >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Fix For: 2.4.0 > > > Obsolete. Superceded by window.open _self (InAppBrowser) -- 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-2203) CordovaLib and upgrading instructions for iOS
[ https://issues.apache.org/jira/browse/CB-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-2203: - Fix Version/s: 2.4.0 > CordovaLib and upgrading instructions for iOS > - > > Key: CB-2203 > URL: https://issues.apache.org/jira/browse/CB-2203 > Project: Apache Cordova > Issue Type: Bug > Components: Docs >Affects Versions: 2.3.0 >Reporter: Jacob Weber >Assignee: Shazron Abdullah >Priority: Minor > Fix For: 2.4.0 > > > In the "Upgrading Cordova iOS" guide, it seems to be assuming the old project > format, where CordovaLib was in a shared directory rather than in the > project's directory. As I understand it, this changed with issue #CB-1526. > Step 1 says to extract Cordova to a permanent location. And there's nothing > in there about updating your project's copy of CordovaLib to the latest > version. > Also, don't we need to upgrade any of the other files in Classes, like > MainViewController.h? -- 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] [Resolved] (CB-1946) iOS: Switch JSON serialization to NSJSONSerialization
[ https://issues.apache.org/jira/browse/CB-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-1946. -- Resolution: Fixed Fix commit - https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=192122fe > iOS: Switch JSON serialization to NSJSONSerialization > - > > Key: CB-1946 > URL: https://issues.apache.org/jira/browse/CB-1946 > Project: Apache Cordova > Issue Type: Task > Components: iOS >Affects Versions: 2.3.0 >Reporter: Kevin Hawkins >Assignee: Shazron Abdullah > Fix For: 2.4.0 > > Original Estimate: 8h > Remaining Estimate: 8h > > Now that iOS 5.0 is a baseline requirement for Cordova for iOS, it would be > good to move away from the JSONKit dependency, in favor of Cocoa's built-in > NSJSONSerialization, which was added in iOS 5. > Add docs in the Cordova Plugin Upgrade Guide, update the unit tests. -- 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-2093) NullPointerException when attaching image from Gallery that contains spaces in the path
[
https://issues.apache.org/jira/browse/CB-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550562#comment-13550562
]
Joe Bowser commented on CB-2093:
[~domer] Can you upload your test?
> NullPointerException when attaching image from Gallery that contains spaces
> in the path
> ---
>
> Key: CB-2093
> URL: https://issues.apache.org/jira/browse/CB-2093
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.3.0
> Environment: Tested Cordova 2.3.0 RC2 on Galaxy Nexus 7 with Android
> 4.2.1
>Reporter: David Omer
>Assignee: Joe Bowser
>Priority: Critical
>
> When trying to use camera.getPicture with source=SAVEDPHOTOALBUM and
> destination=DATA_URL, I'm getting the following error:
> 12-20 15:22:56.256: W/dalvikvm(2089): threadid=1: thread exiting with
> uncaught exception (group=0x4122d930)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): FATAL EXCEPTION: main
> 12-20 15:22:56.266: E/AndroidRuntime(2089): java.lang.RuntimeException:
> Failure delivering result ResultInfo{who=null, request=49, result=-1,
> data=Intent {
> dat=content://com.google.android.gallery3d.provider/picasa/item/5080798897969217026
> flg=0x1 }} to activity
> {com.steton.mobileauditor/com.steton.mobileauditor.App}:
> java.lang.NullPointerException
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> android.app.ActivityThread.deliverResults(ActivityThread.java:3319)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> android.app.ActivityThread.handleSendResult(ActivityThread.java:3362)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> android.app.ActivityThread.access$1100(ActivityThread.java:141)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1282)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> android.os.Handler.dispatchMessage(Handler.java:99)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> android.os.Looper.loop(Looper.java:137)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> android.app.ActivityThread.main(ActivityThread.java:5039)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> java.lang.reflect.Method.invokeNative(Native Method)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> java.lang.reflect.Method.invoke(Method.java:511)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> com.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> dalvik.system.NativeStart.main(Native Method)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): Caused by:
> java.lang.NullPointerException
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> org.apache.cordova.FileUtils.getMimeType(FileUtils.java:989)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> org.apache.cordova.CameraLauncher.onActivityResult(CameraLauncher.java:397)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> org.apache.cordova.DroidGap.onActivityResult(DroidGap.java:806)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> android.app.Activity.dispatchActivityResult(Activity.java:5293)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): at
> android.app.ActivityThread.deliverResults(ActivityThread.java:3315)
> 12-20 15:22:56.266: E/AndroidRuntime(2089): ... 11 more
--
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-2203) CordovaLib and upgrading instructions for iOS
[ https://issues.apache.org/jira/browse/CB-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Weber updated CB-2203: Description: In the "Upgrading Cordova iOS" guide, it seems to be assuming the old project format, where CordovaLib was in a shared directory rather than in the project's directory. As I understand it, this changed with issue #CB-1526. Step 1 says to extract Cordova to a permanent location. And there's nothing in there about updating your project's copy of CordovaLib to the latest version. Also, don't we need to upgrade any of the other files in Classes, like MainViewController.h? was: In the "Upgrading Cordova iOS" guide, it seems to be assuming the old project format, where CordovaLib was in a shared directory rather than in the project's directory. As I understand it, this changed with issue #CB-1526. Step 1 says to extract Cordova to a permanent location. And there's nothing in there about updating your project's copy of CordovaLib to the latest version. > CordovaLib and upgrading instructions for iOS > - > > Key: CB-2203 > URL: https://issues.apache.org/jira/browse/CB-2203 > Project: Apache Cordova > Issue Type: Bug > Components: Docs >Affects Versions: 2.3.0 >Reporter: Jacob Weber >Assignee: Shazron Abdullah >Priority: Minor > > In the "Upgrading Cordova iOS" guide, it seems to be assuming the old project > format, where CordovaLib was in a shared directory rather than in the > project's directory. As I understand it, this changed with issue #CB-1526. > Step 1 says to extract Cordova to a permanent location. And there's nothing > in there about updating your project's copy of CordovaLib to the latest > version. > Also, don't we need to upgrade any of the other files in Classes, like > MainViewController.h? -- 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] [Assigned] (CB-2203) CordovaLib and upgrading instructions for iOS
[ https://issues.apache.org/jira/browse/CB-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brooks reassigned CB-2203: -- Assignee: Shazron Abdullah (was: Michael Brooks) > CordovaLib and upgrading instructions for iOS > - > > Key: CB-2203 > URL: https://issues.apache.org/jira/browse/CB-2203 > Project: Apache Cordova > Issue Type: Bug > Components: Docs >Affects Versions: 2.3.0 >Reporter: Jacob Weber >Assignee: Shazron Abdullah >Priority: Minor > > In the "Upgrading Cordova iOS" guide, it seems to be assuming the old project > format, where CordovaLib was in a shared directory rather than in the > project's directory. As I understand it, this changed with issue #CB-1526. > Step 1 says to extract Cordova to a permanent location. And there's nothing > in there about updating your project's copy of CordovaLib to the latest > version. -- 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] [Assigned] (CB-2188) Remove OpenAllWhitelistURLsInWebView from iOS Project Settings
[ https://issues.apache.org/jira/browse/CB-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah reassigned CB-2188: Assignee: Shazron Abdullah (was: Michael Brooks) > Remove OpenAllWhitelistURLsInWebView from iOS Project Settings > -- > > Key: CB-2188 > URL: https://issues.apache.org/jira/browse/CB-2188 > Project: Apache Cordova > Issue Type: Bug > Components: Docs, iOS >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Fix For: 2.4.0 > > > Obsolete. Superceded by window.open _self (InAppBrowser) -- 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-2203) CordovaLib and upgrading instructions for iOS
Jacob Weber created CB-2203: --- Summary: CordovaLib and upgrading instructions for iOS Key: CB-2203 URL: https://issues.apache.org/jira/browse/CB-2203 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 2.3.0 Reporter: Jacob Weber Assignee: Michael Brooks Priority: Minor In the "Upgrading Cordova iOS" guide, it seems to be assuming the old project format, where CordovaLib was in a shared directory rather than in the project's directory. As I understand it, this changed with issue #CB-1526. Step 1 says to extract Cordova to a permanent location. And there's nothing in there about updating your project's copy of CordovaLib to the latest version. -- 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] [Resolved] (CB-1832) iOS: CDVCordovaView should not inherit from UIWebView
[ https://issues.apache.org/jira/browse/CB-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-1832. -- Resolution: Fixed Fix commit - http://git-wip-us.apache.org/repos/asf/cordova-ios/commit/b4a2e4ae > iOS: CDVCordovaView should not inherit from UIWebView > - > > Key: CB-1832 > URL: https://issues.apache.org/jira/browse/CB-1832 > Project: Apache Cordova > Issue Type: Improvement > Components: iOS >Affects Versions: Master >Reporter: Kevin Hawkins >Assignee: Shazron Abdullah > Fix For: 2.4.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > CDVCordovaView inherits from UIWebView. Apple's documentation for UIWebView > states that classes should not inherit from this class. Most straightforward > recommendation is to simply remove CDVCordovaView, and make > CDVViewController's webView property actually be a UIWebView. There's > currently no custom logic in CDVCordovaView to support a custom view anyway. -- 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] [Resolved] (CB-2197) Remove deprecated - Android - CordovaInterface.cancelLoadUrl()
[ https://issues.apache.org/jira/browse/CB-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser resolved CB-2197. Resolution: Fixed > Remove deprecated - Android - CordovaInterface.cancelLoadUrl() > -- > > Key: CB-2197 > URL: https://issues.apache.org/jira/browse/CB-2197 > Project: Apache Cordova > Issue Type: Task > Components: Android >Reporter: Shazron Abdullah >Assignee: Joe Bowser > Fix For: 2.4.0 > > > Per 6 month deprecation policy: > http://wiki.apache.org/cordova/DeprecationPolicy -- 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] [Resolved] (CB-2196) Remove deprecated - Android - CordovaInterface.getContext()
[ https://issues.apache.org/jira/browse/CB-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser resolved CB-2196. Resolution: Fixed > Remove deprecated - Android - CordovaInterface.getContext() > --- > > Key: CB-2196 > URL: https://issues.apache.org/jira/browse/CB-2196 > Project: Apache Cordova > Issue Type: Task > Components: Android >Reporter: Shazron Abdullah >Assignee: Joe Bowser > Fix For: 2.4.0 > > > Per 6 month deprecation policy: > http://wiki.apache.org/cordova/DeprecationPolicy -- 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-2197) Remove deprecated - Android - CordovaInterface.cancelLoadUrl()
[ https://issues.apache.org/jira/browse/CB-2197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550545#comment-13550545 ] Benn Mapes commented on CB-2197: https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=25aef945d14eae7167ece73c11e32d8471114bee > Remove deprecated - Android - CordovaInterface.cancelLoadUrl() > -- > > Key: CB-2197 > URL: https://issues.apache.org/jira/browse/CB-2197 > Project: Apache Cordova > Issue Type: Task > Components: Android >Reporter: Shazron Abdullah >Assignee: Joe Bowser > Fix For: 2.4.0 > > > Per 6 month deprecation policy: > http://wiki.apache.org/cordova/DeprecationPolicy -- 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-2196) Remove deprecated - Android - CordovaInterface.getContext()
[ https://issues.apache.org/jira/browse/CB-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550544#comment-13550544 ] Benn Mapes commented on CB-2196: https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=25aef945d14eae7167ece73c11e32d8471114bee > Remove deprecated - Android - CordovaInterface.getContext() > --- > > Key: CB-2196 > URL: https://issues.apache.org/jira/browse/CB-2196 > Project: Apache Cordova > Issue Type: Task > Components: Android >Reporter: Shazron Abdullah >Assignee: Joe Bowser > Fix For: 2.4.0 > > > Per 6 month deprecation policy: > http://wiki.apache.org/cordova/DeprecationPolicy -- 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] [Resolved] (CB-2192) Remove deprecated - iOS - CDVURLProtocol registerURLProtocol method
[ https://issues.apache.org/jira/browse/CB-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-2192. -- Resolution: Fixed Fix commit - http://git-wip-us.apache.org/repos/asf/cordova-ios/commit/a484850f > Remove deprecated - iOS - CDVURLProtocol registerURLProtocol method > --- > > Key: CB-2192 > URL: https://issues.apache.org/jira/browse/CB-2192 > Project: Apache Cordova > Issue Type: Task > Components: iOS >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Fix For: 2.4.0 > > > Per 6 month deprecation policy: > http://wiki.apache.org/cordova/DeprecationPolicy -- 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] [Resolved] (CB-2191) Remove deprecated iOS - CDVURLProtocol registerPGHttpURLProtocol method
[ https://issues.apache.org/jira/browse/CB-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-2191. -- Resolution: Fixed Fix commit - http://git-wip-us.apache.org/repos/asf/cordova-ios/commit/a484850f > Remove deprecated iOS - CDVURLProtocol registerPGHttpURLProtocol method > --- > > Key: CB-2191 > URL: https://issues.apache.org/jira/browse/CB-2191 > Project: Apache Cordova > Issue Type: Task > Components: iOS >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Fix For: 2.4.0 > > > Per 6 month deprecation policy: > http://wiki.apache.org/cordova/DeprecationPolicy -- 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: Blog Points out Cordova's Weak Spots
I am one of the people who predict that what happened on the desktop computer will happen on mobile as well. It's just a matter of time. The first thing you launch when your computer boots up is your web browser. That behaviour will also apply to mobile devices in my opinion. On Thu, Jan 10, 2013 at 2:11 PM, Michael Brooks wrote: > It's a good article that's written in an honest and fair tone. > > Personally, I've felt a lot of pain-points that he's mentioned. While > fixing UX / UI performance issues, I've often lost track of what I set out > to create - an app. > > However, one important point that I continually keep in mind is that the > web has came an incredibly long way in a short-time. In the past two years > alone, we've seen web applications become incredibly rich. Yes, they aren't > on par with native applications but the gap is narrowing quickly. I see the > "native vs web" debate playing out similar to the "compiled vs interpreted" > language debate that happened six or seven years ago. > > Michael > > On Thu, Jan 10, 2013 at 12:31 PM, Michal Mocny > wrote: > > > Not sure your analogy works as expected ;) > > http://www.youtube.com/watch?v=dmP_t4_lpzo > > > > > > On Thu, Jan 10, 2013 at 2:50 PM, Shazron wrote: > > > > > Not to mention, UIWebView is hobbled with a slower engine. Sometimes we > > do > > > get a Michael Schumacher driving a Toyota Corolla, and it's a good > > > middle-of-the-pack effort, but there's no way he can overtake a Homer > > > Simpson in a Ferrari engine. That's why we are all here, trying to make > > the > > > WebView a Ferrari... > > > > > > > > > On Thu, Jan 10, 2013 at 10:41 AM, Brian LeRoux wrote: > > > > > > > Articles like these are tricky b/c of the YMMV factor. Its very well > > > > proven that good apps, even completely native feeling apps, *can* be > > > > built but frankly not every developer is up to that task. > > > > > > > > It certainly isn't in our mandate to prescribe web development > > practices > > > > either. > > > > > > > > > > > > On Thu, Jan 10, 2013 at 10:29 AM, Andrew Grieve > > > > wrote: > > > > > > > > > > > > > > > http://engblog.polyvore.com/2012/12/web-developer-admits-objective-c-html.html?m=1 > > > > > > > > > > I think I agree with the author. I do still believe the mobile web > > will > > > > be > > > > > better in the future though :) > > > > > > > > > >
[jira] [Resolved] (CB-2193) Remove deprecated - iOS - CDVViewController invokeString property
[ https://issues.apache.org/jira/browse/CB-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-2193. -- Resolution: Fixed Fix commit - http://git-wip-us.apache.org/repos/asf/cordova-ios/commit/4464c75c > Remove deprecated - iOS - CDVViewController invokeString property > - > > Key: CB-2193 > URL: https://issues.apache.org/jira/browse/CB-2193 > Project: Apache Cordova > Issue Type: Task > Components: iOS >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Fix For: 2.4.0 > > > Per 6 month deprecation policy: > http://wiki.apache.org/cordova/DeprecationPolicy -- 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] [Resolved] (CB-2075) cordova build fails when project added to subversion
[
https://issues.apache.org/jira/browse/CB-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filip Maj resolved CB-2075.
---
Resolution: Fixed
Fixed in
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=161446a616044d53ff9bc1b597b1ab346553c5bf,
as well as 2.3.4 on npm.
> cordova build fails when project added to subversion
>
>
> Key: CB-2075
> URL: https://issues.apache.org/jira/browse/CB-2075
> Project: Apache Cordova
> Issue Type: Bug
> Components: CLI
>Affects Versions: 2.2.0, 2.3.0
>Reporter: Filip Maj
>Assignee: Filip Maj
> Fix For: 2.4.0
>
>
> Ive set up an iOS and android project then used svn import to add to
> repository then a checkout to create my local repo. When i run
> {{$ cordova build ios}}
> or
> {{$ cordova build android}}
> i get the following error
> {code}
> /bin/sh: /Users/{mydevpath}/.cordova/hooks/before_build/.svn: is a directory
> {code}
> Script ".svn"in the before_build hook exited with non-zero status code.
> Aborting.
--
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: collecting mobile-spec test results and generating reports
Take the medic code for a spin and see how it works! If you have questions don't hesitate to ping me. Feel free to file issues on github as well. I've demoed it on a few different computers now (and even during a talk) so its become quite durable over the last 6 months or so that I've been working on it. On 1/10/13 2:43 PM, "Marcel Kinard" wrote: >"I gotta get me one of these!" --Tangled (I have kids.) > >I wasn't aware this existed. Thank you much for the writeup. Just from >what I've read here, I will definitely be looking more into this. For >quite a while we've been contemplating a similar device wall here at IBM. > >@michael, yes, a decentralized continuous integration service would be >nirvana. > >-- Marcel Kinard > >On 1/10/2013 12:58 PM, Filip Maj wrote: >> Hey Marcel, I am working towards that continuous integration vision. >> >> github.com/filmaj/medic >> >> It is a node process that builds the latest commits coming into android, >> iOS + BlackBerry repos, pairs them with mobile-spec, scans for >> connected/nearby devices, and deploys the mobile-spec app to those >> devices. It modifies mobile-spec so that all test results are sent off >>to >> a couchdb server. There is a "dashboard" script you can run that is a >> little node server that aggregates test results from this couchdb server >> and displays. The dashboard is also live here: >> >> http://cordova.medic.jit.su/ >> >> >> Currently the Adobe Vancouver office device wall has this setup running >>on >> it (actually, not at this EXACT time but hopefully be back online by >> tomorrow :) ). Very recently the gitpubsub service over at Apache went >> live (try running curl http://urd.zones.apache.org:2069/json) which >> broadcasts all git commits going into all apache git repos. I am in the >> process of wiring up medic to that new service to pick out cordova >>commits >> as-they-happen. >> >> The idea is, at least now, that this is a setup that we can distribute >>to >> almost anyone and have them submit tests to our centralized server. So, >>a >> mobile, distributed CI setup, if you will. It's a lot of fun to play >>with! >> >> The couchdb server at this point is an Adobe EC2 instance. I haven't set >> up any special permissions (I think it's still in Admin Party mode) so >>if >> we were to publicize that server I'd have to set it up so that, at the >> minimum, no one can delete test results :) >> >> Overall, though, I like your idea of the opt-in submission button. Would >> love to see that in mobile spec. Also I'd love feedback on medic! >> >> Cheers, >> Fil >> >
Re: Android deprecated methods
Done, wiki updated as well On Thu, Jan 10, 2013 at 2:31 PM, Joe Bowser wrote: > Please create the tasks to remove them. They're good "First Bugs". > > On Thu, Jan 10, 2013 at 2:28 PM, Shazron wrote: > > See: http://wiki.apache.org/cordova/DeprecationPolicy > > > > I assume these have been removed? If not I can create tasks: > > > > Android - CordovaInterface.getContext() > > Android - CordovaInterface.cancelLoadUrl() >
Re: collecting mobile-spec test results and generating reports
"I gotta get me one of these!" --Tangled (I have kids.) I wasn't aware this existed. Thank you much for the writeup. Just from what I've read here, I will definitely be looking more into this. For quite a while we've been contemplating a similar device wall here at IBM. @michael, yes, a decentralized continuous integration service would be nirvana. -- Marcel Kinard On 1/10/2013 12:58 PM, Filip Maj wrote: Hey Marcel, I am working towards that continuous integration vision. github.com/filmaj/medic It is a node process that builds the latest commits coming into android, iOS + BlackBerry repos, pairs them with mobile-spec, scans for connected/nearby devices, and deploys the mobile-spec app to those devices. It modifies mobile-spec so that all test results are sent off to a couchdb server. There is a "dashboard" script you can run that is a little node server that aggregates test results from this couchdb server and displays. The dashboard is also live here: http://cordova.medic.jit.su/ Currently the Adobe Vancouver office device wall has this setup running on it (actually, not at this EXACT time but hopefully be back online by tomorrow :) ). Very recently the gitpubsub service over at Apache went live (try running curl http://urd.zones.apache.org:2069/json) which broadcasts all git commits going into all apache git repos. I am in the process of wiring up medic to that new service to pick out cordova commits as-they-happen. The idea is, at least now, that this is a setup that we can distribute to almost anyone and have them submit tests to our centralized server. So, a mobile, distributed CI setup, if you will. It's a lot of fun to play with! The couchdb server at this point is an Adobe EC2 instance. I haven't set up any special permissions (I think it's still in Admin Party mode) so if we were to publicize that server I'd have to set it up so that, at the minimum, no one can delete test results :) Overall, though, I like your idea of the opt-in submission button. Would love to see that in mobile spec. Also I'd love feedback on medic! Cheers, Fil
[jira] [Updated] (CB-1528) Benchmarks folder in mobile-spec
[ https://issues.apache.org/jira/browse/CB-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filip Maj updated CB-1528: -- Component/s: (was: CordovaJS) mobile-spec Summary: Benchmarks folder in mobile-spec (was: Benchmarks folder for CordovaJS) > Benchmarks folder in mobile-spec > > > Key: CB-1528 > URL: https://issues.apache.org/jira/browse/CB-1528 > Project: Apache Cordova > Issue Type: Improvement > Components: mobile-spec >Affects Versions: 2.3.0 >Reporter: Brian LeRoux >Assignee: Filip Maj >Priority: Minor > Fix For: 2.4.0 > > > In reference to this email thread. http://goo.gl/E2YZ5 -- 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-1478) FileReader vs XHR bench
[ https://issues.apache.org/jira/browse/CB-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filip Maj updated CB-1478: -- Component/s: (was: WP7) (was: BlackBerry) (was: Android) (was: iOS) mobile-spec Affects Version/s: (was: 2.2.0) Why not add this to mobile-spec? I see this is related to CB-1528, but I believe this should exist in mobile-spec, not in cordova-js. With mobile-spec, we could create a "benchmarks" section that could run a test between using xhr vs filereader and report the results back. > FileReader vs XHR bench > --- > > Key: CB-1478 > URL: https://issues.apache.org/jira/browse/CB-1478 > Project: Apache Cordova > Issue Type: Task > Components: mobile-spec >Reporter: Brian LeRoux >Assignee: Filip Maj >Priority: Minor > Labels: ci > Attachments: IOBench-debug.apk > > > Long standing rumor that FileReader is/was faster than XHR debunked at > PhoneGap Day EU. Before we do anything to optimize our i/o, we need some > actual science on which is faster, on which platforms. -- 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-2202) Remove deprecated - Android - org.apache.cordova.api.Plugin in favour of org.apache.cordova.api.CordovaPlugin
Shazron Abdullah created CB-2202: Summary: Remove deprecated - Android - org.apache.cordova.api.Plugin in favour of org.apache.cordova.api.CordovaPlugin Key: CB-2202 URL: https://issues.apache.org/jira/browse/CB-2202 Project: Apache Cordova Issue Type: Task Components: Android Reporter: Shazron Abdullah Assignee: Joe Bowser Fix For: 2.7.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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-2201) Remove deprecated - Android - OS versions 2.1 and 3.x
Shazron Abdullah created CB-2201: Summary: Remove deprecated - Android - OS versions 2.1 and 3.x Key: CB-2201 URL: https://issues.apache.org/jira/browse/CB-2201 Project: Apache Cordova Issue Type: Task Components: Android Reporter: Shazron Abdullah Assignee: Joe Bowser Fix For: 2.7.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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-2200) Remove deprecated - Android - device.name
Shazron Abdullah created CB-2200: Summary: Remove deprecated - Android - device.name Key: CB-2200 URL: https://issues.apache.org/jira/browse/CB-2200 Project: Apache Cordova Issue Type: Task Components: Android Reporter: Shazron Abdullah Assignee: Joe Bowser Fix For: 2.7.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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-2199) Remove deprecated - Android - exec() returns the success payload when the call completes synchronously
Shazron Abdullah created CB-2199: Summary: Remove deprecated - Android - exec() returns the success payload when the call completes synchronously Key: CB-2199 URL: https://issues.apache.org/jira/browse/CB-2199 Project: Apache Cordova Issue Type: Task Components: Android Reporter: Shazron Abdullah Assignee: Joe Bowser Fix For: 2.6.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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-2197) Remove deprecated - Android - CordovaInterface.cancelLoadUrl()
Shazron Abdullah created CB-2197: Summary: Remove deprecated - Android - CordovaInterface.cancelLoadUrl() Key: CB-2197 URL: https://issues.apache.org/jira/browse/CB-2197 Project: Apache Cordova Issue Type: Task Components: Android Reporter: Shazron Abdullah Assignee: Joe Bowser Fix For: 2.4.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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-2198) Remove deprecated - Android - backHistory removal
Shazron Abdullah created CB-2198: Summary: Remove deprecated - Android - backHistory removal Key: CB-2198 URL: https://issues.apache.org/jira/browse/CB-2198 Project: Apache Cordova Issue Type: Task Components: Android Reporter: Shazron Abdullah Assignee: Joe Bowser Fix For: 2.6.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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-2196) Remove deprecated - Android - CordovaInterface.getContext()
Shazron Abdullah created CB-2196: Summary: Remove deprecated - Android - CordovaInterface.getContext() Key: CB-2196 URL: https://issues.apache.org/jira/browse/CB-2196 Project: Apache Cordova Issue Type: Task Components: Android Reporter: Shazron Abdullah Assignee: Joe Bowser Fix For: 2.4.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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-1478) FileReader vs XHR bench
[ https://issues.apache.org/jira/browse/CB-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550521#comment-13550521 ] Daniel Kurka commented on CB-1478: -- What happened to the idea of putting this into some kind of CI build so that we can not regress on this? > FileReader vs XHR bench > --- > > Key: CB-1478 > URL: https://issues.apache.org/jira/browse/CB-1478 > Project: Apache Cordova > Issue Type: Task > Components: Android, BlackBerry, iOS, WP7 >Affects Versions: 2.2.0 >Reporter: Brian LeRoux >Assignee: Filip Maj >Priority: Minor > Labels: ci > Attachments: IOBench-debug.apk > > > Long standing rumor that FileReader is/was faster than XHR debunked at > PhoneGap Day EU. Before we do anything to optimize our i/o, we need some > actual science on which is faster, on which platforms. -- 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-2195) Remove deprecated - iOS - BackupWebStorage Cordova.plist property change from boolean to string
Shazron Abdullah created CB-2195: Summary: Remove deprecated - iOS - BackupWebStorage Cordova.plist property change from boolean to string Key: CB-2195 URL: https://issues.apache.org/jira/browse/CB-2195 Project: Apache Cordova Issue Type: Task Components: iOS Reporter: Shazron Abdullah Assignee: Shazron Abdullah Fix For: 2.6.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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-402) Improve Contacts search taking a long time by using (NSArray*)filteredArrayUsingPredicate:(NSPredicate*)predicate
[ https://issues.apache.org/jira/browse/CB-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550516#comment-13550516 ] Benjamin Hill commented on CB-402: -- v2.3.0: Have a few minute wait time when returning results against a ~2000 entry address book, and searching on all fields/all results. > Improve Contacts search taking a long time by using > (NSArray*)filteredArrayUsingPredicate:(NSPredicate*)predicate > - > > Key: CB-402 > URL: https://issues.apache.org/jira/browse/CB-402 > Project: Apache Cordova > Issue Type: Improvement > Components: iOS >Reporter: Shazron Abdullah >Priority: Minor > Labels: benchmark, unit-test > Fix For: 2.4.0 > > > We have to analyze this first to see if it is a big problem, with a huge N. I > believe it is. > Right now our search method is O( n ), while using Apple's search method it > is possibly O( log n ) - but that's just a guess if I assume internally they > use a binary search. > Steps: > 1. Grab all the contacts in a NSArray through > ABAddressBookCopyArrayOfAllPeople > 2. Construct a NSPredicate for the filter, and call > filteredArrayUsingPredicate on the NSArray returned in step 1. > 3. Convert the NSArray returned in step 2. to our CDVContact objects -- 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-2194) Remove deprecated - iOS - CDVCommandDelegate registerPlugin method
Shazron Abdullah created CB-2194: Summary: Remove deprecated - iOS - CDVCommandDelegate registerPlugin method Key: CB-2194 URL: https://issues.apache.org/jira/browse/CB-2194 Project: Apache Cordova Issue Type: Task Components: iOS Reporter: Shazron Abdullah Assignee: Shazron Abdullah Fix For: 2.6.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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: Android deprecated methods
Please create the tasks to remove them. They're good "First Bugs". On Thu, Jan 10, 2013 at 2:28 PM, Shazron wrote: > See: http://wiki.apache.org/cordova/DeprecationPolicy > > I assume these have been removed? If not I can create tasks: > > Android - CordovaInterface.getContext() > Android - CordovaInterface.cancelLoadUrl()
[jira] [Commented] (CB-2174) Users with CoolIris Android Gallery App Can't Select Photo
[
https://issues.apache.org/jira/browse/CB-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550513#comment-13550513
]
Joe Bowser commented on CB-2174:
OK, I was wrong, I was experiencing CB-2185. Please get more information on
this issue.
> Users with CoolIris Android Gallery App Can't Select Photo
> --
>
> Key: CB-2174
> URL: https://issues.apache.org/jira/browse/CB-2174
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.2.0
> Environment: Android 2.3.x
>Reporter: Greg
>Assignee: Joe Bowser
>Priority: Critical
> Labels: camera
>
> For some users with Android 2.3.x runing Cooliris - the photo is not returned
> to the the UI. It doesn't crash the app or reload it, just doesn't get
> returned. Here is a log from the Production version of Untappd (2.1.3):
> 01-04 02:31:38.187 I/InputDispatcher(132): Delivering touch to current input
> target: action: 0, channel '40a90ab8
> com.cooliris.media/com.cooliris.media.Gallery (server)'
> 01-04 02:31:38.191 W/UriTexture(11002): writeToCache file =
> /mnt/sdcard/Android/data/com.cooliris.media/cache/hires-image-cache/4785486220386293994_1280.cache
> 01-04 02:31:38.253 I/InputReader(132): dispatchTouch::touch event's action is
> 1
> 01-04 02:31:38.253 I/InputDispatcher(132): Delivering touch to current input
> target: action: 1, channel '40a90ab8
> com.cooliris.media/com.cooliris.media.Gallery (server)'
> 01-04 02:31:38.261 D/TEST(11002): onSingleTapUp231
> 01-04 02:31:38.265 D/Gallery (11002): performReturn : contentUri =
> content://media/external/images/media/462
> 01-04 02:31:38.265 D/Gallery (11002): performReturn : result = Intent {
> dat=content://media/external/images/media/462 }
> 01-04 02:31:38.265 I/GLThread(11002): onPause tid=64
> 01-04 02:31:38.265 I/Main thread(11002): onPause waiting for mPaused.
> 01-04 02:31:38.273 I/Main thread(11002): onPause waiting for mPaused.
> 01-04 02:31:38.296 I/GLThread(11002): mPaused is now true tid=64
> 01-04 02:31:38.296 I/GLThread(11002): releasing EGL surface because paused
> tid=64
> 01-04 02:31:38.296 W/EglHelper(11002): destroySurface() tid=64
> 01-04 02:31:38.320 W/EglHelper(11002): finish() tid=64
> 01-04 02:31:38.359 I/GLThread(11002): releasing EGL context because paused
> tid=64
> 01-04 02:31:38.359 I/RenderView(11002): OnPause RenderView
> com.cooliris.media.RenderView@40524a88
> 01-04 02:31:38.359 E/SensorManager(11002): unregisterListener:: all sensors,
> listener = com.cooliris.media.RenderView@40524a88
> 01-04 02:31:38.363 D/WakeLock(11002): onpause mCheckDecodeWakeLock : result
> = false
> 01-04 02:31:38.363 D/StatusBarManagerService(132): manageDisableList what=0x0
> pkg=com.cooliris.media
> 01-04 02:31:38.378 D/CameraLauncher(10958): I either have a null image path
> or bitmap
> 01-04 02:31:38.382 D/DroidGap(10958): Resuming the App
> 01-04 02:31:38.382 D/DroidGap(10958): Resuming the App
> 01-04 02:31:38.457 D/MediaItemTexture(11002):
> uriStringcontent://media/external/images/media/448
> 01-04 02:31:38.457 I/MediaItemTexture(11002): Decoding Start
> 01-04 02:31:38.457 I/MediaItemTexture(11002): Decoding End
> 01-04 02:31:38.535 D/MediaItemTexture(11002):
> uriStringcontent://media/external/images/media/449
> 01-04 02:31:38.535 I/MediaItemTexture(11002): Decoding Start
> 01-04 02:31:38.535 I/MediaItemTexture(11002): Decoding End
> 01-04 02:31:38.535 D/MediaItemTexture(11002):
> uriStringcontent://media/external/images/media/450
> 01-04 02:31:38.535 I/MediaItemTexture(11002): Decoding Start
> 01-04 02:31:38.535 I/MediaItemTexture(11002): Decoding End
> 01-04 02:31:38.613 D/CordovaLog(10958): MESSAGE FAIL: Unable to retrieve path
> to picture!
> 01-04 02:31:38.613 D/CordovaLog(10958):
> file:///android_asset/www/assets/js/photo.js: Line 187 : MESSAGE FAIL: Unable
> to retrieve path to picture!
> 01-04 02:31:38.613 I/Web Console(10958): MESSAGE FAIL: Unable to retrieve
> path to picture! at file:///android_asset/www/assets/js/photo.js:187
--
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-1478) FileReader vs XHR bench
[ https://issues.apache.org/jira/browse/CB-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550510#comment-13550510 ] Joe Bowser commented on CB-1478: Can we close this now? > FileReader vs XHR bench > --- > > Key: CB-1478 > URL: https://issues.apache.org/jira/browse/CB-1478 > Project: Apache Cordova > Issue Type: Task > Components: Android, BlackBerry, iOS, WP7 >Affects Versions: 2.2.0 >Reporter: Brian LeRoux >Assignee: Filip Maj >Priority: Minor > Labels: ci > Attachments: IOBench-debug.apk > > > Long standing rumor that FileReader is/was faster than XHR debunked at > PhoneGap Day EU. Before we do anything to optimize our i/o, we need some > actual science on which is faster, on which platforms. -- 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] [Resolved] (CB-2175) Android build scripts fail when project path contains spaces
[ https://issues.apache.org/jira/browse/CB-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser resolved CB-2175. Resolution: Cannot Reproduce Fix Version/s: 2.3.0 This must have been fixed in 2.3, since I can't reproduce it. > Android build scripts fail when project path contains spaces > - > > Key: CB-2175 > URL: https://issues.apache.org/jira/browse/CB-2175 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.2.0 > Environment: Mac os >Reporter: Adalbert Wysocki >Assignee: Joe Bowser > Fix For: 2.3.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > When the project is located in a path with spaces, the clean/debug... cordova > build scripts are failing. > Fix: double quote paths: > clean (L24): > bash $CORDOVA_PATH/cordova clean > => > bash "$CORDOVA_PATH/cordova" clean > cordova (L102) > (cd $PROJECT_PATH && $1) > => > (cd "$PROJECT_PATH" && $1) -- 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] [Resolved] (CB-1804) Create tasks for deprecation
[ https://issues.apache.org/jira/browse/CB-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-1804. -- Resolution: Fixed > Create tasks for deprecation > > > Key: CB-1804 > URL: https://issues.apache.org/jira/browse/CB-1804 > Project: Apache Cordova > Issue Type: Task > Components: iOS >Reporter: Shazron Abdullah >Assignee: Shazron Abdullah > Fix For: 2.4.0 > > > CB-1107 already created. See http://wiki.apache.org/cordova/DeprecationPolicy > for other issues that need to be created -- 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-2192) Remove deprecated - iOS - CDVURLProtocol registerURLProtocol method
Shazron Abdullah created CB-2192: Summary: Remove deprecated - iOS - CDVURLProtocol registerURLProtocol method Key: CB-2192 URL: https://issues.apache.org/jira/browse/CB-2192 Project: Apache Cordova Issue Type: Task Components: iOS Reporter: Shazron Abdullah Assignee: Shazron Abdullah Fix For: 2.4.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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-2193) Remove deprecated - iOS - CDVViewController invokeString property
Shazron Abdullah created CB-2193: Summary: Remove deprecated - iOS - CDVViewController invokeString property Key: CB-2193 URL: https://issues.apache.org/jira/browse/CB-2193 Project: Apache Cordova Issue Type: Task Components: iOS Reporter: Shazron Abdullah Assignee: Shazron Abdullah Fix For: 2.4.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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-2191) Remove deprecated iOS - CDVURLProtocol registerPGHttpURLProtocol method
Shazron Abdullah created CB-2191: Summary: Remove deprecated iOS - CDVURLProtocol registerPGHttpURLProtocol method Key: CB-2191 URL: https://issues.apache.org/jira/browse/CB-2191 Project: Apache Cordova Issue Type: Task Components: iOS Reporter: Shazron Abdullah Assignee: Shazron Abdullah Fix For: 2.4.0 Per 6 month deprecation policy: http://wiki.apache.org/cordova/DeprecationPolicy -- 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: Blog Points out Cordova's Weak Spots
It's a good article that's written in an honest and fair tone. Personally, I've felt a lot of pain-points that he's mentioned. While fixing UX / UI performance issues, I've often lost track of what I set out to create - an app. However, one important point that I continually keep in mind is that the web has came an incredibly long way in a short-time. In the past two years alone, we've seen web applications become incredibly rich. Yes, they aren't on par with native applications but the gap is narrowing quickly. I see the "native vs web" debate playing out similar to the "compiled vs interpreted" language debate that happened six or seven years ago. Michael On Thu, Jan 10, 2013 at 12:31 PM, Michal Mocny wrote: > Not sure your analogy works as expected ;) > http://www.youtube.com/watch?v=dmP_t4_lpzo > > > On Thu, Jan 10, 2013 at 2:50 PM, Shazron wrote: > > > Not to mention, UIWebView is hobbled with a slower engine. Sometimes we > do > > get a Michael Schumacher driving a Toyota Corolla, and it's a good > > middle-of-the-pack effort, but there's no way he can overtake a Homer > > Simpson in a Ferrari engine. That's why we are all here, trying to make > the > > WebView a Ferrari... > > > > > > On Thu, Jan 10, 2013 at 10:41 AM, Brian LeRoux wrote: > > > > > Articles like these are tricky b/c of the YMMV factor. Its very well > > > proven that good apps, even completely native feeling apps, *can* be > > > built but frankly not every developer is up to that task. > > > > > > It certainly isn't in our mandate to prescribe web development > practices > > > either. > > > > > > > > > On Thu, Jan 10, 2013 at 10:29 AM, Andrew Grieve > > > wrote: > > > > > > > > > > http://engblog.polyvore.com/2012/12/web-developer-admits-objective-c-html.html?m=1 > > > > > > > > I think I agree with the author. I do still believe the mobile web > will > > > be > > > > better in the future though :) > > > > > >
[jira] [Updated] (CB-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse
[ https://issues.apache.org/jira/browse/CB-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-2183: - Fix Version/s: 2.4.0 > [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse > -- > > Key: CB-2183 > URL: https://issues.apache.org/jira/browse/CB-2183 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.2.0 > Environment: Tested on iOS 5.1 and 6.0 >Reporter: William Wong >Assignee: Shazron Abdullah >Priority: Critical > Labels: File, FileTransfer > Fix For: 2.4.0 > > > When FileTransfer.download() is downloading a file from file:///, > NSURLConnection did not return with NSHTTPURLResponse. This will fail for > apps that copy files from www/, e.g. apps that initialize its database from a > pre-built cache packaged in IPA. > In CB-1600 (fixed in 2.2.0), the fix assumes all response must be > NSHTTPURLResponse. So when FileTransfer.download() is downloading from a > file:/// URL (e.g. copying file from www/ folder to Documents/), FileTransfer > assumed the download operation failed and returned 403. > Tested if we comment out CB-1600, downloading from file:/// works again. > We need to find out a better fix instead of commenting out CB-1600. > According to > http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html#//apple_ref/doc/uid/1165i, > URL of file:/// is supported. > You can test FileTransfer.download() by calling it with > "encodeURI(document.location.href)" as the "source" parameter. -- 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-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse
[ https://issues.apache.org/jira/browse/CB-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550494#comment-13550494 ] Shazron Abdullah commented on CB-2183: -- I proposed on CB-1600 that we revert that patch since it only applies to iOS 4.3, and we only support iOS 5.0 and greater now. > [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse > -- > > Key: CB-2183 > URL: https://issues.apache.org/jira/browse/CB-2183 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.2.0 > Environment: Tested on iOS 5.1 and 6.0 >Reporter: William Wong >Assignee: Shazron Abdullah >Priority: Critical > Labels: File, FileTransfer > > When FileTransfer.download() is downloading a file from file:///, > NSURLConnection did not return with NSHTTPURLResponse. This will fail for > apps that copy files from www/, e.g. apps that initialize its database from a > pre-built cache packaged in IPA. > In CB-1600 (fixed in 2.2.0), the fix assumes all response must be > NSHTTPURLResponse. So when FileTransfer.download() is downloading from a > file:/// URL (e.g. copying file from www/ folder to Documents/), FileTransfer > assumed the download operation failed and returned 403. > Tested if we comment out CB-1600, downloading from file:/// works again. > We need to find out a better fix instead of commenting out CB-1600. > According to > http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html#//apple_ref/doc/uid/1165i, > URL of file:/// is supported. > You can test FileTransfer.download() by calling it with > "encodeURI(document.location.href)" as the "source" parameter. -- 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-1600) [ios] crash in MobileSpec under 4.3 during file transfer
[
https://issues.apache.org/jira/browse/CB-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550493#comment-13550493
]
Shazron Abdullah commented on CB-1600:
--
I propose we revert this patch because it affects CB-2183, and since we don't
support iOS 4.3 anymore.
> [ios] crash in MobileSpec under 4.3 during file transfer
>
>
> Key: CB-1600
> URL: https://issues.apache.org/jira/browse/CB-1600
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS
>Reporter: Patrick Mueller
>Assignee: Patrick Mueller
> Fix For: 2.2.0
>
>
> I've run Mobile Spec under iOS 4.3 (Xcode 4.5.1 on Lion), and noticed a
> consistent trap.
> The problem occurs in
> [CDVFileTransfer.m:477|https://github.com/apache/incubator-cordova-ios/blob/master/CordovaLib/Classes/CDVFileTransfer.m#L477]
> in method {{- (void)connection:(NSURLConnection*)connection
> didReceiveResponse:(NSURLResponse*)response}}.
> As near as I can tell, from the debugger, the object coming in as the
> response is not actually an NSHTTPURLResponse, and that's where the crash is
> - when it asks for the statusCode. Cast that didn't work, but you don't find
> out till you try to access something that's not there.
> Other debugger info:
> response expectedContentLength == -1
> response URL == http://cordova-filetransfer.jitsu.com/robots.txt
--
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] [Resolved] (CB-2189) Support ArrayBuffer arguments from js to ios native over exec bridge
[ https://issues.apache.org/jira/browse/CB-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michal Mocny resolved CB-2189. -- Resolution: Fixed > Support ArrayBuffer arguments from js to ios native over exec bridge > > > Key: CB-2189 > URL: https://issues.apache.org/jira/browse/CB-2189 > Project: Apache Cordova > Issue Type: New Feature > Components: iOS >Reporter: Michal Mocny >Assignee: Michal Mocny > Fix For: 2.4.0 > > -- 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-2189) Support ArrayBuffer arguments from js to ios native over exec bridge
[ https://issues.apache.org/jira/browse/CB-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550489#comment-13550489 ] Michal Mocny commented on CB-2189: -- ios: https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=dfe407aad9c0ee053529f3cf53a3bc79d94622a9 js: as of https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=50bf9441d29144693d710ecab272d9c1db4c01d2, but actual work was in https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=334b19779c48c9dd79137bf04821fb86ae7efc47 Any ArrayBuffer object in the arguments array of the exec call will be serialized and deserialized into a NSData on the other side. Notes: this ONLY supports ArrayBuffers and ONLY at the "top level" of the arguments array (we don't iterate any of your objects etc). > Support ArrayBuffer arguments from js to ios native over exec bridge > > > Key: CB-2189 > URL: https://issues.apache.org/jira/browse/CB-2189 > Project: Apache Cordova > Issue Type: New Feature > Components: iOS >Reporter: Michal Mocny >Assignee: Michal Mocny > Fix For: 2.4.0 > > -- 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-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse
[ https://issues.apache.org/jira/browse/CB-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550485#comment-13550485 ] Shazron Abdullah commented on CB-2183: -- Confirmed on a device. Note that there are different results on device vs simulator - the Simulator does not exhibit the same behaviour (the didReceiveResponse selector is never called for a file:// url) > [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse > -- > > Key: CB-2183 > URL: https://issues.apache.org/jira/browse/CB-2183 > Project: Apache Cordova > Issue Type: Bug > Components: iOS >Affects Versions: 2.2.0 > Environment: Tested on iOS 5.1 and 6.0 >Reporter: William Wong >Assignee: Shazron Abdullah >Priority: Critical > Labels: File, FileTransfer > > When FileTransfer.download() is downloading a file from file:///, > NSURLConnection did not return with NSHTTPURLResponse. This will fail for > apps that copy files from www/, e.g. apps that initialize its database from a > pre-built cache packaged in IPA. > In CB-1600 (fixed in 2.2.0), the fix assumes all response must be > NSHTTPURLResponse. So when FileTransfer.download() is downloading from a > file:/// URL (e.g. copying file from www/ folder to Documents/), FileTransfer > assumed the download operation failed and returned 403. > Tested if we comment out CB-1600, downloading from file:/// works again. > We need to find out a better fix instead of commenting out CB-1600. > According to > http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html#//apple_ref/doc/uid/1165i, > URL of file:/// is supported. > You can test FileTransfer.download() by calling it with > "encodeURI(document.location.href)" as the "source" parameter. -- 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: collecting mobile-spec test results and generating reports
Great discussion point Marcel! As Fil has mentioned, we've started some of this work and it aligns very closely with your described solution. At the moment, Medic is wired up to our device wall, but I see it extending well beyond that. I would love to see the day where Apache Cordova committers can `npm install -g cordova-medic` and run medic locally. As commits are made to the Apache Cordova projects, your local devices will automatically run mobile-spec against the latest changes and report back to the CouchDB instance. In other words, a de-centralized continuous integration service. Michael On Thu, Jan 10, 2013 at 9:58 AM, Filip Maj wrote: > Hey Marcel, I am working towards that continuous integration vision. > > github.com/filmaj/medic > > It is a node process that builds the latest commits coming into android, > iOS + BlackBerry repos, pairs them with mobile-spec, scans for > connected/nearby devices, and deploys the mobile-spec app to those > devices. It modifies mobile-spec so that all test results are sent off to > a couchdb server. There is a "dashboard" script you can run that is a > little node server that aggregates test results from this couchdb server > and displays. The dashboard is also live here: > > http://cordova.medic.jit.su/ > > > Currently the Adobe Vancouver office device wall has this setup running on > it (actually, not at this EXACT time but hopefully be back online by > tomorrow :) ). Very recently the gitpubsub service over at Apache went > live (try running curl http://urd.zones.apache.org:2069/json) which > broadcasts all git commits going into all apache git repos. I am in the > process of wiring up medic to that new service to pick out cordova commits > as-they-happen. > > The idea is, at least now, that this is a setup that we can distribute to > almost anyone and have them submit tests to our centralized server. So, a > mobile, distributed CI setup, if you will. It's a lot of fun to play with! > > The couchdb server at this point is an Adobe EC2 instance. I haven't set > up any special permissions (I think it's still in Admin Party mode) so if > we were to publicize that server I'd have to set it up so that, at the > minimum, no one can delete test results :) > > Overall, though, I like your idea of the opt-in submission button. Would > love to see that in mobile spec. Also I'd love feedback on medic! > > Cheers, > Fil > > On 1/10/13 8:30 AM, "Marcel Kinard" wrote: > > >Here is something I feel is important and I wanted to see what you think. > > > >Problem definition: Cordova is a bit unique in that it not only has to > >deal with running on a large number of permutations of device models and > >device OS's, but the testing is started manually by a large number of > >people using devices in their desk drawer, it is very decentralized. My > >fear is that there are invisible holes and dups in our testing at the > >end of a release. Thus we are releasing code for environments we didn't > >test, but perhaps could have tested. And are we really running both the > >automatic and manual tests in mobile-spec, or just the automatic tests? > >In a more generalized perspective, we don't have good visibility to what > >environments on which tests ran, and visibility to test failures as we > >evaluate release readiness, other than a few comments on the dev mailing > >list. > > > >Proposed solution: mobile-spec is a reasonably good test suite. But the > >test results never leave the device. So the suggestion is to add a > >"Submit test results" button throughout mobile-spec (at each place where > >test results are generated) that would be an opt-in mechanism to get the > >pass/fail test results off the device. Included in the submission with > >the test results would be a bit of metadata, such as the device make and > >model and OS version, Cordova version, etc. The submission would get > >posted to a centralized db somewhere. A web-based query could be run > >against the db to list the submitted results, with the intention to > >understand which environments have been tested for a particular Cordova > >version, which tests ran, and which tests failed/succeeded. > > > >It should be opt-in instead of opt-out because we generally don't want > >test results from a developer that is working on a new feature in the > >middle of a dev cycle. The intent here is to capture tests from rc's and > >similar as we approach the end of a release. It's about evaluating > >release readiness. Maybe in the long term we want to evaluate release > >readiness all the way through a release, but that's not the short-term > >intention here. > > > >I love the vision of continuous integration test, and see this proposal > >as a first step towards that. > > > >Start shooting holes: Reply with what you think. Before we dive into > >where the db should be hosted and a wire protocol for the submission, at > >a high level do you agree with the problem definition and do you have > >any other ideas/comments on a
[jira] [Commented] (CB-2154) navigator.splashscreen.show() broken in Phonegap 2.2 and 2.3.0rc2
[
https://issues.apache.org/jira/browse/CB-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550469#comment-13550469
]
Benn Mapes commented on CB-2154:
Ok, I'm going to take a look at this bug, I'll let you know of any progress.
> navigator.splashscreen.show() broken in Phonegap 2.2 and 2.3.0rc2
> -
>
> Key: CB-2154
> URL: https://issues.apache.org/jira/browse/CB-2154
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Android, Phonegap 2.2 and 2.3rc2
>Reporter: Ismael Olusola Jimoh
>Assignee: Simon MacDonald
>
> I tested the navigator.splashscreen.show() function as documented and
> realised that it is broken.
> The Splash-screen works as expected when app launched but a button call to
> show splashscreen doesn't work.
> I had tested this same thing on Phonegap 2.1 and it worked alright so was
> surprised it didn't work on 2.2. I then tested on Phonegap 2.3 and realised
> it was also broken.
> Below is the code I used:
>
>
>
> Splashscreen Example
> src="cordova-2.3.0rc2.js">
>
> // Wait for Cordova to load
> //
> document.addEventListener("deviceready", onDeviceReady, false);
> // Cordova is ready
> //
> function onDeviceReady() {
> //navigator.splashscreen.show();
> }
> function showSplash() {
> setTimeout(function() {
> navigator.splashscreen.show();
> }, 2000);
> }
> function hideSplash() {
> setTimeout(function() {
> navigator.splashscreen.hide();
> }, 2000);
> }
>
>
>
> Example
> Show
> Hide
>
>
> It doesn't work as mentioned on neither 2.2 nor 2.3.
> Thanks.
> Ismael
--
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-2190) FileTransfer does not request more time than the 5 second limit when placed in background.
[ https://issues.apache.org/jira/browse/CB-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Ullman updated CB-2190: Description: I've been running into an issue using FileTransfer on iOS that cropped up as part of my upgrade to Cordova 2.2. Previously I had been on PhoneGap 1.2 (a long time between upgrades I know). When using the 1.2 version, I could start a filetransfer upload (using sample code from here: http://docs.phonegap.com/en/2.2.0/cordova_media_capture_capture.md.html#Capture) and it would continue to run if I returned to the home screen or if I locked the device. Now it appears that suspending the app will cause a FileTransferError to occur with error code 3 and error message "The request timed out". After trading some emails with Shazron, he pointed out that the limit to finish up background tasks is 5 seconds. If the task will take longer, the app has to request more time -- and FileTransfer does not do this currently (although the CDVLocalStorage plugin in onResignActive does: https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVLocalStorage.m#L378 was: I've been running into an issue using FileTransfer on iOS that cropped up as part of my upgrade to Cordova 2.2. Previously I had been on PhoneGap 1.2 (a long time between upgrades I know). When using the 1.2 version, I could start a filetransfer upload (using sample code from here: http://docs.phonegap.com/en/2.2.0/cordova_media_capture_capture.md.html#Capture) and it would continue to run if I returned to the home screen or if I locked the device. Now it appears that suspending the app will cause a FileTransferError to occur with error code 3 and error message "The request timed out". After trading some emails with Shazron, he pointed out that the limit to finish up tasks is 5 seconds. If the task will take longer, the app has to request more time -- and FileTransfer does not do this currently (although the CDVLocalStorage plugin in onResignActive does: https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVLocalStorage.m#L378 Summary: FileTransfer does not request more time than the 5 second limit when placed in background. (was: FileTransfer does not request more time than the 5 second limit) > FileTransfer does not request more time than the 5 second limit when placed > in background. > -- > > Key: CB-2190 > URL: https://issues.apache.org/jira/browse/CB-2190 > Project: Apache Cordova > Issue Type: Improvement > Components: iOS >Affects Versions: 2.2.0 > Environment: iOS 6.0.1, Cordova 2.2.0. >Reporter: Leif Ullman >Assignee: Shazron Abdullah > > I've been running into an issue using FileTransfer on iOS that cropped up as > part of my upgrade to Cordova 2.2. Previously I had been on PhoneGap 1.2 (a > long time between upgrades I know). When using the 1.2 version, I could > start a filetransfer upload (using sample code from here: > http://docs.phonegap.com/en/2.2.0/cordova_media_capture_capture.md.html#Capture) > and it would continue to run if I returned to the home screen or if I locked > the device. Now it appears that suspending the app will cause a > FileTransferError to occur with error code 3 and error message "The request > timed out". > After trading some emails with Shazron, he pointed out that the limit to > finish up background tasks is 5 seconds. If the task will take longer, the > app has to request more time -- and FileTransfer does not do this currently > (although the CDVLocalStorage plugin in onResignActive does: > https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVLocalStorage.m#L378 -- 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-2190) FileTransfer does not request more time than the 5 second limit
Leif Ullman created CB-2190: --- Summary: FileTransfer does not request more time than the 5 second limit Key: CB-2190 URL: https://issues.apache.org/jira/browse/CB-2190 Project: Apache Cordova Issue Type: Improvement Components: iOS Affects Versions: 2.2.0 Environment: iOS 6.0.1, Cordova 2.2.0. Reporter: Leif Ullman Assignee: Shazron Abdullah I've been running into an issue using FileTransfer on iOS that cropped up as part of my upgrade to Cordova 2.2. Previously I had been on PhoneGap 1.2 (a long time between upgrades I know). When using the 1.2 version, I could start a filetransfer upload (using sample code from here: http://docs.phonegap.com/en/2.2.0/cordova_media_capture_capture.md.html#Capture) and it would continue to run if I returned to the home screen or if I locked the device. Now it appears that suspending the app will cause a FileTransferError to occur with error code 3 and error message "The request timed out". After trading some emails with Shazron, he pointed out that the limit to finish up tasks is 5 seconds. If the task will take longer, the app has to request more time -- and FileTransfer does not do this currently (although the CDVLocalStorage plugin in onResignActive does: https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVLocalStorage.m#L378 -- 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-2189) Support ArrayBuffer arguments from js to ios native over exec bridge
[ https://issues.apache.org/jira/browse/CB-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550460#comment-13550460 ] Michal Mocny commented on CB-2189: -- Two components: (1) js code to serialize ArrayBuffer into some form, and (2) ios code to deserialize into NSData The reverse of this work will come later to send binary data back down the bridge > Support ArrayBuffer arguments from js to ios native over exec bridge > > > Key: CB-2189 > URL: https://issues.apache.org/jira/browse/CB-2189 > Project: Apache Cordova > Issue Type: New Feature > Components: iOS >Reporter: Michal Mocny >Assignee: Michal Mocny > Fix For: 2.4.0 > > -- 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-2189) Support ArrayBuffer arguments from js to ios native over exec bridge
Michal Mocny created CB-2189: Summary: Support ArrayBuffer arguments from js to ios native over exec bridge Key: CB-2189 URL: https://issues.apache.org/jira/browse/CB-2189 Project: Apache Cordova Issue Type: New Feature Components: iOS Reporter: Michal Mocny Assignee: Michal Mocny Fix For: 2.4.0 -- 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-2188) Remove OpenAllWhitelistURLsInWebView from iOS Project Settings
Shazron Abdullah created CB-2188: Summary: Remove OpenAllWhitelistURLsInWebView from iOS Project Settings Key: CB-2188 URL: https://issues.apache.org/jira/browse/CB-2188 Project: Apache Cordova Issue Type: Bug Components: Docs, iOS Reporter: Shazron Abdullah Assignee: Michael Brooks Fix For: 2.4.0 Obsolete. Superceded by window.open _self (InAppBrowser) -- 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-2075) cordova build fails when project added to subversion
[
https://issues.apache.org/jira/browse/CB-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filip Maj updated CB-2075:
--
Affects Version/s: 2.3.0
> cordova build fails when project added to subversion
>
>
> Key: CB-2075
> URL: https://issues.apache.org/jira/browse/CB-2075
> Project: Apache Cordova
> Issue Type: Bug
> Components: CLI
>Affects Versions: 2.2.0, 2.3.0
>Reporter: Filip Maj
>Assignee: Filip Maj
> Fix For: 2.4.0
>
>
> Ive set up an iOS and android project then used svn import to add to
> repository then a checkout to create my local repo. When i run
> {{$ cordova build ios}}
> or
> {{$ cordova build android}}
> i get the following error
> {code}
> /bin/sh: /Users/{mydevpath}/.cordova/hooks/before_build/.svn: is a directory
> {code}
> Script ".svn"in the before_build hook exited with non-zero status code.
> Aborting.
--
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-2076) Integrate documentation properly into CLI
[ https://issues.apache.org/jira/browse/CB-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filip Maj updated CB-2076: -- Affects Version/s: 2.3.0 > Integrate documentation properly into CLI > - > > Key: CB-2076 > URL: https://issues.apache.org/jira/browse/CB-2076 > Project: Apache Cordova > Issue Type: Bug > Components: CLI >Affects Versions: 2.2.0, 2.3.0 >Reporter: Filip Maj >Assignee: Filip Maj > Fix For: 2.4.0 > > > Once the cordova-docs can be invoked locally to host them, integrate into the > CLI. -- 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] [Resolved] (CB-2073) Does not contain a target named 'CordovaLib'
[ https://issues.apache.org/jira/browse/CB-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filip Maj resolved CB-2073. --- Resolution: Fixed Fix Version/s: (was: 2.4.0) 2.3.0 Cannot reproduce anymore with 2.3.3. Likely fixed in an earlier version, or was fixed in CB-2081. > Does not contain a target named 'CordovaLib' > > > Key: CB-2073 > URL: https://issues.apache.org/jira/browse/CB-2073 > Project: Apache Cordova > Issue Type: Bug > Components: CLI >Affects Versions: 2.2.0 >Reporter: Filip Maj >Assignee: Filip Maj > Fix For: 2.3.0 > > > Not sure why I'm getting this. I added ios as a platform and did > cordova build > I then get: > An error occurred while building the ios project. Build settings from command > line: > ARCHS = i386 > CONFIGURATION_BUILD_DIR = /Users/ray/Dropbox/presentations/Developing Mobile > Applications with PhoneGap/demos/camera/platforms/ios/cordova/../build > SDKROOT = iphonesimulator6.0 > VALID_ARCHS = i386 > xcodebuild: error: The project 'camera.xcodeproj' does not contain a target > named 'CordovaLib'. -- 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] [Resolved] (CB-2074) Could not find Nib in bundle for iPad in Simulator
[
https://issues.apache.org/jira/browse/CB-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filip Maj resolved CB-2074.
---
Resolution: Fixed
Fixed in
[4f9eebe|https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=4f9eebe86c02c64a38c76ddf8c18386d17f62fe9].
Pushed as 2.3.3 to npm.
> Could not find Nib in bundle for iPad in Simulator
> --
>
> Key: CB-2074
> URL: https://issues.apache.org/jira/browse/CB-2074
> Project: Apache Cordova
> Issue Type: Bug
> Components: CLI
>Affects Versions: 2.2.0, 2.3.0
>Reporter: Filip Maj
>Assignee: Filip Maj
> Fix For: 2.4.0
>
>
> Hi,
> Ive hit this a few times recently, Im running xCode 4.5.2 with all other
> settings default
> I start with the following steps to set up a 'vanilla' ios project
> {code}
> $ cordova create testproj
> $ cd testproj
> $ cordova platform add ios
> $ cd /Dev/testproj/ios // location of my cordova project
> $ open HelloCordova.xcodeproj // default name
> {code}
> Then
> if i launch the app as in the iPhone simulator 6.0 it (mostly) runs first time
> if i launch the app in the iPad simulator 6.0 i get a SIGABRT with a break on
> main with an error that says
> "Could not load NIB in bundle"
> having looked more deeply into this, it is because there is a blank entry for
> nib file in the plist file - this is known to cause an issue in some case :
> NOTE: I do have colleagues who do not hit this straight away.
> Anyway, to resolve this problem (after digging around in the scripts) i went
> to this file
> {{/usr/local/lib/node_modules/cordova/lib/ios/bin/templates/project/__TESTING__/__TESTING__-Info.plist}}
> and removed these two elements from the bottom of the file
> {code}
> NSMainNibFile
>
> NSMainNibFile~ipad
>
> {code}
> i can create as many ios platform apps as i want now and they run in either
> simulator without hitch. Just as a note, its worth creating a blank
> "universal" app and looking in the app delegate to see what apple do now with
> the nibs (and also note that they no longer use those to settings (that i
> removed above) in the plist file.
> I hope this helps someone.
--
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] [Resolved] (CB-2056) cordova-filetransfer.jitsu.com service is down
[
https://issues.apache.org/jira/browse/CB-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shazron Abdullah resolved CB-2056.
--
Resolution: Fixed
> cordova-filetransfer.jitsu.com service is down
> --
>
> Key: CB-2056
> URL: https://issues.apache.org/jira/browse/CB-2056
> Project: Apache Cordova
> Issue Type: Bug
> Components: mobile-spec
>Affects Versions: 2.3.0
> Environment: http
>Reporter: Marcel Kinard
>Assignee: Filip Maj
>
> When running the automated tests in mobile-spec, I am getting FileTransfer
> errors. Upon further investigation, it looks like the
> cordova-filetransfer.jitsu.com service used by those tests is down. If I try
> a GET or POST to the URL I get the following:
> An error has occurred:
> {"code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect"}
> As other folks will be running tests during rc2, it would be nice to have
> this up so the tests can properly run.
> Is there someone who set this app up on jitsu.com that has an id/password?
--
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-2074) Could not find Nib in bundle for iPad in Simulator
[
https://issues.apache.org/jira/browse/CB-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filip Maj updated CB-2074:
--
Affects Version/s: 2.3.0
Confirmed I can reproduce running cordova-cli v2.3.2.
> Could not find Nib in bundle for iPad in Simulator
> --
>
> Key: CB-2074
> URL: https://issues.apache.org/jira/browse/CB-2074
> Project: Apache Cordova
> Issue Type: Bug
> Components: CLI
>Affects Versions: 2.2.0, 2.3.0
>Reporter: Filip Maj
>Assignee: Filip Maj
> Fix For: 2.4.0
>
>
> Hi,
> Ive hit this a few times recently, Im running xCode 4.5.2 with all other
> settings default
> I start with the following steps to set up a 'vanilla' ios project
> {code}
> $ cordova create testproj
> $ cd testproj
> $ cordova platform add ios
> $ cd /Dev/testproj/ios // location of my cordova project
> $ open HelloCordova.xcodeproj // default name
> {code}
> Then
> if i launch the app as in the iPhone simulator 6.0 it (mostly) runs first time
> if i launch the app in the iPad simulator 6.0 i get a SIGABRT with a break on
> main with an error that says
> "Could not load NIB in bundle"
> having looked more deeply into this, it is because there is a blank entry for
> nib file in the plist file - this is known to cause an issue in some case :
> NOTE: I do have colleagues who do not hit this straight away.
> Anyway, to resolve this problem (after digging around in the scripts) i went
> to this file
> {{/usr/local/lib/node_modules/cordova/lib/ios/bin/templates/project/__TESTING__/__TESTING__-Info.plist}}
> and removed these two elements from the bottom of the file
> {code}
> NSMainNibFile
>
> NSMainNibFile~ipad
>
> {code}
> i can create as many ios platform apps as i want now and they run in either
> simulator without hitch. Just as a note, its worth creating a blank
> "universal" app and looking in the app delegate to see what apple do now with
> the nibs (and also note that they no longer use those to settings (that i
> removed above) in the plist file.
> I hope this helps someone.
--
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-1662) jake build script puts Windows carriage return in Version String on Windows
[ https://issues.apache.org/jira/browse/CB-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13550424#comment-13550424 ] Filip Maj commented on CB-1662: --- So what is the expectation here? > jake build script puts Windows carriage return in Version String on Windows > --- > > Key: CB-1662 > URL: https://issues.apache.org/jira/browse/CB-1662 > Project: Apache Cordova > Issue Type: Bug > Components: CordovaJS >Affects Versions: 2.1.0, 2.2.0, 2.3.0 >Reporter: Joe Bowser >Assignee: Filip Maj > Fix For: 2.4.0 > > > Jesse found this bug where if you run the Jake script, you find that it > modifies the version in the device.js files on Bada, Tizen and Webworks. The > problem is that it also puts a Windows Carriage Return into the field. This > is present if you look at this file on a Mac: > this.cordova = "2.1.0^M";^M > This basically makes it more difficult to work on Cordova on Windows, which > would affect various platforms (Bada, Webworks, Android, WP7, etc). This > needs to be fixed so we can have a better dev workflow. -- 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] [Resolved] (CB-2186) When adding Android via the CLI tools, get "Provided path not an Android project"
[
https://issues.apache.org/jira/browse/CB-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filip Maj resolved CB-2186.
---
Resolution: Cannot Reproduce
Now I can't reproduce.. hmm.
> When adding Android via the CLI tools, get "Provided path not an Android
> project"
> -
>
> Key: CB-2186
> URL: https://issues.apache.org/jira/browse/CB-2186
> Project: Apache Cordova
> Issue Type: Bug
> Components: CLI
>Affects Versions: 2.3.0
>Reporter: Filip Maj
>Assignee: Filip Maj
> Fix For: 2.4.0
>
>
> {code}
> cordova create baz
> cd baz
> cordova platform add android
> The provided path is not an Android project.
> {code}
--
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: Blog Points out Cordova's Weak Spots
Not sure your analogy works as expected ;) http://www.youtube.com/watch?v=dmP_t4_lpzo On Thu, Jan 10, 2013 at 2:50 PM, Shazron wrote: > Not to mention, UIWebView is hobbled with a slower engine. Sometimes we do > get a Michael Schumacher driving a Toyota Corolla, and it's a good > middle-of-the-pack effort, but there's no way he can overtake a Homer > Simpson in a Ferrari engine. That's why we are all here, trying to make the > WebView a Ferrari... > > > On Thu, Jan 10, 2013 at 10:41 AM, Brian LeRoux wrote: > > > Articles like these are tricky b/c of the YMMV factor. Its very well > > proven that good apps, even completely native feeling apps, *can* be > > built but frankly not every developer is up to that task. > > > > It certainly isn't in our mandate to prescribe web development practices > > either. > > > > > > On Thu, Jan 10, 2013 at 10:29 AM, Andrew Grieve > > wrote: > > > > > > http://engblog.polyvore.com/2012/12/web-developer-admits-objective-c-html.html?m=1 > > > > > > I think I agree with the author. I do still believe the mobile web will > > be > > > better in the future though :) > > >
[jira] [Updated] (CB-2181) unable to create a new phonegap project in eclipse using terminal on a mac
[ https://issues.apache.org/jira/browse/CB-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah updated CB-2181: - Fix Version/s: (was: 2.3.0) 2.4.0 > unable to create a new phonegap project in eclipse using terminal on a mac > --- > > Key: CB-2181 > URL: https://issues.apache.org/jira/browse/CB-2181 > Project: Apache Cordova > Issue Type: Bug >Affects Versions: 2.3.0 > Environment: Eclipse SDK Version: 4.2.1 Build id: M20120914-1800 > Mac OSX version 10.7.5 >Reporter: Matthew Richter > Labels: build > Fix For: 2.4.0 > > > I keep getting "Project already exists! Delete and recreate" I get this error > for any package name or project name that I type in. In other words project > that never existed and I still get the error that the "Project already > exists! Delete and recreate" > Last login: Wed Jan 9 12:04:14 on ttys000 > studioimac:bin mrichter$ source ~/.bash_profile > studioimac:bin mrichter$ ./create /github/avfphonegap/android > com.fullsail.testApp androidavf > Project already exists! Delete and recreate > studioimac:bin mrichter$ -- 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] [Resolved] (CB-2187) contacts.find is exponentially slower than native for large address books
[ https://issues.apache.org/jira/browse/CB-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shazron Abdullah resolved CB-2187. -- Resolution: Duplicate > contacts.find is exponentially slower than native for large address books > - > > Key: CB-2187 > URL: https://issues.apache.org/jira/browse/CB-2187 > Project: Apache Cordova > Issue Type: Improvement > Components: iOS >Affects Versions: 2.3.0 > Environment: iOS 6.0 iPhone 4S >Reporter: Benjamin Hill >Assignee: Shazron Abdullah >Priority: Minor > Labels: newbie > > Given a ~2000 entry address book that has been synced across platforms > (facebook, google, etc) and thus has lots of details, > A general "contacts.find" takes minutes instead of the expected few seconds > when fields = ['*'] > This makes it hard to "find" in any sort of AB management app. Is the only > solution to restrict the resulting fields? -- 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: Blog Points out Cordova's Weak Spots
Not to mention, UIWebView is hobbled with a slower engine. Sometimes we do get a Michael Schumacher driving a Toyota Corolla, and it's a good middle-of-the-pack effort, but there's no way he can overtake a Homer Simpson in a Ferrari engine. That's why we are all here, trying to make the WebView a Ferrari... On Thu, Jan 10, 2013 at 10:41 AM, Brian LeRoux wrote: > Articles like these are tricky b/c of the YMMV factor. Its very well > proven that good apps, even completely native feeling apps, *can* be > built but frankly not every developer is up to that task. > > It certainly isn't in our mandate to prescribe web development practices > either. > > > On Thu, Jan 10, 2013 at 10:29 AM, Andrew Grieve > wrote: > > > http://engblog.polyvore.com/2012/12/web-developer-admits-objective-c-html.html?m=1 > > > > I think I agree with the author. I do still believe the mobile web will > be > > better in the future though :) >
[jira] [Commented] (CB-2185) Cordova can't find the mime type for jpegs which have an upper case JPG extension (like ones from an iPhone)
[ https://issues.apache.org/jira/browse/CB-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549974#comment-13549974 ] Simon MacDonald commented on CB-2185: - [~bowserj] I don't think you should make the whole url lower case. The Android file system can be case sensitive so you might end up not being able to find the file if one of the directories has an upper case letter. I believe it is safer just to do lower case on the extension. > Cordova can't find the mime type for jpegs which have an upper case JPG > extension (like ones from an iPhone) > > > Key: CB-2185 > URL: https://issues.apache.org/jira/browse/CB-2185 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.3.0 >Reporter: Joe Bowser >Assignee: Joe Bowser > Fix For: 2.4.0 > > > 1. Copy a JPEG with the extension in upper case > 2. Go to mobile-spec, open the Camera page, then select that image from the > gallery > Expected: It should appear > What happens: The image doesn't appear because for some reason JPG isn't on > the map while lower case jpg is. I have no idea why this is the case, but > this caused many false positives on CB-2093 -- 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: Suggest we postpone converting to widget spec to 3.0?
Yeah I would like more QA on this (re: 2.9 release) but so far I haven't seen any pain regarding the Cordova.plist -> config.xml change so I'm hopeful. I suppose we could intro this as soon as possible but not lose config.xml support in the meantime, but I'd prefer a clean break like what we just did in 2.3.0. On Wed, Jan 9, 2013 at 5:17 PM, Joe Bowser wrote: > What if it takes more than a month to implement? We should probably > defer for later, but at most I'd move it to 2.9. (BTW: I don't think > anyone in their right mind uses an x.9, since it's basically a major > release minus the extra bug fixes and QA that a major gets in the last > month.) > > Also, this has been mostly implemented but not tested on Android for a > while, so I'm indifferent to when I do the QA on it. :P > > On Wed, Jan 9, 2013 at 4:50 PM, Shazron wrote: > > Mainly because we just did Cordova.plist to config.xml in 2.3.0 iOS, and >
[jira] [Commented] (CB-2185) Cordova can't find the mime type for jpegs which have an upper case JPG extension (like ones from an iPhone)
[ https://issues.apache.org/jira/browse/CB-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549968#comment-13549968 ] Joe Bowser commented on CB-2185: That's close to what I did, although I just sent the whole URL to lower case. https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commit;h=c9aa43afe0a1dff6f3b57a458fce4de7e667faed > Cordova can't find the mime type for jpegs which have an upper case JPG > extension (like ones from an iPhone) > > > Key: CB-2185 > URL: https://issues.apache.org/jira/browse/CB-2185 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.3.0 >Reporter: Joe Bowser >Assignee: Joe Bowser > Fix For: 2.4.0 > > > 1. Copy a JPEG with the extension in upper case > 2. Go to mobile-spec, open the Camera page, then select that image from the > gallery > Expected: It should appear > What happens: The image doesn't appear because for some reason JPG isn't on > the map while lower case jpg is. I have no idea why this is the case, but > this caused many false positives on CB-2093 -- 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] [Resolved] (CB-2185) Cordova can't find the mime type for jpegs which have an upper case JPG extension (like ones from an iPhone)
[ https://issues.apache.org/jira/browse/CB-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser resolved CB-2185. Resolution: Fixed > Cordova can't find the mime type for jpegs which have an upper case JPG > extension (like ones from an iPhone) > > > Key: CB-2185 > URL: https://issues.apache.org/jira/browse/CB-2185 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.3.0 >Reporter: Joe Bowser >Assignee: Joe Bowser > Fix For: 2.4.0 > > > 1. Copy a JPEG with the extension in upper case > 2. Go to mobile-spec, open the Camera page, then select that image from the > gallery > Expected: It should appear > What happens: The image doesn't appear because for some reason JPG isn't on > the map while lower case jpg is. I have no idea why this is the case, but > this caused many false positives on CB-2093 -- 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: Jira notifications (Was: [jira] [Created] (CB-2184) JNI Error on HTC Evo device running android 4.0.3)
Yes please! On Thu, Jan 10, 2013 at 4:52 AM, Patrick Mueller wrote: > On Thu, Jan 10, 2013 at 7:15 AM, Jukka Zitting >wrote: > > > I guess we should file an INFRA request to get the notification scheme > > updated to use the new list address. > > > > Before doing that, is there interest in directing the notifications from > > dev@ to a separate issues@ list? > > > > Yes, I'd like to see them separated. > > -- > Patrick Mueller > http://muellerware.org >
Re: commit messages for newbies
@Marcel nice work, I agree we should add this to the wiki article. One note is that I believe you should have an empty line between the summary and detailed body. The Pro Git Books [1] summaries the git messages templates as: Short (50 chars or less) summary of changes More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here @Josh I think short commit messages and multiple tiny commits are fine (and good). For me, the most important part of the commit message is a reference to the issue that it is related to. For example, "[CB-1287] Rename such and such." The issue reference groups all of the tiny commits into a common task. [1] http://git-scm.com/book/ch5-2.html#Commit-Guidelines On Thu, Jan 10, 2013 at 9:11 AM, Josh Soref wrote: > Marcel wrote: > > A note about commit messages: you are highly encouraged to describe your > > commit with enough detail for someone else to understand it. In doing > > so, your commit message can consist of multiple lines. However, it also > > is highly encouraged that the first line of your commit message not > > exceed 40 characters. This is because some of the tooling that sits on > > top of git (such as the httpd apps that let you browse the repo) assume > > that the first line is top-level summary that is 40 characters or less. > > Thus there will be highlighting and truncating of the commit message > > using these assumptions, and it will look weird if these assumptions are > > not kept. For example, here is a good example of a commit message: > > What should a contributor do if they're sending a bunch of changes which > they'd like someone else to fold/resummarize as the merger wishes? > > Note that I'm talking about sending dozens of tiny commits (I've probably > sent hundreds at this point to Cordova in fact). While I appreciate (and > really want) good commit messages for certain classes of things, if you > make the overhead for me too high, I can assure you that there are other > projects to which I can allocate my spare time instead. > > - > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. >
[jira] [Created] (CB-2187) contacts.find is exponentially slower than native for large address books
Benjamin Hill created CB-2187: - Summary: contacts.find is exponentially slower than native for large address books Key: CB-2187 URL: https://issues.apache.org/jira/browse/CB-2187 Project: Apache Cordova Issue Type: Improvement Components: iOS Affects Versions: 2.3.0 Environment: iOS 6.0 iPhone 4S Reporter: Benjamin Hill Assignee: Shazron Abdullah Priority: Minor Given a ~2000 entry address book that has been synced across platforms (facebook, google, etc) and thus has lots of details, A general "contacts.find" takes minutes instead of the expected few seconds when fields = ['*'] This makes it hard to "find" in any sort of AB management app. Is the only solution to restrict the resulting fields? -- 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: Blog Points out Cordova's Weak Spots
Articles like these are tricky b/c of the YMMV factor. Its very well proven that good apps, even completely native feeling apps, *can* be built but frankly not every developer is up to that task. It certainly isn't in our mandate to prescribe web development practices either. On Thu, Jan 10, 2013 at 10:29 AM, Andrew Grieve wrote: > http://engblog.polyvore.com/2012/12/web-developer-admits-objective-c-html.html?m=1 > > I think I agree with the author. I do still believe the mobile web will be > better in the future though :)
[jira] [Commented] (CB-2185) Cordova can't find the mime type for jpegs which have an upper case JPG extension (like ones from an iPhone)
[ https://issues.apache.org/jira/browse/CB-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549882#comment-13549882 ] Simon MacDonald commented on CB-2185: - Joe, if you change FileUtils line 1031 from: return map.getMimeTypeFromExtension(extension); to this: return map.getMimeTypeFromExtension(extension.toLowerCase()); this bug should be fixed. > Cordova can't find the mime type for jpegs which have an upper case JPG > extension (like ones from an iPhone) > > > Key: CB-2185 > URL: https://issues.apache.org/jira/browse/CB-2185 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 2.3.0 >Reporter: Joe Bowser >Assignee: Joe Bowser > Fix For: 2.4.0 > > > 1. Copy a JPEG with the extension in upper case > 2. Go to mobile-spec, open the Camera page, then select that image from the > gallery > Expected: It should appear > What happens: The image doesn't appear because for some reason JPG isn't on > the map while lower case jpg is. I have no idea why this is the case, but > this caused many false positives on CB-2093 -- 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: Blog Points out Cordova's Weak Spots
Honestly, I noticed that he said that Objective-C > HTML5. The reason I started the Android version of PhoneGap was because I wanted apps on my phone, and I wasn't going to give Apple any of my money. Android users are the big losers if iOS fails, because people are just going to write their iPhone app, and completely ignore Android because of the myths of "Android users don't have money" and "Android users are all nerds anyway", and other things like that. On Thu, Jan 10, 2013 at 10:29 AM, Andrew Grieve wrote: > http://engblog.polyvore.com/2012/12/web-developer-admits-objective-c-html.html?m=1 > > I think I agree with the author. I do still believe the mobile web will be > better in the future though :)
Blog Points out Cordova's Weak Spots
http://engblog.polyvore.com/2012/12/web-developer-admits-objective-c-html.html?m=1 I think I agree with the author. I do still believe the mobile web will be better in the future though :)
[jira] [Assigned] (CB-635) Access application version information from JS.
[ https://issues.apache.org/jira/browse/CB-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Braden Shepherdson reassigned CB-635: - Assignee: Braden Shepherdson (was: Filip Maj) > Access application version information from JS. > --- > > Key: CB-635 > URL: https://issues.apache.org/jira/browse/CB-635 > Project: Apache Cordova > Issue Type: New Feature > Components: CordovaJS >Affects Versions: 1.7.0 > Environment: Notably iOS/Android. >Reporter: Ladar Levison >Assignee: Braden Shepherdson > Labels: api-change, javascript, platform > Original Estimate: 4h > Remaining Estimate: 4h > > It seems that every platform offers the ability to define an application > version. iOS and Android offer string and numeric fields. They are > versionName and versionCode on Android. > My request is to add the ability to access this app version info using > Javascript. Perhaps adding an "app" namespace with app.versionName, > app.versionCode and app.name... > It would be an easy enough plugin to write, but figured it should eventually > become part of the core. > https://developer.android.com/guide/publishing/versioning.html -- 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
