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’);

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.

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.

Do I need Ionic’s Geolocation Plugin?

Most likely not. As described in the Cordova documentation and Ionic documentation, the plugin is for devices that don’t already provide an implementation. The vast majority of modern smartphones natively support the WebView Geolocation API. Also, cellphone enabled tablets typically have a GPS. However, WiFi only tablets may be limited to using non-GPS, WiFi-based geolocation, but the Geolocation API will still work although it will be less accurate.

Skipping the plugin simplifies installation and implementation. You don’t have to install it and that eliminates any possible conflicts and provides a minor reduction in application size. You also don’t have to import the plugin into your application components and that simplifies your code. You can simply use navigator.geolocation like you would in any regular JavaScript app:

watchId = navigator.geolocation.watchPosition(success[, error[, options]])

Sample application:

Using High Accuracy GPS with Mobile Apps

There are times when the built-in GPS simply isn’t good enough for your Android or iOS app. Built-in GPS is good for finding a general location of a geographic feature such as a pond, field, or parking lot. If you need to locate a specific parking space, or a geographic feature within a field, or an inlet to a pond then you’ll need much greater precision of a commercial GPS unit.

Examples. Here is a more specific example to illustrate the concept. Let’s say the application users are mapping insect infected trees in a densely forested urban park. If you are using a smartphone GPS, with an average accuracy of 30+ meters when standing under the tree cover, the latitude/longitude coordinates may end up being unusable for future follow-up because there are dozens of trees within a 30+ meter radius. If you are using a commercial GPS with sub-meter accuracy you can have a much higher degree of certainty that someone will be able to locate that exact tree again.

I’ve seen entire days’ worth of data collection get thrown out the window because of significant location inaccuracies caused by using smartphones and dedicated hand-held consumer GPS units that are well known to outdoor recreational folks. I’ve accidentally sent a backcountry trail maintenance crew to a totally wrong location (they got really mad). All I had was a smartphone GPS and my location coordinate was over a thousand meters off even though the Android Location API returned an “accuracy” value of less than 50 meters. Oops — that’s the difference between precision and accuracy.

Good news. The good excellent news is there are small, handheld commercial GPS units that you can tether to your smartphone via Bluetooth such as the Trimble R1. Units like the R1 are able to override the onboard GPS and when configured correctly work just fine with the browser’s JavaScript-based Geolocation API or native iOS/Android geolocation.

The only downside can be cost. Some of these commercial units cost several thousand dollars and that may be outside the budget of many organizations.

Surprise, Surprise. I spend a ton of time talking to customers about this topic. Many people are very surprised because they regularly use GPS fitness tracker apps or Google Maps and the location information almost always seems very close to reality. The hidden trick is these apps use proprietary software algorithms that attempt to slightly improve accuracy, minimize location fluctuations or even intelligently snap your location to geographic features such as roadways, buildings or trails.

When you are building a custom mobile application, you will be forced to deal with raw, unfiltered geolocation data. And the coordinate data is coming from consumer-grade GPS units mass produced at the lowest possible cost. The antennas are tiny and usually on the back of the device rather than pointed towards the sky. The chipsets are designed to minimize battery usage, because GPS can be extremely battery intensive and generates a lot of heat. They have minimal ability to resolve communication difficulties between your device and GPS satellites, and GPS signals are already relatively weak.

Decisions, decisions. If your budget can’t handle several thousand dollars for a commercial GPS and you only have short term needs you can always look into renting a bluetooth unit. Just make sure to ask if it overrides the onboard GPS chip. You can find GPS rental companies online. There are also consumer-grade Bluetooth GPS units that only cost several hundred dollars. The consumer Bluetooth units aren’t nearly as accurate as commercial units; however, they offer a significant improvement over built-in GPS.

Application Cache is not gone, oh my! Or, is it?

Reports of Application Cache’s early demise are false. Application Cache (a.k.a Cache Manifest and AppCache) isn’t perfect, it can be very frustrating to get working and many people hate it with passion, but the fact is that the API will be around for the foreseeable future. I’ve been getting many questions, so this blog post is an attempt to shed some light on a confusing topic.

Mozilla says Application Cache is deprecated and unstable, WTF?

