from:"Lindsey Simon"

plugin not in registry search (org.chromium.identity) but it's there

2014-03-21 Thread Lindsey Simon

Go to http://plugins.cordova.io/

Search for identity

Get 2 results:
com.blackberry.identityBlackBerry 10 Identity APIs
com.blackberry.user.identityBlackBerry 10 User Identity APIs

Search for org.chromium.identity

Get 1 result:  org.chromium.identityThis plugin provides OAuth2
authentication for Android and iOS.

How do it work? ;0

Re: Rendering Performance Measurement for Cordova

2014-03-03 Thread Lindsey Simon

Totally exciting, can't wait to give it a whirl!


On Thu, Feb 27, 2014 at 10:14 AM, Brian LeRoux b...@brian.io wrote:

 This is really cool stuff man. Will be taking a closer look for sure.


 On Wed, Feb 26, 2014 at 1:28 PM, Parashuram n.parashu...@gmail.com
 wrote:

  Hi,
 
  I am working on a Front End Rendering performance measurement tool that
 can
  be integrated into a continuous integration systems to generate graphs
 like
  this http://nparashuram.com/bootstrap-perf and this
  http://bench.topcoat.io.
 
  This tool started off being based on Chromium telemetry for Topcoat.io
 but
  now allows running any Selenium like test cases and records timeline
 events
  like paint, Layout, frame times, etc.
 
  This currently works on Android 4.4 Cordova apps and Hybrid apps and is
  available here https://github.com/axemclion/maddie in the dev branch.
  Would love to hear any feedback that folks have. If you also have a
 Cordova
  app on Android app and would like to try this out, I would be glad to
 help
  out.
 
 
 
  Parashuram
  http://nparashuram.com

Re: Camera does too many things!!!!

2014-01-26 Thread Lindsey Simon

+1 for nuking data uris


On Fri, Jan 24, 2014 at 11:36 AM, Don Coleman don.cole...@gmail.com wrote:

 I like the Camera API because it's simple. Capture might be standard but it
 seems too complex.

 Resizing and orientation are important features. I never use data URLs.
 What's going on in the standards bodies around image capture? Is there an
 emerging standard that we could scope down to, or is nothing emerging and
 we get to make it up in the meantime?

 I do like the simplicity of the camera plugin (roughly) just doing capture,
 and pushing the utilities into a separate plugin (perhaps even non-core). I
 hear that picture capture and uploading is a common pattern, so we should
 consider the migration impact to existing users.

 On Jan 24, 2014, at 8:47 AM, Mike Billau mike.bil...@gmail.com wrote:

  How does this coincide with the recent thread about Camera vs Capture?

 Yeah, seems like these are part of the same big picture that should be
 thought through simultaneously.

Re: [Android] Deprecation of Geolocation on Android

2014-01-11 Thread Lindsey Simon

+1 to nuking it.

Anyone depending on it for really old versions of Android is likely not
doing anyone a favor (themselves or their users) - and (I think) it adds to
new developer confusion. Then again, having a plugin that only adds the
permission bit sort of does that too.



