Re: Where did we announce deprecation of 2.1 and 3.x?

[Brian LeRoux]

We did not though if we do, we I believe we had consensus on doing, it
should go here:

http://wiki.apache.org/cordova/DeprecationPolicy

And you should shoot a quick email to the Google Group explaining that this
is for 2.3 and greater.




On Sat, Nov 10, 2012 at 6:57 AM, Joe Bowser  wrote:

> Hey
>
> Where did we announce the upcoming deprecation of Eclair and
> Honeycomb? I'm wondering because I remember that we decided to
> deprecate these platforms, but I don't know if we actually told people
> that.
>
> Joe
>

Re: [docs] OS version supported with a Cordova version

[Brian LeRoux]

was trying to think through the exact issue to file here and I'm wondering
if we want another guide titled 'Before you start' or just ensure there is
a 'Minimum Requirements' section in each getting started guideI'm
leaning towards the latter though if we go w/ the former we can give more
general setup advice.

Thoughts?


On Sat, Nov 10, 2012 at 9:55 PM, Brian LeRoux  wrote:

> yep
>
>
> On Thu, Nov 8, 2012 at 9:52 AM, Shazron  wrote:
>
>> Can we swipe that table for Cordova?
>>
>>
>> On Thu, Nov 8, 2012 at 3:58 AM, Brian LeRoux  wrote:
>>
>> > Yup this is a very good idea. We sorta have this on the phonegap dist
>> here
>> > http://phonegap.com/about/feature
>> >
>> >
>> > On Wed, Nov 7, 2012 at 11:51 AM, Filip Maj  wrote:
>> >
>> > > Good idea.
>> > >
>> > > Also: all requirements for a platform implementation should be clearly
>> > > specified at the top of the platform's README. Ant, node, OS versions,
>> > etc.
>> > >
>> > > On 11/7/12 11:29 AM, "Shazron"  wrote:
>> > >
>> > > >I noticed that we don't have anything in the docs regarding a Cordova
>> > > >version's support for an OS version. For example, Cordova 2.3.0 will
>> > > >support iOS 5+ only, there is nowhere in the docs that we can reflect
>> > > >this.
>> > > >
>> > > >I suppose it can be in the Getting Started Guide requirements but
>> > perhaps
>> > > >a
>> > > >new section will be clearer. Objections on adding a new section? I
>> can
>> > add
>> > > >the jira tasks.
>> > >
>> > >
>> >
>>
>
>

[jira] [Commented] (CB-1695) [iOS]: CDVURLProtocol should not apply whitelist to non-Cordova view controllers/requests

[Andrew Grieve (JIRA)]

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

Andrew Grieve commented on CB-1695:
---

Here's some confirmation that the User-Agent idea will work :)
http://stackoverflow.com/questions/12180224/unique-tab-id-appended-to-user-agent-string-in-chrome-for-ios

I was concerned about not being able to append to the UA, but I think what we 
can do is leave the main Cordova UIWebView's UA untouched, and then scrape the 
UA from it. 

> [iOS]: CDVURLProtocol should not apply whitelist to non-Cordova view 
> controllers/requests
> -
>
> Key: CB-1695
> URL: https://issues.apache.org/jira/browse/CB-1695
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 2.2.0
> Environment: Xcode 4.5 / OS X 10.7.5 (Lion) / Commit 
> ef67dcf7bce56c69299bb89ab16c1803d0edd895
>Reporter: Kevin Hawkins
>Assignee: Shazron Abdullah
> Fix For: 2.3.0
>
>
> Registered NSURLProtocol objects respond to NSURLRequests across an 
> application.  As such, CDVURLProtocol handles all requests that would pass 
> through any UIWebView in the application, and applies Cordova's whitelist 
> rules accordingly to each http(s) request.
> This is an unreasonable overreach of authority, in an app where Cordova is 
> only one component of the app.  Consider the case where I have my own 
> UIWebView (think ChildBrowser), and I want to load arbitrary web content.  
> This web content has no access to the Cordova sandbox on the device, and as 
> such should not be subject to the security restrictions that limit requests 
> to whitelisted/trusted hosts.
> The logic in [CDVURLProtocol canInitWithRequest:] that validates the view 
> controller against the global CDVViewController registry, for /!gap_exec 
> calls, should be extended to make the same check against http(s) calls, and 
> allow them without whitelist comparison for requests that originate outside 
> of any registered CDVViewController instances.

--
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: InAppBrowser api questions

[Andrew Grieve]

On Mon, Nov 12, 2012 at 2:11 PM, Shazron  wrote:

> Bump. These questions below still need some discussion and consensus before
> the InAppBrowser implementation can be complete.
>
>
> On Fri, Nov 9, 2012 at 9:43 AM, Shazron  wrote:
>
> > WIki page: http://wiki.apache.org/cordova/InAppBrowser
> > Some questions brought up by Jesse in JIRA (replicated below):
> > http://goo.gl/cZe84
> >
> > 
> > Jesse MacFadyen:
> >
> > I have some open questions about the wiki defined 'spec'
> >
> > 1. window.open('http://random-url.com', '_self'); // loads in
> InAppBrowser
> > so even though the random-url is not whitelisted, it is permitted to
> > load within the application, inside the InAppBrowser. This is currently
> not
> > trivial on iOS.
>
>
> > 2. How can I open a whitelisted url in the native browser? ie. mobile
> > safari
> > there is no clear path to targeting ALL 3 possibilities or a)the app
> > page, b) the InAppBrowser, c) the system browser ( for a whitelisted URL
> )
> > it makes sense that you cannot open a file:// url in the system
> > browser + you cannot open a non-whitelisted url in the app.
> >
> > 
> >
> > My comments:
> >
> > 1. This as Jesse points out, is not trivial on iOS. The "easy way" would
> > be to not allow this, but kick it out to the system browser (Mobile
> > Safari), and have that as a general rule, any non-whitelisted URLs for
> the
> > InAppBrowser are kicked out to the system browser. I don't know how hard
> it
> > is for Android.
> >
> > If we were to do this, we would have to temporarily allow the url to
> > bypass the whitelist which could be kludgy (since we can't know what
> other
> > URLs that URL will load) -- essentially this issue
> > http://issues.cordova.io/1695 would totally solve this correctly, but we
> > don't have a solution yet for that issue.
>

I spent some time playing with how to do this.
1 - Use referer header - Too many situations result in no header, so this
is out!
2 - Use Cookies - if there were a way to have UIWebViews use separate
cookie jars, this might be feasible. Don't think that's possible.
3 - Use User-Agent - this is already suggested in CB-1695. I also found
this:
http://stackoverflow.com/questions/12180224/unique-tab-id-appended-to-user-agent-string-in-chrome-for-ios,
which suggests that this is what Chrome for iOS uses to implement incognito
mode. If they can make it work, then we should be able to as well!

So, this is looking like it's non-trivial but not impossible! As long as
it's possible, let's implement it :)


>  >
> > 2. This case has not been addressed. I would think _blank would be the
> > case but this is specified as the InAppBrowser here. How about this case,
> > we could use _parent for InAppBrowser, but _blank for system browser?
> > However, this would not be consistent with how the other calls are
> > specified (unless we change the others to be consistent).
> >
> > Another possible solution is to kick out to the system browser if an
> > unknown value is used (some random value), that will use the system
> > browser, which is consistent with how window.open works.
> >
>

I don't think the semantics of _parent and _blank really map well to what
we're doing. My vote is to create a new special value: _system, and only
this target kicks you out to the system browser.

Also: on the wiki we have:
[F]  window.open('http://random-url.com', '_blank'); // native browser

