Skip to content

Do you need a mobile app? Probably not

This post from the folks at 18F does a great job of covering why you should default to a responsive web site rather than a native mobile app. While tools like cordova and react native decrease the effort required to build a native application, the ongoing maintenance costs shouldn’t be underestimated.  It is easier to outline the reasons why you should build a mobile application, because there are far more reasons why you should not. From the post I mentioned above:

  • extreme bandwidth constraints or offline operation
  • heavy use of sensors that are not web standards
  • third party interactions

I’d add:

  • branding needs, where you have a compelling application and expect to be be installed on the user’s home screen. Expect to spend $$$ on marketing the app
  • extreme performance. This might be graphics/video, battery or network performance

and, via twitter, Sara Bates added:

  • push notifications, (if used wisely)

If your application doesn’t meet these criteria, I’d think long and hard about launching with a native mobile application, and think about what you could do for your business with the extra budget.

You can likely prototype your app with a responsive website and then build a native mobile app when you know more and/or have user feedback. This can be a great way to economize, because you can leverage outsourced mobile app teams and point them at the prototype as a living requirements document.

Android Mobile Technology Phonegap | moore | | Leave a comment

The Tragedy of Mobile Development

unicorn photo
Photo by Origamiancy

The web, for all its warts, pushed a major advance in software construction.  The separation of concerns.  This is the idea that, just as you wouldn’t have the same person paint a house as lay the foundation, you should have different people design the user interface and the internal guts of software applications.  The skillsets are simply different.

Since modern web applications exist in the browser and are primarily CSS and HTML, with some amount of javascript, it is fairly easy to split up development between designers and developers.  Designers could focus on beautiful, functional user interfaces and developers could focus on making the application work.  HTML and CSS were the common interface, and they weren’t complicated (neither is a full featured programming language).

This separation is more difficult to maintain since the rise of the single page application, which pushes a lot of logic and functionality into the browser with javascript, but is still possible.

But, the mobile device, with its native apps, is a huge step backwards.  Sure, there’s still plenty of scope for people who just want to make things work–APIs and server side logic are a large part of most mobile services.

But for the client side, it’s not enough for designers and UX folks to be fluent in the traditional tools.  They can still do mockups, but the UI for mobile devices is constructed in code (objective C or android java, primarily).  That means that the finer points of UI must be added by developers.  No longer can they be delivered by HTML and CSS.

And hence, the rise of the proverbial unicorn, who can do mobile development, design and UX.  And makes very good money, since there are very few of these.

Is this sour grapes?  Nope.  I know that one of my limitations is my aesthetic sense.  (If I harbored any illusions about this, my wife would be quick to disabuse me.)  And I think that the unicorns should ride this market for all it is worth.  It just frustrates me that we came so far with web applications and separate of concerns and now are taking a huge step back.

Mobile Technology Programming | moore |

Headline: Android User Buys App

cash register photo
Photo by liewcf

A few weeks ago, I bought my first app on Google Play.  Wait?  I thought Android users don’t buy apps?  Well, what can I say, I like to break the mold.

Actually, I think I’m pretty typical for a high end Android phone owner.  I have had an Android phone since 2010–I paid hundreds of dollars for each of my phones.  My wife is a diehard iPhone owner.  At the time I purchased, she wondered why I wanted to buy an Android.  The application process for writing apps is one reason, and another is being able to write an app, on whatever computer I wanted, and install it on my phone.  Now I’m in Google’s ecosystem, and it would take a lot to pull me out of it.

Regardless, I finally bought an app!  I was looking for music on my phone, and have long been a fan of soma fm, ever since John Argo introduced me to them–about a decade ago.  Groove Salad is excellent for doing development.  I looked up their app, and it was $4.  soma fm is one of those organizations that I’ve been meaning to contribute to for years (like KGNU, they are listener supported and commercial free), but never got over the hump.