On Fri, Jan 10, 2014 at 7:26 PM, Michal Mocny mmo...@chromium.org wrote:

 Adding support for play services based geolocation could come as a value
 add later.  If the current implementation is broken and no one wants to
 work on it (seems to be the case since it hasn't been fixed yet), then
 Joe's suggestion to just drop it now and leave a no-op plugin that adds
 permission only sounds like the right thing short term.

 Joes first email claims Web Geolocation supports all current versions of
 android (http://caniuse.com/geolocation claims android 2.1+ though I
 didn't
 look in to possible quirks).

 -Michal


 On Fri, Jan 10, 2014 at 8:43 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Is the plugin still needed on older android versions? e.g. we might
  want to have it be a no-op based on the android version instead of
  deleting it?
 
  Android geolocation seems to have gone Play Services, so another
  option would be to make the plugin use that instead of the OS
  geolocation in order to provide some utility.
 
  On Fri, Jan 10, 2014 at 4:14 PM, Jesse purplecabb...@gmail.com wrote:
   The index.html issue was iOS, not sure if it still exists.
  
   Windows Phone 7+8 use the browser based geolocation as they have
   implemented the spec,  However because of the way permissions are
  managed,
   there is a native do-nothing stub that simply signal that Location
  Services
   are required.
   Windows8 does some massaging of the api to the WinJS version, and adds
  the
   permissions to the project.
  
   I just spoke ( physically ) with Joe, and with this change, the
  geolocation
   plugin would still exist for Android, it would just add the permission
 to
   the app.  So, Android's plugin would be almost identical to WP7+8 with
  this
   change.
  
   +1 from me, assuming everything will just work.
  
  
  
   @purplecabbage
   risingj.com
  
  
   On Fri, Jan 10, 2014 at 3:40 PM, Joe Bowser bows...@gmail.com wrote:
  
   It never did on Android, you can see this in Mobile-Spec.
  
   On Fri, Jan 10, 2014 at 3:39 PM, Brian LeRoux b...@brian.io wrote:
Does the permission dialogue still ask for index.html ?
   
   
On Friday, January 10, 2014, Joe Bowser wrote:
   
Due to numerous issues found in Geolocation, combined with an
  increase
in reliability of the Web Geolocation, I'm wanting to see us EOL
 the
Geolocation plugin.
   
Reasons for this include:
 * Support for Geolocation on all currently supported versions of
   Android
 * Numerous issues with the current Geolocation plugin that may
involve a full re-write of the Geolocation plugins.
 * The Web Geolocation may be more energy efficient than our own
Geolocation polling.
   
What do people think about deprecating this plugin and recommending
that we use the browser's implementation on Android?
   
Joe

Re: Extending CordovaWebView

2013-12-20 Thread Lindsey Simon

I was wondering how this is progressing.. (maybe there's already a
mechanism for this via config.xml?)
I ask because, in the CLI world, I'm not sure how to update webview
settings for android, in particular because I'd like to make the changes
mentioned here:
http://tmkmobile.wordpress.com/2012/03/04/html5-offline-solution/
super.appView.getSettings().setDomStorageEnabled(true);
super.appView.getSettings().setAppCacheMaxSize(1024*1024*8);
super.appView.getSettings().setAppCachePath(/data/data/com.yourdomain/cache);
super.appView.getSettings().setAllowFileAccess(true);
super.appView.getSettings().setAppCacheEnabled(true);
super.appView.getSettings().setCacheMode(WebSettings.LOAD_DEFAULT);


On Tue, Aug 27, 2013 at 7:45 AM, Ian Clelland iclell...@chromium.orgwrote:

 Issues CB-4671 and CB-4678 added to JIRA for this.

 If I have time this week, I'll take a stab at implementing them.


 On Fri, Aug 23, 2013 at 12:30 PM, Ally Ogilvie aogil...@wizcorp.jp
 wrote:

  Hell. Yes. Plus all the things you just wrote +1
 
  Sharing is caring... Is why i want accessibility in plugins for maximum
  awesomeness.
 
  Sent from my Windows Phone From: Ian Clelland
  Sent: 23/08/2013 23:41
  To: dev@cordova.apache.org
  Subject: Re: Extending CordovaWebView
  On Thu, Aug 22, 2013 at 8:43 PM, Ally Ogilvie aogil...@wizcorp.jp
 wrote:
 
First is that there is no way to use a custom WebView /
 WebViewClient /
ChromeClient class within the CLI system, without writing custom
 native
code after your project has been created.
  
   Not sure about the CLI system, don't really use it. Call me old school
  but
   I love my jars 'n frameworks. There is of course another reason for
 this;
   Cordova is very much a framework for me, NOT a platform. I think it's
   crucial to remember there are many reasons to use Cordova in a project,
  it
   can often be just as a means to get a little extra accessibility and
   browser standardisation out of the WebView. The rest of the app could
 be
   80% native with heaps of other SDKs...
  
 
  That is absolutely a valid use of Cordova, and underscores the point that
  the tools which underlie CLI should be even more stable than CLI itself.
  (Which I think is true right now)
 
  If you're using Cordova in that way, then most of this discussion
 wouldn't
  even apply -- your start-of-project flow can just be
  cordova-android/bin/create newproject com.example.newproject, and then
  you can start editing (or just throw away) the default Activity class.
  Nothing here is going to get in the way of that.
 
 
 
  
   For Mobile Chrome Apps, we have a need to subclass the
  CordovaChromeClient
   class used by our applications.  There's not currently a way to do
 that
  in
   the CLI world
  
   Ian, I know you are using CLI, but IF you were not, you would subclass
   CordovaChromeClient on your application's main Activity?? I see no
  sensible
   way to do it on a Plugin without going thread crazy... I can separate a
   thread if you want to keep this CLI related, but I feel the plugin
   developer use case should be considered in this thread too.
  
 
  The only reason I can imagine for me not to use CLI would be if I was
  creating a single-platform application, for which I knew that I was going
  to be making a lot of native code modifications. In that case, I would
  absolutely introduce my own subclass of CordovaChromeClient, and import
 it
  in my main Activity, and override init() to create the right objects.
 
  But that only works for my application; it doesn't give me anything that
 I
  can share with other developers without also instructing them to modify
  their code in the same way.
 
  There's no way right now to encapsulate this sort of change in a plugin.
  The CordovaWebView/Client/ChromeClient are necessarily singletons, and
 it's
  probably not a good idea to allow plugins to arbitrarily replace them. We
  could conceivably come up with a new sort of plugin that can do it -- and
  you could only install one such plugin per project -- but people could
 also
  just distribute custom app templates which do pretty much the same thing.
 
 
  
   I'm 100% hopeful that at a minimum more methods (WebView and
  WebViewCient)
   can be exposed to the Plugins.
  
 
  For individual methods, right now lets just name them specifically, and
 we
  can add delegation to the plugins for them. Later, I think we can move
 to a
  generic registration / notification architecture, once we have a good
  design for that.
 
  I've heard calls for:
   - disableTouchEvents
   - registerGestureHandler
   - onReceivedHttpAuthRequest
   - getHttpAuthUsernamePassword
 
  We can create some issues for those, and get them implemented.
 
  Ian

Seeking a partner for a SXSW 2014 workshop on Cordova (Sat, March 8)

2013-12-02 Thread Lindsey Simon

Hey fellow Cordova devs,

I'm wondering if anyone might want to partner with me to do a Cordova
workshop at SXSW 2014 http://sxsw.com/interactive.