It seems weird to me that the effect of _blank changes based on whether the
URL is in the whitelist. I'd think this case would also open in the
InAppBrowser.


Summary of what I think:
_self or no target --> open in cordova webview if it's in the Whitelist,
InAppBrowser otherwise
_system --> open in system browser
anything else --> open in InAppBrowser

Also, I like Simon's idea of using the options in window.open to specify
whether to show URL bar etc. :)

Re: iOS' device API

[Brian LeRoux]

thanks shaz


On Tue, Nov 13, 2012 at 6:39 AM, Shazron  wrote:

> Added:
>
> http://issues.cordova.io/1836
> http://issues.cordova.io/1837
> http://issues.cordova.io/1838
> http://issues.cordova.io/1839
> http://issues.cordova.io/1840
>
>
>
> On Mon, Nov 12, 2012 at 11:14 AM, Shazron  wrote:
>
> > Adding jira tasks as per Brian's last comment.
> >
> >
> > On Thu, Nov 8, 2012 at 9:52 AM, Shazron  wrote:
> >
> >> +1 sounds like a plan
> >>
> >>
> >> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj  wrote:
> >>
> >>> +1
> >>>
> >>> On 11/8/12 4:01 AM, "Brian LeRoux"  wrote:
> >>>
> >>> >I think would it make sense to:
> >>> >
> >>> >1. align apis as orig msg from fil suggests
> >>> >2. drop in deprecation notice for sync usage and add to deprec page
> >>> >3. add async equiv and get it out of startup path as andrew suggests
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj  wrote:
> >>> >
> >>> >> Although I think we're close to being able to author cross-platform
> >>> apps
> >>> >> sans UA detection , I think people still have valid use cases to use
> >>> it.
> >>> >>
> >>> >> On 11/7/12 6:18 PM, "Andrew Grieve"  wrote:
> >>> >>
> >>> >> >I like the idea of at least removing this from the start-up path.
> If
> >>> >>users
> >>> >> >want to know about the device, they could always call exec()
> >>> >>themselves.
> >>> >> >
> >>> >> >
> >>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron  wrote:
> >>> >> >
> >>> >> >> Also, if we remove the device API like Brian suggested, it would
> be
> >>> >> >>good in
> >>> >> >> the sense that we won't have to call the CDVDevice plugin to
> >>> populate
> >>> >> >>some
> >>> >> >> js variables before deviceready can fire -- eliminating a
> >>> dependency.
> >>> >> >>
> >>> >> >>
> >>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron 
> >>> wrote:
> >>> >> >>
> >>> >> >> > Agree with Fil to make it consistent - in essence this is an
> iOS
> >>> >>bug
> >>> >> >>:)
> >>> >> >> >
> >>> >> >> > Brian, there is one case I can think of -- detecting the iPad
> >>> >>mini's
> >>> >> >> > features using js - Max Firt investigated trying to do it
> >>> >> >> >
> >>> >> >>
> >>> >> >>
> >>> >>
> >>> >>
> >>>
> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
> >>> >> >>tthe only kludgy way right now using PG would be device.platform
> to
> >>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect
> >>> >>this to
> >>> >> >> > enlarge certain UI elements for the mini (since the physical
> area
> >>> >> >>will be
> >>> >> >> > smaller than a reg sized iPad)
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj 
> >>> wrote:
> >>> >> >> >
> >>> >> >> >> CI implementation is what I am gunning for here (and can
> >>> actually
> >>> >>use
> >>> >> >> it).
> >>> >> >> >>
> >>> >> >> >> I don't like it either but reality is for people building
> >>> >> >>cross-platform
> >>> >> >> >> apps at some point you have to do:
> >>> >> >> >>
> >>> >> >> >> if (device.platform == 'android') // do some stuff
> >>> >> >> >>
> >>> >> >> >> For example, knowing when to attach to a back button vs
> >>> rendering
> >>> >> >>some
> >>> >> >> ui
> >>> >> >> >> to handle that.
> >>> >> >> >>
> >>> >> >> >> IMO we should set up deprecation for "name" and move to
> "model"
> >>> as
> >>> >> >>it's
> >>> >> >> >> clearer (and probably was the reason why iOS went for device's
> >>> >>custom
> >>> >> >> name
> >>> >> >> >> in the first place - semantic confusion :P )
> >>> >> >> >>
> >>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux"  wrote:
> >>> >> >> >>
> >>> >> >> >> >This may get some rotton tomatoes thrown at me but I would be
> >>> in
> >>> >> >>favor
> >>> >> >> of
> >>> >> >> >> >axing these apis altogether. I think they are more dangerous
> >>> than
> >>> >> >> useful
> >>> >> >> >> /
> >>> >> >> >> >developers should favor browser feature detection for their
> UI
> >>> >>work.
> >>> >> >> >> >
> >>> >> >> >> >There is no programmatic reason to want these properties
> >>> >>otherwise
> >>> >> >> that I
> >>> >> >> >> >can think of?
> >>> >> >> >> >
> >>> >> >> >> >(But agree at least should be consistent as Fil suggests.)
> >>> >> >> >> >
> >>> >> >> >> >
> >>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj 
> >>> wrote:
> >>> >> >> >> >
> >>> >> >> >> >> Currently if you ask for device.platform you will get
> several
> >>> >> >> different
> >>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc.
> >>> >>This
> >>> >> >> seems
> >>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
> >>> >> >> >> >>
> >>> >> >> >> >> Related, device.name returns the custom device name as the
> >>> user
> >>> >> >> >> defines
> >>> >> >> >> >>it
> >>> >> >> >> >> in iTunes. IMO it should return the model name, I.e. What
> >>> >> >> >> >>device.platform
> >>> >> >> >> >> returns now.
> >>> >> >> >> >>
> >>> >> >> >> >> This would line it up with our docs + other platforms.
> >>> >> >> >> >>
> >>> >> 

Re: Query regarding Storage Class...

[Andrew Grieve]

Hi Kumail, try a Google search for "phonegap sqllite plugin". Looks like
one already exists.


On Thu, Nov 8, 2012 at 6:50 AM, Kumail Raza  wrote:

>
> Hi!
>
> Dear,
>
> First of all thanks to all the team mate of Apache Cordova Library, thats
> really a great piece of work due to which developer could easily develop
> application over vast platform.
>
> Coming to words my problem,
>
> I want to access SQLiteDatabase file which is located on my SDCARD, but I
> did'nt find any of such example code for that over the Internet, please it
> would be really helpful for me, If you add the section on your website with
> the heading "Accessing SQLiteDB from SDCARD using your API".
>
> If in case this feature not added yet, in the library, I will be waiting
> for this feature to be add as soon as possible.
>
>
> Thanks.
>
> Regards,
> Kumail Raza
> +923343104692
>

[jira] [Resolved] (CB-1841) orientationchange event issues in iOS 4.3

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah resolved CB-1841.
--

Resolution: Not A Problem

Ok,
I managed to run the 4.3 Simulator on OS X Lion 10.7.5 (in a VM), using Cordova 
2.2.0 on Xcode 4.3.3. Aside from some Objective-C issues that I fixed (going 
forward in Cordova 2.3.0 we are dropping iOS 4 support), I managed to verify 
that the orientationchange event is indeed fired.

These are my notes:
1. orientationchange is only fired by us explicitly if iOS < 5 ( >= 5 it is 
built in by iOS)
2. You must add the orientationchange listener before deviceready is fired 
(adding it after does not make it fire, so there might be a bug there)
3. Your viewport meta tag must NOT have the value "height=device-height" value