This was my chance to support the radio station which I loved!  Google made it easy–just had to enter a billing method (options included credit card, paypal, and bill to my phone account) and re-enter my password.  (Yes, I realize this was a small donation in the scheme of things.  The app has convenient links to the donation page.

So, what does this anecdote mean for people looking to make a living selling apps?

Don’t count on me, because the only app I’ve ever paid for was because it was a donation.

I had a long conversation with a friend about this and it appears to me that mobile apps are, in the vast majority of cases, complements to existing businesses, and not businesses themselves.  That was my experience at 8z as well. Being a complement is still a ginormous market, but it isn’t a goldrush for individuals.

Android Mobile Technology | moore |

Guest posts about Cordova CLI

I’ve recently had the good fortune to write a couple of guest posts at some blogs to promote my book about the Cordova CLI.

First, I wrote a post on the CloudFour blog: “PhoneGap makes mobile development more accessible”.

But PhoneGap, a four year old project, now lets developers leverage standard web technologies such as CSS, HTML and JavaScript to build mobile applications. Designers who know CSS and HTML can create fantastic mobile friendly user interfaces (leveraging frameworks like Topcoat and Junior) and developers can focus on functionality and performance.

CloudFour is a consultancy based in Portland OR that my company has worked with in the past. They focus on the mobile web, and are very sharp.

Second, I wrote a post about hooks on Devgirl’s weblog: “Three hooks your Cordova/PhoneGap project needs”.

These hooks automate three common scenarios that will take place in almost any Cordova application–adding plugins to an app, switching between deployment environments, and adding custom icons and splash screens.

Write a hook anytime you have a build process that is tedious, repetitive, or required to build your app. Look carefully at any documented manual build processes. If you need to perform steps to build your app (copying icon files to various directories under platforms, for example), see if you can automate them in a hook script to make your build process quicker, easier, and more repeatable.

Devgirl, aka Holly Schinsky, is a developer evangelist for Adobe who has written about a wide variety of topics, including push notifications and Flex.

Cordova CLI Mobile Technology | moore |

PhoneGap Usage Survey Results

A few weeks ago, I asked the PhoneGap google group members to fill out a simple usage survey. I was interested in versions of Cordova/PhoneGap used, as well as what device platforms were targeted. I had 30 responses over just under two weeks. Note that this survey closed on the 29th, before Cordova 3.1 was released.

Here are the results. (Some questions allowed multiple answers, so the number of responses may exceed 30.)

“What version of Cordova/PhoneGap do you mainly use?” A solid majority was on a modern version, either 2.9 or 3.0.
Which version of cordova do you use?

“What device platforms do you target?” The vast majority of respondents target iOS and, to a slightly lesser extent, Android. There are a smattering of other platforms being targetted.
what-device-platforms-do-you-target

“What versions do you have in production?” Every version of the 2.x line was represented. I think this shows that upgrading PhoneGap/Cordova projects used to be a pain (and, once an app is finished, there often times is no need to revisit).
Which versions do you have in production?

“Do you use Cordova or PhoneGap?” This is interesting to me because I think there is a lot of confusion around the difference. Most people were pretty clear.
do-you-use-cordova-or-phonegap

The results of this survey was interesting to me and I hope to you as well.

Mobile Technology Phonegap | moore |

How to collect usage statistics in your phonegap/cordova application

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.

8z Android Mobile Technology Phonegap Useful Tools | moore |

Releasing with 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.

Subscribe to my infrequent Cordova newsletter

Cordova CLI Mobile Technology Phonegap | moore |

How to ‘plugman’ify an existing plugin

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:

  • install the plugin the old fashioned way, by downloading and copying its files into your project directory. This is a a bad idea because if there are future bug fixes or feature improvements to the plugin, you’ll have to manually pull them in.
  • forego the plugin. But you are looking at it specifically to save you time or allow you to implement a feature that would otherwise be too hard or time consuming–so you can’t exactly ignore it.
  • search for another plugin that does the same thing–great, if you can find it.
  • make the plugin plugman compatible–this is the best option.

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.

Subscribe to my infrequent Cordova newsletter

Cordova CLI Mobile Technology Phonegap | moore |

How to set up a new plugin for use with Cordova CLI

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.

Subscribe to my infrequent Cordova newsletter

Cordova CLI Mobile Technology Phonegap | moore |

Platform specific configuration files with Cordova CLI

I previously posted about using the merges directory to handle situations where your css or javascript differed between platforms.

However, there are cases where platform specific Cordova configuration differs from that created by cordova platforms add [platform]. In this case, if you want to version control the configuration changes (and you should) you need to write a hook to copy over the configuration file from a well known location. I create a top level directory called config and underneath that have platform specific directories.

However, there are two types of platform specific configuration to consider. The first type aren’t modified by any other processes–application icons and splash screen images are examples of this. In this case, your hook script can live in .cordova/hooks/after_prepare and be run every time. Therefore, if you switch out a splash screen with a new image, it will show up the very next time you run cordova build.

The second type of platform specific configuration file is one that is modified by other processes; for example, plugins often modify AndroidManifest.xml. In this case, if you were to put the copying script into after_prepare, your plugin changes would be removed unless you reinstalled your plugins every time. The better part of the build lifecycle in which to execute your copy script is after_platform_add. This means, however, that when you need to change such files, you’ll need to remove and re add the platform (or merge your changes manually).

In the next post, I will discuss adding plugins using Cordova CLI.

Subscribe to my infrequent Cordova newsletter

Cordova CLI Mobile Technology Phonegap | moore |