I made a proposal that has been accepted for a 2.5hr talk for Sat. March
8th, and my plan is to do a walkthrough of taking a relatively simple
website and showing how to convert it to a Cordova app while highlighting
some gotchas and cool things along the way.

If you're interested, please email me off-list before December 8th. I
suspect I can add up to 2 other speakers onto this workshop. You'll receive
a complimentary Gold access pass to SXSW as a speaker, but your
flight/hotel/etc will be something you'd need to figure out.

As far as the time commitment goes I think I'll likely do the bulk of the
prep-work, but I'd love to have someone who's willing to spend some time on
it as well in advance and get together beforehand for a few hours in Austin
to really talk it through on Friday or Saturday. I'm hoping that some of
the audience will actually participate along the way with a computer and so
having someone else to walk around and help folks out in addition to myself
will be helpful.

Also - just a heads up that SXSW can be a big, unruly conference and this
format, the 2.5hr workshop, is something kind of new and experimental, so
I'm hoping to end up with some useful tutorial materials to post online as
well after the fact to make the most of the effort.

-l

Re: Seeking a partner for a SXSW 2014 workshop on Cordova (Sat, March 8)

2013-12-02 Thread Lindsey Simon

Hey Gord,

Sounds awesome! I've also heard from Lorin Beer that he'd like to come
along too. I just sent an email to my contact at SXSW to see how best to
proceed with getting them your info, etc..


On Mon, Dec 2, 2013 at 10:02 AM, Gord Tanner gtan...@gmail.com wrote:

 Hey,

 I can help out if you want.

 Here is a talk I have given in the past on Cordova:
 http://www.youtube.com/watch?v=ZsDPnxBfybo

 Gord


 On Mon, Dec 2, 2013 at 12:47 PM, Lindsey Simon els...@gmail.com wrote:

  Hey fellow Cordova devs,
 
  I'm wondering if anyone might want to partner with me to do a Cordova
  workshop at SXSW 2014 http://sxsw.com/interactive.
 
  I made a proposal that has been accepted for a 2.5hr talk for Sat. March
  8th, and my plan is to do a walkthrough of taking a relatively simple
  website and showing how to convert it to a Cordova app while highlighting
  some gotchas and cool things along the way.
 
  If you're interested, please email me off-list before December 8th. I
  suspect I can add up to 2 other speakers onto this workshop. You'll
 receive
  a complimentary Gold access pass to SXSW as a speaker, but your
  flight/hotel/etc will be something you'd need to figure out.
 
  As far as the time commitment goes I think I'll likely do the bulk of the
  prep-work, but I'd love to have someone who's willing to spend some time
 on
  it as well in advance and get together beforehand for a few hours in
 Austin
  to really talk it through on Friday or Saturday. I'm hoping that some of
  the audience will actually participate along the way with a computer and
 so
  having someone else to walk around and help folks out in addition to
 myself
  will be helpful.
 
  Also - just a heads up that SXSW can be a big, unruly conference and this
  format, the 2.5hr workshop, is something kind of new and experimental, so
  I'm hoping to end up with some useful tutorial materials to post online
 as
  well after the fact to make the most of the effort.
 
  -l

Re: cordova-plugins repo release

2013-11-25 Thread Lindsey Simon

It seems like a shared repo is just a recipe for the troubles of the last
shared repo.


On Mon, Nov 25, 2013 at 1:17 PM, Jesse purplecabb...@gmail.com wrote:

 All of this is fine.

 I also see no reason why you cannot hack in your own repo, just ensure you
 start with the right license.  Nothing says that the apache git has to be
 the origin of code.


 @purplecabbage
 risingj.com


 On Mon, Nov 25, 2013 at 1:01 PM, Anis KADRI anis.ka...@gmail.com wrote:

  It sounds like we all agree. Start hacking on cordova-plugins and
  if/when it's mature move it to its own repository. Publishig from
  cordova-plugins should not be an issue.
 
  On Mon, Nov 25, 2013 at 11:52 AM, Braden Shepherdson
  bra...@chromium.org wrote:
   I'm not sure if I was clear: I am content with the current repo setup
 and
   argue for keeping it as it is. The main core plugins are in their own
  repos
   and I support that. On the other hand I support having the
  cordova-plugins
   repo as an incubator for experimental projects that either die or
  graduate
   to having real repos.
  
   Braden
  
  
   On Mon, Nov 25, 2013 at 2:44 PM, Michal Mocny mmo...@chromium.org
  wrote:
  
   Okay -- while I do agree with Braden -- in the interests of not
 debating
   again, I'll concede to not publishing core plugins from a shared repo
  (if
   for no other reason than for consistency with the other core plugins).
   But
   I think its still worth having a cordova-plugins repo for early
   experiments/incubation period so you don't have to file a ticket with
  INFRA
   before you even get started.
  
   Seems the two published plugins are keyboard and statusbar, so we
 should
   get INFRA tickets to make repos for those?
  
   -Michal
  
  
   On Mon, Nov 25, 2013 at 10:47 AM, Brian LeRoux b...@brian.io wrote:
  
Super disagree about putting src into a single big repo. I get why
 we
  do
that. I do not buy that we 'have too many repos' or that complexity
 is