> orientationchange event issues in iOS 4.3
> -
>
> Key: CB-1841
> URL: https://issues.apache.org/jira/browse/CB-1841
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 2.2.0
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
>
> Going forward, we are not supporting iOS 4.3, but leaving this for the 
> knowledgebase. This is from someone that emailed me:
> The problem is as follows: under 4.3 the orientation/fire orientation event 
> is kind of screwed up (I’m using it with Sencha 2.0 and it works fine on 5.0, 
> 5.1, 6.0).
>  
> Starting the app in Portrait mode will correctly identify it as portrait… 
> when you den flip to either side into landscape mode the orientation change 
> is not fired and the app ‘thinks’ it is still in Portrait. Flip it back the 
> event is fired again as portrait. If you start the application in Landscape 
> mode though everything works fine. Orientations are fired correctly. I am 
> currently partially circumventing the problem with checking the width of the 
> window and see what it shoul be and resize accordingly.. unfortunately that 
> doesn’t help me when there is no orientation event fired and just creating a 
> check every second doesn’t really make sense.
>  
> It looks like as if the webview thinks it is in Landscape during start and 
> doesn’t fire an orientation change event when the pad is actually in Portrait 
> mode. 

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

[jira] [Created] (CB-1841) orientationchange event issues in iOS 4.3

[Shazron Abdullah (JIRA)]

Shazron Abdullah created CB-1841:


 Summary: orientationchange event issues in iOS 4.3
 Key: CB-1841
 URL: https://issues.apache.org/jira/browse/CB-1841
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.2.0
Reporter: Shazron Abdullah
Assignee: Shazron Abdullah


Going forward, we are not supporting iOS 4.3, but leaving this for the 
knowledgebase. This is from someone that emailed me:

The problem is as follows: under 4.3 the orientation/fire orientation event is 
kind of screwed up (I’m using it with Sencha 2.0 and it works fine on 5.0, 5.1, 
6.0).
 
Starting the app in Portrait mode will correctly identify it as portrait… when 
you den flip to either side into landscape mode the orientation change is not 
fired and the app ‘thinks’ it is still in Portrait. Flip it back the event is 
fired again as portrait. If you start the application in Landscape mode though 
everything works fine. Orientations are fired correctly. I am currently 
partially circumventing the problem with checking the width of the window and 
see what it shoul be and resize accordingly.. unfortunately that doesn’t help 
me when there is no orientation event fired and just creating a check every 
second doesn’t really make sense.
 
It looks like as if the webview thinks it is in Landscape during start and 
doesn’t fire an orientation change event when the pad is actually in Portrait 
mode. 

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

[jira] [Resolved] (CB-1699) improve docs and fix typos in coho

[Marcel Kinard (JIRA)]

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

Marcel Kinard resolved CB-1699.
---

Resolution: Fixed

Pull request was merged by Steven a few days ago.

Pull request closed.

> improve docs and fix typos in coho
> --
>
> Key: CB-1699
> URL: https://issues.apache.org/jira/browse/CB-1699
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Coho
>Affects Versions: Master
>Reporter: Marcel Kinard
>Assignee: Marcel Kinard
>Priority: Minor
> Fix For: 2.3.0
>
>
> The docs in coho are extremely sparse. Most of the automated tests fail.

--
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-1185) When Application is placed in background and resumed, the UI is frozen

[Lindsey Simon (JIRA)]

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

Lindsey Simon commented on CB-1185:
---

Unless anyone pings back that they're working on it, I'm going to make a sample 
app this afternoon which just pings a server in the background periodically and 
see if I can repro by leaving it on for a long time.

> When Application is placed in background and resumed, the UI is frozen
> --
>
> Key: CB-1185
> URL: https://issues.apache.org/jira/browse/CB-1185
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.0.0
> Environment: Jelly Bean 4.1, ICS 4.0.x
>Reporter: Greg
>Assignee: Filip Maj
> Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch, 
> 0002-Uncomment.patch, cordova-2.0.0.jar, issues.zip
>
>
> When using PhoneGap 2.0.0 on ICS or JellyBean, the application freezes up 
> after you set the app to the background or turn of the screen. After around 
> 3-7 seconds, the application unfreezes and pretty much causes a panic and 
> usually crashes. No error reports have been submitted.
> Here is how you re-produce the issue:
> 1. Download Untappd - 
> V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app)
> 2. After logging in stay on the Friends tab
> 3. Turn the the screen off and wait about 3-7 minutes
> 4. Turn the screen back on, and the interface should be frozen.
> Another possible path to re-producing the issue:
> 1. Download Untappd - 
> V2.0.4(https://play.google.com/store/apps/details?id=com.untappdllc.app)
> 2. After logging in stay on the Friends tab
> 3. Go back to the home screen then use other apps for about 3-7 minutes.
> 4. Go back into Untappd, and the interface should be frozen.
> When the app is frozen, native menu buttons will not nor any options in the 
> UI. 
> Would love to see if anyone can replicate this. I've tested this on Jelly 
> Bean 4.1.x on a Samsung Galaxy Nexus, but users have been having this problem 
> majority on ICS (4.0.x)
> Thanks,
> Greg

--
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-1839) iOS - Update Device docs for corrected device.name implementation

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah updated CB-1839:
-

Fix Version/s: 2.3.0

> iOS - Update Device docs for corrected device.name implementation
> -
>
> Key: CB-1839
> URL: https://issues.apache.org/jira/browse/CB-1839
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs, iOS
>Reporter: Shazron Abdullah
>Assignee: Michael Brooks
> Fix For: 2.3.0
>
>
> See CB-1837. device.name should return the device model (what device.platform 
> used to return)

--
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-1837) Device core plugin - device.name should return the actual device string (eg iPod Touch, iPhone 3GS)

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah updated CB-1837:
-

Fix Version/s: 2.3.0

> Device core plugin - device.name should return the actual device string (eg 
> iPod Touch, iPhone 3GS)
> ---
>
> Key: CB-1837
> URL: https://issues.apache.org/jira/browse/CB-1837
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Fix For: 2.3.0
>
>
> Device.name returns the custom device name as the user defines it
> in iTunes. It should return the model name, I.e. What device.platform
> returns now (related: CB-1836)

--
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-1836) Device core plugin - device.platform should return "iOS"

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah updated CB-1836:
-

Fix Version/s: 2.3.0

> Device core plugin - device.platform should return "iOS"
> 
>
> Key: CB-1836
> URL: https://issues.apache.org/jira/browse/CB-1836
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Shazron Abdullah
>Assignee: Shazron Abdullah
> Fix For: 2.3.0
>
>
> Currently if you ask for device.platform you will get several different
> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc. This seems
> backwards. All of these should return 'iOS'.
> What device.platform returns now should really be what device.name returns.

--
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-1840) Deprecate sync usage of Device API call before deviceready can be fired, add async

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah updated CB-1840:
-

Fix Version/s: 2.3.0

> Deprecate sync usage of Device API call before deviceready can be fired, add 
> async
> --
>
> Key: CB-1840
> URL: https://issues.apache.org/jira/browse/CB-1840
> Project: Apache Cordova
>  Issue Type: Task
>  Components: CordovaJS, iOS
>Reporter: Shazron Abdullah
>Assignee: Filip Maj
> Fix For: 2.3.0
>
>
> Device API call:
> 1. drop in deprecation notice for sync usage and add to deprec page
> 2. add async equiv and get it out of startup path
> See ML thread: http://markmail.org/thread/ja7kixjlu6gei7kb

--
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-1838) iOS - Update Device docs for corrected device.platform implementation

[Shazron Abdullah (JIRA)]

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

Shazron Abdullah updated CB-1838:
-