First, let’s review what Mozilla is saying about Application Cache since the majority of questions I get come from what they are saying. Mozilla has some fairly strong wording on their developer site, you can read all about it here. Or, if you don’t feel like following a link, here’s the official text from Mozilla Developer Network (MDN) website. I added the underlines to emphasize wording that’s tripping people up:

Deprecated. This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time.

Using the application caching feature described here is at this point highly discouraged; it’s in the process of being removed from the Web platform. Use Service Workers instead. In fact, as of Firefox 44, when AppCache is used to provide offline support for a page a warning message is now displayed in the console advising developers to use Service workers instead (bug 1204581).

Mozilla also references the Web Hypertext Application Technology Working Group’s (WHATWG) position on Application Cache. But, their wording is similar but definitely different in meaning from the WHATWG statement in their HTML Living Standard, Section 7.7. You may want to read this several times:

This feature is in the process of being removed from the Web platform. (This is a long process that takes many years.) Using any of the offline Web application features at this time is highly discouraged. Use service workers instead.

An oversimplified description of the WHATWG is it’s an organization that provides research and makes recommendations to the W3C – World Wide Web Consortium. It’s the W3C that finalizes recommendations and makes them into standards.

Also note: Application Cache is, for the moment, still officially part of the latest draft of the WHATWG HTML Living Standard document as shown here in Section 7.2.2 (it’s a big document, it’s best to just search for application cache).


What is the true state of Service Workers?

Reality is always nuanced when it comes to cross-browser web application development. Here’s a summary of facts for cross-browser developers to consider (as of February 1, 2016):

  • Service Workers are NOT supported on the following platforms, and you’ll need to use Application Cache if it suits your requirements and any Application Cache bugs don’t adversely affect your apps. You can verify these on
    • Android Browsers at v4.4.4 and older (there are still a lot of phones out there using older browsers). Yes, a percentage of these users download Chrome. However, as of Feb 1, 2016, Android is reporting that v4.1.x thru v4.4 represents 60.8% of all phones in circulation.
    • Desktop Safari
    • iOS Safari
    • IE and Edge – don’t forget that a lot of offline field worker apps are built specifically for laptops.
  • The Service Worker specification is still a Working Draft according to the W3C. It’s not final according to the official standards bodies. Mozilla even lists Service Workers as “Experimental Technology”. You can view that yourself here. Here’s MDNs wording copied directly from their webpage:

This is an experimental technology 

Because this technology’s specification has not stabilized, check the compatibility table for the proper prefixes to use in various browsers. Also note that the syntax and behavior of an experimental technology is subject to change in future versions of browsers as the spec changes.

  • Service workers are more complex and require coding skills in comparison to Application Cache which requires only a configuration file and one line of HTML code. Here’s an example. It’s going to be a big step for long time Application Cache developers to wrap their heads around using Service Workers. It’s a very powerful API but it’s not going to be as easy as simply swapping out your Application Cache for offline capabilities built on Service Workers.

What to do, what to do?

My thoughts are MDNs statement leaves developers between a rock and a hard place, and holds the most water if the ONLY web browsers you need to support are browsers that have implemented all aspects of Service Workers that meet your requirements. You’ll also need to keep in mind that Service Workers are in beta so they can also can break or not work as expected, and there is a remote possibility the functionality could change.

When you combine MDN’s statement with the WHATWG statement and the WHATWG Living Standard document the picture becomes more clear. Here’s my interpretation: Application Cache is going to be around for a while longer. However, it would be a really good idea for you, as a cross-browser developer, to keep your eye on the progress of Service Workers and to consider using them in applications if/when it makes sense based on requirements and browser capabilities.

Don’t throw away an working/stable code built on Application Cache just yet.   If you are building apps on platforms that don’t support Service Workers then Application Cache may be your only viable alternative until you can upgrade to newer platforms or other browsers.

Additional References:

Advanced geolocation plugin for Cordova and PhoneGap for Android

The W3C’s browser-based, JavaScript Geolocation API is excellent as a one-size-fits-all interface, but that approach comes at a price and it can cause some serious limitations when it comes to implementing more stringent professional, commercial and government use-cases.