minimized by combining. Anyhow: not a discussion I think is even
  worth us
having AGAIN. =/
   
   
On Mon, Nov 25, 2013 at 10:32 AM, Braden Shepherdson 
   bra...@chromium.org
wrote:
   
 Hang on a second:

 The release you send to the plugman registry doesn't care about
 git.
   You
 point it at a (sub)directory and it uploads the plugin. The
 version
  is
set
 by the plugin.xml of that plugin.

 If we want tags for when those plugins were pushed to npm, what's
  wrong
 with tags like whateverplugin-1.0.0? It's a little cluttered to
  see
   all
 the tags for all the plugins, but you can still see all the
 releases
   of a
 given plugin. They're in this repo precisely because they're small
  or
 experimental and not ready for their own repos yet.

 -10 to one repo per plugin; we have way too many repos already,
 and
   this
 cordova-plugins repo is intended to be the catchall place for
 small
  and
 experimental plugins.

 Braden




 On Mon, Nov 25, 2013 at 11:05 AM, Michal Mocny 
 mmo...@chromium.org
  
 wrote:

  Would that only be true if you shared readable tag names between
plugins?
   If we used tags unique to each plugin, perhaps by prefixing
 tags
   with
 the
  target plugins' name, then plugin releases would be isolated,
  right?
 
  -Michal
 
 
  On Fri, Nov 22, 2013 at 8:02 PM, Jesse purplecabb...@gmail.com
 
wrote:
 
   The issue that if use a tag to signify the new version, then
 the
   tag
is
   applied to all plugins in the repo. This is probably not a big
  deal
for
   minor bumps, but when a plugin needs a major bump, they all
  will.
   So
 you
   will/could have a plugin with a major version bump even though
  the
code
  has
   not changed.
  
  
  
   @purplecabbage
   risingj.com
  
  
   On Fri, Nov 22, 2013 at 6:36 PM, Michal Mocny 
  mmo...@chromium.org
   
  wrote:
  
I don't understand, whats the problem?  I thought you
 publish
plugins
  by
git-repo  subdir  hash -- so multiple plugins makes no
difference.
   
The master  dev branch deal was to do with cordova-3.0
 users
   that
 did
   not
support plugin repo install from !master branch, right?  But
  none
of
   these
plugins in cordova-plugins existed back then, so we just set
   engine
requirement to 3.1?
   
-Michal
   
   
On Fri, Nov 22, 2013 at 1:32 PM, Steven Gill 
stevengil...@gmail.com
 
wrote:
   
 +1 on one plugin per repo. Would making releasing and
  tagging
much
simpler.


 On Fri, Nov 22, 2013 at 1:29 PM, Carlos Santana 
  csantan...@gmail.com
 wrote:

  Yep that's the problem with having independent plugins
 in
  a
 single
repo,

Re: Cordova Debug Mode

2013-11-21 Thread Lindsey Simon

On Thu, Nov 21, 2013 at 11:37 AM, Ian Clelland iclell...@chromium.orgwrote:

 David and I were talking about this this morning, and since Joe brought it
 up as well, we should probably get the list involved.

 I think that there is some value in having Debug and Release builds of
 Cordova projects. I don't know if the platforms have any way to do this
 already, but it seems like there are a lot of behaviours that are
 incredibly useful for testing and development, which shouldn't ever be
 enabled in released applications.

 Off the top of my head:

 * All of our Console / ADB / NSLog Logging


If you disable logging by default, make it a preference somewhere. Because
I always wanted console/Java logging in production Android apps to capture
wtf was going on for my users all the time.


 * Enabling the remote debugger in Android 4.4+
 * (maybe) disabling the network whitelist

 I'm sure there are others -- we have a plugin for chrome.alarm that is
 *supposed* to have a 1-minute minimum timeout, but I'd love to be able to
 make that 1/4s in debug mode only.

 Would it make sense to have a build flag for this? cordova build --debug,
 cordova build --release; something like that (bikeshed colours welcome).
 I don't think that config.xml is the place for it; it seems like it should
 be lower than that, but I'm not exactly sure how it should be set. There
 will probably need to be platform-specific implementations, but it would be
 good to have a cross-platform way of turning it on and off.

 Thoughts?

 Ian

Re: Cordova Debug Mode

2013-11-21 Thread Lindsey Simon

On Thu, Nov 21, 2013 at 12:58 PM, Ian Clelland iclell...@chromium.orgwrote:

 On Thu, Nov 21, 2013 at 3:22 PM, Lindsey Simon lsi...@commoner.com
 wrote:

  On Thu, Nov 21, 2013 at 11:37 AM, Ian Clelland iclell...@chromium.org
  wrote:
 
   David and I were talking about this this morning, and since Joe brought
  it
   up as well, we should probably get the list involved.
  
   I think that there is some value in having Debug and Release builds
  of
   Cordova projects. I don't know if the platforms have any way to do this
   already, but it seems like there are a lot of behaviours that are
   incredibly useful for testing and development, which shouldn't ever be
   enabled in released applications.
  
   Off the top of my head:
  
   * All of our Console / ADB / NSLog Logging
  
 
  If you disable logging by default, make it a preference somewhere.
 Because
  I always wanted console/Java logging in production Android apps to
 capture
  wtf was going on for my users all the time.


 Do you mean console.log() statements from application code? Those should
 definitely be allowed, and if you have the console plugin installed, then
 they can go to the device's log. I meant that we could shut up all of the
 logging that goes on inside Cordova and inside our plugins. If *those*
 messages are still useful in production apps, then we should clean them up
 a bit :)


