We definitely need to do better with understanding the general user. We can't predict however how they choose to do development ultimately but I believe the CLI is getting there -- I think it will be a building block towards (maybe) improved tooling, if not by us, then the community (which I hope they will contribute back).
Personally its easier for me to use bin/create and plugman, not only because of the rapid turnaround time for debugging, but also to eliminate side effects possibly from the CLI. This has caused me to missed bugs however (like CB-5031). On Thu, Oct 17, 2013 at 8:03 AM, Braden Shepherdson <bra...@chromium.org>wrote: > Viras, thank you for your feedback. I find myself missing Google's Consumer > Ops people from when I was working on G+, whose job it was to keep their > finger on the user community's pulse, reviewing the feedback given inside > the apps, on blogs, comments, Groups, etc., and pass along the major pain > points and feature requests to the developers. I've learned about several > new pain points in this email thread - things that are not in the > CLI/Plugman JIRA or elsewhere. > > We're in the unfortunate position that the people who are primarily working > on these tools are not using them in anger, building apps with them. > > Here are some things I've learned from this thread and will be treating > like CLI feature requests: > > - Command-line flags for platform add that let's you specify (a) to install > source rather than the jar, where relevant, (b) to install from a given > directory instead of .cordova/libs. (Currently you can achieve (b) by > editing .cordova/config.json, but that's both global and lame.) > > - There are needs to make various edits to the WebView's logic on Android, > and probably elsewhere too. In the short term, we should make by-hand > editing of the source code easier (above); in the long term any of these > that are more common than weird one-off cases should be turned into > plugins, or failing that, preferences in the platform's config.xml. > > - When people talk about CLI not working with IDEs, what is meant is that > if you load your platforms/ios in Xcode, for example, you can't edit the > web assets because they'll be overwritten on prepare. It's not a normal > Xcode project in that sense. We already have a feature request for this. > Xcode in particular makes this difficult, since it doesn't handle symlinks > well. Eclipse is somewhat better. I'm not sure how much we can really do > here, beyond educating our users about where they should actually be making > their edits (top-level www, inside the plugins, merges, etc.). > Alternatively, we support cordova build, run and emulate, which are > designed to hide the use of Xcode, Eclipse and friends completely. My > Eclipse is actually broken right now, some PermGen space nonsense, and I > can still build Android apps cheerfully. I only use the IDEs now when I > need to debug the native code. But I work primarily on CLI and Plugman, and > use vim for editing, so I have little desire or cause to use the IDEs. > > Braden > > > > > On Thu, Oct 17, 2013 at 8:31 AM, Lucas Holmquist <lholm...@redhat.com > >wrote: > > > while not perfect, i like the CLI/plugman . it's still in its infancy > and > > can get better. > > > > > > > > On Oct 17, 2013, at 12:13 AM, Viras <vi...@users.sourceforge.net> 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 <mmo...@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 > > > > >
