cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Viras <>
Subject Re: config.xml discussion, we need to talk
Date Thu, 17 Oct 2013 16:10:30 GMT
This might be true - it took me quite some time to figure out how the 
CLI actually works - despite also having to fix one or two bugs for the 
WPX implementation of the CLI code (as well as the Windows 8 CLI code). 
But still I would hate to see the CLI go, since I think once you are 
used to it, it saves you quite a lot of time (I still have those old 
documents which guide me through the setup of the IDE projects for the 
different platforms - which is now mostly obsolete).

So I guess supporting both methods is the way to go... :)


Am 2013-10-17 16:13, schrieb Michal Mocny:
> Thanks so much for chiming in, I'm very happy to see that you've 
> figured
> out how to leverage the benefits and avoid the drawbacks of the new
> workflow, and that it has led to increased productivity for you.
> I do think that perhaps it is still too difficult for every developer 
> to
> learn what you already have.
> -Michal
> On Thu, Oct 17, 2013 at 12:13 AM, Viras <> 
> wrote:
>> 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 <>
>>> 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
>>> (**config-xml-changes-for-ios-**
>>> and-android/#comment-10731<>
>>> )
>>> and this
>>> (**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
>> - powered by Cordova

GOFG - Get On Fat Guy - powered by Cordova

View raw message