Ah, no worries then - you mean internal logging ;) Carry on.

Re: config.xml discussion, we need to talk

2013-09-26 Thread Lindsey Simon

On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana csantan...@gmail.comwrote:

 Branden,
On Android, it's really easy to load XML files from res/xml/foo.xml,
 so that's where we put it.

 Easy for who?
 I think is difficult for web developer to not find it in www/config.xml and
 start searching for it

 I don't know much about Android so maybe I'm putting my foot in my mouth
 because it's too complex to read the file from www/


When you say www are you referring to project/www or
project/platform/android/assets/www?




 --Carlos


 On Thursday, September 26, 2013, Braden Shepherdson wrote:

  I am strongly opposed to splitting into one file per platform. We want to
  support platform tags in config.xml, which will allow platform-specific
  content within the single config.xml.
 
  There are good reasons why the CLI moves the config.xml on some
 platforms.
  On Android, it's really easy to load XML files from res/xml/foo.xml, so
  that's where we put it. We should be deleting the
  platforms/android/assets/www/config.xml though, since it's an unused
  duplicate and confusing.
 
  Braden
 
 
  On Wed, Sep 25, 2013 at 4:59 PM, Carlos Santana csantan...@gmail.com
 javascript:;
  wrote:
 
   I was not trying to be purist with the w3c www/config.xml
  
   I just want to see some consistency across all platforms for
  configuration
   settings for a Cordova App.
  
   The same way I have a single index.html, app.css and app.js. I want see
  one
   config.xml for all platforms inside www/ or many config.xml per
 platform
   config.ios.xml, config.android.xml, etc... But as a web developer I'm
   excepting all the files that I need to modify inside www/ using CLI or
  not
  
   Even if I have to run something like ./bin/processconfig.sh to
 propagate
   changes from the /www/config.xml
  
   As web developer I might update the config.xml once for every 100 edits
  to
   my app web files (HTML, JS, CSS)
  
   TLDR: consistency wins over correctness
  
   PS: what is the phonegap team doing? I think you tell users to edit one
   config.xml for the web app and pgbuild takes care of the rest
  
  
   -- Carlos
  
   On Wednesday, September 25, 2013, Braden Shepherdson wrote:
  
I'm in favour of CLI (platform parsers, probably) deleting this
www/config.xml that they don't use. It's a waste of space and has
   confused
people in the past.
   
It even confused the iOS prepare code and caused that odd my project
doesn't work if it starts with x, y or z bug (because
  xFactor/config.xml
sorts after www/config.xml, and it was blindly taking the first one).
   
Braden
   
   
On Wed, Sep 25, 2013 at 4:22 PM, Bryan Higgins 
  bhigg...@blackberry.com javascript:;
   javascript:;
wrote:
   
 Thanks for the clarification. BlackBerry happened to luck out
 because
   we
 expect config.xml in www.

 Perhaps copying of config.xml should become a responsibility of the
 platform parsers.

 I can understand moving config.xml to root or cordova for the
 reason
stated
 in the JIRA, but my vote would be to keep it config.xml rather
 than
 app.xml.


 On Wed, Sep 25, 2013 at 3:55 PM, Jesse purplecabb...@gmail.com
   wrote:

  I am not saying deviate, I am saying, what is it supposed to be?
 If
   you
  look at the various platforms you will see it is all over the
 map.
 
  Looking at Android code, and talking to Joe, the only location
 that
   the
  config.xml file is loaded from is in res/xml, and the fact that
 cordova-cli
  creates another one sitting in the www folder is just irrelevant
  sloppiness.
 
  It may make sense for the config.xml file to sit in the root/www
   folder
 of
  the CLI project, but in reality at runtime, it's location will
 vary
   by
  platform.
 
 
 
  @purplecabbage
  risingj.com
 
 
  On Wed, Sep 25, 2013 at 12:29 PM, Bryan Higgins 
bhigg...@blackberry.com
  wrote:
 
   www/config.xml aligns nicely with the w3c widget spec [1]. Why
   would
we
   want to deviate?
  
   [1]
 http://www.w3.org/TR/widgets/#reserved-file-and-folder-names
  
  
   On Wed, Sep 25, 2013 at 3:23 PM, Jesse 
 purplecabb...@gmail.com
 wrote:
  
Seems any project created with the CLI has a config.xml in
 the
   www
   folder.
[1]
Why do we have 2 of these?
   
I also recently closed a defect created by Carlos, stating
 that
   WP8
 did
   NOT
have it's config.xml in the www folder. [2] Now I am not
 sure I
 should
   have
called this invalid, however, after creating a new WP8
 project
   with
 the
CLI, I see a config.xml in the www folder AND one in the app
   root.
 wtf?
   
There is an open issue [3] to re-org config files, where
 Braden
 states
   We
already have plans to move

Re: phonegap build doesn't preserve symlink paths

2013-09-16 Thread Lindsey Simon

Ok cool thanks fellas - I didn't know if this was a bug or if maybe I was
just doing it wrong..