Fix Version/s: 2.3.0

> iOS - Update Device docs for corrected device.platform implementation
> -
>
> Key: CB-1838
> URL: https://issues.apache.org/jira/browse/CB-1838
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs, iOS
>Reporter: Shazron Abdullah
>Assignee: Michael Brooks
> Fix For: 2.3.0
>
>
> See CB-1836. device.platform should return "iOS" 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

Re: iOS' device API

[Shazron]

Added:

http://issues.cordova.io/1836
http://issues.cordova.io/1837
http://issues.cordova.io/1838
http://issues.cordova.io/1839
http://issues.cordova.io/1840



On Mon, Nov 12, 2012 at 11:14 AM, Shazron  wrote:

> Adding jira tasks as per Brian's last comment.
>
>
> On Thu, Nov 8, 2012 at 9:52 AM, Shazron  wrote:
>
>> +1 sounds like a plan
>>
>>
>> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj  wrote:
>>
>>> +1
>>>
>>> On 11/8/12 4:01 AM, "Brian LeRoux"  wrote:
>>>
>>> >I think would it make sense to:
>>> >
>>> >1. align apis as orig msg from fil suggests
>>> >2. drop in deprecation notice for sync usage and add to deprec page
>>> >3. add async equiv and get it out of startup path as andrew suggests
>>> >
>>> >
>>> >
>>> >
>>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj  wrote:
>>> >
>>> >> Although I think we're close to being able to author cross-platform
>>> apps
>>> >> sans UA detection , I think people still have valid use cases to use
>>> it.
>>> >>
>>> >> On 11/7/12 6:18 PM, "Andrew Grieve"  wrote:
>>> >>
>>> >> >I like the idea of at least removing this from the start-up path. If
>>> >>users
>>> >> >want to know about the device, they could always call exec()
>>> >>themselves.
>>> >> >
>>> >> >
>>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron  wrote:
>>> >> >
>>> >> >> Also, if we remove the device API like Brian suggested, it would be
>>> >> >>good in
>>> >> >> the sense that we won't have to call the CDVDevice plugin to
>>> populate
>>> >> >>some
>>> >> >> js variables before deviceready can fire -- eliminating a
>>> dependency.
>>> >> >>
>>> >> >>
>>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron 
>>> wrote:
>>> >> >>
>>> >> >> > Agree with Fil to make it consistent - in essence this is an iOS
>>> >>bug
>>> >> >>:)
>>> >> >> >
>>> >> >> > Brian, there is one case I can think of -- detecting the iPad
>>> >>mini's
>>> >> >> > features using js - Max Firt investigated trying to do it
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >>
>>> >>
>>> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>>> >> >>tthe only kludgy way right now using PG would be device.platform to
>>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect
>>> >>this to
>>> >> >> > enlarge certain UI elements for the mini (since the physical area
>>> >> >>will be
>>> >> >> > smaller than a reg sized iPad)
>>> >> >> >
>>> >> >> >
>>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj 
>>> wrote:
>>> >> >> >
>>> >> >> >> CI implementation is what I am gunning for here (and can
>>> actually
>>> >>use
>>> >> >> it).
>>> >> >> >>
>>> >> >> >> I don't like it either but reality is for people building
>>> >> >>cross-platform
>>> >> >> >> apps at some point you have to do:
>>> >> >> >>
>>> >> >> >> if (device.platform == 'android') // do some stuff
>>> >> >> >>
>>> >> >> >> For example, knowing when to attach to a back button vs
>>> rendering
>>> >> >>some
>>> >> >> ui
>>> >> >> >> to handle that.
>>> >> >> >>
>>> >> >> >> IMO we should set up deprecation for "name" and move to "model"
>>> as
>>> >> >>it's
>>> >> >> >> clearer (and probably was the reason why iOS went for device's
>>> >>custom
>>> >> >> name
>>> >> >> >> in the first place - semantic confusion :P )
>>> >> >> >>
>>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux"  wrote:
>>> >> >> >>
>>> >> >> >> >This may get some rotton tomatoes thrown at me but I would be
>>> in
>>> >> >>favor
>>> >> >> of
>>> >> >> >> >axing these apis altogether. I think they are more dangerous
>>> than
>>> >> >> useful
>>> >> >> >> /
>>> >> >> >> >developers should favor browser feature detection for their UI
>>> >>work.
>>> >> >> >> >
>>> >> >> >> >There is no programmatic reason to want these properties
>>> >>otherwise
>>> >> >> that I
>>> >> >> >> >can think of?
>>> >> >> >> >
>>> >> >> >> >(But agree at least should be consistent as Fil suggests.)
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj 
>>> wrote:
>>> >> >> >> >
>>> >> >> >> >> Currently if you ask for device.platform you will get several
>>> >> >> different
>>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc.
>>> >>This
>>> >> >> seems
>>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
>>> >> >> >> >>
>>> >> >> >> >> Related, device.name returns the custom device name as the
>>> user
>>> >> >> >> defines
>>> >> >> >> >>it
>>> >> >> >> >> in iTunes. IMO it should return the model name, I.e. What
>>> >> >> >> >>device.platform
>>> >> >> >> >> returns now.
>>> >> >> >> >>
>>> >> >> >> >> This would line it up with our docs + other platforms.
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >>
>>> >>
>>>
>>>
>>
>

[jira] [Created] (CB-1840) Deprecate sync usage of Device API call before deviceready can be fired, add async

[Shazron Abdullah (JIRA)]

Shazron Abdullah created CB-1840:


 Summary: Deprecate sync usage of Device API call before 
deviceready can be fired, add async
 Key: CB-1840
 URL: https://issues.apache.org/jira/browse/CB-1840
 Project: Apache Cordova
  Issue Type: Task
  Components: CordovaJS, iOS
Reporter: Shazron Abdullah
Assignee: Filip Maj


Device API call:
1. drop in deprecation notice for sync usage and add to deprec page
2. add async equiv and get it out of startup path

See ML thread: http://markmail.org/thread/ja7kixjlu6gei7kb

--
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-1839) iOS - Update Device docs for corrected device.name implementation

[Shazron Abdullah (JIRA)]

Shazron Abdullah created CB-1839:


 Summary: iOS - Update Device docs for corrected device.name 
implementation
 Key: CB-1839
 URL: https://issues.apache.org/jira/browse/CB-1839
 Project: Apache Cordova
  Issue Type: Bug
  Components: Docs, iOS
Reporter: Shazron Abdullah
Assignee: Michael Brooks


See CB-1837. device.name should return the device model (what device.platform 
used to return)

--
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-1838) iOS - Update Device docs for corrected device.platform implementation

[Shazron Abdullah (JIRA)]

Shazron Abdullah created CB-1838:


 Summary: iOS - Update Device docs for corrected device.platform 
implementation
 Key: CB-1838
 URL: https://issues.apache.org/jira/browse/CB-1838
 Project: Apache Cordova
  Issue Type: Bug
  Components: Docs, iOS
Reporter: Shazron Abdullah
Assignee: Michael Brooks


See CB-1836. device.platform should return "iOS" 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-1837) Device core plugin - device.name should return the actual device string (eg iPod Touch, iPhone 3GS)

[Shazron Abdullah (JIRA)]

Shazron Abdullah created CB-1837:


 Summary: Device core plugin - device.name should return the actual 
device string (eg iPod Touch, iPhone 3GS)
 Key: CB-1837
 URL: https://issues.apache.org/jira/browse/CB-1837
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Reporter: Shazron Abdullah
Assignee: Shazron Abdullah


