I think we should seriously consider this, but agree that it should wait
until after 3.0. It's a good point that 90% of the code formerly in the jar
will be copied in from plugins now.
Braden
On Tue, Jun 18, 2013 at 6:12 AM, Jesse MacFadyen wrote:
> The wp7 change Benn mentioned has several mot
The wp7 change Benn mentioned has several motivations behind it. The
windows phone permission model and the app store's static analysis
decide permission based on linkage, so having 1 library dll would
require all permissions, and a separate dll for each API was unwieldy.
In my mind, given our mov
We def do not want to do this before 3.0 ...too big of a change.
I think while we are seeing lots of benefits in issue tracking for iOS
I share Joe's anxiety that we may end up with cowboy upgrades
conflicting with project upgrades. Lets get 3 out the door and have a
look after.
Added to roadmap
I don't think it's caused any issues on iOS, and it definitely has improved
bug reports. That's because you get better stack traces on iOS though, I
don't think the same is true for Android.
I'll also point out that with 3.0, the majority of the code will already be
in the form of source files sin
We surely have data on this, since iOS has transitioned; how many issues have
been raised on iOS because someone mucked around where they shouldn't have?
Perhaps not directly applicable to Android, but it would perhaps be a rough
estimate.
___
Kerri Shotts
photo
My bet is six months
On Mon, Jun 17, 2013 at 2:32 PM, Filip Maj wrote:
> I'm ambivalent on this issue.
>
> To play devil's advocate, Joe, it hasn't been an issue on iOS or Windows
> Phone, so any speculation that this _will_ be an issue in the future is
> just that: speculation.
>
> If anything w
I'm ambivalent on this issue.
To play devil's advocate, Joe, it hasn't been an issue on iOS or Windows
Phone, so any speculation that this _will_ be an issue in the future is
just that: speculation.
If anything we should set an over/under on how long it will take after
introducing this change bef
+1
I really like having source code. On Windows Phone we have moved from a
pre-compiled .dll to just the source as well. Like Kerri said, it is very
helpful when stepping through your application and debugging any problems
you might have, as well as getting more people looking at the code and
under
-1
This only caters to a minority of our users. Most of our users can't debug
Cordova, since they can't write Java (or even Javascript) well.
I think this will have far more things break and we'll have a huge backlash
from our mainstream users, just like when we deprecated plugins.
On Jun 17, 201
Big +1 from me: Being able to debug in to the IOS internals has saved me
more than once. Usually a change in the internals isn't necessary, but
often elucidates why my approach is failing, more than an error message (or
a silently failing error) does.
My only potential concern is build time. My ma
I'd like to propose that instead of having the create script compile a
version of Cordova into a .jar, that instead it copies over the source
files instead.
My main motivation is that doing so will make debugging native code much
easier since the source code will show up in Eclipse / Android Studi
11 matches
Mail list logo