On Mon, Sep 16, 2013 at 12:03 PM, Andrew Grieve agri...@chromium.orgwrote:

 Bug filed: https://issues.apache.org/jira/browse/CB-4828

 Thanks Lindsey.


 On Mon, Sep 16, 2013 at 2:17 PM, Shazron shaz...@gmail.com wrote:

  Lindsey, always file an issue. Thanks :)
 
 
  On Mon, Sep 16, 2013 at 10:26 AM, Lindsey Simon els...@gmail.com
 wrote:
 
   In my project/www I symlink my js/css/img directories to another
  directory
   in my tree (where my server deploys from).
  
   When I run `phonegap build android` the symlinks get copied to
   platforms/android/assets/www/css but the path is no longer valid.
  
   Anyone else experience this? Should I file a bug? (and attempt a CL?)
  
   Thanks

phonegap build doesn't preserve symlink paths

2013-09-16 Thread Lindsey Simon

In my project/www I symlink my js/css/img directories to another directory
in my tree (where my server deploys from).

When I run `phonegap build android` the symlinks get copied to
platforms/android/assets/www/css but the path is no longer valid.

Anyone else experience this? Should I file a bug? (and attempt a CL?)

Thanks

Re: phonegap build doesn't preserve symlink paths

2013-09-16 Thread Lindsey Simon

On Mon, Sep 16, 2013 at 1:09 PM, Michal Mocny mmo...@chromium.org wrote:

 Creating symlinks to absolute paths might be sufficient to fix your issue
 right now.


Good idea, that totally worked for now.




 On Mon, Sep 16, 2013 at 12:44 PM, Lindsey Simon lsi...@commoner.com
 wrote:

  Ok cool thanks fellas - I didn't know if this was a bug or if maybe I was
  just doing it wrong..
 
 
 
  On Mon, Sep 16, 2013 at 12:03 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   Bug filed: https://issues.apache.org/jira/browse/CB-4828
  
   Thanks Lindsey.
  
  
   On Mon, Sep 16, 2013 at 2:17 PM, Shazron shaz...@gmail.com wrote:
  
Lindsey, always file an issue. Thanks :)
   
   
On Mon, Sep 16, 2013 at 10:26 AM, Lindsey Simon els...@gmail.com
   wrote:
   
 In my project/www I symlink my js/css/img directories to another
directory
 in my tree (where my server deploys from).

 When I run `phonegap build android` the symlinks get copied to
 platforms/android/assets/www/css but the path is no longer valid.

 Anyone else experience this? Should I file a bug? (and attempt a
 CL?)

 Thanks

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2013-01-05 Thread Lindsey Simon (JIRA)

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

Lindsey Simon commented on CB-1185:
---

For some closure on this - I think what fixed it for us was some handing of
pause/resume with on short timeouts and with canceling on one or the other to
deal with pause and resume being called nearly back to back and perhaps twice
really close together when we would come up. Especially happens when we'd
resume from a notification intent.

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: Joe Bowser
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] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-14 Thread Lindsey Simon (JIRA)

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

Lindsey Simon commented on CB-1185:
---

[~gregavola] Since you do have an easy to repro situation for some magical
reason, can you try adding this to the Activity to see if it makes any
difference? I started wondering if it wasn't a cache/memory issue.

@Override
public void onResume() {
this.appView.clearCache(false);
this.appView.destroyDrawingCache();
super.onResume();
}

When Application is placed in background and resumed, the UI is frozen
--

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-13 Thread Lindsey Simon (JIRA)

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

Lindsey Simon commented on CB-1185:
---

So my simple app test-case didn't reproduce the bug last night.
I'll put up a link to a github clone with my changes shortly.. but, in the
meantime - @Untappd = what's your high-level main components/lib setup?

For Twist it's:
- Zepto
- Underscore/Backbone
- Hogan templates
- GPS watchPosition / stopWatchPosition action
- Bing Maps

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

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-13 Thread Lindsey Simon (JIRA)

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

Lindsey Simon commented on CB-1185:
---

Ok, here's a link to a repo for perusal, and in particular the JS file:
https://github.com/elsigh/cordova-android-anr/blob/master/assets/www/js/index.js

I tried with this running just turning off the data and wifi and the app
continue to run for about 30 minutes no problem, it would just get the error
for the fetch and then the timeout fired and another would go off. So I don't
know that it's just that.

It's unfortunately some combo of moving parts. Ugh.

Things I've not tried yet but want to:
* Sending multiple XHRs at once and looping/re-fetching once they're all
complete.
* Including battery listeners
* Using backbone in this equation.

Also - @Untappd folks - do you guys use Urban Airship for push? I wonder if
it's relevant.

thanks

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

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-13 Thread Lindsey Simon (JIRA)


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

Lindsey Simon commented on CB-1185:
---