Device.name returns the custom device name as the user defines it
in iTunes. It should return the model name, I.e. What device.platform
returns now (related: CB-1836)

--
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-1836) Device core plugin - device.platform should return "iOS"

[Shazron Abdullah (JIRA)]

Shazron Abdullah created CB-1836:


 Summary: Device core plugin - device.platform should return "iOS"
 Key: CB-1836
 URL: https://issues.apache.org/jira/browse/CB-1836
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Reporter: Shazron Abdullah
Assignee: Shazron Abdullah


Currently if you ask for device.platform you will get several different
responses on iOS. You'll get iPhone, iPad, iPod Touch, etc. This seems
backwards. All of these should return 'iOS'.

What device.platform returns now should really be what device.name returns.


--
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: CB975 - camera.getPicture crashes app on iPad3 when capturing multiple images

[Vik Tara]

Thanks Shazron - will continue over there.

On 12/11/12 19:12, Shazron wrote:

Hi Vik,
A dev is taking a fresh look at this today. You should continue the
discussion in that issue.

To contribute a patch, please review this workflow:
http://wiki.apache.org/cordova/ContributorWorkflow


On Mon, Nov 12, 2012 at 3:55 AM, Vik Tara  wrote:


On 11/12/2012 10:39 AM, Vik Tara wrote:


Hi Cordova Devs,

We have an app which is suffering from this bug and am thinking about
spending some time
trying to resolve it / contributing a patch.

Does anyone have any pointers / are looking at it already?


Forgot the url!

https://issues.apache.org/**jira/browse/CB-975

Re: iOS' device API

[Shazron]

Adding jira tasks as per Brian's last comment.


On Thu, Nov 8, 2012 at 9:52 AM, Shazron  wrote:

> +1 sounds like a plan
>
>
> On Thu, Nov 8, 2012 at 9:34 AM, Filip Maj  wrote:
>
>> +1
>>
>> On 11/8/12 4:01 AM, "Brian LeRoux"  wrote:
>>
>> >I think would it make sense to:
>> >
>> >1. align apis as orig msg from fil suggests
>> >2. drop in deprecation notice for sync usage and add to deprec page
>> >3. add async equiv and get it out of startup path as andrew suggests
>> >
>> >
>> >
>> >
>> >On Wed, Nov 7, 2012 at 7:13 PM, Filip Maj  wrote:
>> >
>> >> Although I think we're close to being able to author cross-platform
>> apps
>> >> sans UA detection , I think people still have valid use cases to use
>> it.
>> >>
>> >> On 11/7/12 6:18 PM, "Andrew Grieve"  wrote:
>> >>
>> >> >I like the idea of at least removing this from the start-up path. If
>> >>users
>> >> >want to know about the device, they could always call exec()
>> >>themselves.
>> >> >
>> >> >
>> >> >On Wed, Nov 7, 2012 at 4:57 PM, Shazron  wrote:
>> >> >
>> >> >> Also, if we remove the device API like Brian suggested, it would be
>> >> >>good in
>> >> >> the sense that we won't have to call the CDVDevice plugin to
>> populate
>> >> >>some
>> >> >> js variables before deviceready can fire -- eliminating a
>> dependency.
>> >> >>
>> >> >>
>> >> >> On Wed, Nov 7, 2012 at 11:00 AM, Shazron  wrote:
>> >> >>
>> >> >> > Agree with Fil to make it consistent - in essence this is an iOS
>> >>bug
>> >> >>:)
>> >> >> >
>> >> >> > Brian, there is one case I can think of -- detecting the iPad
>> >>mini's
>> >> >> > features using js - Max Firt investigated trying to do it
>> >> >> >
>> >> >>
>> >> >>
>> >>
>> >>
>> http://www.mobilexweb.com/blog/ipad-mini-detection-for-html5-user-agentbu
>> >> >>tthe only kludgy way right now using PG would be device.platform to
>> >> >> > detect iPad2,5 and iPad2,6. I suppose ppl would need to detect
>> >>this to
>> >> >> > enlarge certain UI elements for the mini (since the physical area
>> >> >>will be
>> >> >> > smaller than a reg sized iPad)
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Nov 7, 2012 at 10:06 AM, Filip Maj  wrote:
>> >> >> >
>> >> >> >> CI implementation is what I am gunning for here (and can actually
>> >>use
>> >> >> it).
>> >> >> >>
>> >> >> >> I don't like it either but reality is for people building
>> >> >>cross-platform
>> >> >> >> apps at some point you have to do:
>> >> >> >>
>> >> >> >> if (device.platform == 'android') // do some stuff
>> >> >> >>
>> >> >> >> For example, knowing when to attach to a back button vs rendering
>> >> >>some
>> >> >> ui
>> >> >> >> to handle that.
>> >> >> >>
>> >> >> >> IMO we should set up deprecation for "name" and move to "model"
>> as
>> >> >>it's
>> >> >> >> clearer (and probably was the reason why iOS went for device's
>> >>custom
>> >> >> name
>> >> >> >> in the first place - semantic confusion :P )
>> >> >> >>
>> >> >> >> On 11/7/12 7:35 AM, "Brian LeRoux"  wrote:
>> >> >> >>
>> >> >> >> >This may get some rotton tomatoes thrown at me but I would be in
>> >> >>favor
>> >> >> of
>> >> >> >> >axing these apis altogether. I think they are more dangerous
>> than
>> >> >> useful
>> >> >> >> /
>> >> >> >> >developers should favor browser feature detection for their UI
>> >>work.
>> >> >> >> >
>> >> >> >> >There is no programmatic reason to want these properties
>> >>otherwise
>> >> >> that I
>> >> >> >> >can think of?
>> >> >> >> >
>> >> >> >> >(But agree at least should be consistent as Fil suggests.)
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >On Tue, Nov 6, 2012 at 4:40 PM, Filip Maj 
>> wrote:
>> >> >> >> >
>> >> >> >> >> Currently if you ask for device.platform you will get several
>> >> >> different
>> >> >> >> >> responses on iOS. You'll get iPhone, iPad, iPod Touch, etc.
>> >>This
>> >> >> seems
>> >> >> >> >> backwards. IMO all of these should return 'iOS'.
>> >> >> >> >>
>> >> >> >> >> Related, device.name returns the custom device name as the
>> user
>> >> >> >> defines
>> >> >> >> >>it
>> >> >> >> >> in iTunes. IMO it should return the model name, I.e. What
>> >> >> >> >>device.platform
>> >> >> >> >> returns now.
>> >> >> >> >>
>> >> >> >> >> This would line it up with our docs + other platforms.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >>
>> >>
>>
>>
>

Re: CB975 - camera.getPicture crashes app on iPad3 when capturing multiple images

[Shazron]

Hi Vik,
A dev is taking a fresh look at this today. You should continue the
discussion in that issue.

To contribute a patch, please review this workflow:
http://wiki.apache.org/cordova/ContributorWorkflow


On Mon, Nov 12, 2012 at 3:55 AM, Vik Tara  wrote:

>
> On 11/12/2012 10:39 AM, Vik Tara wrote:
>
>> Hi Cordova Devs,
>>
>> We have an app which is suffering from this bug and am thinking about
>> spending some time
>> trying to resolve it / contributing a patch.
>>
>> Does anyone have any pointers / are looking at it already?
>>
> Forgot the url!
>
> https://issues.apache.org/**jira/browse/CB-975
>

Re: InAppBrowser api questions

[Shazron]

Bump. These questions below still need some discussion and consensus before
the InAppBrowser implementation can be complete.


On Fri, Nov 9, 2012 at 9:43 AM, Shazron  wrote:

