cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Viras <vi...@users.sourceforge.net>
Subject Re: config.xml discussion, we need to talk
Date Thu, 17 Oct 2013 04:13:13 GMT
my view on this discussion:

I've used the CLI to release the latest version of GOFG Sports Computer 
for Windows Phone. The support for the "merges" directory is a fantastic 
feature which allows me to focus on the javascript code using e.g. the 
NetBeans IDE - I can finally handle all my platform specific code from 
JavaScript in one consistent directory structure - which is what Cordova 
should be about.

In addition the CLI forces you to write clean code (not implying that 
the other method forces to write messy code). If you need something 
native write a clean plugin for it (which also makes the code reusable) 
- no need to mess around in the native projects code - this also makes 
upgrading cordova much easier.

Once I've done the Windows Phone version I've simply added Android as a 
platform, build it and I was done - no need for fiddling around with SDK 
/ IDE setup etc (besides actually installing it). So CLI is my favorite 
way to develop now - and it is far more powerful than the old approach 
(in my opinion) - since it saves you from fiddling around with project 
settings, etc. when you do a multi-platform release.

Oh yes - and GOFG SC uses two custom plugins, 5 official plugins and 
cordova 3.0 - so it is a bit beyond the "Hello World" application....

And I do not agree that it isn't possible to work with the native IDEs 
with their own projects - this is simply wrong since you can always go 
to the "platforms" directory and open the platform-projects using their 
native IDE from there (I've done this myself for e.g. plugin 
development).

Still I agree that both versions should be supported - but don't make 
the assumption that the CLI is for "n00bs" only!

Best,
Wolfgang

Am 2013-10-16 23:11, schrieb Joe Bowser:
> On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny <mmocny@chromium.org> 
> wrote:
>> Anis: Totally agrees, but its important to highlight that both 
>> directions
>> for that arguments hold.  We've done our best to support bin/ scripts 
>> post
>> 3.0, yet blanket statements like "CLI should not be used with IDE", 
>> or "CLI
>> sucks unless you just doing something trivial" are being thrown 
>> around,
>> which are harmful in my opinion, and I don't think its fair that some 
>> of us
>> are promoting that message to users.
>> 
> 
> I don't think we're communicating with our users at all, so I don't
> see how this could be communicated.  When users communicate their
> frustrations, it's usually something like this
> (http://www.infil00p.org/config-xml-changes-for-ios-and-android/#comment-10731)
> and this
> (http://www.infil00p.org/introducing-cordova-3-0-0-for-android/#comment-10694).
> 
>> CLI works well for me, and while its not perfect, I strive to learn 
>> its
>> limitations and make it better, not condemn it.
> 
> I avoid it because it's not developed for me, or developers like me
> who like to see a big pile of output when things fail.  I avoided
> having any part in its development because I thought it was the wrong
> way to do things.  I assumed that the majority of users actually
> wanted this and that I should do my best to work around this, but with
> the backlash that we're getting, such as the blog posts and some
> comments on the Google Groups, it seems that this is a feature very
> few people actually wanted.
> 
>> As far as the CordovaWebView use case, I actually have never tried 
>> that.
>>  Has anyone bothered to make sure it works well post-3.0, or does Joe 
>> have
>> a point that we missed addressing this?
> 
> We have JUnit unit tests in the Android repository to make sure that
> this still works.  However, I would like to see this test case
> revisited since it may be more appropriate to have CordovaActivity be
> inherited instead of CordovaInterface, or for both to be supported.
> This is so that we can make more hybrid applications and deal with the
> fact that we're so brutally non-complaint with Android UI guidelines
> instead of just ignoring it.  I'll probably bring this up and present
> more source code when it's ready to explain why we need this feature
> in the next couple of weeks, and why it's important to respect the
> platform, even when the platform doesn't respect the web.

-- 
GOFG - Get On Fat Guy
http://www.gofg.at/ - powered by Cordova

Mime
View raw message