I just wanted to let all my loyal readers know that Developing Cross Platform Mobile Applications With Cordova CLI.
If you are an experienced PhoneGap/Cordova developer who wants to leverage the new CLI to make your life easier, or if you are just a command line junkie who is interested in mobile apps, this is the book for you.
A decade ago, I wrote my first post about RSS, and how I wished someone would aggregate events via RSS. I’m still waiting for this 🙂
I had recently come back from a trip abroad, and was a young contract programmer living as cheaply as I could. One decade on, I am a married father with a house who is a full time employee. Things change, but I still blog.
A decade of blogging has taught me many things. How much I enjoy teaching, how widely the Internet lets you reach, how much people care about Yahoo Mail and dating software, how powerful Google is. But most of all, how writing about something helps you truly understand it.
I’ve been hot and cold on blogging–sometimes posting every couple of days and interacting with the commenters, sometimes ignoring my blog and treating it is a write only medium. Either way, the corpus of 600+ posts (more than one post a week) and the thousands of visits per month the blog gets, are gratifying.
I look back on proudly on all my blog posts. And I can’t tell you how fun it is to hear from someone that I’ve helped them, or to run across a post of mine when I’m doing a google search, or to see from where people have linked to my articles.
Here’s to another decade.
I took the content from my blog posts about Cordova CLI, and am revising and updating it for an ebook about Developing Cross Platform Mobile Applications with Cordova CLI. I discuss some of the intricacies of Cordova CLI in more depth than either in my blog posts or in the Cordova documentation.
If the topic interests you, I’d love to hear your feedback.
Plus this gives me a chance to use Leanpub, which I’ve written about previously.
My company recently wrote a couple of mobile applications. Since one is for consumer use (search for ‘8z neighborhood’ in the App Store/Google Play if you live in Colorado or the Bay area and want to check it out), I wanted to know what type of users were downloading and installing it, what was being used, and other general usage statistics.
I asked a mobile app vendor we’ve worked with what they used for usage stats, and they said Flurry. I also looked at Google Analytics, Mobile–this is a nice q&a explaining the major players in the mobile analytics market. We didn’t want anything complicated, just basic stats with the possibility of collecting further information in the future, so I went with the vendor recommendation. Flurry also works with the two platforms we were targeting: IOS and Android, as well as many others.
Flurry is zero cost, but nothing’s free–they want your data and you grant them a “right, for any purpose, to collect, retain, use, and publish in an aggregate manner” all data collected from your application. I’ve seen similar TOS from most of the free analytics vendors, so this was no surprise.
To use Flurry with cordova/phonegap, and with plugman, I was ready to plugmanify an existing Flurry phonegap plugin. Luckily, someone else had already done it. All I had to do was update the plugin to work with Cordova 2.9, and to use the latest IOS7 compatible Flurry library.
After you install the plugin (I recommend doing so in an after_platform_add hook script), you simply add this to your code after the deviceready event fires: window.plugins.flurry.startSession(sessionkey). I inject the session key using a hook script, because I wanted a different key for stage and production builds, and also for each device platform (Flurry requires the latter). Because hooks only get the root directory as context (although this is supposed to change) I had to put some logic in the javascript to call startSession with the appropriate key:
App.config.flurryid = "";
if (window.device && window.device.platform) {
if (window.device.platform == "Android") {
App.config.flurryid = /*REP*/ 'notreallyanandroidflurryid' /*REP*/ ;
}
if (window.device.platform == "iOS") {
App.config.flurryid = /*REP*/ 'notreallyaniosflurryidxxx' /*REP*/ ;
}
}
Although I have not used any of the more specific event tracking, the basic statistics are a great start (including new users, retained users, device versions, etc).
Don’t fly blind when you release your phonegap/cordova mobile app–use Flurry or something simliar.
Here is a PDF of my slides from the ‘Transforming Data with Kettle’ talk I did last night at the Boulder Java Users’ Group.
I really enjoyed some of the discussion, which centered around topics like how to version control output of graphical code generation tools, error handling and transactions, and who had interacted with the EDI data format. As far as my audience survey questions, I’d say around 40% of people had written scripts to munge data from one datasource to another, and about 15% had used java code and about 20% had used an ETL tool.
Thanks to everyone who attended.
I’m presenting on transforming data with Pentaho Data Integration (aka Kettle) at the Boulder Java Users Group this Tuesday.
I hope you can join us as I present a gentle introduction to Kettle, including a couple of demos. I hear there will be pizza as well.
I hope I have convinced you that when you are planning your next Cordova/Phonegap application, you should use Cordova CLI. While definitely not fully baked, this powerful framework makes it possible to maintain a Cordova application for much longer, and makes building and deploying for testing and development a breeze. Feel free to contact me if you have questions.
Again, remember these posts only cover cordova cli 2.9. Cordova 3.0 is an overhaul that changes how the core Cordova app is assembled, and therefore has different constraints.
In conclusion, here’s a list of all the posts around Cordova CLI:
When you are done developing your mobile application, you will want to release the binary, and have it distributed by whatever means is typical for that platform (typically some kind of app store).
How does Cordova CLI help with this? It doesn’t.
Typically, the best way to release a cordova/phonegap application for a given platform is to find out how to do a release for that platform from the platform’s documentation, and follow that. For instance, for android, you can run ant release and sign an apk with custom keys–all of that process is independent of Cordova CLI.
It’s worth reiterating that cordova CLI is a toolset to help with development of applications–deployment is still platform specific.
Next up, a conclusion.
In a previous post, I talked about adding a new plugin that you wrote to your Cordova CLI project. However, there are a ton of existing plugins out there, and many of them haven’t yet migrated over to the new plugman architecture. What should you do when there is a plugin that solves your problem, but is not installable via plugman?
Your options include:
The first step to making a plugin plugman compatible is to file a bug/issue with the project. Perhaps they are already planning to do this work, and a request from you will get it moved up the queue. If so, fantastic–see when they think it will be done. If not, at least you’ve let them (and others who look at the issues list) know that this is something they should do.
If it won’t be done in your timeframe (or at all), you can do it yourself. The main tassks are writing a plugin.xml file, and possibly modifying some javascript files. Start with the plugin.xml spec.
Before you plunge in, though, think about the licensing surrounding the plugin, as, unless you are replacing everything or the license is extremely permissive, your contributions will need to be under the same or a compatible license as the original code, especially if you want to contribute the changes back.
You want to make sure you use version control. If you are modifying a plugin on github, it is as simple as forking that project. You may be able to take the plugin code and import it into your version control system.
Write the plugin.xml file, and make sure to check it into the version control system. Writing a plugin.xml file is straightforward; however, there are two ways to handle javascript–you can treat it as an asset, where plugman dumbly copies it to the www directory wherever you tell it to, or you can treat it as a js-module. Plugman does some extra work for js-module javascript, including injecting it into the index.html and adding the created javascript object to the window object. Using js-module is the preferred method, but you may have to edit the javascript files and remove any cordova.define syntax. Also, if you need to move plugin files around, or rename them to help code maintainability, do so.
Test and install it just as you would any other plugman managed plugin (cordova plugins add http://...).
Once you’ve done this and it works, consider pointing to your plugin.xml in your open bug. Some authors may be receptive to code contributions or pull requests.
In the next post, I’ll discuss how Cordova CLI helps you release your application.
The first step whenever you feel you need access to native functionality for a phonegap/cordova application is to search for a pre written plugin. Unfortunately, at this time there is no central repository. There is phonegap plugins github repo, but I always find myself reverting to searching with google–there are lots of plugins that are described on blogs (web intent, application preferences) that are not present in the phonegap plugins github repository.
However, if you can’t find a plugin that does something you want, you will have to write your own. First, get the plugin working using an IDE or placing the code directly under the platforms directory in a new project (so that you can minimize external complexities). Get the plugin running in your phone and/or emulator. There are plenty of tutorials on writing a cordova plugin, not least of which is the one in the phonegap docs.
After it is running, you want to convert it to a plugman compatible plugin. Plugman is a tool for managing cordova plugins (and, incidentally, is planning to support a directory of plugins). You configure how plugins are installed by writing a plugin.xml file; here’s the plugin.xml spec. This document well worth reading a couple of times closely, as it specifies what you can ask plugman to do when installing a plugin.
Create a new project in your version control system and copy in the plugin files previously tested, as well as the plugin.xml. Make sure they are all committed.
Then you go to your project and run cordova plugins add http://github.com/path/to/plugin.xml. From the plugman documentation, it looks like you can install a plugin from a local path, rather than a URL, but I have not done so.
Note that when you check out the source tree on a different machine, you will want to run cordova plugins add http://github.com/path/to/plugin.xml again. Putting a list of these in an after_platform_add hook script will ensure that this happens automatically.
The next post will discuss how to take an existing plugin and have it work with Cordova CLI.
Follow me on Twitter
Follow me on Blue Sky