> WIki page: http://wiki.apache.org/cordova/InAppBrowser
> Some questions brought up by Jesse in JIRA (replicated below):
> http://goo.gl/cZe84
>
> 
> Jesse MacFadyen:
>
> I have some open questions about the wiki defined 'spec'
>
> 1. window.open('http://random-url.com', '_self'); // loads in InAppBrowser
> so even though the random-url is not whitelisted, it is permitted to
> load within the application, inside the InAppBrowser. This is currently not
> trivial on iOS.
>
> 2. How can I open a whitelisted url in the native browser? ie. mobile
> safari
> there is no clear path to targeting ALL 3 possibilities or a)the app
> page, b) the InAppBrowser, c) the system browser ( for a whitelisted URL )
> it makes sense that you cannot open a file:// url in the system
> browser + you cannot open a non-whitelisted url in the app.
>
> 
>
> My comments:
>
> 1. This as Jesse points out, is not trivial on iOS. The "easy way" would
> be to not allow this, but kick it out to the system browser (Mobile
> Safari), and have that as a general rule, any non-whitelisted URLs for the
> InAppBrowser are kicked out to the system browser. I don't know how hard it
> is for Android.
>
> If we were to do this, we would have to temporarily allow the url to
> bypass the whitelist which could be kludgy (since we can't know what other
> URLs that URL will load) -- essentially this issue
> http://issues.cordova.io/1695 would totally solve this correctly, but we
> don't have a solution yet for that issue.
>
> 2. This case has not been addressed. I would think _blank would be the
> case but this is specified as the InAppBrowser here. How about this case,
> we could use _parent for InAppBrowser, but _blank for system browser?
> However, this would not be consistent with how the other calls are
> specified (unless we change the others to be consistent).
>
> Another possible solution is to kick out to the system browser if an
> unknown value is used (some random value), that will use the system
> browser, which is consistent with how window.open works.
>

Re: [BlackBerry] launch app from command line?

[Filip Maj]

Thanks Drew. I'm gonna go with Playbook and BB10 OS automation as a first
pass for now.

On 11/12/12 10:34 AM, "Drew Walters"  wrote:

>In regards to updating an app on BB5-7, for the simulators you can at
>least
>use fledgecontroller to update the application without requiring the
>simulator to restart:
>
>https://gist.github.com/2428385
>
>I believe its possible to also launch the app via fledgecontroller but I
>think you have to essentially simulate the correct touch events and can't
>simply launch by name.
>
>
>On Sun, Nov 11, 2012 at 12:18 AM, Filip Maj  wrote:
>
>> Hmm system_profiler is close but when I connected both a playbook and a
>> BB10 device they are listed to have the same Ips (169.254.0.1).
>>
>> They both have an actual network ip as well (192.168.1.xxx in my case
>> right now) but it only lists the 169 under system profiler.
>>
>> The one benefit of system_profiler is you can at least determine how
>>many
>> playbook or bb10 devices are connected.. That's a start.
>>
>> On 11/9/12 5:10 PM, "Tim Kim"  wrote:
>>
>> >Update! Try this command instead
>> >
>> >system_profiler SPNetworkDataType -detailLevel basic
>> >
>> >Runs faster since it doesn't have to generate an entire system's
>>report.
>> >
>> >
>> >On 9 November 2012 17:02, Tim Kim  wrote:
>> >
>> >> Hrmmm, I think you can figure out which devices are currently
>>connected
>> >> using
>> >> system_profiler -detailLevel basic
>> >>
>> >> The bb10 entry is under PlayBook (en5) and the playbook entry is
>>under
>> >> PlayBook (en3) (not sure if the en# changes or not).  Also, those
>> >>entries
>> >> should all fall under the "Network" stuff.
>> >>
>> >> In any case, if you look for those, there'll be a field that should
>>give
>> >> you the ip address of the device.
>> >>
>> >> Looks like you can make a quick script to grep for that stuff!
>> >>
>> >>
>> >> On 9 November 2012 16:22, Filip Maj  wrote:
>> >>
>> >>> For getting a list of devices, it's a network issue due to OTA
>> >>>deployment.
>> >>> Would be nice if there was a "discover" command in the BB suite of
>> >>>tools
>> >>> that would scan the local network and find any Bbs. Just sayin :)
>> >>>
>> >>> As for determining which one is a playbook or bb10, you can do that
>> >>> through ./blackberry-deploy -getDeviceInfo -device  -password
>> >>> 
>> >>>
>> >>> PS the various cli tools that come with the BB SDK are awesome. The
>> >>>_one_
>> >>> thing missing is an equivalent to Android's "adb devices" which
>>lists
>> >>>all
>> >>> accessible / connected / reachable Android devices.
>> >>>
>> >>> On 11/9/12 3:56 PM, "Filip Maj"  wrote:
>> >>>
>> >>> >Yeah that worked awesome. Silly me for trying BB 7 ;)
>> >>> >
>> >>> >Nukul (or anyone for that matter), one more quick question: any
>>way to
>> >>> >accomplish the following:
>> >>> >
>> >>> >- get a list of connected BlacKBerry devices (only playbook / bb10
>>is
>> >>> >fine)
>> >>> >- determine which one is a playbook and which one is a bb10 ?
>> >>> >
>> >>> >On 11/9/12 3:26 PM, "Nukul Bhasin"  wrote:
>> >>> >
>> >>> >>Not possible for BlackBerry os 6 or 7
>> >>> >>You can do it for pb and bb10 using BlackBerry-deploy
>> >>> >>
>> >>> >>From: Tim Kim
>> >>> >>To: dev@cordova.apache.org
>> >>> >>Reply To: dev@cordova.apache.org
>> >>> >>*Re: [BlackBerry] launch app from command line?*
>> >>> >>2012-11-09 6:18:09 PM
>> >>> >>
>> >>> >>I talked to Fil over IM about this and here were some points I
>>came
>> >>>up
>> >>> >>with:
>> >>> >>- pretty sure just doing ./cordova/debug on bb10/playbook will
>>auto
>> >>> >>launch
>> >>> >>app
>> >>> >>- not sure what to do for bb 6/7 - ./cordova/debug will install
>>onto
>> >>> >>device
>> >>> >>but not launch it
>> >>> >>- also updating an app of bb 6/7 reboots the device which could be
>> >>> >>problematic for testing new changes without a human involved
>> >>> >>
>> >>> >>
>> >>> >>On 9 November 2012 15:04, Filip Maj wrote:
>> >>> >>
>> >>> >>> I can successfully package and deploy an app to a device.
>> >>> >>>
>> >>> >>> I am now looking to launch it from my command line. I am
>>working on
>> >>> the
>> >>> >>> cordova CI setup.
>> >>> >>>
>> >>> >>> I dug around for some articles but couldn't find anything. Tim /
>> >>>Gord
>> >>> /
>> >>> >>> Ken / any other RIM lurkers around that could potentially set
>>up?
>> >>> >>>
>> >>> >>> I am interested in all flavors of BlackBerry: OS 6-7, PlayBook,
>>or
>> >>> >>>BB10.
>> >>> >>> Command-line launching for any/all of these would be rad.
>> >>> >>>
>> >>> >>> Thx in advance for any help / pointers.
>> >>> >>>
>> >>> >>> Fil
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>> >>--
>> >>> >>Timothy Kim
>> >>> >
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Timothy Kim
>> >>
>> >>
>> >>
>> >
>> >
>> >--
>> >Timothy Kim
>>
>>

incubator-cordova-android pull request: Getting the path from the URI fails...

[ilbambino]

Github user ilbambino closed the pull request at:

https://github.com/apache/incubator-cordova-android/pull/53

