Injecting Custom Files into Ionic Build

This post is about including custom .html, .css and .js files in an Ionic 3.x+ project so that they get copied from /src to /www during the build process. Basically, we are talking about files that are handled separately from the webpack compiler process, but you want them to be swept into the test or production build when they get updated.

Step 1: Modify your projects main package.json file in the root directory to override the copying process in ionic:build and ionic:serve. In this example we are referencing a custom library called ionic-config-override.js that controls what we want to copy, and this library lives in the root directory, as well.

{
     . . .
     “scripts”: {
          . . .
          "ionic:build": "ionic-app-scripts build --copy ionic-config-override.js",
          “ionic:serve”: "ionic-app-scripts serve --copy ionic-config-override.js"
     }
     . . .
}

Step 2: Create a JavaScript file of the same name you referenced in package.json for example ionic-config-override.js. In this new JavaScript library use the node.js fs-extra file utility to copy the files you want when the build process is run. Here’s one example:

var fs = require(‘fs-extra’);
fs.copy(‘src/special.html’,’www/special.html’);

Step 3: To test locally instead of using ionic serve, run this new script using the command line command npm run ionic:serve. Or, if you are ready to test on a device run the script using npm run ionic:build android and then when that is completed successfully use ionic cordova run android.

References:
Ionic –copy command

The Copy command source code can be found in your project path @ionic/app-scripts/config/copy.config.js

Additional information can be found on the Ionic forums.

What version of Android do I target?

The version of Android that you need to develop against really depends on your customers and your requirements. If you are simply planning on aiming for the latest and greatest version of Android there are some facts you should be aware of:

Approximately 86% of Android users are running Android v2.2 – 2.3.7 (Gingerbread). Less than 5% are running v3.0 and above (Honeycomb and Ice cream sandwich). And, only 1% are using Android v4 (Ice cream sandwich)! It’s true, and you can check my stats from Google here.

To add some context, Android v3 was released in February 2011. Android v4 was released in October 2011, which was less than one year later. That’s two major releases in one year, and there’s already press on Android v5 being released in 2012. Most software companies have major release cycles over several years for a variety of reasons including allowing time for their customer base to adopt new technology. Of course, consumers and organizations are going to continue to trade-in their smartphones for newer versions. But, that’s going to take time as contracts expire and phones wear out.

So, if you plan on building an app within the next few months that is mostly focused on the newest, coolest features and hardware there may be many potential customers that can’t use it. It’s something to consider. My suggestion is to check your current technical requirements against the deprecated list in Android v4 and see if all your functionality is forward compatible. Then weigh any new features that are only supported on Android v3 and v4 against how many of your most important customers will be able to use it and be willing to pay for it.

It’s interesting and disturbing at the same time that Google is two major operating system versions ahead of the vast majority of their customers. I’m not 100% certain, but I think this is an unprecedented position in the software industry. My take-away is if your product is targeting a much wider swath of users than the bleeding edge adopters, then you need to be careful about what new features you implement.

If you spend too many development cycles building cool new features that your customers don’t need or can’t use for another six months to a year, then it’s potentially a wasted effort, or worse.  And, if your strategy is to be ahead of the curve and entice customers with new features, then don’t get so far ahead of the curve that customers can’t keep up or you’ll risk leaving them behind.