date:20130205


[ 
https://issues.apache.org/jira/browse/CB-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572181#comment-13572181
 ] 

Andrew Grieve commented on CB-571:
--

I don't love android's behaviour here, because there's no way to discover the 
full path to the file you've just created. That said, if you want to keep the 
file (not have it in the cache dir), then arguably you should just use an 
absolute URL as an argument anyways.

Since this is already the behaviour on Android, I think it's too late to change 
(outside of our grand API audit). I think the equivalent on iOS would be to put 
the file in the /tmp directory. If they want to keep the 
file, or save it in the Documents directory, then they should use a full URL.



> Check that audio file recording to using Media.startRecord is of type .wav
> --
>
> Key: CB-571
> URL: https://issues.apache.org/jira/browse/CB-571
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Affects Versions: 1.6.1
> Environment: iOS
>Reporter: Ram Kulkarni
>Assignee: Becky Gibson
>Priority: Minor
>  Labels: ios, media
> Fix For: 2.5.0
>
>
> As we document in {{startRecord}} on our [docs 
> page|http://docs.phonegap.com/en/1.6.1/cordova_media_media.md.html#media.startRecord],
>  when recording audio in iOS, you need to make sure the file exists and that 
> it is of type .wav.
> It would be nice if the {{startRecordingAudio}} method in CDVSound.m checked 
> that the requested file to record to is of the right type, and throw an error 
> if it is not.

--
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-2384) Add new iOS Project Setting to suppress the form accessory bar above the keyboard