Re: [BlackBerry] launch app from command line?

[Drew Walters]

In regards to updating an app on BB5-7, for the simulators you can at least
use fledgecontroller to update the application without requiring the
simulator to restart:

https://gist.github.com/2428385

I believe its possible to also launch the app via fledgecontroller but I
think you have to essentially simulate the correct touch events and can't
simply launch by name.


On Sun, Nov 11, 2012 at 12:18 AM, Filip Maj  wrote:

> Hmm system_profiler is close but when I connected both a playbook and a
> BB10 device they are listed to have the same Ips (169.254.0.1).
>
> They both have an actual network ip as well (192.168.1.xxx in my case
> right now) but it only lists the 169 under system profiler.
>
> The one benefit of system_profiler is you can at least determine how many
> playbook or bb10 devices are connected.. That's a start.
>
> On 11/9/12 5:10 PM, "Tim Kim"  wrote:
>
> >Update! Try this command instead
> >
> >system_profiler SPNetworkDataType -detailLevel basic
> >
> >Runs faster since it doesn't have to generate an entire system's report.
> >
> >
> >On 9 November 2012 17:02, Tim Kim  wrote:
> >
> >> Hrmmm, I think you can figure out which devices are currently connected
> >> using
> >> system_profiler -detailLevel basic
> >>
> >> The bb10 entry is under PlayBook (en5) and the playbook entry is under
> >> PlayBook (en3) (not sure if the en# changes or not).  Also, those
> >>entries
> >> should all fall under the "Network" stuff.
> >>
> >> In any case, if you look for those, there'll be a field that should give
> >> you the ip address of the device.
> >>
> >> Looks like you can make a quick script to grep for that stuff!
> >>
> >>
> >> On 9 November 2012 16:22, Filip Maj  wrote:
> >>
> >>> For getting a list of devices, it's a network issue due to OTA
> >>>deployment.
> >>> Would be nice if there was a "discover" command in the BB suite of
> >>>tools
> >>> that would scan the local network and find any Bbs. Just sayin :)
> >>>
> >>> As for determining which one is a playbook or bb10, you can do that
> >>> through ./blackberry-deploy -getDeviceInfo -device  -password
> >>> 
> >>>
> >>> PS the various cli tools that come with the BB SDK are awesome. The
> >>>_one_
> >>> thing missing is an equivalent to Android's "adb devices" which lists
> >>>all
> >>> accessible / connected / reachable Android devices.
> >>>
> >>> On 11/9/12 3:56 PM, "Filip Maj"  wrote:
> >>>
> >>> >Yeah that worked awesome. Silly me for trying BB 7 ;)
> >>> >
> >>> >Nukul (or anyone for that matter), one more quick question: any way to
> >>> >accomplish the following:
> >>> >
> >>> >- get a list of connected BlacKBerry devices (only playbook / bb10 is
> >>> >fine)
> >>> >- determine which one is a playbook and which one is a bb10 ?
> >>> >
> >>> >On 11/9/12 3:26 PM, "Nukul Bhasin"  wrote:
> >>> >
> >>> >>Not possible for BlackBerry os 6 or 7
> >>> >>You can do it for pb and bb10 using BlackBerry-deploy
> >>> >>
> >>> >>From: Tim Kim
> >>> >>To: dev@cordova.apache.org
> >>> >>Reply To: dev@cordova.apache.org
> >>> >>*Re: [BlackBerry] launch app from command line?*
> >>> >>2012-11-09 6:18:09 PM
> >>> >>
> >>> >>I talked to Fil over IM about this and here were some points I came
> >>>up
> >>> >>with:
> >>> >>- pretty sure just doing ./cordova/debug on bb10/playbook will auto
> >>> >>launch
> >>> >>app
> >>> >>- not sure what to do for bb 6/7 - ./cordova/debug will install onto
> >>> >>device
> >>> >>but not launch it
> >>> >>- also updating an app of bb 6/7 reboots the device which could be
> >>> >>problematic for testing new changes without a human involved
> >>> >>
> >>> >>
> >>> >>On 9 November 2012 15:04, Filip Maj wrote:
> >>> >>
> >>> >>> I can successfully package and deploy an app to a device.
> >>> >>>
> >>> >>> I am now looking to launch it from my command line. I am working on
> >>> the
> >>> >>> cordova CI setup.
> >>> >>>
> >>> >>> I dug around for some articles but couldn't find anything. Tim /
> >>>Gord
> >>> /
> >>> >>> Ken / any other RIM lurkers around that could potentially set up?
> >>> >>>
> >>> >>> I am interested in all flavors of BlackBerry: OS 6-7, PlayBook, or
> >>> >>>BB10.
> >>> >>> Command-line launching for any/all of these would be rad.
> >>> >>>
> >>> >>> Thx in advance for any help / pointers.
> >>> >>>
> >>> >>> Fil
> >>> >>>
> >>> >>>
> >>> >>
> >>> >>
> >>> >>--
> >>> >>Timothy Kim
> >>> >
> >>>
> >>>
> >>
> >>
> >> --
> >> Timothy Kim
> >>
> >>
> >>
> >
> >
> >--
> >Timothy Kim
>
>

[jira] [Commented] (CB-975) camera.getPicture crashes app on iPad3 when capturing multiple images

[Lorin Beer (JIRA)]

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

Lorin Beer commented on CB-975:
---

Hi Andrew,

is the code you provided in the bug description still representative of the 
code generating the crash? I have a suspicion that this has to do with spotty 
memory management on the native side. UIImage caches the image when initialized 
from certain sources, and this would be more in line a crash of the 
com.apple.camera.avcapturesession thread.

Could you share any memory profiling data you've collected? 