One more bit... I went looking back at a prior crash log and see:
11-02 16:56:21.803 D/STATUSBAR-BatteryController(  779): onReceive() - 
ACTION_BATTERY_CHANGED
11-02 16:56:21.803 D/STATUSBAR-BatteryController(  779): onReceive() - level:99
11-02 16:56:21.803 D/STATUSBAR-BatteryController(  779): onReceive() - plugged:0
11-02 16:56:21.803 D/STATUSBAR-BatteryController(  779): onReceive() - 
BATTERY_STATUS_DISCHARGING: stat_sys_battery
11-02 16:56:21.833 D/dalvikvm( 2234): GC_CONCURRENT freed 1779K, 27% free 
14122K/19107K, paused 8ms+3ms
11-02 16:56:21.983 D/Zygote  (  333): Process 15854 terminated by signal (11)
11-02 16:56:21.993 W/InputDispatcher(  643): channel ~ Consumer closed input 
channel or an error occurred.  events=0x8
11-02 16:56:21.993 E/InputDispatcher(  643): channel ~ Channel is unrecoverably 
broken and will be disposed!
11-02 16:56:21.993 W/InputDispatcher(  643): Attempted to unregister already 
unregistered input channel
11-02 16:56:21.993 I/WindowManager(  643): WINDOW DIED Window{4210e748 
XXX.X.XXX/XXX.X.XXX.XX paused=false}
11-02 16:56:21.993 I/ActivityManager(  643): Process com.twist.android (pid 
15854) has died.

What about this being relevant?:
http://stackoverflow.com/questions/4973310/signal-11-sigsegv-crash-android
aka clearCache and destroyDrawingCache ?

(stabbing in dark)

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

2012-11-13 Thread Lindsey Simon (JIRA)


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

Lindsey Simon commented on CB-1185:
---

Hrm... I started looking higher up in my log posted above and found something 
that looks very much like what's being discussed in this thread (and please 
forgive me if somehow is not relevant.. I'm kinda shooting at fish in a barrel 
here).

http://www.jasonshah.com/handling-android-2-3-webviews-broken-addjavascriptinterface/

From my log:
11-02 16:56:21.263 D/DroidGap(15854): Resuming the App
11-02 16:56:21.263 I/CpuGovernorService(  643): intent action: 
android.intent.action.SCREEN_ON
11-02 16:56:21.263 I/SamplingRateChangeProcessor(  643): Decreased sampling 
rate.
11-02 16:56:21.263 D/CordovaWebView(15854):  loadUrlNow()
11-02 16:56:21.263 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:21.263 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled

...

11-02 16:56:21.563 W/System.err(15854): at 
android.webkit.BrowserFrame.stringByEvaluatingJavaScriptFromString(Native 
Method)
11-02 16:56:21.563 W/System.err(15854): at 
android.webkit.BrowserFrame.loadUrl(BrowserFrame.java:303)
11-02 16:56:21.563 W/System.err(15854): at 
android.webkit.WebViewCore.loadUrl(WebViewCore.java:2817)
11-02 16:56:21.563 W/System.err(15854): at 
android.webkit.WebViewCore.access$1900(WebViewCore.java:76)
11-02 16:56:21.563 W/System.err(15854): at 
android.webkit.WebViewCore$EventHub$1.handleMessage(WebViewCore.java:1668)
11-02 16:56:21.563 W/System.err(15854): at 
android.os.Handler.dispatchMessage(Handler.java:99)
11-02 16:56:21.563 W/System.err(15854): at 
android.os.Looper.loop(Looper.java:137)
11-02 16:56:21.563 W/System.err(15854): at 
android.webkit.WebViewCore$WebCoreThread.run(WebViewCore.java:956)
11-02 16:56:21.563 W/System.err(15854): at 
java.lang.Thread.run(Thread.java:856)

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

2012-11-13 Thread Lindsey Simon (JIRA)


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

Lindsey Simon commented on CB-1185:
---

[~bowserj]
Pasting more of the logs in case there's something of interest there. 
My device is a Galaxy S3, so yah Android 4.x