2013-02-05 Thread Shazron Abdullah (JIRA)


 [ 
https://issues.apache.org/jira/browse/CB-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shazron Abdullah updated CB-2384:
-

Description: 
See: 
http://stackoverflow.com/questions/7904892/remove-form-assistant-from-keyboard-in-iphone-standalone-web-app


{code}
[[NSNotificationCenter defaultCenter] addObserver:self 
selector:@selector(keyboardDidShow:) name:UIKeyboardDidShowNotification 
object:nil];
{code}

{code}
-(void)keyboardDidShow:(NSNotification*)notif
{
NSArray *array = [[UIApplication sharedApplication] windows];

for (UIWindow* wind in array) {
for (UIView* currView in wind.subviews) {
if ([[currView description] hasPrefix:@"http://stackoverflow.com/questions/7904892/remove-form-assistant-from-keyboard-in-iphone-standalone-web-app

{code}
[[NSNotificationCenter defaultCenter] addObserver:self 
selector:@selector(keyboardDidShow:) name:UIKeyboardDidShowNotification 
object:nil];
{code}

{code}
-(void)keyboardDidShow:(NSNotification*)notif
{
NSArray *array = [[UIApplication sharedApplication] windows];

for (UIWindow* wind in array) {
for (UIView* currView in wind.subviews) {
if ([[currView description] hasPrefix:@" Add new iOS Project Setting to suppress the form accessory bar above the 
> keyboard
> -
>
> Key: CB-2384
> URL: https://issues.apache.org/jira/browse/CB-2384
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
>Priority: Minor
> Fix For: 2.5.0
>
>
> See: 
> http://stackoverflow.com/questions/7904892/remove-form-assistant-from-keyboard-in-iphone-standalone-web-app
> {code}
> [[NSNotificationCenter defaultCenter] addObserver:self 
> selector:@selector(keyboardDidShow:) name:UIKeyboardDidShowNotification 
> object:nil];
> {code}
> {code}
> -(void)keyboardDidShow:(NSNotification*)notif
> {
> NSArray *array = [[UIApplication sharedApplication] windows];
> for (UIWindow* wind in array) {
> for (UIView* currView in wind.subviews) {
> if ([[currView description] hasPrefix:@" for (UIView* perView in currView.subviews) {
> if ([[perView description] 
> hasPrefix:@" [perView setHidden:YES];
> }
> }
> }
> }
> }
> }
> {code}
> Suggested name for the setting: *HideKeyboardFormAccessoryBar* with a default 
> of false

--
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

using "Chrome Frame" for pre-IE9 support in cordova-windows?

2013-02-05 Thread Jared Albers

Not sure who the right people to talk to about this is as I understand some
Intel folks are the main contributors for the win32 portion of
cordova-windows.

I'm curious if anyone has looked at using Google's "Chrome Frame" plugin as
a way to get support for pre-IE9 based windows systems. Although Chrome
Frame won't work out of the box with embedded webviews according to
here,
it is open-source and under a BSD-style license.

Chrome Frame feels like it would be a rather clever way to get win32
support for setups that don't have IE9 or greater (or for web developers
that don't want to rely on the trident rendering engine at all).

Of course keeping app distributables small is also important since we
wouldn't want to distribute a 30MB+ dependency with each app. To solve
this, the integration could be designed such that the Chrome Frame
framework was downloaded and installed silently in the background and only
when needed/requested. Not the most desirable solution, but perhaps a
necessary evil to gain Windows XP & Vista support.

Thoughts?

-Jared

[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files


[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572179#comment-13572179
 ] 

Andrew Grieve commented on CB-285:
--

Yes. Definitely want to allow users to chose make the decision of where their 
files go. Android has no iCloud equivalent, but instead has a shared 
file-system for things like music & photos.

So, here's another proposal: Instead of adding non-standard constants to 
requestFileSystem(), we add a new (non-standard) API:

LocalFileSystem.getAppDirectory(callback) 
// gets a (read-only) DirectoryEntry for the www directory.

LocalFileSystem.getDirectoryForPurpose({
  sandboxed: true || false,
  persistence: 'temporary' || 'cache' || 'device_persistent' || 'persistent',
  category: 'data' || 'documents'
}, success);

sandboxed: will be ignored for iOS. For Android it will toggle between external 
an internal storage.
- Defaults to true.
- If non-sandboxed is unavailable (iOS), fall-back to true.

persistence: 
- on Android, 'temporary' == 'cache', but on iOS they are different.
- on Android, 'device_persistent' == 'persistent', but on iOS one has iCloud 
enabled and the other does not.

category:
- Defaults to 'data'
- persistence == 'temporary' or 'cache' ==> this value is ignored.
- Android && sandboxed == true ==> files/ directory
- 'data' && iOS && persistence == 'persistent' ==> /Library
- 'data' && iOS && persistence == 'device_persistent' ==> 
/Library/NoCloud (and we set the extended attr on this 
directory to make it unsynced.
- 'data' && Android ==> files/ subdirectory of app storage (based on sandboxed 
value)
- 'documents' && iOS && persistence == 'persistent' ==> 
/Documents
- 'documents' && iOS && persistence == 'device_persistent' ==> 
/Documents/NoCloud
- 'documents' && Android ==> /sdcard



> Add property returning root path of PhoneGap files
> --
>
> Key: CB-285
> URL: https://issues.apache.org/jira/browse/CB-285
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: CordovaJS
>Affects Versions: 1.4.0
> Environment: Both PhoneGap SDK and PhoneGap Build
>Reporter: Ashley Gullen
>Assignee: Andrew Grieve
>  Labels: features
>
> There needs to be a property in PhoneGap that returns the root path to the 
> general files added to the PhoneGap project (i.e. the directory index.html is 
> in).  For example, if I add 'music.mp3' to my project, in Android it will be 
> located in:
> /android_asset/www/music.mp3
> On iOS after being built with PhoneGap Build it will be located in some path 
> like this:
> /var/mobile/Applications//.app/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .app.
> This has two side effects:
> 1. Paths to audio for Media must be hard-coded separately depending on the 
> platform, which is inconvenient.
> 2. Paths to audio for Media cannot be known if developing a framework that 
> uses PhoneGap.  Since a framework does not know the App ID or name in 
> advance, it's impossible for the framework to determine the correct path.
> This is actively blocking audio from working on iOS in PhoneGap projects 
> exported by Construct 2 (www.scirra.com), a HTML5 game creator.  Also, it 
> seems like kind of an important function to make available anyway, since 
> hard-coding paths for each platform is a pain.
> This PhoneGap Support thread led to this issue: 
> http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios

--
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-2385) Custom Font Broken for Windows Phone Devices

2013-02-05 Thread Ismael Olusola Jimoh (JIRA)

Ismael Olusola Jimoh created CB-2385:


 Summary: Custom Font Broken for Windows Phone Devices
 Key: CB-2385
 URL: https://issues.apache.org/jira/browse/CB-2385
 Project: Apache Cordova
  Issue Type: Bug
  Components: WP7, WP8
Affects Versions: 2.3.0
Reporter: Ismael Olusola Jimoh
Assignee: Jesse MacFadyen


Trying to use custom fonts in my page seems to be broken.

I have tried the same codes on browser and seems to work well.

I have tried both using an external URL for the font as well as having the 
fonts in my local machine and seems not to work either way.

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] [Created] (CB-2384) Add new iOS Project Setting to suppress the form accessory bar above the keyboard

2013-02-05 Thread Shazron Abdullah (JIRA)

Shazron Abdullah created CB-2384:


 Summary: Add new iOS Project Setting to suppress the form 
accessory bar above the keyboard
 Key: CB-2384
 URL: https://issues.apache.org/jira/browse/CB-2384
 Project: Apache Cordova
  Issue Type: Improvement
  Components: iOS
Reporter: Shazron Abdullah
Assignee: Shazron Abdullah
Priority: Minor
 Fix For: 2.5.0


See: 
http://stackoverflow.com/questions/7904892/remove-form-assistant-from-keyboard-in-iphone-standalone-web-app

{code}
[[NSNotificationCenter defaultCenter] addObserver:self 
selector:@selector(keyboardDidShow:) name:UIKeyboardDidShowNotification 
object:nil];
{code}

{code}
-(void)keyboardDidShow:(NSNotification*)notif
{
NSArray *array = [[UIApplication sharedApplication] windows];

for (UIWindow* wind in array) {
for (UIView* currView in wind.subviews) {
if ([[currView description] hasPrefix:@"http://www.atlassian.com/software/jira

[jira] [Commented] (CB-2227) Move mapping of module->symbol into individual plugins


[ 
https://issues.apache.org/jira/browse/CB-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572095#comment-13572095
 ] 

Andrew Grieve commented on CB-2227:
---

Nope, the majority of the changes are still in the symbolmapping branch. I'll 
merge & close this once 2.4 is out.

> Move mapping of module->symbol into individual plugins
> --
>
> Key: CB-2227
> URL: https://issues.apache.org/jira/browse/CB-2227
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS
>Reporter: Andrew Grieve
>Assignee: Andrew Grieve
>Priority: Minor
> Fix For: 2.4.0
>
>
> Goals:
> - Change from listing module->symbol mapping within common.js & platform.js, 
> to listing this within the plugins themselves.
> - Support apps that don't want us to clobber global symbols. 
> aka, allow module->symbol mapping to be turned off
> - Allow retrieval of clobbered globals
> - Currently modules save it themselves when they are loaded
> - This won't work (reliably) for saving references to globals overridden by 
> other modules
> - This gets in the way of the idea of lazy-loading modules via getters
> - Support the use of other module loaders 
> - So... don't do crazy things at require() time.
> Requirements:
> Plugins must be able to declare dependencies
> Plugins must be able to delay onDeviceReady()
> Plugins must be able to run code to initialize
> Implementation
> modulemapper.js:
> clobbers(...)
> merges(...)
> defaults(...)
> mapModules(wnd)
> getOriginalSymbol('FileSystem')
> Start-up flow:
> Parse all modules
> common-bootstrap:
> Loads list of modules named "cordova.*/symbols"
> Run modulemapper.mapModules(window);
> Loads list of modules named "cordova.*/main"
>   
> symbols.js files:
> Will make calls to modulemapper instead of exporting {clobbers:}
> This make dependencies work by require()ing dependent symbols
> We want the to be an evaluated .js file instead of something listed in 
> plugin.xml
> So that it can export based on browser version
> Implementation Steps
> 1. - Expose list of registered modules in scripts/require.js so that we can 
> loop over them
> 2. - Write modulemapper.js (and have unit tests, of course)
> 3. - Add logic to bootstrap.js that calls into modulemapper
> create $PLUGIN_NAME/symbols.js files for each plugin within cordova.
> 4. - Add logic to bootstrap.js that calls into modulemapper
> 5. - Create main.js files for those that currently have logic in their 
> platform.js files

--
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-2383) Make the inspect button works.

2013-02-05 Thread unbug (JIRA)

unbug created CB-2383:
-

 Summary: Make the inspect button works.
 Key: CB-2383
 URL: https://issues.apache.org/jira/browse/CB-2383
 Project: Apache Cordova
  Issue Type: New Feature
  Components: weinre
Reporter: unbug
Assignee: Patrick Mueller


Make the inspect button works.select an element in the page to inspect it.

--
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-2346) config.xml preference orientation - landscape not working.


 [ 
https://issues.apache.org/jira/browse/CB-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesse MacFadyen resolved CB-2346.
-

Resolution: Invalid

> config.xml preference orientation - landscape not working.
> --
>
> Key: CB-2346
> URL: https://issues.apache.org/jira/browse/CB-2346
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: WP7
>Affects Versions: 2.4.0
>Reporter: Matiss
>Assignee: Jesse MacFadyen
> Fix For: 2.5.0
>
>
> Setting this option in config.xml have no effect when running application.
> PhoneGap 2.4.0rc1.
> I'm using Lumia 800 with WP7.8

--
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-852) xhr2 impl


[ 
https://issues.apache.org/jira/browse/CB-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572010#comment-13572010
 ] 

Jesse MacFadyen commented on CB-852:


Already supported on Windows Phone 8 and Windows 8 ...

> xhr2 impl
> -
>
> Key: CB-852
> URL: https://issues.apache.org/jira/browse/CB-852
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Android, Bada, BlackBerry, CordovaJS, iOS, Qt, webOS, WP7
>Reporter: Brian LeRoux
>Assignee: Shazron Abdullah
>Priority: Minor
> Fix For: 2.5.0
>
>
> implement xhr2 on top of current filetransfer

--
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-2346) config.xml preference orientation - landscape not working.


[ 
https://issues.apache.org/jira/browse/CB-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572009#comment-13572009
 ] 

Jesse MacFadyen commented on CB-2346:
-

You can work around this by modifying the XAML in MainPage.xaml

SupportedOrientations="PortraitOrLandscape" || "Portrait" || "Landscape"
Orientation="Portrait"

I will create a new 'feature' task for supporting orientation uniformly across 
platforms.

> config.xml preference orientation - landscape not working.
> --
>
> Key: CB-2346
> URL: https://issues.apache.org/jira/browse/CB-2346
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: WP7
>Affects Versions: 2.4.0
>Reporter: Matiss
>Assignee: Jesse MacFadyen
> Fix For: 2.5.0
>
>
> Setting this option in config.xml have no effect when running application.
> PhoneGap 2.4.0rc1.
> I'm using Lumia 800 with WP7.8

--
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-1815) WP8. NTH. Update CSS to use system colors


 [ 
https://issues.apache.org/jira/browse/CB-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesse MacFadyen resolved CB-1815.
-

Resolution: Fixed

background: Background;
color: Highlight;
border-color: Highlight;

Already implemented, somewhere down the line ...

> WP8. NTH. Update CSS to use system colors
> -
>
> Key: CB-1815
> URL: https://issues.apache.org/jira/browse/CB-1815
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: WP8
>Reporter: Sergey Grebnov
>Assignee: Sergey Grebnov
>Priority: Trivial
>
> There are new CSS properties to define device/system background color and 
> accent color. We can use them to automatically apply system look and feel for 
> the Examples and Template projects

--
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] [Closed] (CB-1816) WP8. Plugins: Facebook\Logout- Nice to have logout option


 [ 
https://issues.apache.org/jira/browse/CB-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesse MacFadyen closed CB-1816.
---

Resolution: Invalid
  Assignee: Jesse MacFadyen  (was: Sergey Grebnov)

Not a wp8 problem, but a plugin problem.
File an issue in the plugin repo.

> WP8. Plugins: Facebook\Logout- Nice to have logout option
> -
>
> Key: CB-1816
> URL: https://issues.apache.org/jira/browse/CB-1816
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: WP8
>Reporter: Sergey Grebnov
>Assignee: Jesse MacFadyen
>Priority: Trivial
>
> Current plugin for Facebook does not have 'Log-out' feature.
> It is nice to have a way which will help users to log-out from the Facebook 
> Account.
> Reported by Tushar Sharma (MS Open Tech)

--
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-2231) Support config.xml for whitelisting plugins, preferences, and access domains


 [ 
https://issues.apache.org/jira/browse/CB-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesse MacFadyen updated CB-2231:


Component/s: (was: WP8)
 (was: WP7)

> Support config.xml for whitelisting plugins, preferences, and access domains
> 
>
> Key: CB-2231
> URL: https://issues.apache.org/jira/browse/CB-2231
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Bada, webOS, Windows 8
>Reporter: Jesse MacFadyen
>Assignee: Anis Kadri
>
> Details here:
> http://docs.phonegap.com/en/2.3.0/guide_whitelist_index.md.html#Domain%20Whitelist%20Guide
> Preferences are not 'required' but plugins + access should both be 
> implemented.

--
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: a Cordova Jake Error ?

2013-02-05 Thread Filip Maj

Hey Paul, I believe this issue already notes this problem:

https://issues.apache.org/jira/browse/CB-2345


Feel free to patch it, you are a committer after all :)

On 2/5/13 7:53 AM, "Plaquette, Paul"  wrote:

>sounds the culprit might be a line in the jakefile:
> "lib/firefoxos/plugin/firefoxos/Device.js":/(this\.cordova\s=\s").+(")/,
>
>in place of:
> "lib/firefoxos/plugin/firefoxos/device.js":/(this\.cordova\s=\s").+(")/,
>
>hope this helps !
>
>
>On Tue, Feb 5, 2013 at 4:45 PM, Plaquette, Paul
>wrote:
>
>> Hi all,
>>
>> I get a fresh Cordova repository and by the way I also updated node on
>>my
>> ubuntu 12.04 laptop.
>>
>> When I build using command line jake  I got this:
>>
>> 
>>
>> jake aborted.
>> Error: ENOENT, no such file or directory
>> 'lib/firefoxos/plugin/firefoxos/Device.js'
>> at Object.openSync (fs.js:230:18)
>> (See full trace by running task with --trace)
>>
>> the build succeed if the device.js file in firefoxos is renamed as
>> Device.js
>>
>> Does someone see what is going wrong?
>> (Actually I wonder if it is an issue on may machine or not)
>>
>> Cordially,
>> Paul
>>
>>
>> --
>> 
>>
>> Paul Plaquette,
>> Senior Software Engineer
>> Intel Corporation SAS
>> Open source Technology Center - OTC
>> France, Montpellier
>>
>>
>
>
>-- 
>
>
>Paul Plaquette,
>Senior Software Engineer
>Intel Corporation SAS
>Open source Technology Center - OTC
>France, Montpellier

[jira] [Resolved] (CB-2355) Update JavaScript for BlackBerry


 [ 
https://issues.apache.org/jira/browse/CB-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj resolved CB-2355.
---

Resolution: Fixed

> Update JavaScript for BlackBerry
> 
>
> Key: CB-2355
> URL: https://issues.apache.org/jira/browse/CB-2355
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: BlackBerry
>Reporter: Filip Maj
>Assignee: Tim Kim
> Fix For: 2.4.0
>
>
> Update the cordova.js after CordovaJS has been tagged.

--
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-2341) Need to update getting starting guide for BlackBerry to reflect changes to bin/create


 [ 
https://issues.apache.org/jira/browse/CB-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2341:
--

Fix Version/s: (was: 2.4.0)
   2.5.0

Moving to 2.5.0. Couple things I noticed:

- I suggest you have both a "dist" set of instructions (when people download 
the cordova distribution) and a "source" set of instructions (if they are using 
the source directly).
- The download location to Cordova should point to apache servers, not phonegap.
- Some of the links are incorrectly done. Please run {{./bin/generate}} in the 
docs and check out the final rendered version for yourself to see what I mean 
(or check out the Getting Started for BlackBerry doc on docs.phonegap.com)

> Need to update getting starting guide for BlackBerry to reflect changes to 
> bin/create
> -
>
> Key: CB-2341
> URL: https://issues.apache.org/jira/browse/CB-2341
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs
>Affects Versions: 2.4.0
>Reporter: Tim Kim
>Assignee: Tim Kim
>Priority: Minor
> Fix For: 2.5.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] [Updated] (CB-2214) Refactor JS files to be more ready to move into their own repositories


 [ 
https://issues.apache.org/jira/browse/CB-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2214:
--

Fix Version/s: (was: 2.4.0)
   2.5.0

Moving to 2.5!

> Refactor JS files to be more ready to move into their own repositories
> --
>
> Key: CB-2214
> URL: https://issues.apache.org/jira/browse/CB-2214
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS
>Reporter: Andrew Grieve
>Assignee: Andrew Grieve
>Priority: Minor
> Fix For: 2.5.0
>
>
> Refer to ML discussion: http://callback.markmail.org/thread/xnhpidbnxg5ps7zr
> This task is specifically to move files around. Instead of having : 
> lib/$PLATFORM/plugin
> We will have: plugin/PLUGIN_NAME/PLATFORM
> Changing of common.js / platform.js is *not* a part of this issue, but 
> instead will be a follow-up (requires more thought)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CB-1936) Backward compatibility on FileTransfer.upload header support is broken


[ 
https://issues.apache.org/jira/browse/CB-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571954#comment-13571954
 ] 

Filip Maj edited comment on CB-1936 at 2/5/13 11:57 PM:


Moving to 2.5.0.

[~macdonst] I suppose the following line should also be considered?

{code}
final JSONObject params = args.optJSONObject(5) == null ? new JSONObject() : 
args.optJSONObject(5);
{code}

  was (Author: filmaj):
Moving to 2.5.0.

[~macdonst] I suppose the following line should also be considered?

{{{final JSONObject params = args.optJSONObject(5) == null ? new JSONObject() : 
args.optJSONObject(5);}}}
  
> Backward compatibility on FileTransfer.upload header support is broken
> --
>
> Key: CB-1936
> URL: https://issues.apache.org/jira/browse/CB-1936
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: Simon MacDonald
>Assignee: Simon MacDonald
>Priority: Minor
> Fix For: 2.5.0
>
>
> There is a bug in the Android code for backward compatibility. See if you can 
> spot it:
> // Look for headers on the params map for backwards compatibility with older 
> Cordova versions.
> final JSONObject headers = args.optJSONObject(8) == null ? 
> params.optJSONObject("headers") : args.optJSONObject(8);
> I bet you didn't find it. The first comparison against null will fail. You 
> see when the arguments are stringified on the JS side the null will become a 
> "null". So there needs to be a comparison against the string "null" and not 
> the null value.

--
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-1936) Backward compatibility on FileTransfer.upload header support is broken


 [ 
https://issues.apache.org/jira/browse/CB-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1936:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.3.0

Moving to 2.5.0.

[~macdonst] I suppose the following line should also be considered?

{{{final JSONObject params = args.optJSONObject(5) == null ? new JSONObject() : 
args.optJSONObject(5);}}}

> Backward compatibility on FileTransfer.upload header support is broken
> --
>
> Key: CB-1936
> URL: https://issues.apache.org/jira/browse/CB-1936
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: Simon MacDonald
>Assignee: Simon MacDonald
>Priority: Minor
> Fix For: 2.5.0
>
>
> There is a bug in the Android code for backward compatibility. See if you can 
> spot it:
> // Look for headers on the params map for backwards compatibility with older 
> Cordova versions.
> final JSONObject headers = args.optJSONObject(8) == null ? 
> params.optJSONObject("headers") : args.optJSONObject(8);
> I bet you didn't find it. The first comparison against null will fail. You 
> see when the arguments are stringified on the JS side the null will become a 
> "null". So there needs to be a comparison against the string "null" and not 
> the null value.

--
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-580) Automate Splashscreen Tests


 [ 
https://issues.apache.org/jira/browse/CB-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj resolved CB-580.
--

   Resolution: Won't Fix
Fix Version/s: (was: 2.4.0)

Mmk I think this has toiled long enough without any progress. Closing.

> Automate Splashscreen Tests
> ---
>
> Key: CB-580
> URL: https://issues.apache.org/jira/browse/CB-580
> Project: Apache Cordova
>  Issue Type: Test
>  Components: Android
>Reporter: Joe Bowser
>Assignee: Simon MacDonald
>Priority: Minor
>
> Moving to 1.9.0, since 1.8.0rc1 has already been tagged.

--
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-1865) add minimum requirements to 'getting started' guide


 [ 
https://issues.apache.org/jira/browse/CB-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1865:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> add minimum requirements to 'getting started' guide
> ---
>
> Key: CB-1865
> URL: https://issues.apache.org/jira/browse/CB-1865
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Docs
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Brian LeRoux
>Assignee: Michael Brooks
>Priority: Minor
> Fix For: 2.5.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-2167) Support File.slice for retrieving parts of files using FileReader


[ 
https://issues.apache.org/jira/browse/CB-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571944#comment-13571944
 ] 

Filip Maj commented on CB-2167:
---

[~shepheb] can you provide any specifications or requirements to get this 
feature landed? Do we have tests for this? How are the other platforms supposed 
to add support for this?

> Support File.slice for retrieving parts of files using FileReader
> -
>
> Key: CB-2167
> URL: https://issues.apache.org/jira/browse/CB-2167
> Project: Apache Cordova
>  Issue Type: New Feature
>  Components: CordovaJS
>Reporter: Braden Shepherdson
>Assignee: Braden Shepherdson
>Priority: Minor
>  Labels: android, ios
> Fix For: 2.5.0
>
>
> These changes are nearly complete, I'm creating this bug for three reasons: 
> To point to the commits across the various repos, to capture the one 
> outstanding bug on iOS (see sub-bug) and to track adding this feature to more 
> platforms (more sub-bugs).

--
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-2167) Support File.slice for retrieving parts of files using FileReader


 [ 
https://issues.apache.org/jira/browse/CB-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2167:
--

Fix Version/s: (was: 2.4.0)
   2.5.0

Moving to 2.5.0.

> Support File.slice for retrieving parts of files using FileReader
> -
>
> Key: CB-2167
> URL: https://issues.apache.org/jira/browse/CB-2167
> Project: Apache Cordova
>  Issue Type: New Feature
>  Components: CordovaJS
>Reporter: Braden Shepherdson
>Assignee: Braden Shepherdson
>Priority: Minor
>  Labels: android, ios
> Fix For: 2.5.0
>
>
> These changes are nearly complete, I'm creating this bug for three reasons: 
> To point to the commits across the various repos, to capture the one 
> outstanding bug on iOS (see sub-bug) and to track adding this feature to more 
> platforms (more sub-bugs).

--
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-2169) File.slice() on BlackBerry


 [ 
https://issues.apache.org/jira/browse/CB-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2169:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> File.slice() on BlackBerry
> --
>
> Key: CB-2169
> URL: https://issues.apache.org/jira/browse/CB-2169
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: BlackBerry
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Braden Shepherdson
>Assignee: Tim Kim
>Priority: Minor
> Fix For: 2.5.0
>
>
> Support File.slice() on BlackBerry FileReader.

--
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-2179) Warn developers about including third-party content in their apps.


 [ 
https://issues.apache.org/jira/browse/CB-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2179:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> Warn developers about including third-party content in their apps.
> --
>
> Key: CB-2179
> URL: https://issues.apache.org/jira/browse/CB-2179
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs
>Affects Versions: 2.4.0
>Reporter: Andrew Grieve
>Assignee: Andrew Grieve
>Priority: Minor
> Fix For: 2.5.0
>
>
> We expose our native APIs to iframes as well as top-level content, so we 
> should warn against using iframes for third-party code.
> Might make sense to change "Domain Whitelist Guide" -> "Security & Whitelist 
> Guide" and then add a section to it about the dangers of embedding untrusted 
> content.

--
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-2227) Move mapping of module->symbol into individual plugins


[ 
https://issues.apache.org/jira/browse/CB-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571931#comment-13571931
 ] 

Filip Maj commented on CB-2227:
---

[~agrieve] i see this is merged in. Can we set this as resolved?

> Move mapping of module->symbol into individual plugins
> --
>
> Key: CB-2227
> URL: https://issues.apache.org/jira/browse/CB-2227
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: CordovaJS
>Reporter: Andrew Grieve
>Assignee: Andrew Grieve
>Priority: Minor
> Fix For: 2.4.0
>
>
> Goals:
> - Change from listing module->symbol mapping within common.js & platform.js, 
> to listing this within the plugins themselves.
> - Support apps that don't want us to clobber global symbols. 
> aka, allow module->symbol mapping to be turned off
> - Allow retrieval of clobbered globals
> - Currently modules save it themselves when they are loaded
> - This won't work (reliably) for saving references to globals overridden by 
> other modules
> - This gets in the way of the idea of lazy-loading modules via getters
> - Support the use of other module loaders 
> - So... don't do crazy things at require() time.
> Requirements:
> Plugins must be able to declare dependencies
> Plugins must be able to delay onDeviceReady()
> Plugins must be able to run code to initialize
> Implementation
> modulemapper.js:
> clobbers(...)
> merges(...)
> defaults(...)
> mapModules(wnd)
> getOriginalSymbol('FileSystem')
> Start-up flow:
> Parse all modules
> common-bootstrap:
> Loads list of modules named "cordova.*/symbols"
> Run modulemapper.mapModules(window);
> Loads list of modules named "cordova.*/main"
>   
> symbols.js files:
> Will make calls to modulemapper instead of exporting {clobbers:}
> This make dependencies work by require()ing dependent symbols
> We want the to be an evaluated .js file instead of something listed in 
> plugin.xml
> So that it can export based on browser version
> Implementation Steps
> 1. - Expose list of registered modules in scripts/require.js so that we can 
> loop over them
> 2. - Write modulemapper.js (and have unit tests, of course)
> 3. - Add logic to bootstrap.js that calls into modulemapper
> create $PLUGIN_NAME/symbols.js files for each plugin within cordova.
> 4. - Add logic to bootstrap.js that calls into modulemapper
> 5. - Create main.js files for those that currently have logic in their 
> platform.js files

--
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-1871) Tizen min reqs


 [ 
https://issues.apache.org/jira/browse/CB-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1871:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> Tizen min reqs
> --
>
> Key: CB-1871
> URL: https://issues.apache.org/jira/browse/CB-1871
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs, Tizen
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Brian LeRoux
>Assignee: Anis Kadri
> Fix For: 2.5.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] [Updated] (CB-1872) webOS min reqs


 [ 
https://issues.apache.org/jira/browse/CB-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1872:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0. 

> webOS min reqs
> --
>
> Key: CB-1872
> URL: https://issues.apache.org/jira/browse/CB-1872
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs, webOS
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Brian LeRoux
>Assignee: Herm Wong
> Fix For: 2.5.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] [Updated] (CB-1944) Create script on Android has to provide better error messages


 [ 
https://issues.apache.org/jira/browse/CB-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1944:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.3.0

Moving to 2.5.0.

> Create script on Android has to provide better error messages
> -
>
> Key: CB-1944
> URL: https://issues.apache.org/jira/browse/CB-1944
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: Simon MacDonald
>Assignee: Simon MacDonald
> Fix For: 2.5.0
>
>
> We moved to providing a source release that is compiled by the user via the 
> "create" script. In order for this to work the user is required to install 
> and setup:
> JDK
> Ant
> Android SDK
> If any one of those packages is missing from the Windows PATH then the script 
> fails with a generic error message:
> Missing one of the following:
> JDK: http://java.oracle.com
> Android SDK: http://developer.android.com
> Apache ant: http://ant.apache.org
> This could be a lot better and based on the feedback on the I've seen on the 
> mailing list we have a lot of upset users and we could make life a lot easier 
> for them.

--
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-979) Implement hastings init


 [ 
https://issues.apache.org/jira/browse/CB-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-979:
-

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.3.0

Moving to 2.5.0.

> Implement hastings init
> ---
>
> Key: CB-979
> URL: https://issues.apache.org/jira/browse/CB-979
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: Michael Brooks
>Assignee: Michael Brooks
> Fix For: 2.5.0
>
>
> [Reference: hastings init 
> \[path\]|http://wiki.apache.org/cordova/DocumentationCLIDesign#A.24_hastings_init_.5Bpath.5D]

--
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-1024) Capture API cancellation undefined


 [ 
https://issues.apache.org/jira/browse/CB-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1024:
--

Fix Version/s: (was: 2.4.0)
Affects Version/s: 2.4.0
   2.0.0
   2.1.0
   2.2.0
   2.3.0

Removing a fixVersion for this one.

This requires massaging on the mailing list to:

1. determine what the functionality is
2. setup tasks for docs, js, tests, and then implementations.

> Capture API cancellation undefined
> --
>
> Key: CB-1024
> URL: https://issues.apache.org/jira/browse/CB-1024
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs
>Affects Versions: 1.9.0, 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0
>Reporter: Jesse MacFadyen
>Assignee: Michael Brooks
>
> The documentation does not state what the result of a user-cancelled capture 
> operation is.  Therefore, implementations may vary ...
> When the user cancels the capture operation :
> - does the success callback get called? without MediaFiles?
> - does the error callback get called? with what error 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

[jira] [Resolved] (CB-1098) Remove TM from template app


 [ 
https://issues.apache.org/jira/browse/CB-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj resolved CB-1098.
---

Resolution: Cannot Reproduce

There is no TM anymore..

> Remove TM from template app
> ---
>
> Key: CB-1098
> URL: https://issues.apache.org/jira/browse/CB-1098
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Bada, BlackBerry, webOS
>Reporter: Jesse MacFadyen
>Assignee: Michael Brooks
> Fix For: 2.4.0
>
>
> Update the cordova-labs sample app, then all the templates that use it.
> WP7 Updated.

--
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-1247) An option similar to "webviewbounce" is needed that works on Windows Phone


 [ 
https://issues.apache.org/jira/browse/CB-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1247:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.1.0
   2.2.0
   2.3.0

Judging by the comments I am not sure whether this is resolved or not. 
[~purplecabbage]?

> An option similar to "webviewbounce" is needed that works on Windows Phone
> --
>
> Key: CB-1247
> URL: https://issues.apache.org/jira/browse/CB-1247
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: WP7
>Affects Versions: 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0
> Environment: Windows Phone
>Reporter: Rob Van Wicklen
>Assignee: Jesse MacFadyen
> Fix For: 2.5.0
>
>
> A "webviewbounce" option can be set to fix an app's viewable area in place on 
> the iOS screen, making it so that users cannot drag it and move it off the 
> side of the screen. A similar setting is needed for Windows Phone.
> Currently, even if the viewport size is set to the device screen dimensions 
> and the scale is fixed at 1.0, Windows Phone users can still drag the app's 
> viewport which results in a bounce effect similar to what's seen on iOS when 
> the webviewbounce option isn't set to false.
> The Windows Phone WebBrowser control doesn't directly expose a property that 
> lets you eliminate the bounce, but the desired result can be acheived with a 
> small amount of wrapper code around the control. This would need to be 
> implemented within Cordova. The following article explains how to do it:
>  
> http://www.scottlogic.co.uk/blog/colin/2011/11/suppressing-zoom-and-scroll-interactions-in-the-windows-phone-7-browser-control
> Justification: the ability to eliminate the bounce effect is important for 
> app developers who want to create an experience that's similar to a native 
> app. This is not currently possible on Windows Phone.

--
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-1393) Add reset() to plugin API on Qt


 [ 
https://issues.apache.org/jira/browse/CB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1393:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.1.0
   2.2.0
   2.3.0

Moving to 2.5.0.

> Add reset() to plugin API on Qt
> ---
>
> Key: CB-1393
> URL: https://issues.apache.org/jira/browse/CB-1393
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Qt
>Affects Versions: 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0
>Reporter: Braden Shepherdson
>Assignee: Jeff Tranter
> Fix For: 2.5.0
>
>
> Add a reset() function to the plugin API which is called on top-level 
> navigation or refresh, so that plugins can know to cancel any long-running 
> requests and reinitialize themselves.

--
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-1392) Add reset() to plugin API on Blackberry


 [ 
https://issues.apache.org/jira/browse/CB-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1392:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.1.0
   2.2.0
   2.3.0

Moving to 2.5.0.

> Add reset() to plugin API on Blackberry
> ---
>
> Key: CB-1392
> URL: https://issues.apache.org/jira/browse/CB-1392
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: BlackBerry
>Affects Versions: 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0
>Reporter: Braden Shepherdson
>Assignee: Tim Kim
> Fix For: 2.5.0
>
>
> Add a reset() function to the plugin API which is called on top-level 
> navigation or refresh, so that plugins can know to cancel any long-running 
> requests and reinitialize themselves.

--
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-1396) Add reset() to plugin API on Windows 8


 [ 
https://issues.apache.org/jira/browse/CB-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1396:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.1.0
   2.2.0
   2.3.0

Moving to 2.5.0.

> Add reset() to plugin API on Windows 8
> --
>
> Key: CB-1396
> URL: https://issues.apache.org/jira/browse/CB-1396
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Windows 8
>Affects Versions: 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0
>Reporter: Braden Shepherdson
>Assignee: Jesse MacFadyen
> Fix For: 2.5.0
>
>
> Add a reset() function to the plugin API which is called on top-level 
> navigation or refresh, so that plugins can know to cancel any long-running 
> requests and reinitialize themselves.

--
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-1395) Add reset() to plugin API on WebOS


 [ 
https://issues.apache.org/jira/browse/CB-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1395:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.1.0
   2.2.0
   2.3.0

Moving to 2.5.0.

> Add reset() to plugin API on WebOS
> --
>
> Key: CB-1395
> URL: https://issues.apache.org/jira/browse/CB-1395
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: webOS
>Affects Versions: 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0
>Reporter: Braden Shepherdson
>Assignee: Herm Wong
> Fix For: 2.5.0
>
>
> Add a reset() function to the plugin API which is called on top-level 
> navigation or refresh, so that plugins can know to cancel any long-running 
> requests and reinitialize themselves.

--
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-1394) Add reset() to plugin API on Tizen


 [ 
https://issues.apache.org/jira/browse/CB-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1394:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.1.0
   2.2.0
   2.3.0

Moving to 2.5.0.

> Add reset() to plugin API on Tizen
> --
>
> Key: CB-1394
> URL: https://issues.apache.org/jira/browse/CB-1394
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Tizen
>Affects Versions: 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0
>Reporter: Braden Shepherdson
>Assignee: Paul Plaquette
> Fix For: 2.5.0
>
>
> Add a reset() function to the plugin API which is called on top-level 
> navigation or refresh, so that plugins can know to cancel any long-running 
> requests and reinitialize themselves.

--
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-1388) Add reset() to plugin API and fix callback collisions on all platforms


 [ 
https://issues.apache.org/jira/browse/CB-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1388:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.1.0
   2.2.0
   2.3.0

Moving to 2.5.0.

> Add reset() to plugin API and fix callback collisions on all platforms
> --
>
> Key: CB-1388
> URL: https://issues.apache.org/jira/browse/CB-1388
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Bada, BlackBerry, CordovaJS, Qt, Tizen, webOS
>Affects Versions: 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.4.0
>Reporter: Braden Shepherdson
>Assignee: Braden Shepherdson
> Fix For: 2.5.0
>
>
> There are three parts to this bug.
> First, platform-specific: we should add a reset() function to the plugin API 
> which is called on top-level navigation or refresh, so that plugins can know 
> to cancel any long-running requests and reinitialize themselves. This won't 
> be relevant to some platforms 
> Second, platform-independent: the callback IDs generated on the Javascript 
> side should be randomized in some way to prevent collisions after navigation. 
> Otherwise a request might get the ID "Service1", and before it has a chance 
> to complete we navigate and a new request is made, also receiving "Service1". 
> Then the first response comes back and the new Service1 callback is handed 
> the old results.
> Third, we should add a test for this to Mobile Spec, if possible. This is a 
> tricky thing to reproduce reliably, unfortunately.
> I'll tackle the second and third parts, and Android for the first part. It 
> would be great if people who work on other platforms would add the reset() 
> logic, or close the platform bugs if the platform is all-Javascript and fully 
> reloaded on navigation.

--
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-1678) Create native extensions for bb10


 [ 
https://issues.apache.org/jira/browse/CB-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1678:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.3.0

Moving this to 2.5.0. Is this resolved yet [~timkim]?

> Create native extensions for bb10
> -
>
> Key: CB-1678
> URL: https://issues.apache.org/jira/browse/CB-1678
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
> Environment: blackberry 10
>Reporter: Tim Kim
>Assignee: Tim Kim
> Fix For: 2.5.0
>
>
> Currently with the webworks blackberry repo, there is no possibility to make 
> a native extension for bb10 (this is because bb10 is now qnx with a c++ 
> implementation). By making the infrastructure to support this, a developer 
> would then be able to make their own plugins on the bb10 platform. 

--
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-1583) Some types are not constructable


 [ 
https://issues.apache.org/jira/browse/CB-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1583:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.2.0
   2.3.0

Moving to 2.5.0.

> Some types are not constructable
> 
>
> Key: CB-1583
> URL: https://issues.apache.org/jira/browse/CB-1583
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: mobile-spec
>Affects Versions: 2.1.0, 2.2.0, 2.3.0, 2.4.0
>Reporter: Jesse MacFadyen
>Assignee: Jesse MacFadyen
> Fix For: 2.5.0
>
>
> ex. should be able to define a Position object with coords and timestamp 
> properties
> invalid test.

--
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-1599) successCallback not called after stopRecording, duplicate AudioPlayer objects created


 [ 
https://issues.apache.org/jira/browse/CB-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1599:
--

  Component/s: Android
Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.2.0
   2.3.0

Tagging Android and moving to 2.5.0.

> successCallback not called after stopRecording, duplicate AudioPlayer objects 
> created
> -
>
> Key: CB-1599
> URL: https://issues.apache.org/jira/browse/CB-1599
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android, CordovaJS
>Affects Versions: 2.1.0, 2.2.0, 2.3.0, 2.4.0
> Environment: Android 2.3? 
>Reporter: Bob Flavin
>Assignee: Simon MacDonald
> Fix For: 2.5.0
>
> Attachments: AudioHandler.java
>
>
> A successCallback is not called sometimes after stopRecording() is called.
> The problem is that javascript cordova calls to 'new Media()' and 
> 'mediaObj.startRecord() are dispatched by androidExec (prompt) to new threads 
> on the java side and are not synchronized.  Thus 
> org.apache.cordova.AudioHandler.execute for action='create', calls new 
> AudioPlayer().   Asynchronously, ...AudioHandler.execute for 
> action='startAudioRecording' calls AudioHandler.startAudioRecording(), which 
> gets a null from this.players.get(id) which causes the if statement to call 
> new AudioRecorder which creates a second instance of AudioRecorder for that 
> id.
> public void startRecordingAudio(String id, String file) {
> AudioPlayer audio = this.players.get(id);
> if ( audio == null) {
> audio = new AudioPlayer(this, id, file);
> this.players.put(id, audio);
> }
> audio.startRecording(file);
> }
> One instance of AudioPlayer goes into STATE MEDIA_RUNNING the other remains 
> in MEDIA_NONE.  
> When the javascript calls mediaObj.stopRecord() (and mediaObj.release()) it 
> may get the instance of AudioPlayer that is in MEDIA_NONE.  This prevents 
> AudioPlayer.stopRecording() from calling this.recorder.stop() and 
> this.setState(STATE.MEDIA_STOPPED) because that AudioPlayer instance is in 
> STATE MEDIA_NONE.  Thus AudioPlayer.setState doesn't call the 
> handler.sendJavascript to call the javascript Media.onStatus method that 
> would call the statusCallback and the successCallback.
> I think that the AudioHandler should have a synchronized block that prevents 
> 'create' and 'startRecordingAudio from running at the same time and that 
> 'create' should use the same code that startRecodingAudio does:
> AudioPlayer audio = this.players.get(id);
> if ( audio == null) {
> audio = new AudioPlayer(this, id, file);
> this.players.put(id, audio);
> }
> to prevent creating a second AudioPlayer instance if the startRecordingAudio 
> thread executes before the 'create' thread.
> There may be other actions in AudioHandler.execute that need this 
> synchronization as well.
> One effect of this problem is that the javascript successCallback is never 
> called (after stopRecord)

--
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-1505) Add iPhone 5 Splash Screens


 [ 
https://issues.apache.org/jira/browse/CB-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1505:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Didn't make it in 2.4.0, moving to 2.5.0.

> Add iPhone 5 Splash Screens
> ---
>
> Key: CB-1505
> URL: https://issues.apache.org/jira/browse/CB-1505
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: App Hello World
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Michael Brooks
>Assignee: Michael Brooks
> Fix For: 2.5.0
>
>
> iPhone 5 resolution is: 640px x 1136px (w x 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] [Updated] (CB-1880) incorporate docs into project website


 [ 
https://issues.apache.org/jira/browse/CB-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1880:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
  Description: Moving to 2.5.0...
Affects Version/s: 2.4.0

> incorporate docs into project website
> -
>
> Key: CB-1880
> URL: https://issues.apache.org/jira/browse/CB-1880
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Docs
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Brian LeRoux
>Assignee: Brian LeRoux
> Fix For: 2.5.0
>
>
> Moving to 2.5.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] [Resolved] (CB-2224) docs on cordova.apache.org


 [ 
https://issues.apache.org/jira/browse/CB-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj resolved CB-2224.
---

   Resolution: Duplicate
Fix Version/s: (was: 2.5.0)

Actually closing this as this is a duplicate of CB-1880.

> docs on cordova.apache.org
> --
>
> Key: CB-2224
> URL: https://issues.apache.org/jira/browse/CB-2224
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Docs
>Affects Versions: 2.4.0
>Reporter: Marcel Kinard
>Assignee: Michael Brooks
>
> Would it make sense to host a copy of the docs on cordova.apache.org? Other 
> Apache projects have their docs online at their apache.org site.
> See http://markmail.org/thread/xwuzkey5ud23m54r

--
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-1870) bada min req


 [ 
https://issues.apache.org/jira/browse/CB-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1870:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> bada min req
> 
>
> Key: CB-1870
> URL: https://issues.apache.org/jira/browse/CB-1870
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Bada, Docs
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Brian LeRoux
>Assignee: Anis Kadri
> Fix For: 2.5.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] [Updated] (CB-1881) update project website contribution text to make it more clear a CLA is required


 [ 
https://issues.apache.org/jira/browse/CB-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1881:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
  Description: Moving to 2.5.0...
Affects Version/s: 2.4.0

> update project website contribution text to make it more clear a CLA is 
> required
> 
>
> Key: CB-1881
> URL: https://issues.apache.org/jira/browse/CB-1881
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Docs
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Brian LeRoux
>Assignee: Brian LeRoux
> Fix For: 2.5.0
>
>
> Moving to 2.5.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] [Updated] (CB-2157) Add support for Contacts API in BlackBerry 10


 [ 
https://issues.apache.org/jira/browse/CB-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2157:
--

  Component/s: (was: CordovaJS)
Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.3.0

Moving to 2.5.0.

> Add support for Contacts API in BlackBerry 10
> -
>
> Key: CB-2157
> URL: https://issues.apache.org/jira/browse/CB-2157
> Project: Apache Cordova
>  Issue Type: New Feature
>  Components: BlackBerry
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Gord
>Assignee: Gord
> Fix For: 2.5.0
>
>
> Support: 
> http://docs.phonegap.com/en/2.2.0/cordova_contacts_contacts.md.html#Contacts
> Basically a proxy to this API:
> https://developer.blackberry.com/html5/apis/blackberry.pim.contacts.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

[jira] [Updated] (CB-2156) Add support for InAppBrowser to BlackBerry 10


 [ 
https://issues.apache.org/jira/browse/CB-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2156:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> Add support for InAppBrowser to BlackBerry 10
> -
>
> Key: CB-2156
> URL: https://issues.apache.org/jira/browse/CB-2156
> Project: Apache Cordova
>  Issue Type: New Feature
>  Components: BlackBerry, CordovaJS
>Affects Versions: 2.4.0
>Reporter: Gord
>Assignee: Gord
> Fix For: 2.5.0
>
>
> Support:
> http://wiki.apache.org/cordova/InAppBrowser.
> BlackBerry 10 has added support for window.open(url, "_blank") and we should 
> be able to use that plus the invoke API to support the 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-2158) Fix mobile spec errors in filetransfer for BlackBerry 10


 [ 
https://issues.apache.org/jira/browse/CB-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2158:
--

  Component/s: (was: mobile-spec)
   (was: CordovaJS)
Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.3.0

Moving to 2.5.0.

> Fix mobile spec errors in filetransfer for BlackBerry 10
> 
>
> Key: CB-2158
> URL: https://issues.apache.org/jira/browse/CB-2158
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Gord
>Assignee: Gord
> Fix For: 2.5.0
>
>
> Currently we are failing a bunch of the tests.
> We may need to switch over to an XHR2 backed impl because I have heard rumors 
> that the filetransfer API might be removed. 
> https://developer.blackberry.com/html5/apis/blackberry.io.filetransfer.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

[jira] [Updated] (CB-2224) docs on cordova.apache.org


 [ 
https://issues.apache.org/jira/browse/CB-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2224:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> docs on cordova.apache.org
> --
>
> Key: CB-2224
> URL: https://issues.apache.org/jira/browse/CB-2224
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: Docs
>Affects Versions: 2.4.0
>Reporter: Marcel Kinard
>Assignee: Michael Brooks
> Fix For: 2.5.0
>
>
> Would it make sense to host a copy of the docs on cordova.apache.org? Other 
> Apache projects have their docs online at their apache.org site.
> See http://markmail.org/thread/xwuzkey5ud23m54r

--
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-2216) Create Mobile Spec Test to benchmark ArrayBuffer exec bridge


 [ 
https://issues.apache.org/jira/browse/CB-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2216:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0 since mobile-spec is now tagged 2.4.0.

> Create Mobile Spec Test to benchmark ArrayBuffer exec bridge
> 
>
> Key: CB-2216
> URL: https://issues.apache.org/jira/browse/CB-2216
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: mobile-spec
>Affects Versions: 2.4.0
>Reporter: Michal Mocny
>Assignee: Michal Mocny
> Fix For: 2.5.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] [Updated] (CB-2321) Add Bada-specific project-settings guide


 [ 
https://issues.apache.org/jira/browse/CB-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2321:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> Add Bada-specific project-settings guide
> 
>
> Key: CB-2321
> URL: https://issues.apache.org/jira/browse/CB-2321
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Bada, Docs
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Filip Maj
>Assignee: Anis Kadri
> Fix For: 2.5.0
>
>
> I've added a top-level project settings guide that is platform agnostic. 
> There is also now a stub for Bada-specific guide w.r.t. the project settings.
> Can you fill out the details of the Bada guide for the project settings and 
> add any  tag support that is not mentioned?
> You can follow the Android and iOS guides as a template.

--
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-2320) Add webOS-specific project settings guide


 [ 
https://issues.apache.org/jira/browse/CB-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2320:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> Add webOS-specific project settings guide
> -
>
> Key: CB-2320
> URL: https://issues.apache.org/jira/browse/CB-2320
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs, webOS
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Filip Maj
>Assignee: Herm Wong
> Fix For: 2.5.0
>
>
> I've added a top-level project settings guide that is platform agnostic. 
> There is also now a stub for webOS-specific guide w.r.t. the project settings.
> Can you fill out the details of the webOS guide for the project settings and 
> add any  tag support that is not mentioned?
> You can follow the Android and iOS guides as a template.

--
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-2319) Add Windows Phone 8-specific project settings guide


 [ 
https://issues.apache.org/jira/browse/CB-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2319:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> Add Windows Phone 8-specific project settings guide
> ---
>
> Key: CB-2319
> URL: https://issues.apache.org/jira/browse/CB-2319
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs, WP8
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Filip Maj
>Assignee: Jesse MacFadyen
> Fix For: 2.5.0
>
>
> I've added a top-level project settings guide that is platform agnostic. 
> There is also now a stub for Windows Phone 8-specific guide w.r.t. the 
> project settings.
> Can you fill out the details of the Windows Phone 8 guide for the project 
> settings and add any  tag support that is not mentioned?
> You can follow the Android and iOS guides as a template.

--
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-2318) Add Windows Phone 7-specific project settings guide


 [ 
https://issues.apache.org/jira/browse/CB-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2318:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> Add Windows Phone 7-specific project settings guide
> ---
>
> Key: CB-2318
> URL: https://issues.apache.org/jira/browse/CB-2318
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs, WP7
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Filip Maj
>Assignee: Jesse MacFadyen
> Fix For: 2.5.0
>
>
> I've added a top-level project settings guide that is platform agnostic. 
> There is also now a stub for Windows Phone 7-specific guide w.r.t. the 
> project settings.
> Can you fill out the details of the Windows Phone 7 guide for the project 
> settings and add any  tag support that is not mentioned?
> You can follow the Android and iOS guides as a template.

--
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-2316) Add BlackBerry-specific project settings guide


 [ 
https://issues.apache.org/jira/browse/CB-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj resolved CB-2316.
---

   Resolution: Fixed
Fix Version/s: (was: 2.4.0)
   2.5.0
 Assignee: Filip Maj  (was: Tim Kim)

https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=b9bd36c797d016e201be45c0643653b39f5813ab

> Add BlackBerry-specific project settings guide
> --
>
> Key: CB-2316
> URL: https://issues.apache.org/jira/browse/CB-2316
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: BlackBerry, Docs
>Affects Versions: 2.3.0
>Reporter: Filip Maj
>Assignee: Filip Maj
> Fix For: 2.5.0
>
>
> I've added a top-level project settings guide that is platform agnostic. 
> There is also now a stub for BlackBerry-specific guide w.r.t. the project 
> settings.
> The BlackBerry guide should be fairly simple, as it should mostly link to the 
> BlackBerry WebWorks config.xml documentation (unless there are other elements 
> that we support in cordova over and above what WebWorks supports).

--
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-2317) Add Windows 8-specific project settings guide


 [ 
https://issues.apache.org/jira/browse/CB-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2317:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.0.

> Add Windows 8-specific project settings guide
> -
>
> Key: CB-2317
> URL: https://issues.apache.org/jira/browse/CB-2317
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Windows 8
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Filip Maj
>Assignee: Jesse MacFadyen
> Fix For: 2.5.0
>
>
> I've added a top-level project settings guide that is platform agnostic. 
> There is also now a stub for Windows 8-specific guide w.r.t. the project 
> settings.
> Can you fill out the details of the Windows 8 guide for the project settings 
> and add any {{}} tag support that is not mentioned?
> You can follow the Android and iOS guides as a template.

--
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-2382) Cannot play resource audio


 [ 
https://issues.apache.org/jira/browse/CB-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesse MacFadyen resolved CB-2382.
-

   Resolution: Fixed
Fix Version/s: 2.5.0

Currently in a branch here:
https://github.com/purplecabbage/cordova-wp8/commit/936c03a642835c889d5c97cf4faf35872092f1d3

This will be pulled in for 2.5.0

> Cannot play resource audio
> --
>
> Key: CB-2382
> URL: https://issues.apache.org/jira/browse/CB-2382
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: WP8
>Affects Versions: 2.4.0
>Reporter: Jesse MacFadyen
>Assignee: Jesse MacFadyen
> Fix For: 2.5.0
>
>
> The current implementation of Media playback is expecting the audio file to 
> have been unpacked to Isolated Storage, which was the case on WP7 when this 
> code was written.
> Currently it is not possible to play a file that is packaged as a resource.
> We need to implement reading the file from stream in order to address this.
> StreamResourceInfo fileResourceStreamInfo = Application.GetResourceStream(new 
> Uri("www/sound1.wav", UriKind.Relative));
> SoundEffect soundEffect = 
> SoundEffect.FromStream(fileResourceStreamInfo.Stream);
> soundEffect.Play();

--
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-2315) Vet Android-specific project settings following addition of top-level project settings guide


 [ 
https://issues.apache.org/jira/browse/CB-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj resolved CB-2315.
---

   Resolution: Fixed
Fix Version/s: (was: 2.4.0)
   2.5.0
 Assignee: Filip Maj  (was: Joe Bowser)

I've worked this out a little bit. It will land in 2.5.0.

https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=273078605b48c27c76bb0715e48a659a6d65f110

> Vet Android-specific project settings following addition of top-level project 
> settings guide
> 
>
> Key: CB-2315
> URL: https://issues.apache.org/jira/browse/CB-2315
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Android, Docs
>Affects Versions: 2.3.0
>Reporter: Filip Maj
>Assignee: Filip Maj
> Fix For: 2.5.0
>
>
> I've added a top-level guide describing the major platform-agnostic elements 
> that we support in cordova inside config.xml.
> Can you vet the project-specific Android guide and make sure we are a) not 
> duplicating content and b) the preferences elements documentation is all up 
> to date?
> Thanks!

--
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-2314) Vet iOS-specific project settings following addition of top-level project settings guide


 [ 
https://issues.apache.org/jira/browse/CB-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-2314:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0

Moving to 2.5.

> Vet iOS-specific project settings following addition of top-level project 
> settings guide
> 
>
> Key: CB-2314
> URL: https://issues.apache.org/jira/browse/CB-2314
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs, iOS
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Filip Maj
>Assignee: Shazron Abdullah
> Fix For: 2.5.0
>
>
> I've added a top-level project settings guide. Can you please review the 
> iOS-specific guide and make sure we are not duplicating content? The majority 
> of iOS-specific content w.r.t. project settings is for the {{}} 
> elements only.

--
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-1365) Need to document config.xml


 [ 
https://issues.apache.org/jira/browse/CB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj updated CB-1365:
--

Fix Version/s: (was: 2.4.0)
   2.5.0
Affects Version/s: 2.4.0
   2.3.0

Moving to 2.5

> Need to document config.xml
> ---
>
> Key: CB-1365
> URL: https://issues.apache.org/jira/browse/CB-1365
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: Simon MacDonald
>Assignee: Filip Maj
> Fix For: 2.5.0
>
>
> Is there documentation somewhere regarding options in the config.xml file for 
> phonegap/cordova 2.0, specifically preferences. I see bits and pieces here 
> and there, but nothing all in one spot.
> Further edits necessary:
> - We should provide examples, like the iOS specific content doc
> - it might confuse people since our config.xml root element is actually 
> 'cordova', not 'widget' (yet) (files as CB-2323)

--
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-2375) Tag Mobile Spec


 [ 
https://issues.apache.org/jira/browse/CB-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj resolved CB-2375.
---

Resolution: Fixed

https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=commit;h=66a4bd7f070182d547de51bd6a409cb9798a3347

> Tag Mobile Spec
> ---
>
> Key: CB-2375
> URL: https://issues.apache.org/jira/browse/CB-2375
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: mobile-spec
>Reporter: Filip Maj
>Assignee: Filip Maj
> Fix For: 2.4.0
>
>
> After all platforms have been tagged, mobile-spec can be tagged.

--
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-2293) File Transfer of picture fails on every other picture


[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571834#comment-13571834
 ] 

Amrit Kahlon commented on CB-2293:
--

Removing con.disconnect() crashes app

> File Transfer of picture fails on every other picture
> -
>
> Key: CB-2293
> URL: https://issues.apache.org/jira/browse/CB-2293
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as 
> a Samsung Galaxy S3(Android 4.1.1)
>Reporter: Amrit Kahlon
>Assignee: Andrew Grieve
> Attachments: cordova-2.4.0rc1.jar
>
>
> When uploading pictures using the File Transfer function on android, the 
> first picture will upload fine. Then the second upload will give the 
> following error:
> 01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from 
> connection.
> 01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.io.Streams.readAsciiLine(Streams.java:203)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): 
> {"target":"http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2&api_key=x&source=androidapp-2.2.1","source":"file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392","code":3}
> 01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto 
> failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.sendto(IoBridge.java:475)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.io.DataOutputStream.write(DataOutputStream.java:98)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): Caused by: 
> libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendtoBytes(Native Method)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendto(Posix.java:146)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.sendto(IoBridge.java:473)
> 01-21 13:48:02.555: E/FileTransfer(8894): ... 9 more
> 01-21 13:48:02.575: D/CordovaLog(8894): error: 
> {"code":3,"source":"file:///storage/sdcard0/Android/data/com.hockeycommunity.hc_app/cache/resize.jpg?1358804880392","targ

[jira] [Created] (CB-2382) Cannot play resource audio

Jesse MacFadyen created CB-2382:
---

 Summary: Cannot play resource audio
 Key: CB-2382
 URL: https://issues.apache.org/jira/browse/CB-2382
 Project: Apache Cordova
  Issue Type: Bug
  Components: WP8
Affects Versions: 2.4.0
Reporter: Jesse MacFadyen
Assignee: Jesse MacFadyen


The current implementation of Media playback is expecting the audio file to 
have been unpacked to Isolated Storage, which was the case on WP7 when this 
code was written.
Currently it is not possible to play a file that is packaged as a resource.

We need to implement reading the file from stream in order to address this.

StreamResourceInfo fileResourceStreamInfo = Application.GetResourceStream(new 
Uri("www/sound1.wav", UriKind.Relative));
SoundEffect soundEffect = SoundEffect.FromStream(fileResourceStreamInfo.Stream);
soundEffect.Play();

--
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: Creating repos for core plugins

2013-02-05 Thread Brian LeRoux

Just kicked up a quick wiki page to help vett this. I'm thinking we
try to stay as close to the spec names as possible.

http://wiki.apache.org/cordova/Core%20Plugin%20Name%20Proposal


On Tue, Feb 5, 2013 at 11:40 AM, Becky Gibson  wrote:
> My only comment would be about media.  Currently it just supports audio so
> perhaps codova-plugin-audio makes more sense and we can leave media open
> for the rewrite.  Although, I do realize the api is labelled "media" so
> perhaps it would be too confusing to change the repo name.  Just a
> thought.
>
>
> On Tue, Feb 5, 2013 at 1:38 PM, Andrew Grieve  wrote:
>
>> Before I go ahead with this, let's agree upon the repo names / which
>> plugins to include.
>>
>> Here's the proposed list:
>>
>> Repos to create:
>>
>> cordova-plugin-accelerometer
>> cordova-plugin-battery
>> cordova-plugin-camera
>> cordova-plugin-capture
>> cordova-plugin-compass
>> cordova-plugin-contacts
>> cordova-plugin-device
>> cordova-plugin-file
>> cordova-plugin-geolocation
>> cordova-plugin-globalization
>> cordova-plugin-logger
>> cordova-plugin-media
>> cordova-plugin-networkstatus
>> cordova-plugin-notification
>> cordova-plugin-splashscreen
>> cordova-plugin-inappbrowser
>>
>> Note that I have device and network status in this list. Plugins that delay
>> ondeviceready just add themselves to channel.deviceReadyChannelsArray.
>>
>> Plugins *not* getting their own Repo:
>>
>> blackberry/plugin/java/app
>> android/plugin/android/app
>> android/plugin/android/storage
>> errgen/plugin/errgen
>> ios/plugin/ios/console (seems like this should be merged into the logger
>> plugin)
>> windowsphone/plugin/windowsphone/DOMStorage
>> windowsphone/plugin/windowsphone/XHRPatch
>> windowsphone/plugin/windowsphone/console
>> iOS's CDVLocalStorage.m
>>
>>
>> On Tue, Feb 5, 2013 at 9:34 AM, Andrew Grieve 
>> wrote:
>>
>> > Great! Sounds like an agreement :). I'll file an INFRA to get them
>> created.
>> >
>> >
>> > On Mon, Feb 4, 2013 at 9:44 PM, Shazron  wrote:
>> >
>> >> +1 on separate repos. It's the sane choice.
>> >>
>> >>
>> >> On Mon, Feb 4, 2013 at 11:53 PM, Jesse  wrote:
>> >>
>> >> > +1, I agree on the separate repositories.
>> >> > I still contend that nothing should need to be 'built' and there
>> should
>> >> be
>> >> > NO dependencies on the plugins from cordova-js, ( aside from
>> device.js +
>> >> > network.js which are both required pre device ready, and I think
>> should
>> >> > remain in the cordova-js repo )
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Feb 4, 2013 at 2:46 PM, Anis KADRI 
>> >> wrote:
>> >> >
>> >> > > +1 for separate repositories. Should take a bit longer than normal
>> to
>> >> > > package a release but not too long especially if the repos are
>> pulled
>> >> > from
>> >> > > a local source (ie no network overhead).
>> >> > > I'd be ok to ship a set of default plugins and give the ability for
>> >> > people
>> >> > > to build their 'own' Cordova.
>> >> > >
>> >> > >
>> >> > > On Mon, Feb 4, 2013 at 2:11 PM, Brian LeRoux  wrote:
>> >> > >
>> >> > > > I'm in favor of discreet plugin repos. It shouldn't effect a
>> release
>> >> > > > if we automate install/remove and add to the Coho tool... though
>> >> > > > perhaps this is a naive assumption.
>> >> > > >
>> >> > > > On Mon, Feb 4, 2013 at 1:44 PM, Andrew Grieve <
>> agri...@chromium.org
>> >> >
>> >> > > > wrote:
>> >> > > > > Thought it'd be worth having a discussion around whether we
>> want a
>> >> > > > separate
>> >> > > > > repo for each core plugin or not.
>> >> > > > >
>> >> > > > > As far as I can see, we can either have all core plugins in one
>> >> repo,
>> >> > > or
>> >> > > > > have each in it's own and call them:
>> >> > > > > cordova-plugin-file
>> >> > > > > cordova-plugin-network
>> >> > > > > cordova-plugin-media
>> >> > > > > etc...
>> >> > > > >
>> >> > > > > I think my preference would be to have them as their own repos
>> so
>> >> > that
>> >> > > it
>> >> > > > > will be easier to add/remove lists of plugins to the "which ones
>> >> are
>> >> > > > core"
>> >> > > > > list. It will also let us version them separately (if we want to
>> >> do
>> >> > > > this).
>> >> > > > >
>> >> > > > > The downside is that it may take longer to perform a release?
>> >> Would
>> >> > we
>> >> > > > even
>> >> > > > > bundle the plugins with releases anyways though?
>> >> > > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > @purplecabbage
>> >> > risingj.com
>> >> >
>> >>
>> >
>> >
>>

[jira] [Commented] (CB-571) Check that audio file recording to using Media.startRecord is of type .wav

2013-02-05 Thread Becky Gibson (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571789#comment-13571789
 ] 

Becky Gibson commented on CB-571:
-

I'm looking at how to fix this but it is going to be difficult to unify with 
Android so I could use some help.  

For recording via the media object you could pass in documents://filename to 
store a recording in the application documents directory.  Andrew suggested 
requiring a full path name (or documents://) for the file name of the 
recording.  However, one of the biggest complaints in this ticket is the 
difference between iOS and Android.  Currently iOS requires that the file exist 
(which is what I am changing) and Android does not. Android accepts just a 
filename and then stores it in: new File("/data/data/" + 
handler.cordova.getActivity().getPackageName() + "/cache/" + file).  Thus, the 
reason CB-571 has been open so long - how to unify these apis with the least 
changes.  Suggestions welcome!

> Check that audio file recording to using Media.startRecord is of type .wav
> --
>
> Key: CB-571
> URL: https://issues.apache.org/jira/browse/CB-571
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Affects Versions: 1.6.1
> Environment: iOS
>Reporter: Ram Kulkarni
>Assignee: Becky Gibson
>Priority: Minor
>  Labels: ios, media
> Fix For: 2.5.0
>
>
> As we document in {{startRecord}} on our [docs 
> page|http://docs.phonegap.com/en/1.6.1/cordova_media_media.md.html#media.startRecord],
>  when recording audio in iOS, you need to make sure the file exists and that 
> it is of type .wav.
> It would be nice if the {{startRecordingAudio}} method in CDVSound.m checked 
> that the requested file to record to is of the right type, and throw an error 
> if it is not.

--
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-2293) File Transfer of picture fails on every other picture


[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571786#comment-13571786
 ] 

Amrit Kahlon commented on CB-2293:
--

I've tried the chunked mode already, didn't help. I'll give the other ones a 
shot

> File Transfer of picture fails on every other picture
> -
>
> Key: CB-2293
> URL: https://issues.apache.org/jira/browse/CB-2293
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as 
> a Samsung Galaxy S3(Android 4.1.1)
>Reporter: Amrit Kahlon
>Assignee: Andrew Grieve
> Attachments: cordova-2.4.0rc1.jar
>
>
> When uploading pictures using the File Transfer function on android, the 
> first picture will upload fine. Then the second upload will give the 
> following error:
> 01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from 
> connection.
> 01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.io.Streams.readAsciiLine(Streams.java:203)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): 
> {"target":"http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2&api_key=x&source=androidapp-2.2.1","source":"file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392","code":3}
> 01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto 
> failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.sendto(IoBridge.java:475)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.io.DataOutputStream.write(DataOutputStream.java:98)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): Caused by: 
> libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendtoBytes(Native Method)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendto(Posix.java:146)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.sendto(IoBridge.java:473)
> 01-21 13:48:02.555: E/FileTransfer(8894): ... 9 more
> 01-21 13:48:02.575: D/CordovaLog(8894): error: 
> {"code":3,"source":"file:///storage/sdcard0/Android/data/com.hockeycommunity

[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files

2013-02-05 Thread Becky Gibson (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571785#comment-13571785
 ] 

Becky Gibson commented on CB-285:
-

OK, I can live with not using the Documents directory for PERSISTENT, although 
I think we should give devs a way to access it if they DO want to put user data 
in the documents dir - I guess access to  would give them 
that option.  I don't know enough about Android to know if this works there or 
not!

For the media object they can pass in documents://filename to store a recording 
there.  I like your idea of requiring a full path name (or documents://) for 
the file name of the recording.  However, one of the biggest complaints in 
CB-571 is the difference between iOS and Android.  Currently iOS requires that 
the file exist (which is what I am changing) and Android does not. Android 
accepts just a filename and then stores it in: new File("/data/data/" + 
handler.cordova.getActivity().getPackageName() + "/cache/" + file).  Thus, the 
reason CB-571 has been open so long!  I'll put this media specific stuff in 
that ticket for further conversation.  

> Add property returning root path of PhoneGap files
> --
>
> Key: CB-285
> URL: https://issues.apache.org/jira/browse/CB-285
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: CordovaJS
>Affects Versions: 1.4.0
> Environment: Both PhoneGap SDK and PhoneGap Build
>Reporter: Ashley Gullen
>Assignee: Andrew Grieve
>  Labels: features
>
> There needs to be a property in PhoneGap that returns the root path to the 
> general files added to the PhoneGap project (i.e. the directory index.html is 
> in).  For example, if I add 'music.mp3' to my project, in Android it will be 
> located in:
> /android_asset/www/music.mp3
> On iOS after being built with PhoneGap Build it will be located in some path 
> like this:
> /var/mobile/Applications//.app/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .app.
> This has two side effects:
> 1. Paths to audio for Media must be hard-coded separately depending on the 
> platform, which is inconvenient.
> 2. Paths to audio for Media cannot be known if developing a framework that 
> uses PhoneGap.  Since a framework does not know the App ID or name in 
> advance, it's impossible for the framework to determine the correct path.
> This is actively blocking audio from working on iOS in PhoneGap projects 
> exported by Construct 2 (www.scirra.com), a HTML5 game creator.  Also, it 
> seems like kind of an important function to make available anyway, since 
> hard-coding paths for each platform is a pain.
> This PhoneGap Support thread led to this issue: 
> http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios

--
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-2370) Tag webOS

2013-02-05 Thread Herm Wong (JIRA)


 [ 
https://issues.apache.org/jira/browse/CB-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herm Wong resolved CB-2370.
---

Resolution: Fixed

> Tag webOS
> -
>
> Key: CB-2370
> URL: https://issues.apache.org/jira/browse/CB-2370
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: webOS
>Reporter: Filip Maj
>Assignee: Herm Wong
> Fix For: 2.4.0
>
>
> After updating the JavaScript and sample application, the release can be 
> tagged.

--
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-2359) Update JavaScript for webOS

2013-02-05 Thread Herm Wong (JIRA)


 [ 
https://issues.apache.org/jira/browse/CB-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herm Wong resolved CB-2359.
---

Resolution: Fixed

> Update JavaScript for webOS
> ---
>
> Key: CB-2359
> URL: https://issues.apache.org/jira/browse/CB-2359
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: webOS
>Reporter: Filip Maj
>Assignee: Herm Wong
> Fix For: 2.4.0
>
>
> Update the cordova.js after CordovaJS has been tagged.

--
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-2293) File Transfer of picture fails on every other picture


[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571755#comment-13571755
 ] 

Andrew Grieve commented on CB-2293:
---

Great! Thanks for the investigation Amrit!

Found another possibly-related SO question: 
http://stackoverflow.com/questions/12319194/android-httpurlconnection-throwing-eofexception
Right at the bottom they suggest that maybe toggling useChunkedMode will have 
an effect.

Another thing from the previous SO question suggested removing the .close() 
calls when reading the response, or removing the conn.disconnect() call right 
at the end of the method.

Are you able to see if these help?

> File Transfer of picture fails on every other picture
> -
>
> Key: CB-2293
> URL: https://issues.apache.org/jira/browse/CB-2293
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as 
> a Samsung Galaxy S3(Android 4.1.1)
>Reporter: Amrit Kahlon
>Assignee: Andrew Grieve
> Attachments: cordova-2.4.0rc1.jar
>
>
> When uploading pictures using the File Transfer function on android, the 
> first picture will upload fine. Then the second upload will give the 
> following error:
> 01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from 
> connection.
> 01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.io.Streams.readAsciiLine(Streams.java:203)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): 
> {"target":"http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2&api_key=x&source=androidapp-2.2.1","source":"file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392","code":3}
> 01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto 
> failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.sendto(IoBridge.java:475)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.io.DataOutputStream.write(DataOutputStream.java:98)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): Caused by: 
> libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendtoBytes(Native Method)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendto(Po

Re: iOS 2.4.0 issues

2013-02-05 Thread Filip Maj

I have a few things that will hold up the release until tomorrow.

First, I saw some issues with the blackberry create script (CB-2381). I
have fixed them but would like more time to test. Also, I will not be able
to deploy + test on a BB7, a Playbook and a BB10 until tomorrow. If
someone else can help out with that, then we can speed that bit up. If
not, I'll do it tomorrow.

Once I have BlackBerry sorted I can then integrate the 2.4.0 tags of iOS,
BlackBerry and Android into cordova-cli and test that / make any necessary
tweaks.

So: hopefully tomorrow we can cut the release.

On 1/31/13 6:57 PM, "Andrew Grieve"  wrote:

>Thanks for the reminder! Done and done.
>
>
>On Thu, Jan 31, 2013 at 7:01 PM, Shazron  wrote:
>
>> There are 16 issues listed, most minor:
>>
>> 
>>https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20fix
>>Version%20%3D%20%222.4.0%22%20AND%20resolution%20%3D%20Unresolved%20AND%2
>>0component%20%3D%20iOS%20ORDER%20BY%20priority%20DESC
>>
>> ...which will be moved to 2.5.0. Haven't gone through all of them yet,
>>so
>> if they are assigned to you see if they are important enough to be in
>> 2.5.0.
>>

[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files


[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571724#comment-13571724
 ] 

Andrew Grieve commented on CB-285:
--

Thanks for the feedback Becky!

Moving from Documents -> Library: My thought here was that it's more common to 
use it for app data than for user-generated content. Users should be able to 
understand what each file in their Documents directory is for. That's not a 
distinction that the LocalFileSystem API makes. 

Agree that a USER_DATA might make sense, but that doesn't map as well 
x-platform, and so wanted to punt on it for the first go-around. If you (or 
someone else) wants to propose something for it though, now's not a bad time to 
discuss! :)

I suggest exposing  only to avoid exposing every 
sub-directory of it as different constants. Maybe this would be better though? 
I can also imagine third-party plugins wanting to be able to chose a 
sub-directory to use for plugin-specific files that does not show up to the app 
within their PERSISTENT / TEMPORARY spaces. e.g. /tmp/my-plugin or 
/Library/my-plugin/. Exposing the root ( makes this possible.

For assets - it's not currently possible to create a FileEntry() to a file in 
the www/ directory (unless you call the constructor directly with the full 
path, which is not really a supported API). There can also be siblings of www/ 
on both iOS and Android. I figured it would be useful to expose these (through 
our non-standard additions), but I can't actually think of a reason right now 
why you'd want to. It would only make your life harder, no? Maybe instead of 
APP_ASSETS, we should just have a CORDOVA_WWW constant? wdyt? The reason we 
want to expose it via the FileSystem API even though it's read-only, is that it 
makes it enumerable.

I *think* I agree with what you said about relative paths. They should be 
treated as relative URLs, so should be relative to the html file you're 
currently on.

For CB-571, I don't know that it's safe to assume Documents directory. It could 
be the app is a shazam-like app and the sound-clip is really just temporary app 
data. The best thing would be if the apps passed in absolute URLs for where 
they want the file. According to what you (and I agree) suggest for handling 
relative URLs, passing in just a filename should resolve to a file in the www/ 
directory, and be read-only. This would be my expected behaviour if I created 
the Media object with the intention of calling .play() on it.


> Add property returning root path of PhoneGap files
> --
>
> Key: CB-285
> URL: https://issues.apache.org/jira/browse/CB-285
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: CordovaJS
>Affects Versions: 1.4.0
> Environment: Both PhoneGap SDK and PhoneGap Build
>Reporter: Ashley Gullen
>Assignee: Andrew Grieve
>  Labels: features
>
> There needs to be a property in PhoneGap that returns the root path to the 
> general files added to the PhoneGap project (i.e. the directory index.html is 
> in).  For example, if I add 'music.mp3' to my project, in Android it will be 
> located in:
> /android_asset/www/music.mp3
> On iOS after being built with PhoneGap Build it will be located in some path 
> like this:
> /var/mobile/Applications//.app/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .app.
> This has two side effects:
> 1. Paths to audio for Media must be hard-coded separately depending on the 
> platform, which is inconvenient.
> 2. Paths to audio for Media cannot be known if developing a framework that 
> uses PhoneGap.  Since a framework does not know the App ID or name in 
> advance, it's impossible for the framework to determine the correct path.
> This is actively blocking audio from working on iOS in PhoneGap projects 
> exported by Construct 2 (www.scirra.com), a HTML5 game creator.  Also, it 
> seems like kind of an important function to make available anyway, since 
> hard-coding paths for each platform is a pain.
> This PhoneGap Support thread led to this issue: 
> http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios

--
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-2381) BlackBerry create script does not use name and package parameters provided


 [ 
https://issues.apache.org/jira/browse/CB-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filip Maj resolved CB-2381.
---

Resolution: Fixed

Fixed in e391d5f 

> BlackBerry create script does not use name and package parameters provided
> --
>
> Key: CB-2381
> URL: https://issues.apache.org/jira/browse/CB-2381
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: BlackBerry
>Affects Versions: 2.4.0
> Environment: 2.4.0rc1
>Reporter: Filip Maj
>Assignee: Filip Maj
> Fix For: 2.4.0
>
>
> The reason is because the create script:
> - runs {{ant dist}}
> - then copies the {{./dist/sample}} app to the project path specified by the 
> user. This sample already has default app name and package id.
> - the create script ends by interpolating tokens (__NAME__ and __PACKAGE__) 
> it expects in the config.xml to exist. But because it created a sample 
> application first, these tokens do not exist in the sample app config.xml.
> In fact, the {{./bin/templates}} directory is completely unused. This must 
> have not functioned at all for a few releases.

--
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-2381) BlackBerry create script does not use name and package parameters provided

Filip Maj created CB-2381:
-

 Summary: BlackBerry create script does not use name and package 
parameters provided
 Key: CB-2381
 URL: https://issues.apache.org/jira/browse/CB-2381
 Project: Apache Cordova
  Issue Type: Bug
  Components: BlackBerry
Affects Versions: 2.4.0
 Environment: 2.4.0rc1
Reporter: Filip Maj
Assignee: Filip Maj
 Fix For: 2.4.0


The reason is because the create script:

- runs {{ant dist}}
- then copies the {{./dist/sample}} app to the project path specified by the 
user. This sample already has default app name and package id.
- the create script ends by interpolating tokens (__NAME__ and __PACKAGE__) it 
expects in the config.xml to exist. But because it created a sample application 
first, these tokens do not exist in the sample app config.xml.

In fact, the {{./bin/templates}} directory is completely unused. This must have 
not functioned at all for a few releases.

--
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-2293) File Transfer of picture fails on every other picture


[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571682#comment-13571682
 ] 

Amrit Kahlon commented on CB-2293:
--

I tried just deleting setRequestProperty and my app crashed when I tried to 
upload a picture. Then I tried putting setRequestProperty back and simply add 
System.setProperty and my app uploaded one picture, but crashed on the second 
one. So the only way it works is when you delete the line from 
FileTransfer.java as well as add System.setProperty to you project.

> File Transfer of picture fails on every other picture
> -
>
> Key: CB-2293
> URL: https://issues.apache.org/jira/browse/CB-2293
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as 
> a Samsung Galaxy S3(Android 4.1.1)
>Reporter: Amrit Kahlon
>Assignee: Andrew Grieve
> Attachments: cordova-2.4.0rc1.jar
>
>
> When uploading pictures using the File Transfer function on android, the 
> first picture will upload fine. Then the second upload will give the 
> following error:
> 01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from 
> connection.
> 01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.io.Streams.readAsciiLine(Streams.java:203)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): 
> {"target":"http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2&api_key=x&source=androidapp-2.2.1","source":"file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392","code":3}
> 01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto 
> failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.sendto(IoBridge.java:475)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.io.DataOutputStream.write(DataOutputStream.java:98)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): Caused by: 
> libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendtoBytes(Native Method)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendto(Posix.java:146)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.BlockGuardOs.sendto(BlockGuardOs.java:177)
> 0

Re: Adding new LocalFileSystem constants.

2013-02-05 Thread Bryan Higgins

Thanks for the info Andrew!

It seems like the main difference between Android and BB10 is that we
provide shared storage both internal and external. Apps like the camera
will prompt where files should be saved once an SD card is inserted. It's
also possible we could have multiple external sources (ie cloud storage,
usb).

My 2 cents is that SHARED is probably a better name for the default target.
For platforms with removable media, constants are probably not the best way
to go. As a developer, I'd want a API to query available mount points and
go from there.



On Tue, Feb 5, 2013 at 1:53 PM, Andrew Grieve  wrote:

> Thanks for the input Bryan!
>
> Good ref's for storage locations:
> Android: http://developer.android.com/guide/topics/data/data-storage.html
> ):
> iOS:
>
> http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html
>
> Shared files:
> On Android, they go on /sdcard/Pictures, /sdcard/Music, etc.
> On iOS, Photos & Videos are shared via the AssetLibrary framework and music
> through the MusicPlayer framework. Neither one is provides a
> filesystem-like interface.
>
>
> Would SHARED be different from EXTERNAL_ROOT? Maybe SHARED would be a
> better name for it?
>
>
> On Tue, Feb 5, 2013 at 1:31 PM, Bryan Higgins  >wrote:
>
> > Hi Andrew,
> >
> > I really like this proposal. It's something we'd likely pick up for
> > BlackBerry WebWorks.
> >
> > Right now we have a separate API call which removes the sandbox and
> exposes
> > the full file system via PERSISTENT. We provide constants for paths to
> > things like application root, sd card and shared directories. Sandboxed
> > file systems are rooted in a subdirectory of the application. That
> approach
> > (plus our use of local:/// protocol) has caused some confusion with
> > developers.
> >
> > I think the list of android constants would work well for BB10, perhaps
> > with the addition of SHARED. I'm not too familiar with iOS and Android
> file
> > systems. Is there a single directory which contains shared documents,
> > music, etc?
> >
> > Thanks,
> > Bryan
> >
> >
> >
> > On Tue, Feb 5, 2013 at 11:52 AM, Andrew Grieve 
> > wrote:
> >
> > > FYI - Still looking for feedback here!
> > >
> > > -- Forwarded message --
> > > From: Andrew Grieve (JIRA) 
> > > Date: Tue, Feb 5, 2013 at 11:38 AM
> > > Subject: [jira] [Commented] (CB-285) Add property returning root path
> of
> > > PhoneGap files
> > > To: callback-...@incubator.apache.org
> > >
> > >
> > >
> > > [
> > >
> > >
> >
> https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571437#comment-13571437
> > > ]
> > >
> > > Andrew Grieve commented on CB-285:
> > > --
> > >
> > > I like the idea of switching PERSISTENT to be internal-only. The W3C
> spec
> > > intends this area to be sandboxed to the app, so shouldn't be on the
> > > sdcard.
> > >
> > > I think we need more than just an APP constant though, as there are
> many
> > > places where an app might want to put things.
> > >
> > > For iOS, You'd minimally want:
> > > 1. Application bundle,
> > > 2. 
> > >
> > >
> > > The other locations are all subdirectories of , so
> not
> > a
> > > big deal if we don't have constants for them
> > >
> > > For Android, You'd minimally want:
> > > 1. Assets directory (seems like a parallel to iOS Application Bundle)
> > > 2. Application data on internal storage
> (/data/data/$PACKAGE_NAME/files)
> > > 3. Application cache on internal storage
> (/data/data/$PACKAGE_NAME/cache)
> > > 4. External root: (/sdcard)
> > >
> > > We could maybe combine #2 and #3 into a single one that gave you
> > > /data/data/$PACKAGE_NAME, and document that Android wants files in the
> > > "files" and "cache" directories.
> > >
> > >
> > >
> > > The Ideal iOS constants:
> > >  1. PERSISTENT changes from /Documents -->
> > > /Library/CdvPersistentStorage
> > >  2. TEMPORARY changes from /tmp -->
> > > /tmp/CdvTemporaryStorage
> > >  3. APP_ASSETS --> Application bundle
> > >  4. APP_DATA --> 
> > >
> > > The main reason for changing #1 is that iCloud treats Documents
> directory
> > > specially
> > > The main reason for adding subdirs under Library/tmp is that it keeps
> the
> > > storage areas separate from the rest of the app (apps that have native
> > > components won't interfere with the webview's storage area).
> > >
> > > The ideal Android constants:
> > >  1. PERSISTENT --> /data/data/$PACKAGE_NAME/files/CdvPersistentStorage
> > >  2. TEMPORARY --> /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage
> > >  3. APP_ASSETS --> assets directory
> > >  4. APP_DATA --> /data/data/$PACKAGE_NAME
> > >  5. EXTERNAL_APP_DATA --> /sdcard/Android/data/$PACKAGE_NAME
> > >  6. EXTERNAL_ROOT --> /sdcard
> > >
> > >
> > > I even think there would be merit in adding more constants (e.g.
> > DOCUMENTS,
> > > android resourc

Re: Creating repos for core plugins

2013-02-05 Thread Becky Gibson

My only comment would be about media.  Currently it just supports audio so
perhaps codova-plugin-audio makes more sense and we can leave media open
for the rewrite.  Although, I do realize the api is labelled "media" so
perhaps it would be too confusing to change the repo name.  Just a
thought.


On Tue, Feb 5, 2013 at 1:38 PM, Andrew Grieve  wrote:

> Before I go ahead with this, let's agree upon the repo names / which
> plugins to include.
>
> Here's the proposed list:
>
> Repos to create:
>
> cordova-plugin-accelerometer
> cordova-plugin-battery
> cordova-plugin-camera
> cordova-plugin-capture
> cordova-plugin-compass
> cordova-plugin-contacts
> cordova-plugin-device
> cordova-plugin-file
> cordova-plugin-geolocation
> cordova-plugin-globalization
> cordova-plugin-logger
> cordova-plugin-media
> cordova-plugin-networkstatus
> cordova-plugin-notification
> cordova-plugin-splashscreen
> cordova-plugin-inappbrowser
>
> Note that I have device and network status in this list. Plugins that delay
> ondeviceready just add themselves to channel.deviceReadyChannelsArray.
>
> Plugins *not* getting their own Repo:
>
> blackberry/plugin/java/app
> android/plugin/android/app
> android/plugin/android/storage
> errgen/plugin/errgen
> ios/plugin/ios/console (seems like this should be merged into the logger
> plugin)
> windowsphone/plugin/windowsphone/DOMStorage
> windowsphone/plugin/windowsphone/XHRPatch
> windowsphone/plugin/windowsphone/console
> iOS's CDVLocalStorage.m
>
>
> On Tue, Feb 5, 2013 at 9:34 AM, Andrew Grieve 
> wrote:
>
> > Great! Sounds like an agreement :). I'll file an INFRA to get them
> created.
> >
> >
> > On Mon, Feb 4, 2013 at 9:44 PM, Shazron  wrote:
> >
> >> +1 on separate repos. It's the sane choice.
> >>
> >>
> >> On Mon, Feb 4, 2013 at 11:53 PM, Jesse  wrote:
> >>
> >> > +1, I agree on the separate repositories.
> >> > I still contend that nothing should need to be 'built' and there
> should
> >> be
> >> > NO dependencies on the plugins from cordova-js, ( aside from
> device.js +
> >> > network.js which are both required pre device ready, and I think
> should
> >> > remain in the cordova-js repo )
> >> >
> >> >
> >> >
> >> > On Mon, Feb 4, 2013 at 2:46 PM, Anis KADRI 
> >> wrote:
> >> >
> >> > > +1 for separate repositories. Should take a bit longer than normal
> to
> >> > > package a release but not too long especially if the repos are
> pulled
> >> > from
> >> > > a local source (ie no network overhead).
> >> > > I'd be ok to ship a set of default plugins and give the ability for
> >> > people
> >> > > to build their 'own' Cordova.
> >> > >
> >> > >
> >> > > On Mon, Feb 4, 2013 at 2:11 PM, Brian LeRoux  wrote:
> >> > >
> >> > > > I'm in favor of discreet plugin repos. It shouldn't effect a
> release
> >> > > > if we automate install/remove and add to the Coho tool... though
> >> > > > perhaps this is a naive assumption.
> >> > > >
> >> > > > On Mon, Feb 4, 2013 at 1:44 PM, Andrew Grieve <
> agri...@chromium.org
> >> >
> >> > > > wrote:
> >> > > > > Thought it'd be worth having a discussion around whether we
> want a
> >> > > > separate
> >> > > > > repo for each core plugin or not.
> >> > > > >
> >> > > > > As far as I can see, we can either have all core plugins in one
> >> repo,
> >> > > or
> >> > > > > have each in it's own and call them:
> >> > > > > cordova-plugin-file
> >> > > > > cordova-plugin-network
> >> > > > > cordova-plugin-media
> >> > > > > etc...
> >> > > > >
> >> > > > > I think my preference would be to have them as their own repos
> so
> >> > that
> >> > > it
> >> > > > > will be easier to add/remove lists of plugins to the "which ones
> >> are
> >> > > > core"
> >> > > > > list. It will also let us version them separately (if we want to
> >> do
> >> > > > this).
> >> > > > >
> >> > > > > The downside is that it may take longer to perform a release?
> >> Would
> >> > we
> >> > > > even
> >> > > > > bundle the plugins with releases anyways though?
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > @purplecabbage
> >> > risingj.com
> >> >
> >>
> >
> >
>

Re: Adding new LocalFileSystem constants.

2013-02-05 Thread Becky Gibson

I commented in the ticket:
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571437#comment-13571647



On Tue, Feb 5, 2013 at 1:53 PM, Andrew Grieve  wrote:

> Thanks for the input Bryan!
>
> Good ref's for storage locations:
> Android: http://developer.android.com/guide/topics/data/data-storage.html
> ):
> iOS:
>
> http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html
>
> Shared files:
> On Android, they go on /sdcard/Pictures, /sdcard/Music, etc.
> On iOS, Photos & Videos are shared via the AssetLibrary framework and music
> through the MusicPlayer framework. Neither one is provides a
> filesystem-like interface.
>
>
> Would SHARED be different from EXTERNAL_ROOT? Maybe SHARED would be a
> better name for it?
>
>
> On Tue, Feb 5, 2013 at 1:31 PM, Bryan Higgins  >wrote:
>
> > Hi Andrew,
> >
> > I really like this proposal. It's something we'd likely pick up for
> > BlackBerry WebWorks.
> >
> > Right now we have a separate API call which removes the sandbox and
> exposes
> > the full file system via PERSISTENT. We provide constants for paths to
> > things like application root, sd card and shared directories. Sandboxed
> > file systems are rooted in a subdirectory of the application. That
> approach
> > (plus our use of local:/// protocol) has caused some confusion with
> > developers.
> >
> > I think the list of android constants would work well for BB10, perhaps
> > with the addition of SHARED. I'm not too familiar with iOS and Android
> file
> > systems. Is there a single directory which contains shared documents,
> > music, etc?
> >
> > Thanks,
> > Bryan
> >
> >
> >
> > On Tue, Feb 5, 2013 at 11:52 AM, Andrew Grieve 
> > wrote:
> >
> > > FYI - Still looking for feedback here!
> > >
> > > -- Forwarded message --
> > > From: Andrew Grieve (JIRA) 
> > > Date: Tue, Feb 5, 2013 at 11:38 AM
> > > Subject: [jira] [Commented] (CB-285) Add property returning root path
> of
> > > PhoneGap files
> > > To: callback-...@incubator.apache.org
> > >
> > >
> > >
> > > [
> > >
> > >
> >
> https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571437#comment-13571437
> > > ]
> > >
> > > Andrew Grieve commented on CB-285:
> > > --
> > >
> > > I like the idea of switching PERSISTENT to be internal-only. The W3C
> spec
> > > intends this area to be sandboxed to the app, so shouldn't be on the
> > > sdcard.
> > >
> > > I think we need more than just an APP constant though, as there are
> many
> > > places where an app might want to put things.
> > >
> > > For iOS, You'd minimally want:
> > > 1. Application bundle,
> > > 2. 
> > >
> > >
> > > The other locations are all subdirectories of , so
> not
> > a
> > > big deal if we don't have constants for them
> > >
> > > For Android, You'd minimally want:
> > > 1. Assets directory (seems like a parallel to iOS Application Bundle)
> > > 2. Application data on internal storage
> (/data/data/$PACKAGE_NAME/files)
> > > 3. Application cache on internal storage
> (/data/data/$PACKAGE_NAME/cache)
> > > 4. External root: (/sdcard)
> > >
> > > We could maybe combine #2 and #3 into a single one that gave you
> > > /data/data/$PACKAGE_NAME, and document that Android wants files in the
> > > "files" and "cache" directories.
> > >
> > >
> > >
> > > The Ideal iOS constants:
> > >  1. PERSISTENT changes from /Documents -->
> > > /Library/CdvPersistentStorage
> > >  2. TEMPORARY changes from /tmp -->
> > > /tmp/CdvTemporaryStorage
> > >  3. APP_ASSETS --> Application bundle
> > >  4. APP_DATA --> 
> > >
> > > The main reason for changing #1 is that iCloud treats Documents
> directory
> > > specially
> > > The main reason for adding subdirs under Library/tmp is that it keeps
> the
> > > storage areas separate from the rest of the app (apps that have native
> > > components won't interfere with the webview's storage area).
> > >
> > > The ideal Android constants:
> > >  1. PERSISTENT --> /data/data/$PACKAGE_NAME/files/CdvPersistentStorage
> > >  2. TEMPORARY --> /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage
> > >  3. APP_ASSETS --> assets directory
> > >  4. APP_DATA --> /data/data/$PACKAGE_NAME
> > >  5. EXTERNAL_APP_DATA --> /sdcard/Android/data/$PACKAGE_NAME
> > >  6. EXTERNAL_ROOT --> /sdcard
> > >
> > >
> > > I even think there would be merit in adding more constants (e.g.
> > DOCUMENTS,
> > > android resources) going forward, but one step at a time...
> > >
> > >
> > > == Transitioning to these new constants ==
> > >
> > > TEMPORARY:
> > > Use the new path right away. No need to transition since the files
> there
> > > are temporary anyways.
> > >
> > >
> > > PERSISTENT (iOS):
> > > - If new location directory exists, use that.
> > > - Else, if any files exist in the legacy locatio

[jira] [Commented] (CB-285) Add property returning root path of PhoneGap files

2013-02-05 Thread Becky Gibson (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571647#comment-13571647
 ] 

Becky Gibson commented on CB-285:
-

For iOS I'm not sure that I understand why you want to change the PERSISTENT 
directory out of /Documents into 
/Library/CdvPersistent?  The iOS documentation that you 
reference explicitly states for /Library/, "You should not 
use this directory for user data files."  I could see adding a USERDATA setting 
if you want to make a distinction between user data and app data, although then 
we are deviating from the W3C spec.

I'm also not sure I understand the need for a way to retrieve the 
 directory - why would an app want to write here?  I can see 
why the user might want the APP_ASSETS in order to obtain a full path to the 
www directory but I think that would be confusing in the File APIs since this 
is read only.  Generally by convention in the core plugins file names with w/o 
a full path are treated as coming from te www directory.  At least this is what 
media does and we could standardize any other core plugins that do not use this 
convention. 

While we are thinking about directory names and locations,  I am looking at 
fixing CB-571 where iOS requires the file to exist before recording.  If the 
user just passes in a file name,  I was going to create and store the recording 
in the /Documents directory since it is user generated and 
should be backed up.  I'm not sure how this flies in the face of your proposed 
conventions for the File api - I guess the dev could get to these recorded 
files later using the proposed APP_HOME and appending /Documents to access the 
directory?  Or are you proposing that recorded files would also go in the 
/Library/CdvPersistent dir??? 


> Add property returning root path of PhoneGap files
> --
>
> Key: CB-285
> URL: https://issues.apache.org/jira/browse/CB-285
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: CordovaJS
>Affects Versions: 1.4.0
> Environment: Both PhoneGap SDK and PhoneGap Build
>Reporter: Ashley Gullen
>Assignee: Andrew Grieve
>  Labels: features
>
> There needs to be a property in PhoneGap that returns the root path to the 
> general files added to the PhoneGap project (i.e. the directory index.html is 
> in).  For example, if I add 'music.mp3' to my project, in Android it will be 
> located in:
> /android_asset/www/music.mp3
> On iOS after being built with PhoneGap Build it will be located in some path 
> like this:
> /var/mobile/Applications//.app/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .app.
> This has two side effects:
> 1. Paths to audio for Media must be hard-coded separately depending on the 
> platform, which is inconvenient.
> 2. Paths to audio for Media cannot be known if developing a framework that 
> uses PhoneGap.  Since a framework does not know the App ID or name in 
> advance, it's impossible for the framework to determine the correct path.
> This is actively blocking audio from working on iOS in PhoneGap projects 
> exported by Construct 2 (www.scirra.com), a HTML5 game creator.  Also, it 
> seems like kind of an important function to make available anyway, since 
> hard-coding paths for each platform is a pain.
> This PhoneGap Support thread led to this issue: 
> http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios

--
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-2293) File Transfer of picture fails on every other picture


[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571613#comment-13571613
 ] 

Amrit Kahlon commented on CB-2293:
--

[~drewschmaltz] I threw it in my main app.java file

public class staging extends DroidGap
{
@Override
public void onCreate(Bundle savedInstanceState)
{
System.setProperty("http.keepAlive", "false");
super.onCreate(savedInstanceState);
super.loadUrl("file:///android_asset/www/views/index.html");
}
}

I will try playing around and see what it was exactly

> File Transfer of picture fails on every other picture
> -
>
> Key: CB-2293
> URL: https://issues.apache.org/jira/browse/CB-2293
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as 
> a Samsung Galaxy S3(Android 4.1.1)
>Reporter: Amrit Kahlon
>Assignee: Andrew Grieve
> Attachments: cordova-2.4.0rc1.jar
>
>
> When uploading pictures using the File Transfer function on android, the 
> first picture will upload fine. Then the second upload will give the 
> following error:
> 01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from 
> connection.
> 01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.io.Streams.readAsciiLine(Streams.java:203)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): 
> {"target":"http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2&api_key=x&source=androidapp-2.2.1","source":"file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392","code":3}
> 01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto 
> failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.sendto(IoBridge.java:475)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.io.DataOutputStream.write(DataOutputStream.java:98)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): Caused by: 
> libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendtoBytes(Native Method)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendto(Posix.java:146)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.BlockGuardOs.send

Re: Adding new LocalFileSystem constants.

Thanks for the input Bryan!

Good ref's for storage locations:
Android: http://developer.android.com/guide/topics/data/data-storage.html):
iOS:
http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html

Shared files:
On Android, they go on /sdcard/Pictures, /sdcard/Music, etc.
On iOS, Photos & Videos are shared via the AssetLibrary framework and music
through the MusicPlayer framework. Neither one is provides a
filesystem-like interface.


Would SHARED be different from EXTERNAL_ROOT? Maybe SHARED would be a
better name for it?


On Tue, Feb 5, 2013 at 1:31 PM, Bryan Higgins wrote:

> Hi Andrew,
>
> I really like this proposal. It's something we'd likely pick up for
> BlackBerry WebWorks.
>
> Right now we have a separate API call which removes the sandbox and exposes
> the full file system via PERSISTENT. We provide constants for paths to
> things like application root, sd card and shared directories. Sandboxed
> file systems are rooted in a subdirectory of the application. That approach
> (plus our use of local:/// protocol) has caused some confusion with
> developers.
>
> I think the list of android constants would work well for BB10, perhaps
> with the addition of SHARED. I'm not too familiar with iOS and Android file
> systems. Is there a single directory which contains shared documents,
> music, etc?
>
> Thanks,
> Bryan
>
>
>
> On Tue, Feb 5, 2013 at 11:52 AM, Andrew Grieve 
> wrote:
>
> > FYI - Still looking for feedback here!
> >
> > -- Forwarded message --
> > From: Andrew Grieve (JIRA) 
> > Date: Tue, Feb 5, 2013 at 11:38 AM
> > Subject: [jira] [Commented] (CB-285) Add property returning root path of
> > PhoneGap files
> > To: callback-...@incubator.apache.org
> >
> >
> >
> > [
> >
> >
> https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571437#comment-13571437
> > ]
> >
> > Andrew Grieve commented on CB-285:
> > --
> >
> > I like the idea of switching PERSISTENT to be internal-only. The W3C spec
> > intends this area to be sandboxed to the app, so shouldn't be on the
> > sdcard.
> >
> > I think we need more than just an APP constant though, as there are many
> > places where an app might want to put things.
> >
> > For iOS, You'd minimally want:
> > 1. Application bundle,
> > 2. 
> >
> >
> > The other locations are all subdirectories of , so not
> a
> > big deal if we don't have constants for them
> >
> > For Android, You'd minimally want:
> > 1. Assets directory (seems like a parallel to iOS Application Bundle)
> > 2. Application data on internal storage (/data/data/$PACKAGE_NAME/files)
> > 3. Application cache on internal storage (/data/data/$PACKAGE_NAME/cache)
> > 4. External root: (/sdcard)
> >
> > We could maybe combine #2 and #3 into a single one that gave you
> > /data/data/$PACKAGE_NAME, and document that Android wants files in the
> > "files" and "cache" directories.
> >
> >
> >
> > The Ideal iOS constants:
> >  1. PERSISTENT changes from /Documents -->
> > /Library/CdvPersistentStorage
> >  2. TEMPORARY changes from /tmp -->
> > /tmp/CdvTemporaryStorage
> >  3. APP_ASSETS --> Application bundle
> >  4. APP_DATA --> 
> >
> > The main reason for changing #1 is that iCloud treats Documents directory
> > specially
> > The main reason for adding subdirs under Library/tmp is that it keeps the
> > storage areas separate from the rest of the app (apps that have native
> > components won't interfere with the webview's storage area).
> >
> > The ideal Android constants:
> >  1. PERSISTENT --> /data/data/$PACKAGE_NAME/files/CdvPersistentStorage
> >  2. TEMPORARY --> /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage
> >  3. APP_ASSETS --> assets directory
> >  4. APP_DATA --> /data/data/$PACKAGE_NAME
> >  5. EXTERNAL_APP_DATA --> /sdcard/Android/data/$PACKAGE_NAME
> >  6. EXTERNAL_ROOT --> /sdcard
> >
> >
> > I even think there would be merit in adding more constants (e.g.
> DOCUMENTS,
> > android resources) going forward, but one step at a time...
> >
> >
> > == Transitioning to these new constants ==
> >
> > TEMPORARY:
> > Use the new path right away. No need to transition since the files there
> > are temporary anyways.
> >
> >
> > PERSISTENT (iOS):
> > - If new location directory exists, use that.
> > - Else, if any files exist in the legacy location, use the legacy
> location
> > - Else, use the new path.
> >
> > PERSISTENT (Android):
> > - PERSISTENT is currently /sdcard, so files will always exist :(
> >
> > In both cases, add a PERSISTENT_NEW constant to allow them to move their
> > files over.
> > In Cordova 3.0, change PERSISTENT to be PERSISTENT_NEW, and add
> > PERSISTENT_LEGACY (in case apps have still not switched).
> >
> >
> >
> >
> >
> >
> > Side issue:
> >
> > The spec says PERSISTENT and TEMPORARY are constants on the window object
> > (ugh). So far though

[jira] [Commented] (CB-2226) FileTransfer.abort -- successfully aborting actually calls the error callback. Nothing ever gets called for the success callback.


[ 
https://issues.apache.org/jira/browse/CB-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571567#comment-13571567
 ] 

Andrew Grieve commented on CB-2226:
---

Android's the same story I think.



> FileTransfer.abort -- successfully aborting actually calls the error 
> callback. Nothing ever gets called for the success callback.
> -
>
> Key: CB-2226
> URL: https://issues.apache.org/jira/browse/CB-2226
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
>Priority: Minor
> Fix For: 2.5.0
>
>
> See: 
> https://github.com/apache/cordova-ios/blob/adf226876d03723b89b4e3a9d2e9d0cfa8f2eb07/CordovaLib/Classes/CDVFileTransfer.m#L315
> The mobile spec tests only calls abort with no parameters, thus this problem 
> was never detected.

--
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: Creating repos for core plugins

Before I go ahead with this, let's agree upon the repo names / which
plugins to include.

Here's the proposed list:

Repos to create:

cordova-plugin-accelerometer
cordova-plugin-battery
cordova-plugin-camera
cordova-plugin-capture
cordova-plugin-compass
cordova-plugin-contacts
cordova-plugin-device
cordova-plugin-file
cordova-plugin-geolocation
cordova-plugin-globalization
cordova-plugin-logger
cordova-plugin-media
cordova-plugin-networkstatus
cordova-plugin-notification
cordova-plugin-splashscreen
cordova-plugin-inappbrowser

Note that I have device and network status in this list. Plugins that delay
ondeviceready just add themselves to channel.deviceReadyChannelsArray.

Plugins *not* getting their own Repo:

blackberry/plugin/java/app
android/plugin/android/app
android/plugin/android/storage
errgen/plugin/errgen
ios/plugin/ios/console (seems like this should be merged into the logger
plugin)
windowsphone/plugin/windowsphone/DOMStorage
windowsphone/plugin/windowsphone/XHRPatch
windowsphone/plugin/windowsphone/console
iOS's CDVLocalStorage.m


On Tue, Feb 5, 2013 at 9:34 AM, Andrew Grieve  wrote:

> Great! Sounds like an agreement :). I'll file an INFRA to get them created.
>
>
> On Mon, Feb 4, 2013 at 9:44 PM, Shazron  wrote:
>
>> +1 on separate repos. It's the sane choice.
>>
>>
>> On Mon, Feb 4, 2013 at 11:53 PM, Jesse  wrote:
>>
>> > +1, I agree on the separate repositories.
>> > I still contend that nothing should need to be 'built' and there should
>> be
>> > NO dependencies on the plugins from cordova-js, ( aside from device.js +
>> > network.js which are both required pre device ready, and I think should
>> > remain in the cordova-js repo )
>> >
>> >
>> >
>> > On Mon, Feb 4, 2013 at 2:46 PM, Anis KADRI 
>> wrote:
>> >
>> > > +1 for separate repositories. Should take a bit longer than normal to
>> > > package a release but not too long especially if the repos are pulled
>> > from
>> > > a local source (ie no network overhead).
>> > > I'd be ok to ship a set of default plugins and give the ability for
>> > people
>> > > to build their 'own' Cordova.
>> > >
>> > >
>> > > On Mon, Feb 4, 2013 at 2:11 PM, Brian LeRoux  wrote:
>> > >
>> > > > I'm in favor of discreet plugin repos. It shouldn't effect a release
>> > > > if we automate install/remove and add to the Coho tool... though
>> > > > perhaps this is a naive assumption.
>> > > >
>> > > > On Mon, Feb 4, 2013 at 1:44 PM, Andrew Grieve > >
>> > > > wrote:
>> > > > > Thought it'd be worth having a discussion around whether we want a
>> > > > separate
>> > > > > repo for each core plugin or not.
>> > > > >
>> > > > > As far as I can see, we can either have all core plugins in one
>> repo,
>> > > or
>> > > > > have each in it's own and call them:
>> > > > > cordova-plugin-file
>> > > > > cordova-plugin-network
>> > > > > cordova-plugin-media
>> > > > > etc...
>> > > > >
>> > > > > I think my preference would be to have them as their own repos so
>> > that
>> > > it
>> > > > > will be easier to add/remove lists of plugins to the "which ones
>> are
>> > > > core"
>> > > > > list. It will also let us version them separately (if we want to
>> do
>> > > > this).
>> > > > >
>> > > > > The downside is that it may take longer to perform a release?
>> Would
>> > we
>> > > > even
>> > > > > bundle the plugins with releases anyways though?
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > @purplecabbage
>> > risingj.com
>> >
>>
>
>

[jira] [Commented] (CB-2226) FileTransfer.abort -- successfully aborting actually calls the error callback. Nothing ever gets called for the success callback.

2013-02-05 Thread Shazron Abdullah (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571557#comment-13571557
 ] 

Shazron Abdullah commented on CB-2226:
--

Not sure about a use case, for iOS. Looking at the iOS code, I can't really see 
where the abort can fail (except for the delegate being nil) -- so I think it 
makes sense to remove the callbacks for abort. Not sure about the other 
platforms.

> FileTransfer.abort -- successfully aborting actually calls the error 
> callback. Nothing ever gets called for the success callback.
> -
>
> Key: CB-2226
> URL: https://issues.apache.org/jira/browse/CB-2226
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
>Priority: Minor
> Fix For: 2.5.0
>
>
> See: 
> https://github.com/apache/cordova-ios/blob/adf226876d03723b89b4e3a9d2e9d0cfa8f2eb07/CordovaLib/Classes/CDVFileTransfer.m#L315
> The mobile spec tests only calls abort with no parameters, thus this problem 
> was never detected.

--
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: Adding new LocalFileSystem constants.

2013-02-05 Thread Bryan Higgins

Hi Andrew,

I really like this proposal. It's something we'd likely pick up for
BlackBerry WebWorks.

Right now we have a separate API call which removes the sandbox and exposes
the full file system via PERSISTENT. We provide constants for paths to
things like application root, sd card and shared directories. Sandboxed
file systems are rooted in a subdirectory of the application. That approach
(plus our use of local:/// protocol) has caused some confusion with
developers.

I think the list of android constants would work well for BB10, perhaps
with the addition of SHARED. I'm not too familiar with iOS and Android file
systems. Is there a single directory which contains shared documents,
music, etc?

Thanks,
Bryan



On Tue, Feb 5, 2013 at 11:52 AM, Andrew Grieve  wrote:

> FYI - Still looking for feedback here!
>
> -- Forwarded message --
> From: Andrew Grieve (JIRA) 
> Date: Tue, Feb 5, 2013 at 11:38 AM
> Subject: [jira] [Commented] (CB-285) Add property returning root path of
> PhoneGap files
> To: callback-...@incubator.apache.org
>
>
>
> [
>
> https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571437#comment-13571437
> ]
>
> Andrew Grieve commented on CB-285:
> --
>
> I like the idea of switching PERSISTENT to be internal-only. The W3C spec
> intends this area to be sandboxed to the app, so shouldn't be on the
> sdcard.
>
> I think we need more than just an APP constant though, as there are many
> places where an app might want to put things.
>
> For iOS, You'd minimally want:
> 1. Application bundle,
> 2. 
>
>
> The other locations are all subdirectories of , so not a
> big deal if we don't have constants for them
>
> For Android, You'd minimally want:
> 1. Assets directory (seems like a parallel to iOS Application Bundle)
> 2. Application data on internal storage (/data/data/$PACKAGE_NAME/files)
> 3. Application cache on internal storage (/data/data/$PACKAGE_NAME/cache)
> 4. External root: (/sdcard)
>
> We could maybe combine #2 and #3 into a single one that gave you
> /data/data/$PACKAGE_NAME, and document that Android wants files in the
> "files" and "cache" directories.
>
>
>
> The Ideal iOS constants:
>  1. PERSISTENT changes from /Documents -->
> /Library/CdvPersistentStorage
>  2. TEMPORARY changes from /tmp -->
> /tmp/CdvTemporaryStorage
>  3. APP_ASSETS --> Application bundle
>  4. APP_DATA --> 
>
> The main reason for changing #1 is that iCloud treats Documents directory
> specially
> The main reason for adding subdirs under Library/tmp is that it keeps the
> storage areas separate from the rest of the app (apps that have native
> components won't interfere with the webview's storage area).
>
> The ideal Android constants:
>  1. PERSISTENT --> /data/data/$PACKAGE_NAME/files/CdvPersistentStorage
>  2. TEMPORARY --> /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage
>  3. APP_ASSETS --> assets directory
>  4. APP_DATA --> /data/data/$PACKAGE_NAME
>  5. EXTERNAL_APP_DATA --> /sdcard/Android/data/$PACKAGE_NAME
>  6. EXTERNAL_ROOT --> /sdcard
>
>
> I even think there would be merit in adding more constants (e.g. DOCUMENTS,
> android resources) going forward, but one step at a time...
>
>
> == Transitioning to these new constants ==
>
> TEMPORARY:
> Use the new path right away. No need to transition since the files there
> are temporary anyways.
>
>
> PERSISTENT (iOS):
> - If new location directory exists, use that.
> - Else, if any files exist in the legacy location, use the legacy location
> - Else, use the new path.
>
> PERSISTENT (Android):
> - PERSISTENT is currently /sdcard, so files will always exist :(
>
> In both cases, add a PERSISTENT_NEW constant to allow them to move their
> files over.
> In Cordova 3.0, change PERSISTENT to be PERSISTENT_NEW, and add
> PERSISTENT_LEGACY (in case apps have still not switched).
>
>
>
>
>
>
> Side issue:
>
> The spec says PERSISTENT and TEMPORARY are constants on the window object
> (ugh). So far though, Cordova has exposed them not as globals, but instead
> as LocalFileSystem.PERSISTENT and LocalFileSystem.TEMPORARY. I like the
> idea of exposing them on LocalFileSystem, but we should also put PERSISTENT
> and TEMPORARY on the window.
>
>
>
>
>
>
>
> > Add property returning root path of PhoneGap files
> > --
> >
> > Key: CB-285
> > URL: https://issues.apache.org/jira/browse/CB-285
> > Project: Apache Cordova
> >  Issue Type: Improvement
> >  Components: CordovaJS
> >Affects Versions: 1.4.0
> > Environment: Both PhoneGap SDK and PhoneGap Build
> >Reporter: Ashley Gullen
> >Assignee: Andrew Grieve
> >  Labels: features
> >
> > There needs to be a property in PhoneGap that returns the root path to
> the general files added to the PhoneGap project (i.e. the directory
>

[jira] [Comment Edited] (CB-285) Add property returning root path of PhoneGap files

[
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571437#comment-13571437
]

Andrew Grieve edited comment on CB-285 at 2/5/13 4:54 PM:
--

I like the idea of switching PERSISTENT to be internal-only. The W3C spec
intends this area to be sandboxed to the app, so shouldn't be on the sdcard.

I think we need more than just an APP constant though, as there are many places
where an app might want to put things.

For iOS, You'd minimally want:
1. Application bundle,
2.

The other locations are all subdirectories of , so not a big
deal if we don't have constants for them

For Android, You'd minimally want:
1. Assets directory (seems like a parallel to iOS Application Bundle)
2. Application data on internal storage (/data/data/$PACKAGE_NAME/files)
3. Application cache on internal storage (/data/data/$PACKAGE_NAME/cache)
4. External root: (/sdcard)

We could maybe combine #2 and #3 into a single one that gave you
/data/data/$PACKAGE_NAME, and document that Android wants files in the "files"
and "cache" directories.

The Ideal iOS constants:
1. PERSISTENT changes from /Documents -->
/Library/CdvPersistentStorage
2. TEMPORARY changes from /tmp -->
/tmp/CdvTemporaryStorage
3. APP_ASSETS --> Application bundle
4. APP_DATA -->

The main reason for changing #1 is that iCloud treats Documents directory
specially
The main reason for adding subdirs under Library/tmp is that it keeps the
storage areas separate from the rest of the app (apps that have native
components won't interfere with the webview's storage area).

The ideal Android constants:
1. PERSISTENT --> /data/data/$PACKAGE_NAME/files/CdvPersistentStorage
2. TEMPORARY --> /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage
3. APP_ASSETS --> assets directory
4. APP_DATA --> /data/data/$PACKAGE_NAME
5. EXTERNAL_APP_DATA --> /sdcard/Android/data/$PACKAGE_NAME
6. EXTERNAL_ROOT --> /sdcard

I even think there would be merit in adding more constants (e.g. DOCUMENTS,
android resources) going forward, but one step at a time...

== Transitioning to these new constants ==

TEMPORARY:
Use the new path right away. No need to transition since the files there are
temporary anyways.

PERSISTENT (iOS):
- If new location directory exists, use that.
- Else, if any files exist in the legacy location, use the legacy location
- Else, use the new path.

PERSISTENT (Android):
- PERSISTENT is currently /sdcard, so files will always exist :(
- Is there a way to detect new installs so that we can switch over for new
installs at least?

In both cases, add a PERSISTENT_NEW constant to allow them to move their files
over.
In Cordova 3.0, change PERSISTENT to be PERSISTENT_NEW, and add
PERSISTENT_LEGACY (in case apps have still not switched).

Side issue:

The spec says PERSISTENT and TEMPORARY are constants on the window object
(ugh). So far though, Cordova has exposed them not as globals, but instead as
LocalFileSystem.PERSISTENT and LocalFileSystem.TEMPORARY. I like the idea of
exposing them on LocalFileSystem, but we should also put PERSISTENT and
TEMPORARY on the window.

was (Author: agrieve):
I like the idea of switching PERSISTENT to be internal-only. The W3C spec
intends this area to be sandboxed to the app, so shouldn't be on the sdcard.

I think we need more than just an APP constant though, as there are many places
where an app might want to put things.

For iOS, You'd minimally want:
1. Application bundle,
2.

The other locations are all subdirectories of , so not a big
deal if we don't have constants for them

We could maybe combine #2 and #3 into a single one that gave you
/data/data/$PACKAGE_NAME, and document that Android wants files in the "files"
and "cache" directories.

Adding new LocalFileSystem constants.

FYI - Still looking for feedback here!

-- Forwarded message --
From: Andrew Grieve (JIRA) 
Date: Tue, Feb 5, 2013 at 11:38 AM
Subject: [jira] [Commented] (CB-285) Add property returning root path of
PhoneGap files
To: callback-...@incubator.apache.org

[
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571437#comment-13571437]

Andrew Grieve commented on CB-285:
--

I like the idea of switching PERSISTENT to be internal-only. The W3C spec
intends this area to be sandboxed to the app, so shouldn't be on the sdcard.

I think we need more than just an APP constant though, as there are many
places where an app might want to put things.

For iOS, You'd minimally want:
1. Application bundle,
2. 

The other locations are all subdirectories of , so not a
big deal if we don't have constants for them

For Android, You'd minimally want:
1. Assets directory (seems like a parallel to iOS Application Bundle)
2. Application data on internal storage (/data/data/$PACKAGE_NAME/files)
3. Application cache on internal storage (/data/data/$PACKAGE_NAME/cache)
4. External root: (/sdcard)

We could maybe combine #2 and #3 into a single one that gave you
/data/data/$PACKAGE_NAME, and document that Android wants files in the
"files" and "cache" directories.

The Ideal iOS constants:
 1. PERSISTENT changes from /Documents -->
/Library/CdvPersistentStorage
 2. TEMPORARY changes from /tmp -->
/tmp/CdvTemporaryStorage
 3. APP_ASSETS --> Application bundle
 4. APP_DATA --> 

The main reason for changing #1 is that iCloud treats Documents directory
specially
The main reason for adding subdirs under Library/tmp is that it keeps the
storage areas separate from the rest of the app (apps that have native
components won't interfere with the webview's storage area).

The ideal Android constants:
 1. PERSISTENT --> /data/data/$PACKAGE_NAME/files/CdvPersistentStorage
 2. TEMPORARY --> /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage
 3. APP_ASSETS --> assets directory
 4. APP_DATA --> /data/data/$PACKAGE_NAME
 5. EXTERNAL_APP_DATA --> /sdcard/Android/data/$PACKAGE_NAME
 6. EXTERNAL_ROOT --> /sdcard

I even think there would be merit in adding more constants (e.g. DOCUMENTS,
android resources) going forward, but one step at a time...

== Transitioning to these new constants ==

TEMPORARY:
Use the new path right away. No need to transition since the files there
are temporary anyways.

PERSISTENT (iOS):
- If new location directory exists, use that.
- Else, if any files exist in the legacy location, use the legacy location
- Else, use the new path.

PERSISTENT (Android):
- PERSISTENT is currently /sdcard, so files will always exist :(

In both cases, add a PERSISTENT_NEW constant to allow them to move their
files over.
In Cordova 3.0, change PERSISTENT to be PERSISTENT_NEW, and add
PERSISTENT_LEGACY (in case apps have still not switched).

Side issue:

The spec says PERSISTENT and TEMPORARY are constants on the window object
(ugh). So far though, Cordova has exposed them not as globals, but instead
as LocalFileSystem.PERSISTENT and LocalFileSystem.TEMPORARY. I like the
idea of exposing them on LocalFileSystem, but we should also put PERSISTENT
and TEMPORARY on the window.

> Add property returning root path of PhoneGap files
> --
>
> Key: CB-285
> URL: https://issues.apache.org/jira/browse/CB-285
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: CordovaJS
>Affects Versions: 1.4.0
> Environment: Both PhoneGap SDK and PhoneGap Build
>Reporter: Ashley Gullen
>Assignee: Andrew Grieve
>  Labels: features
>
> There needs to be a property in PhoneGap that returns the root path to
the general files added to the PhoneGap project (i.e. the directory
index.html is in).  For example, if I add 'music.mp3' to my project, in
Android it will be located in:
> /android_asset/www/music.mp3
> On iOS after being built with PhoneGap Build it will be located in some
path like this:
> /var/mobile/Applications//.app/www/music.mp3
> However, there does not appear to be a programmatic way to determine both
 and .app.
> This has two side effects:
> 1. Paths to audio for Media must be hard-coded separately depending on
the platform, which is inconvenient.
> 2. Paths to audio for Media cannot be known if developing a framework
that uses PhoneGap.  Since a framework does not know the App ID or name in
advance, it's impossible for the framework to determine the correct path.
> This is actively blocking audio from working on iOS in PhoneGap projects
exported by Construct 2 (www.scirra.com), a HTML5 game creator.  Also, it
seems like kind of an important function to make available anyway, since
hard-coding paths for each platform is a pain.
> This PhoneGa

[jira] [Resolved] (CB-2374) Tag Docs

2013-02-05 Thread Michael Brooks (JIRA)


 [ 
https://issues.apache.org/jira/browse/CB-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Brooks resolved CB-2374.


Resolution: Fixed

> Tag Docs
> 
>
> Key: CB-2374
> URL: https://issues.apache.org/jira/browse/CB-2374
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs
>Reporter: Filip Maj
>Assignee: Michael Brooks
> Fix For: 2.4.0
>
>
> After all platforms have been tagged, the docs can be tagged.

--
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-2374) Tag Docs

2013-02-05 Thread Michael Brooks (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571450#comment-13571450
 ] 

Michael Brooks commented on CB-2374:


Tag 2.4.0 as commit 
[8778e5|https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=8778e583a9e9febfe4c1672a0243628a44d564dc]

> Tag Docs
> 
>
> Key: CB-2374
> URL: https://issues.apache.org/jira/browse/CB-2374
> Project: Apache Cordova
>  Issue Type: Sub-task
>  Components: Docs
>Reporter: Filip Maj
>Assignee: Michael Brooks
> Fix For: 2.4.0
>
>
> After all platforms have been tagged, the docs can be tagged.

--
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-285) Add property returning root path of PhoneGap files


[ 
https://issues.apache.org/jira/browse/CB-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571437#comment-13571437
 ] 

Andrew Grieve commented on CB-285:
--

I like the idea of switching PERSISTENT to be internal-only. The W3C spec 
intends this area to be sandboxed to the app, so shouldn't be on the sdcard.

I think we need more than just an APP constant though, as there are many places 
where an app might want to put things.

For iOS, You'd minimally want:
1. Application bundle,
2. 


The other locations are all subdirectories of , so not a big 
deal if we don't have constants for them

For Android, You'd minimally want:
1. Assets directory (seems like a parallel to iOS Application Bundle)
2. Application data on internal storage (/data/data/$PACKAGE_NAME/files)
3. Application cache on internal storage (/data/data/$PACKAGE_NAME/cache)
4. External root: (/sdcard)

We could maybe combine #2 and #3 into a single one that gave you 
/data/data/$PACKAGE_NAME, and document that Android wants files in the "files" 
and "cache" directories.



The Ideal iOS constants:
 1. PERSISTENT changes from /Documents --> 
/Library/CdvPersistentStorage
 2. TEMPORARY changes from /tmp --> 
/tmp/CdvTemporaryStorage
 3. APP_ASSETS --> Application bundle
 4. APP_DATA --> 

The main reason for changing #1 is that iCloud treats Documents directory 
specially
The main reason for adding subdirs under Library/tmp is that it keeps the 
storage areas separate from the rest of the app (apps that have native 
components won't interfere with the webview's storage area).

The ideal Android constants:
 1. PERSISTENT --> /data/data/$PACKAGE_NAME/files/CdvPersistentStorage
 2. TEMPORARY --> /data/data/$PACKAGE_NAME/cache/CdvTemporaryStorage
 3. APP_ASSETS --> assets directory
 4. APP_DATA --> /data/data/$PACKAGE_NAME
 5. EXTERNAL_APP_DATA --> /sdcard/Android/data/$PACKAGE_NAME
 6. EXTERNAL_ROOT --> /sdcard


I even think there would be merit in adding more constants (e.g. DOCUMENTS, 
android resources) going forward, but one step at a time...


== Transitioning to these new constants ==

TEMPORARY: 
Use the new path right away. No need to transition since the files there are 
temporary anyways.


PERSISTENT (iOS):
- If new location directory exists, use that.
- Else, if any files exist in the legacy location, use the legacy location
- Else, use the new path.

PERSISTENT (Android):
- PERSISTENT is currently /sdcard, so files will always exist :(

In both cases, add a PERSISTENT_NEW constant to allow them to move their files 
over.
In Cordova 3.0, change PERSISTENT to be PERSISTENT_NEW, and add 
PERSISTENT_LEGACY (in case apps have still not switched).






Side issue:

The spec says PERSISTENT and TEMPORARY are constants on the window object 
(ugh). So far though, Cordova has exposed them not as globals, but instead as 
LocalFileSystem.PERSISTENT and LocalFileSystem.TEMPORARY. I like the idea of 
exposing them on LocalFileSystem, but we should also put PERSISTENT and 
TEMPORARY on the window.







> Add property returning root path of PhoneGap files
> --
>
> Key: CB-285
> URL: https://issues.apache.org/jira/browse/CB-285
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: CordovaJS
>Affects Versions: 1.4.0
> Environment: Both PhoneGap SDK and PhoneGap Build
>Reporter: Ashley Gullen
>Assignee: Andrew Grieve
>  Labels: features
>
> There needs to be a property in PhoneGap that returns the root path to the 
> general files added to the PhoneGap project (i.e. the directory index.html is 
> in).  For example, if I add 'music.mp3' to my project, in Android it will be 
> located in:
> /android_asset/www/music.mp3
> On iOS after being built with PhoneGap Build it will be located in some path 
> like this:
> /var/mobile/Applications//.app/www/music.mp3
> However, there does not appear to be a programmatic way to determine both 
>  and .app.
> This has two side effects:
> 1. Paths to audio for Media must be hard-coded separately depending on the 
> platform, which is inconvenient.
> 2. Paths to audio for Media cannot be known if developing a framework that 
> uses PhoneGap.  Since a framework does not know the App ID or name in 
> advance, it's impossible for the framework to determine the correct path.
> This is actively blocking audio from working on iOS in PhoneGap projects 
> exported by Construct 2 (www.scirra.com), a HTML5 game creator.  Also, it 
> seems like kind of an important function to make available anyway, since 
> hard-coding paths for each platform is a pain.
> This PhoneGap Support thread led to this issue: 
> http://phonegap.tenderapp.com/discussions/questions/208-android_asset-equivalent-for-ios

--
This message is automatically generated by JIRA.
If you think it wa

Re: a Cordova Jake Error ?

2013-02-05 Thread Plaquette, Paul

sounds the culprit might be a line in the jakefile:
 "lib/firefoxos/plugin/firefoxos/Device.js":/(this\.cordova\s=\s").+(")/,

in place of:
 "lib/firefoxos/plugin/firefoxos/device.js":/(this\.cordova\s=\s").+(")/,

hope this helps !


On Tue, Feb 5, 2013 at 4:45 PM, Plaquette, Paul wrote:

> Hi all,
>
> I get a fresh Cordova repository and by the way I also updated node on my
> ubuntu 12.04 laptop.
>
> When I build using command line jake  I got this:
>
> 
>
> jake aborted.
> Error: ENOENT, no such file or directory
> 'lib/firefoxos/plugin/firefoxos/Device.js'
> at Object.openSync (fs.js:230:18)
> (See full trace by running task with --trace)
>
> the build succeed if the device.js file in firefoxos is renamed as
> Device.js
>
> Does someone see what is going wrong?
> (Actually I wonder if it is an issue on may machine or not)
>
> Cordially,
> Paul
>
>
> --
> 
>
> Paul Plaquette,
> Senior Software Engineer
> Intel Corporation SAS
> Open source Technology Center - OTC
> France, Montpellier
>
>


-- 


Paul Plaquette,
Senior Software Engineer
Intel Corporation SAS
Open source Technology Center - OTC
France, Montpellier

a Cordova Jake Error ?

2013-02-05 Thread Plaquette, Paul

Hi all,

I get a fresh Cordova repository and by the way I also updated node on my
ubuntu 12.04 laptop.

When I build using command line jake  I got this:



jake aborted.
Error: ENOENT, no such file or directory
'lib/firefoxos/plugin/firefoxos/Device.js'
at Object.openSync (fs.js:230:18)
(See full trace by running task with --trace)

the build succeed if the device.js file in firefoxos is renamed as Device.js

Does someone see what is going wrong?
(Actually I wonder if it is an issue on may machine or not)

Cordially,
Paul


-- 


Paul Plaquette,
Senior Software Engineer
Intel Corporation SAS
Open source Technology Center - OTC
France, Montpellier

[jira] [Resolved] (CB-1701) FileTransfer response UTF-8 Bug


 [ 
https://issues.apache.org/jira/browse/CB-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Grieve resolved CB-1701.
---

Resolution: Fixed

Assuming this is fixed. Please re-open if problem still occurs on Cordova 2.2 
or greater

> FileTransfer response UTF-8 Bug 
> 
>
> Key: CB-1701
> URL: https://issues.apache.org/jira/browse/CB-1701
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.1.0
> Environment: Android, Eclipse
>Reporter: Paul Poirel
>Assignee: Andrew Grieve
>Priority: Minor
>
> I am using the FileTransfer API to upload a picture to a .ashx service (.NET).
> Everything is fine, except that the response (FileUploadResult.response) is 
> not correctly encoded. It appears like a UTF8 string encoded as ISO.
> Here are the logs from Eclipse debug console (LogCat) :
> 10-23 00:21:39.580: D/FileTransfer(24513): upload 
> file:///mnt/sdcard/AgoraStockPictures/740aze1350954367223.jpg to 
> http://*/upload-photo.ashx
> 10-23 00:21:39.580: D/FileTransfer(24513): fileKey: fileData
> 10-23 00:21:39.580: D/FileTransfer(24513): fileName: 740aze1350954367223.jpg
> 10-23 00:21:39.580: D/FileTransfer(24513): mimeType: image/jpeg
> 10-23 00:21:39.580: D/FileTransfer(24513): params: 
> {"lastPicture":true,"idproduit":"teststock2224388212","token":"9876543","login":"teststock"}
> 10-23 00:21:39.580: D/FileTransfer(24513): trustEveryone: false
> 10-23 00:21:39.580: D/FileTransfer(24513): chunkedMode: true
> 10-23 00:21:39.580: D/FileTransfer(24513): headers: null
> 10-23 00:21:39.580: D/FileTransfer(24513): String Length: 424
> 10-23 00:21:39.580: D/FileTransfer(24513): Content Length: 91341
> 10-23 00:21:40.910: D/FileTransfer(24513): got response from server
> 10-23 00:21:40.910: D/FileTransfer(24513): 
> [{"data":{},"errors":{"etat":"-93","libelle":"L\u0027image existe dÃ©jÃ ."}}]
> 10-23 00:21:40.910: D/FileTransfer(24513): ** About to return a result 
> from upload
> And the result (in an alert or in console.log) is :  
> {"etat":"-93","libelle":"L'image existe dÃ©jÃ ."}
> The expected result is :  {"etat":"-93","libelle":"L'image existe déjà ."}
> When I test the server whith a html form on chrome, I get the correct result.
> Plus, the result looks like UTF8 displayed as ISO, so I believe that the 
> server is sending the UTF8 encoded response, and that it is a client-side 
> issue.
> Here are the HTTP headers from the response :
> HTTP/1.1 200 OK
> Cache-Control: private 
> Content-Length: 197
> Content-Type: text/plain; charset=UTF-8
> Content-Encoding: gzip
> Server: Microsoft-IIS/7.5
> X-AspNet-Version: 2.0.50727
> Accepts-Encoding: gzip
> Access-Control-Allow-Origin: *
> X-Powered-By: ASP.NET
> Date: Tue, 23 Oct 2012 10:28:33 GMT
> Note : this might be related to the issue #CB-920, which was about the POST 
> params encoding.

--
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-2293) File Transfer of picture fails on every other picture


[ 
https://issues.apache.org/jira/browse/CB-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571369#comment-13571369
 ] 

Andrew Grieve commented on CB-2293:
---

According to this post:
http://android-developers.blogspot.ca/2011/09/androids-http-clients.html

This bug is supposed to be fixed in Android 2.2. I guess some vendor versions 
still have the bug though :(.

One solution is to switch to HttpClient, another is to figure out which phones 
to disable connection: keep-alive for. Or maybe the problem is that we're 
explicitly setting the keep-alive header in FileTransfer.

Amrit, are you able to play around and see if just removing the explicit 
setting of the header works? Or maybe removing our call to InputStream.close()?

> File Transfer of picture fails on every other picture
> -
>
> Key: CB-2293
> URL: https://issues.apache.org/jira/browse/CB-2293
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0, 2.3.0
> Environment: Tested on a Motorola Atrix HD(Android 4.1.2) as well as 
> a Samsung Galaxy S3(Android 4.1.1)
>Reporter: Amrit Kahlon
>Assignee: Andrew Grieve
> Attachments: cordova-2.4.0rc1.jar
>
>
> When uploading pictures using the File Transfer function on android, the 
> first picture will upload fine. Then the second upload will give the 
> following error:
> 01-21 13:48:02.545: W/FileTransfer(8894): Error getting HTTP status code from 
> connection.
> 01-21 13:48:02.545: W/FileTransfer(8894): java.io.EOFException
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.io.Streams.readAsciiLine(Streams.java:203)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponseHeaders(HttpEngine.java:560)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpEngine.readResponse(HttpEngine.java:813)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:274)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> libcore.net.http.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:486)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.createFileTransferError(FileTransfer.java:535)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer.access$500(FileTransfer.java:62)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:437)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.545: W/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): 
> {"target":"http:\/\/xxx.xxx.xxx\/api\/photo_uploads\/create?version=2&api_key=x&source=androidapp-2.2.1","source":"file:\/\/\/storage\/sdcard0\/Android\/data\/com.hockeycommunity.hc_app\/cache\/resize.jpg?1358804880392","code":3}
> 01-21 13:48:02.555: E/FileTransfer(8894): java.net.SocketException: sendto 
> failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.maybeThrowAfterSendto(IoBridge.java:506)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.IoBridge.sendto(IoBridge.java:475)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.write(PlainSocketImpl.java:508)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl.access$100(PlainSocketImpl.java:46)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.net.PlainSocketImpl$PlainSocketOutputStream.write(PlainSocketImpl.java:270)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.net.http.FixedLengthOutputStream.write(FixedLengthOutputStream.java:41)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.io.DataOutputStream.write(DataOutputStream.java:98)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> org.apache.cordova.FileTransfer$1.run(FileTransfer.java:372)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> java.lang.Thread.run(Thread.java:856)
> 01-21 13:48:02.555: E/FileTransfer(8894): Caused by: 
> libcore.io.ErrnoException: sendto failed: EPIPE (Broken pipe)
> 01-21 13:48:02.555: E/FileTransfer(8894): at 
> libcore.io.Posix.sendtoBytes(Native Me

[jira] [Commented] (CB-2226) FileTransfer.abort -- successfully aborting actually calls the error callback. Nothing ever gets called for the success callback.


[ 
https://issues.apache.org/jira/browse/CB-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571359#comment-13571359
 ] 

Andrew Grieve commented on CB-2226:
---

What's is the suggested fix? Is there a use-case for having abort callbacks? 
maybe we should just delete the callbacks.

> FileTransfer.abort -- successfully aborting actually calls the error 
> callback. Nothing ever gets called for the success callback.
> -
>
> Key: CB-2226
> URL: https://issues.apache.org/jira/browse/CB-2226
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
>Priority: Minor
> Fix For: 2.5.0
>
>
> See: 
> https://github.com/apache/cordova-ios/blob/adf226876d03723b89b4e3a9d2e9d0cfa8f2eb07/CordovaLib/Classes/CDVFileTransfer.m#L315
> The mobile spec tests only calls abort with no parameters, thus this problem 
> was never detected.

--
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: Creating repos for core plugins