Challenges with the default Geolocation API. One of the primary limitations is the Geolocation API does not tell you how it got a location. All locations are lumped together in a black box. Let me explain. On a smartphone or tablet, location data comes from one of three places: the GPS chipset, the cellular provider’s Location Service, or the browser’s Location Service. The W3C Geolocation API simply lumps these data points together. The end result is typically seen by the end user as significant and disturbingly wild jumps back and forth in the reported location, sometimes over large distances. A key to minimizing these fluctuations is to gain back control and understand which location provider created the latitude and longitude point.

Cordova-plugin-advanced-geolocation. The good news is that Android, in particular, has a very detailed API called LocationManager for examining geolocation data that comes from the device.  And, even better news for JavaScript developers is that the API, along with its access to all on-device GPS and Network location providers, has been exposed thru a Cordova plugin that is available here:

What geolocation data is available? With this plugin you’ll be able to programmatically differentiate between the following geolocation data as well as get access to GPS satellites meta data:

  • Real-time GPS location – This is data from the on-board GPS or some devices will allow it to be the location data from an external GPS that is connected to the device via bluetooth.
  • Cached GPS location – Most devices cache the last-known GPS location and it’s persistent even when the device is restarted.
  • Real-time Network location triangulation – this is completely dependent on devices and cellular service providers. It may require WiFi to be turned on. It also may not be available in all countries or regions.
  • Cached Network location – Most devices cache the last-known network-based location and it’s persistent even when the device is restarted.

Use cases. With this plugin, you can now use your JavaScript skills to implement the following use cases and much more. For example, I’ve always wanted to play with the Satellite data to make a 3D map of the satellites using JavaScript. This plugin provides a huge advantage to developers building applications for capturing a single location such as field survey work as well as the following use cases and others that I haven’t thought of:

  • Determine a static outdoors location and only use GPS.
  • While indoors turn on only network location. Do not use GPS.
  • While in an urban area, use network location to get initial location before the GPS warms up and then turn off network location and only use GPS
  • Compare the differences between GPS and Network locations
  • …???

How does this plugin help minimize location fluctuations? This plugin comes with a configuration option for turning on a buffer. You can set the size of the buffer, each new geolocation from the device will be added to it, and then plugin will determine the geometric center based on all the locations in the buffer.

Are there any other advanced plugins? Yes, some Cordova plugins are focused on being activity based and will detect if you are walking, stopped, moving, etc. These plugins tend to work as apps that can be backgrounded. Feel free to browse the Cordova plug-in directory here.

Does using PhoneGap improve geolocation?

No, using PhoneGap or Cordova doesn’t change how you retrieve geolocation information from within a mobile application and it doesn’t improve accuracy. You still use the W3C HTML Geolocation API coding pattern.

The reason why is because PhoneGap runs the HTML/CSS/JS code in a native OS WebView. This is a chrome-less browser with mostly similar functionality as Chrome (Android) and Safari (iOS). There isn’t any additional functionality that would improve accuracy.

Some people have asked me if cordova-plugin-geolocation provides additional functionality. That plugin only works for devices that don’t already support geolocation and then it abides by the W3C Geolocation API spec.

The HTML Geolocation API in the browser also works offline. Yes, it’s true. You can use a web browser offline to get geolocation and even view a map without PhoneGap, here’s an example project that demonstrates the functionality in a number of ways. As long as the GPS on the device is enabled and working, and the user opt’s in at the geolocation-approval prompt then the application will receive GPS location data.

Are there any advantages to using PhoneGap for geolocation?

Yes, there are several potential advantages to using PhoneGap for geolocation. You can retrieve geolocation information while the device screen is locked and/or when the application is running in the background. You cannot do this with a typical web app. As soon as a browser is minimized a web app will stop running even if the GPS is still running.

Another advantage is you can write a PhoneGap plug-in to tap directly into the native OS location API. Taking this approach will give you a greater level of control over the information you are retrieving. And, you have coding tools and access to APIs to better manage the device’s battery life in a way that the HTML Geolocation API cannot deliver. In the case of Android you can tap into significantly greater information such as details on GPS satellites, granular information on device’s internet connection, as well as NMEA strings and more.