Thank you to everyone (all 229 of you) who responded to my PhoneGap/Cordova survey. The survey asked what version of PhoneGap or Cordova you used, how quickly you upgrade, and asked what problems you had (in general) with PhoneGap and Cordova. I've included an Excel sheet of all the results below. Let's look at the numerical results first.
First up - what version of Cordova are you using.
I expected to see a set of folks still on 2.9.X as the 3.X change was big, and there does seem to be a set of folks not upgrading, but they are in the minority. This is good to know. Now let's look at the PhoneGap side.
Pretty much the same thing. No surprise there. Next I asked how quickly folks upgraded.
It looks like - for the most part - people upgrade when they can or right away. Which is a good thing I guess. It implies there isn't a strong barrier to upgrading.
So that covers the easy stuff. Now what about the problems folks had? If you download the XLS sheet (again, attached below) you can see the full set of comments. What follows is my personal take on the results. I do not speak for the PhoneGap team, or the Cordova project. I consider myself a "interested developer" just like y'all so keep that in mind when reading my comments.
One big theme was performance. I know this is an issue for older Android browsers. There are definitely steps you can do to improve performance in your Cordova apps, but maybe this needs to be addressed in the docs more clearly? For example, there is a privacy guide which is cool, so I think it makes sense to add one for performance as well. My gut tells me this isn't the kind of thing where they can provide a "magic bullet" solution, but I think some direction could be useful here.
And speaking of documentation, this also came up quite a bit in the responses. I saw specific mention of the FileSystem (I've gotten a crap ton of questions about this lately). I also saw folks call out the docs on new versions. I can say that the teams do blog posts on new versions, typically called out by platform, but you probably don't see that if your first entrance is just docs.cordova.io. Again - can we do something on the docs site perhaps to make it easier to see what has changed?
I should point out that by "blog" I mean the "News" section at cordova.apache.org. There is a subscribe link there but it is just RSS. A way to get these items via email would be nice as it would be more direct.
Debugging was mentioned a few times, and one user had this to say in particular: "Debugging is still painful - more so on Android, Safari remote inspector on iOS makes that a little more bearable." I wonder if they are aware that you can remote debug Cordova and Android now? Again - perhaps there should be a guide in the main doc table of contents to discuss this?
I saw a bunch of remarks about plugins. Some of these were for things out of our control, specifically third-party plugins. If someone makes a cool plugin and never updates it, you need to lean on them, not the PhoneGap/Cordova team. Other comments talked about discoverability. If you aren't aware, the Cordova Plugin Registry got a major overhaul in the past few days. Check it out.
Next, there were multiple comments about PhoneGap vs Cordova. This comment was quite interesting: "What the hell is Cordova anyway? Docs just start talking about it like I'm supposed to know, I thought I was using phonegap?" So it looks like not only are there some folks still confused by the split some aren't even aware that there was a split.
Speaking for myself... I'm focusing on Cordova. Period. When I present, I mention both CLIs, and I mention the excellent PhoneGap Build. But for all intents and purposes, I'm going to talk on Cordova, blog on Cordova, and pay attention to the Cordova CLI only. That makes it easier, and easier for my readers I think. (And when I say "I will only" - well, honestly, I'll probably screw up too. Heck, look at the title of this blog post.)
Finally, here are some comments regarding installation and usage. (As a quick edit - I want to be clear that I respect the fact that people took the time to answer this survey. I feel like I'm coming down on a few people in a somewhat harsh manner. Please know that it isn't personal. I think we can agree to disagree on things and hopefully you expect me to use this blog for my honest, somewhat-unbiased, opinion on things.)
"The 3.x installation. Phonegap requires node.js, requires ant, just to install. And then the install doesn't work and gives me cryptic messages. Please make a proper installer."
"Having to type things in to a command line. Why no GUI? Not ideal for beginners. The tutorials make too many assumptions. I just want to use PhoneGap Build with Dreamweaver and utilise a few features of PhoneGap to access basic phone functions. I thought I could just put a phonegap.js file into my development folder but now I'm told I need to use node.js and type in commands. I don't get it."
"The CLI is hard to setup and to use for web developers, particularly I had to install platform SDK. We need an easy to develop without any platform knowledge and installation."
Well, not to be rude, but I think you (and by you, I'm speaking generically of course!) need to get over it. Like it or not, Node, or more specifically, npm, is becoming a default requirement for modern web development. More and more tools make use of it for ease of installation and updates. You can't ignore it. Hell, you don't have to even really learn it per se, but you should get comfortable with using npm to install tools. It isn't going away.
I do think the 2.9 to 3.0 change could have been addressed a bit nicer for folks (which is why I tried to blog on it as soon as possible - it kind of caught me by surprise as well!).
What about the Dreamweaver and PhoneGap Build user? Well, PGB does make it rather easy. Write some code. Upload a zip (or use Dreamweaver's built-in support), and voilĂ , you get some bits. That's darn useful. That being said, you are going to want to learn how to do it the "manual" way at some point. Building locally is faster, easier to debug, and in the end, you get more control. Even if I were using PGB to handle my builds for a production release, I'd have my local environment set up so I could build locally during development.
And finally - the comment about "without any platform knowledge" is not only wrong, it is dangerous. You should not think of Cordova as "write once, run anywhere". Yes, you can write once and spit out builds for multiple platforms! But you need to be aware of every single platform. They all have their own performance considerations, their own UX considerations, and their own feature differences. I make the same argument about hardware. I can build for iOS using the simulator on a Mac. I can build for iOS using my PC and PhoneGap Build. But it would be ludicrous for me to assume that is good enough. I need to buy, and test, on real hardware or I am not doing my job. Period.
So... there ya go. Two more things I want to leave you with. I'm going to schedule a Google Hangout next week that will be a repeat of my FluentConf session on mobile debugging. If you want to see Remote Debug for iOS and Android, and Weinre too, come check it out. I'll record it for folks who can't attend. Also, the sessions I did in the past over Adobe Connect that were general Q and A worked very well I think. I don't know if a Google Hangout would work well for that, but I definitely plan on hosting an open Cordova QA session soon.
Archived Comments
From the perspective of someone who uses and teaches PhoneGap: I don't think Node or NPM is really what irks people. It is rather that there is so much else to configure. Let me give you n example: on my Windows machine... (hold your tongue, Macaholics!) ... I installed Node just fine... npm to bring down phonegap and ripple just fine... the problem comes into play when I need to ALSO get the Android SDK and tools... ANT... Java... change a bunch of PATH settings... set up my machine as if I were doing native Android dev, really. At that point - I may as well be doing native Android development.
Now, I understand that this isn't exactly any fault of Apache or Adobe... just saying I don't think Node/npm is he problem here.
(Am I defending Node??? OMG.)
It's interesting to hear that people are continually frustrated by tooling and the "on-boarding" process to get up and running with PhoneGap/Cordova. Services like Telerik AppBuilder and PhoneGap Build really have shown that you don't need to go through all of those setup routines. (Disclaimer: I am Product Manager for Telerik AppBuilder). I love Cordova and am continually impressed by its maturation over the last couple of years - but it is still young in many ways. However, people are always surprised once you show them how much you really can do (and how performant you can make hybrid apps).
I think a lot of people coming from Adobe tooling (Flash Builder and AIR for mobile app dev) are shocked because it is so very different. With that platform you just build it and then compile for the platforms you want. Done.
Agreed that Build negates some of this - but still if you want access to dev tooling and even the phonegap stuff inherent in Node - you still need to grab and config a lot of stuff.
I like this comment: "What the hell is Cordova anyway? Docs just start talking about it like I'm supposed to know". This is exactly what I was thinking. (I didn't write that comment BTW)
I get that node is supposed to be this foundation of development goodness(!?) but the PhoneGap docs don't explain the basics, it makes big assumptions that *all* devs are familiar with it and understand the CLI required to use Phonegap.
There are ample of tutorials to teach JavaScript and HTML5, but I have no idea how to create the phonegap.js file for PG. Why isn't this file available on their website that can be copied into my apps' folder and used without having to do anything else? Just give me that missing file so I don't have to get my head around node, please! :-)
Devs need to learn new things from somewhere and there's a lack of tutorials (or patches of mist) when it comes to getting started with PG. Ray, any tutorials you do are warmly received, as always. The remote debugging tutorial sounds good. I can't stand the slow desktop emulators, it feels quicker to user PGB with Hydration and a real mobile device.
@JL: I agree that the initial install can take a little while, but I'm not sure I agree with your last statement ("I might as well be doing native..."). I view myself as an Android and iOS developer, even when I'm using Cordova. Having to have the SDKs just seems like a natural part of the process even if I'm not doing native.
@RL: I like PGB (and haven't tried your service yet - I want to) and I can see the appeal - but as I said above - I see it as a compliment to building locally.
@JL2: Interesting point here. I don't think of Cordova as an Adobe thing. PhoneGap technically is. But I don't come to it with expectations of it being as easy a Flex, but I definitely can see how folks may do so.
@GF: "I get that node is supposed to be this foundation of development goodness(!?) but the PhoneGap docs don't explain the basics, it makes big assumptions that all devs are familiar with it and understand the CLI required to use Phonegap."
To be clear, Node is not required. You aren't learning Node. You are installing Node to just get npm, which again, is used *quite* a bit in development. Maybe we can make that more clear? As for the CLI, no one expects you to know the CLI immediately after installing - that's why we have docs. ;) And the CLI itself will print help to the screen (and again, this is pretty standard for CLI tools). If you have *0* experience with doing stuff CLI, well, this will be different, I'm not sure there is much we can do alleviate that.
"There are ample of tutorials to teach JavaScript and HTML5, but I have no idea how to create the phonegap.js file for PG. Why isn't this file available on their website that can be copied into my apps' folder and used without having to do anything else? Just give me that missing file so I don't have to get my head around node, please! :-)"
Because the JS file is going to be unique per platform. The CLI handles taking care of this for you. As for just being able to download a JS file and nothing more - it isn't that easy. There are things you *can't* do in mobile html, like vibration for example, that requires a combination of the JS file Cordova provides and the native hook in plugins. If you want to stick to mobile web, then sure, do that. But if you want the extra power that Cordova gives you, it requires more than just one file.
"I can't stand the slow desktop emulators, it feels quicker to user PGB with Hydration and a real mobile device."
You mean Android. ;) Yeah, the Android emulator is slow as crap. When I debug with it I ensure I don't shut it down so it is launched and stays launched.
Yeah, Android. :-) I'm convinced the emulator only uses 1 core on the host which doesn't help. Running jQuery Mobile on it is painful. BlueStacks performs much better but ridiculously doesn't allow you to change its screen resolution.
You said node is used by PG to create a js file that's unique per platform. Does PGB do that automatically to eliminate the need to install PG/node on my desktop? When I write some PG specific code in Dreamweaver do I need to add any PG js files into the code or does PGB add it for me? Maybe this is where I'm getting stuck?
With Apple moving away from apps targeted for IOS 6, what is going to be done about deprecated plugins from Cordova?
What should be done? Again, these plugins (I assume you don't mean the Core plugins) are built by other people. We can't force them to upgrade. Did you have something in mind?
"You said node is used by PG to create a js file that's unique per platform. Does PGB do that automatically to eliminate the need to install PG/node on my desktop? When I write some PG specific code in Dreamweaver do I need to add any PG js files into the code or does PGB add it for me? Maybe this is where I'm getting stuck?"
PGB will auto inject the proper JS file per platform, and yes, you can skip installing PG/node. I would NOT skip it, but that's just my opinion.
You do need to have this line: <script src="cordova.js"></script> in your code.
Ray, that doesn't work. Trying a simple command like this - navigator.notification.vibrate(2000); - results in nothing happening. I've got <script src="cordova.js"></script> in the <head> and PGB created an app which I ran on my real Android phone. Similar tests for life such as navigator.notification.beep(3); don't work either. So Cordova or Phonegap js libs aren't present. Using Weinre to debug, any Cordova command is met with "Cannot call method". I know it should work but it doesn't. Something is missing. :-(
Sorry Gary - I forgot - it was updated for 3.X as well. Please see this description:
http://www.raymondcamden.co...
I read that post and the plugins are correctly specified in the config.xml file. PGB confirms it's added the plugins into the build. I am getting this error now when launching the app: "Error initializing Cordova: class not found". Even simple things like alert(device.name) don't work and return undefined. Ray, I'd gladly PayPal you some beer money for 5 mins of your time.
How about you hit me up off line. Send me a zip of your code - the simplest failing example you have.
I was the person who commented about debugability on Android - note that the Chrome Remote Debugger only applies to the new Android 4.4 KitKat webviews, which doesn't help me on my pre-Android 4.4 test devices.
Obviously I can, for example, use weinre on those other devices, but it's still not the nice integration available with Safari / iOS (and it works on both iOS6 and 7).
Fair point I guess, but you could say the same about iOS. It only supported Remote Debug in ... um... ok I forget. ;) It is more common than Android now. Point is - both *current* releases support it which is a good thing I think.
@Marcin You should take a look at jsHybugger for debugging Android apps < 4.4.
@Gary I'm not one to blatantly promote my company's product in a forum like this - but it's worth giving Telerik AppBuilder a look for your hybrid development. A lot of the pain you are seeing with getting up and running with Cordova is handled with our tools and cloud-based services.
I was just skimming the comments and someone mentioned something about the emulator. I wanted to suggest an alternative which involved downloading an ISO image from here: https://code.google.com/p/a... and than creating a VirtualBox or whatever virtualization software you like, and creating a virtual machine for your Android emulator. The VM's run just like a native phone/tablet setup and you can do everything the device can do. I've tried it with native Android and with Cordova/Phonegap while back. Hope that helps!
Do you know if that works with "cordova emulate"? Ie will it target it?
@Ray, would you believe I fixed this not by changing my code but by deleting the App from PGB and starting a new App and uploading the same zip file. I'm so annoyed I wasted 3 days when the problem was down to PGB all along. I wonder if this issue has been reported to them before? Thanks for the offer of offline help - can I bank it for next time? :-)
@Rob, I wasn't aware of Telerik. I'll check it out to see what it has over PGB.
@Ray, when you setup the VM in VirtualBox for example, you will be working over IP instead of connecting a device to your computer or using the built in emulator. You have to go the command line and do adb connect 192.168.XXX.XXX and than Eclipse will recognize the device and launch the changes etc... on that device. Or it will be in the list of available devices if you have more than one setup.
I don't use Eclipse though. Have you tried to 'talk' to it via "cordova emulate android"?
I am getting this error now when launching the app: "Error initializing Cordova: class not found". Even simple things like alert(device.name) don't work and return undefined. Ray, I'd gladly PayPal you some beer money for 5 mins of your time like another user before me. Help
Sounds like you didn't add the device plugin.