> camera.getPicture crashes app on iPad3 when capturing multiple images
> -
>
> Key: CB-975
> URL: https://issues.apache.org/jira/browse/CB-975
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 1.7.0, 1.8.1, 1.9.0, 2.0.0
> Environment: iOS 5.1.1
> iPad 3 (device is not jailbbroken or anything special, stock standard)
> Built on PhoneGap Build service
> iPhone 4s
>Reporter: Andrew Smith
>Assignee: Shazron Abdullah
>Priority: Critical
>  Labels: camera, memory
>
> I have a page which allows users to capture multiple images, one after the 
> other.  Somewhere between the second and fifth capture, the application 
> crashes.  Restarting the device and closing other apps makes no difference as 
> to how long it takes to crash.
> -deleted-I have not been able to test on an iPhone.-deleted-
> Update: can confirm it happens on iPhone 4S too.
> I have tried with both FILE_URI and DATA_URL, with no noticeable change.
> Here is my pared down code which exhibits the detailed behaviour.  This 
> method is called from an onclick event on a DIV element.
> {code:javascript}
> ModFormCommon.AddPhoto = function () {
>   
>   if (!navigator.camera) {
>   alert("Photos are not supported on this device");
>   return;
>   }
>   navigator.camera.getPicture(
>   function( data ) {
>   alert("Photo taken: " + data.length);
>   },
>   function (sMessage) {
>   alert("Photo error: " + sMessage);
>   },
>   {
>   quality: 25,
>   //destinationType: Camera.DestinationType.FILE_URI 
>   destinationType: Camera.DestinationType.DATA_URL
>   });
> };
> {code}
> The Crashlog is sometimes proceeded by a low memory warning, but not always, 
> so don't know that it's relevant.
> Crashlog is as follows:
> Incident Identifier: F8CD8A48-0989-479C-AC7E-4CBF31BAE737
> CrashReporter Key:   f491a35dbb4b6f2e7c0d29faeee7feaf7813f4c8
> Hardware Model:  iPad3,3
> Process: MDC [809]
> Path:
> /var/mobile/Applications/CC253554-F6B5-4E8F-BC83-27F34241AE80/MDC.app/MDC
> Identifier:  MDC
> Version: ??? (???)
> Code Type:   ARM (Native)
> Parent Process:  launchd [1]
> Date/Time:   2012-06-28 11:53:53.141 +1000
> OS Version:  iPhone OS 5.1.1 (9B206)
> Report Version:  104
> Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x
> Crashed Thread:  10
> Thread 0 name:  Dispatch queue: com.apple.main-thread
> Thread 0:
> 0   libsystem_kernel.dylib0x35034004 0x35033000 + 4100
> 1   libsystem_kernel.dylib0x350341fa 0x35033000 + 4602
> 2   CoreFoundation0x32b413ec 0x32ab4000 + 578540
> 3   CoreFoundation0x32b400ea 0x32ab4000 + 573674
> 4   CoreFoundation0x32ac349e 0x32ab4000 + 62622
> 5   CoreFoundation0x32ac3366 0x32ab4000 + 62310
> 6   GraphicsServices  0x32c10432 0x32c0c000 + 17458
> 7   UIKit 0x350a2cce 0x35071000 + 203982
> 8   MDC   0x24c8 0x1000 + 5320
> 9   MDC   0x2444 0x1000 + 5188
> Thread 1 name:  Dispatch queue: com.apple.libdispatch-manager
> Thread 1:
> 0   libsystem_kernel.dylib0x350343a8 0x35033000 + 5032
> 1   libdispatch.dylib 0x31298f04 0x31295000 + 16132
> 2   libdispatch.dylib 0x31298c22 0x31295000 + 15394
> Thread 2 name:  WebThread
> Thread 2:
> 0   libsystem_kernel.dylib0x35034004 0x35033000 + 4100
> 1   libsystem_kernel.dylib0x350341fa 0x35033000 + 4602
> 2   CoreFoundation0x32b413ec 0x32ab4000 + 578540
> 3   CoreFoundation0x32b40124 0x32ab4000 + 573732
> 4   CoreFoundation0x32ac349e 0x32ab4000 + 62622
> 5   CoreFoundation0x32ac3366 0x32ab4000 + 62310
> 6   WebCore   0x35861c9c 0x357b8000 

[jira] [Resolved] (CB-1835) Camera.getPicture gives error when get a picture from photo library with spaces in its name on Android

[Simon MacDonald (JIRA)]

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

Simon MacDonald resolved CB-1835.
-

   Resolution: Fixed
Fix Version/s: 2.3.0

Fixed the issue with spaces in file names failing to be selected.

> Camera.getPicture gives error when get a picture from photo library with 
> spaces in its name on Android
> --
>
> Key: CB-1835
> URL: https://issues.apache.org/jira/browse/CB-1835
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
> Environment: Android
>Reporter: Gerardo Parra
>Assignee: Simon MacDonald
> Fix For: 2.3.0
>
>
> When you use Camera.getPicture to get a photo from photo library, it returns 
> error if the file name has spaces in its name. In my case, I use a Samsung 
> Galaxy S SCL smartphone and the camera saves the photos using spaces. If I 
> try to get a picture without spaces, it returns successfully the file.

--
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-1835) Camera.getPicture gives error when get a picture from photo library with spaces in its name on Android

[Simon MacDonald (JIRA)]

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

Simon MacDonald commented on CB-1835:
-

The call:

MimeTypeMap map = MimeTypeMap.getSingleton();
return 
map.getMimeTypeFromExtension(MimeTypeMap.getFileExtensionFromUrl(filename));

returns "null" if the filename has a space in it which is just a pain in the, 
hey, hey kids! I was using that check to make sure someone did not try to get a 
text file using getPicture. Guarding against the false negative now.

Next step I need to take a look at when something like DropBox returns a url 
encoded file URI.

> Camera.getPicture gives error when get a picture from photo library with 
> spaces in its name on Android
> --
>
> Key: CB-1835
> URL: https://issues.apache.org/jira/browse/CB-1835
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
> Environment: Android
>Reporter: Gerardo Parra
>Assignee: Simon MacDonald
>
> When you use Camera.getPicture to get a photo from photo library, it returns 
> error if the file name has spaces in its name. In my case, I use a Samsung 
> Galaxy S SCL smartphone and the camera saves the photos using spaces. If I 
> try to get a picture without spaces, it returns successfully the file.

--
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-1835) Camera.getPicture gives error when get a picture from photo library with spaces in its name on Android

[Simon MacDonald (JIRA)]

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

Simon MacDonald commented on CB-1835:
-

I'm already working on a similar issue. Should be able to check in a fix today.

> Camera.getPicture gives error when get a picture from photo library with 
> spaces in its name on Android
> --
>
> Key: CB-1835
> URL: https://issues.apache.org/jira/browse/CB-1835
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
> Environment: Android
>Reporter: Gerardo Parra
>Assignee: Simon MacDonald
>
> When you use Camera.getPicture to get a photo from photo library, it returns 
> error if the file name has spaces in its name. In my case, I use a Samsung 
> Galaxy S SCL smartphone and the camera saves the photos using spaces. If I 
> try to get a picture without spaces, it returns successfully the file.

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

[jira] [Assigned] (CB-1835) Camera.getPicture gives error when get a picture from photo library with spaces in its name on Android

[Simon MacDonald (JIRA)]

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

Simon MacDonald reassigned CB-1835:
---

Assignee: Simon MacDonald  (was: Joe Bowser)

> Camera.getPicture gives error when get a picture from photo library with 
> spaces in its name on Android
> --
>
> Key: CB-1835
> URL: https://issues.apache.org/jira/browse/CB-1835
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Android
>Affects Versions: 2.2.0
> Environment: Android
>Reporter: Gerardo Parra
>Assignee: Simon MacDonald
>
> When you use Camera.getPicture to get a photo from photo library, it returns 
> error if the file name has spaces in its name. In my case, I use a Samsung 
> Galaxy S SCL smartphone and the camera saves the photos using spaces. If I 
> try to get a picture without spaces, it returns successfully the file.

--
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-1835) Camera.getPicture gives error when get a picture from photo library with spaces in its name on Android

[Gerardo Parra (JIRA)]

Gerardo Parra created CB-1835:
-

 Summary: Camera.getPicture gives error when get a picture from 
photo library with spaces in its name on Android
 Key: CB-1835
 URL: https://issues.apache.org/jira/browse/CB-1835
 Project: Apache Cordova
  Issue Type: Bug
  Components: Android
Affects Versions: 2.2.0
 Environment: Android
Reporter: Gerardo Parra
Assignee: Joe Bowser


When you use Camera.getPicture to get a photo from photo library, it returns 
error if the file name has spaces in its name. In my case, I use a Samsung 
Galaxy S SCL smartphone and the camera saves the photos using spaces. If I try 
to get a picture without spaces, it returns successfully the file.

--
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: CB975 - camera.getPicture crashes app on iPad3 when capturing multiple images

[Vik Tara]

On 11/12/2012 10:39 AM, Vik Tara wrote:

Hi Cordova Devs,

We have an app which is suffering from this bug and am thinking about 
spending some time

trying to resolve it / contributing a patch.

Does anyone have any pointers / are looking at it already?

Forgot the url!

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

CB975 - camera.getPicture crashes app on iPad3 when capturing multiple images

[Vik Tara]

Hi Cordova Devs,

We have an app which is suffering from this bug and am thinking about 
spending some time

trying to resolve it / contributing a patch.

Does anyone have any pointers / are looking at it already?

Thanks



Vik