11-02 16:56:00.243 V/AlarmManager(  643): waitForAlarm result :8
11-02 16:56:00.243 V/AlarmManager(  643): ClockReceiver onReceive() 
ACTION_TIME_TICK
11-02 16:56:00.243 W/AlarmManager(  643): FACTORY_ON= 0
11-02 16:56:00.323 D/KeyguardUpdateMonitor(  643): received broadcast 
android.intent.action.TIME_TICK
11-02 16:56:00.333 D/KeyguardUpdateMonitor(  643): handleTimeUpdate
11-02 16:56:00.353 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:00.353 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:00.363 D/STATUSBAR-Clock(  779): onReceive() - ACTION_TIME_TICK
11-02 16:56:00.363 D/STATUSBAR-Clock(  779): updateClock :4:56 PM
11-02 16:56:00.413 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:00.413 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:00.413 D/STATUSBAR-DateView(  779): updateClock :11/02/2012
11-02 16:56:00.564 D/ClockWidget(  643): refreshTime()
11-02 16:56:00.604 D/ClockWidget(  643): TTS Message = It is 4 : 56 PM, Friday, 
November 2
11-02 16:56:01.545 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:01.545 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:01.555 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:01.555 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:02.986 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:02.986 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:03.006 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:03.006 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:04.107 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:04.107 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:04.117 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:04.117 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:05.559 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:05.559 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:05.559 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:05.559 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:07.251 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:07.251 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:07.271 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:07.271 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:07.511 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:07.511 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:08.542 D/BatteryService(  643): update start
11-02 16:56:08.542 D/BatteryService(  643): level:99 scale:100 status:3 
health:2 present:true voltage: 4261 temperature: 290 technology: Li-ion AC 
powered:false USB powered:false icon:17303121 invalid charger:0
11-02 16:56:08.552 D/KeyguardUpdateMonitor(  643): received broadcast 
android.intent.action.BATTERY_CHANGED
11-02 16:56:08.552 D/KeyguardUpdateMonitor(  643): handleBatteryUpdate
11-02 16:56:08.552 D/ThermistorObserver(  643): mBatteryBRForAMOLED : 
onReceive() : newTemperature : 290
11-02 16:56:08.552 D/STATUSBAR-BatteryController(  779): onReceive() - 
ACTION_BATTERY_CHANGED
11-02 16:56:08.552 D/STATUSBAR-BatteryController(  779): onReceive() - level:99
11-02 16:56:08.552 D/STATUSBAR-BatteryController(  779): onReceive() - plugged:0
11-02 16:56:08.552 D/STATUSBAR-BatteryController(  779): onReceive() - 
BATTERY_STATUS_DISCHARGING: stat_sys_battery
11-02 16:56:10.815 E/MP-Decision( 1366): UP Ld:92 Nw:1.99 Tw:140 
rq:1.00 seq:147.00
11-02 16:56:11.155 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:11.155 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:11.175 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:11.175 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:11.185 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:11.185 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:11.195 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:11.195 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:11.205 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:11.205 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:11.215 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:11.215 D/FirewallPolicy(  643): isUrlBlocked - Policy disabled
11-02 16:56:11.305 D/FirewallPolicy(  643): getURLFilterEnabled(true)
11-02 16:56:11.305 D/FirewallPolicy

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-08 Thread Lindsey Simon (JIRA)

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

Lindsey Simon commented on CB-1185:
---

One other thing.. the last log from my app (awhile before this) is this one
from UrbanAirship. h. (just throwing this out there to see if Untappd might
also be using UA, or else this is just a red herring)

11-08 21:00:13.585 I/Twist - UALib( 691): Sending 4 events.
11-08 21:00:13.595 I/Twist - UALib( 691): Sending Analytics to:
https://combine.urbanairship.com/warp9/

When Application is placed in background and resumed, the UI is frozen
--

Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch,
0002-Uncomment.patch, cordova-2.0.0.jar

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-07 Thread Lindsey Simon (JIRA)

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

Lindsey Simon commented on CB-1185:
---

I can't even reproduce it in our app, as much as I try.
I'm fantasizing that I'll be able to. If I find a way, I'll definitely try to
distill it.

When Application is placed in background and resumed, the UI is frozen
--

Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch,
0002-Uncomment.patch, cordova-2.0.0.jar

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-06 Thread Lindsey Simon (JIRA)

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

Lindsey Simon commented on CB-1185:
---

on keepRunning - I found a ref for it, but we don't change the default (which
is true right?)

When Application is placed in background and resumed, the UI is frozen
--

Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch,
0002-Uncomment.patch, cordova-2.0.0.jar

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-06 Thread Lindsey Simon (JIRA)

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

Lindsey Simon commented on CB-1185:
---

We build locally, but need to keepRunning for our app to work. We're
gathering geopoints and beaconing them to a server while backgrounded.

When Application is placed in background and resumed, the UI is frozen
--

Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch,
0002-Uncomment.patch, cordova-2.0.0.jar

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-06 Thread Lindsey Simon (JIRA)

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

Lindsey Simon commented on CB-1185:
---

We just got logs with a crash like this, but nothing new here really:

11-06 22:38:35.070 D/DroidGap( 5361): onMessage(onNativeReady,null)
11-06 22:38:35.070 D/DroidGap( 5361):
onMessage(onPageFinished,file:///android_asset/www/settings)

When Application is placed in background and resumed, the UI is frozen
--

Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch,
0002-Uncomment.patch, cordova-2.0.0.jar

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

2012-11-06 Thread Lindsey Simon (JIRA)

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

Lindsey Simon commented on CB-1185:
---

Actually, apologies - that log line and when I think the crash happened don't
line up, the more I look at the logs. I got excited because I saw an earlier
mention on this thread that had these called out, but they're common enough in
my logs (they look like they just represent page load).

When Application is placed in background and resumed, the UI is frozen
--

Attachments: 0001-Fix-issue-with-pause-resume-freezing-the-UI.patch,
0002-Uncomment.patch, cordova-2.0.0.jar

plugin not in registry search (org.chromium.identity) but it's there

Re: Rendering Performance Measurement for Cordova

Re: Camera does too many things!!!!

Re: [Android] Deprecation of Geolocation on Android

Re: Extending CordovaWebView

Seeking a partner for a SXSW 2014 workshop on Cordova (Sat, March 8)

Re: Seeking a partner for a SXSW 2014 workshop on Cordova (Sat, March 8)

Re: cordova-plugins repo release

Re: Cordova Debug Mode

Re: Cordova Debug Mode

Re: config.xml discussion, we need to talk

Re: phonegap build doesn't preserve symlink paths

phonegap build doesn't preserve symlink paths

Re: phonegap build doesn't preserve symlink paths

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

[jira] [Commented] (CB-1185) When Application is placed in background and resumed, the UI is frozen

27 matches

Site Navigation

Mail list logo

Footer information