This is the final instalment of a two-part tutorial, in which we have been creating a web-app – Breeze – that will load and display temperature information for various locations using data from OpenWeatherMap.

In this instalment, we will build on what we covered previously during the first part of the tutorial in order to create the logic of the Breeze application – loading and displaying current temperature information for various locations by making AJAX requests to the OpenWeatherMap API. We’ll also improve the Grunt workflow and briefly look at SCSS variables and mixins.

Whether you’re short on time and just want to see the code for the complete project, or simply want to follow along, then you can fork the repo on Github and switch to the ’tutorial-part-2’ branch.

If, for whatever reason, you don’t want to fork or clone the project, but want to get at the code, then you can download the whole project as a zip file.

Once you have the project, open Terminal and ensure that you change to the ‘breeze’ directory before running the following command to install dependencies:

npm install

Improving the Grunt Task Workflow

There are quite a few things that we could be doing differently in order to make the build workflow and overall code quality of our project better; by updating the Gruntfile setup we will be improving the process of loading tasks, as well as the browser coverage of our compiled CSS code. We will also automate more tasks in order to make development simpler and faster.

Loading Grunt Tasks Simultaneously

Currently, within our Gruntfile, we’ve been loading tasks one at a time. Instead of doing this, we’ll start using a module called load-grunt-tasks, which allows us to load all the necessary Grunt tasks that are defined as dev dependencies within the package.json file.

Using Terminal, ensure that you have changed to the ‘breeze’ directory – we will be running all commands from this directory throughout the tutorial – and then run the following command:

npm install load-grunt-tasks --save-dev

This installs the load-grunt-tasks module into the node-modules folder and adds it as a development dependency within the package.json file.

Once that’s done, we need to update part of our Gruntfile to make use of the module.

This is what the relevant part of the Gruntfile looked like before:

grunt.loadNpmTasks("grunt-contrib-sass");
grunt.loadNpmTasks("grunt-contrib-uglify");
grunt.loadNpmTasks("grunt-contrib-connect");
grunt.loadNpmTasks("grunt-contrib-watch");

We are going to replace all of that with the following single line instead:

require("load-grunt-tasks")(grunt);

The next time we run the grunt breeze command, all of our npm module dependencies should be loaded, just like before, but with a much more neat and concise syntax.

Automatic CSS Prefixes

Normally, in order to ensure a web application works in various browsers, we’d need to add vendor-specific prefixes, for example, -webkit-transition, -moz-transition, and -ms-transition would be used in addition to the standard spec of transition.

Instead of manually adding prefixes, we’ll start using a module called grunt-autoprefixer, which allows us to write our SCSS using just the standard spec, as it will automatically add the necessary vendor prefixes where appropriate during the Grunt build step. This is a great option, because it allows us to keep our SCSS code simple and clean, rather than having it littered with prefixes.

Using Terminal, run the following command to install autoprefixer:

npm install grunt-autoprefixer --save-dev

Now we need to add a config to the Gruntfile for autoprefixer:

autoprefixer: {

    dist : {
        options: {
            // add prefixes to support the last 2 browser versions,
            // as well as IE9+ and Android 4 stock browsers
            browsers: ["last 2 versions", "ie >= 9", "Android 4"],
            map: true
        },

        files: {
            "dist/css/app.min.css": "src/scss/app.scss"
        }
    }
}

Note that, within the scope of this tutorial, we’ll only really need to run the autoprefixer task when creating a distribution build, as when developing locally we should be using a good browser, such as Chrome, which supports a lot of the CSS spec by default. If you need to test in not-so-modern browsers during development, then the autoprefixer task should be run on every build of the SCSS code, and you may also want to look at the documentation for autoprefixer, which provides many configuration options.

Auto-updating Style Changes in the Browser

The watch task supports an option called ‘livereload’, which can automatically reload the browser when any of the watched files are changed. To use this option, we first need to install the livereload browser extension for Chrome or follow the simple installation guide if you want to use Firefox or Safari.

Once livereload is installed in the browser, we then need to update the Gruntfile. Modify the config for the watch task so that it includes an ‘options’ object containing a ’livereload’ property:

watch: {

    options: {
        livereload: true,
    },

    html: {
        files: ["index.html"],
    },

    js: {
        files: ["src/js/**/*.js"],
        tasks: ["uglify:dev"]
    },

    scss: {
        files: ["src/scss/**/*.scss"],
        tasks: ["sass:dev"]
    },

    img: {
        files: ["src/img/**/*.*"],
        tasks: ["copy:img"]
    }
}

Now when we run grunt breeze we will be able to turn on livereload for the page running in the browser. To do this, simply click on the livereload browser icon and its very subtle centre circle should turn black for Chrome/Safari, or red for Firefox, meaning that it has successfully connected to the running Grunt task.

In Chrome/Safari:

And in Firefox:

Implementing the OpenWeatherMap API

So far, in terms of JavaScript, we've only added an alert message. In this section we will use the HTML5 geolocation API to get the coordinates of a user and the atomic AJAX library to get weather data from the OpenWeatherMap API, based on the coordinates we obtain.

Before we get started on this section, create a free OpenWeatherMap account in order to obtain a developer API key. This key will be needed later when we start making requests to the API.

Main Application Logic

The logic of the application will be fairly simple, and we can break it into two clearly defined parts – getting weather data for the current location coordinates, and getting weather data using a specific search term. There will also be some logic for displaying the weather information, which will be shared by both these parts.

Logic Using Coordinates

1. Attempt to get the coordinates of the current user with the HTML5 geolocation API
2. If we get the coordinates, then make an API request to OpenWeatherMap for weather data using the coordinates
3. Run ‘shared logic’ below

Logic Using a Search Term

1. Listen for when the user submits the search form
2. Make an api request using the text they entered into the search text field
3. Run ‘shared logic’ below

Shared Logic

1. Parse the JSON data received from the API
2. If the location is found, display temperature information using the parsed data
3. If the location is not found, or if we get an error when making the AJAX request, then display an error message to notify the user.

Getting Started

Firstly, remove the alert that we added in the previous part of this tutorial, as it was just a temporary placeholder for our actual code.

Next, it’s a good idea to create an immediately invoked closure which will contain all our code. Doing this is good practice, as it will stop our variables polluting the global (window) scope:

(function (){

	// code...

})();

If you’d like more information about closures, this article is a pretty good one.

We want to ensure the DOM has fully loaded before we start running any of our logic. To do this, we add a listener for the ‘DOMContentLoaded’ event and once this occurs we run an initialisation function for the application:

(function (){
	
	document.addEventListener("DOMContentLoaded", init);

	function init ()
	{
		// code...
	}

})();

Now that we have the basics set up, let’s move on to the first part of the app logic – getting weather data for the current coordinates.

Getting Coordinated

In order to request location information for the current user, we can use the getCurrentPosition method of the navigator.geolocation object:

(function (){
	
	// Add an event listener to ensure the DOM has loaded before
	// initialising the application.
	document.addEventListener("DOMContentLoaded", init);

	function init ()
	{
		navigator.geolocation.getCurrentPosition(geolocationSuccessHandler, geolocationErrorHandler);
	}

	function geolocationSuccessHandler (position)
	{
		// get lat and lon values from the position object.
		var lat = position.coords.latitude;
		var lon = position.coords.longitude;
	}

	function geolocationErrorHandler (error)
	{
		// The user has disallowed sharing their geolocation, or there was a general error obtaining the info.
		console.log("geolocationErrorHandler");
	}

})();

Running this method causes a notification to be displayed within the browser. Notice that we also provide two functions as parameters – the first will be run if the user allows our web app to use location information, and the second runs if the user does not allow this, or if there is an error obtaining the information. Note that, at the time of writing, Firefox will not run the error function if a user chooses the ‘Not now’ option within the location notification – it simply fails silently in this case, which is a known Mozilla bug that has been open for a long time. Firefox does, however, run the error handler if a user chooses the ‘Never’ option.

Also, it’s useful to note that, if coordinates are returned, they are sometimes precise and sometimes approximate. This is because some browsers, such as Chrome, give users a choice as to whether or not a precise location should be used.

We’re now ready to make an API request to get weather data for the coordinates we obtained from the position object.

Requesting Weather Data

Next, add variables to store the API URL, the type of units you want (metric or imperial), and your OpenWeatherMap API key, as well as a few for alerting error messages, and a function that will get weather data from coordinates passed as parameters. You must replace the value of the API_KEY variable – ’YOUR_API_KEY_HERE’ – with the API key you got after signing up to OpenWeatherMap, ensuring that you keep the quotation marks as they are:

(function (){
	
	var API_KEY = "YOUR_API_KEY_HERE";
	var API_UNIT_TYPE = "metric"; // otherwise change to 'imperial'.
	var API_URL = "http://api.openweathermap.org/data/2.5/weather?APPID=" + API_KEY + "&units=" + API_UNIT_TYPE;

	var MESSAGE_LOCATION_NOT_FOUND = "Location not found.";
	var MESSAGE_API_REQUEST_ERROR = "API Error.";

	// Add an event listener to ensure the DOM has loaded before
	// initialising the application.
	document.addEventListener("DOMContentLoaded", init);

	function init ()
	{
		navigator.geolocation.getCurrentPosition(geolocationSuccessHandler, geolocationErrorHandler);
	}

	function geolocationSuccessHandler (position)
	{
		// get lat and lon values from the position object.
		var lat = position.coords.latitude;
		var lon = position.coords.longitude;

		// Load weather data using the lat and lon values, now that we have the user's position.
		getWeatherDataFromCoords(lat, lon);
	}

	function geolocationErrorHandler (error)
	{
		// The user has disallowed sharing their geolocation, or there was a general error obtaining the info.
		console.log("geolocationErrorHandler");
	}

	function getWeatherDataFromCoords (lat, lon)
	{
		console.log("getting weather data...", lat, lon);
		
		// Build a request URL based on the current lat and lon values.
		var requestURL = API_URL + "&lat=" + lat + "&lon=" + lon;

		// Make an AJAX request to the API.
		atomic.get(requestURL)
			.success(apiRequestSuccess)
			.error(apiRequestError);
	}

	function apiRequestSuccess (data, xhr)
	{
		console.log("weather data received.", data);

		if (typeof data.cod !== "undefined" && data.cod === "404")
		{
			alert(MESSAGE_LOCATION_NOT_FOUND);
			return;
		}
	}

	function apiRequestError (data, xhr)
	{
		alert(MESSAGE_API_REQUEST_ERROR);
	}

})();

We have now built a function to request weather data – getWeatherDataFromCoords – and we are calling it after we have obtained the user’s coordinates, from within the geolocationSuccessHandler function.

If you open up the JavaScript console on your browser, you should see the log messages from the application, including an object containing weather information.

Displaying Weather Information

Logging the data we got from the API is all well and good, but it would be great to update the HTML in order to show the weather information to the user, so let’s go ahead and do that now:

(function (){
	
	var API_KEY = "YOUR_API_KEY_HERE";
	var API_UNIT_TYPE = "metric"; // otherwise change to 'imperial'.
	var API_URL = "http://api.openweathermap.org/data/2.5/weather?APPID=" + API_KEY + "&units=" + API_UNIT_TYPE;

	// Use '°C' for metric units, or  '°F' for imperial units.
	var UNITS_SUFFIX = API_UNIT_TYPE === "metric" ? "°C" : "°F";

	var MESSAGE_LOCATION_NOT_FOUND = "Location not found. Please search for something else.";
	var MESSAGE_API_REQUEST_ERROR = "There was a problem getting weather data. Please try again.";

	var _locationNameDisplay;
	var _temperatureDisplay;

	// Add an event listener to ensure the DOM has loaded before
	// initialising the application.
	document.addEventListener("DOMContentLoaded", init);

	function init ()
	{
		_locationNameDisplay = document.querySelector(".location-name-display");
		_temperatureDisplay = document.querySelector(".temperature-display");

		// Get the geo position of the current user (if they allow this).
		navigator.geolocation.getCurrentPosition(geolocationSuccessHandler, geolocationErrorHandler);
	}

	function geolocationSuccessHandler (position)
	{
		// Get lat and lon values from the position object.
		var lat = position.coords.latitude;
		var lon = position.coords.longitude;

		// Load weather data using the lat and lon values, now that we have the user's position.
		getWeatherDataFromCoords(lat, lon);
	}

	function geolocationErrorHandler (error)
	{
		// The user has disallowed sharing their geolocation, or there was a general error obtaining the info.
		console.log("geolocationErrorHandler");
	}

	function getWeatherDataFromCoords (lat, lon)
	{
		console.log("getting weather data...", lat, lon);

		// Build a request URL based on the current lat and lon values.
		var requestURL = API_URL + "&lat=" + lat + "&lon=" + lon;

		// Make an AJAX request to the API.
		atomic.get(requestURL)
			.success(apiRequestSuccess)
			.error(apiRequestError);
	}

	function apiRequestSuccess (data, xhr)
	{
		console.log("weather data received.", data);

		// The data returned by the API contains a property called 'cod',
		// rather than 'code', for the response status code. This is not a typo!
		if (typeof data.cod !== "undefined" && data.cod === "404")
		{
			alert(MESSAGE_LOCATION_NOT_FOUND);
			return;
		}

		// Get the location name, country code, and temperature from the data object
		// returned by the API, ensuring that we round it to the nearest integer.
		var locationName = data.name;
		var countryCode = data.sys.country;
		var temperature = Math.round(data.main.temp);

		// Don't display anything if there is no name and country code.
		if (locationName === "" && countryCode === "")
		{
			alert(MESSAGE_LOCATION_NOT_FOUND);
			return;
		}

		updateLocationDisplay(locationName, countryCode, temperature);
	}

	function apiRequestError (data, xhr)
	{
		alert(MESSAGE_API_REQUEST_ERROR);
	}

	function updateLocationDisplay(locationName, countryCode, temperature)
	{
		if (locationName !== "")
		{
			_locationNameDisplay.innerHTML = locationName + ", " + countryCode;
		}
		else
		{
			_locationNameDisplay.innerHTML = countryCode;
		}

		_temperatureDisplay.innerHTML = temperature + UNITS_SUFFIX;
	}

})();

Firstly, we are checking if the status code in the data object returned by the API is 404 (not found) before proceeding. If it is then we need to alert the user so they know there was a problem with the request. We then grab the location name, country code, and temperature from the API data object. Next, we check if both the location name and country code are empty strings, and if this is the case we again alert the user, since we would have nothing to display. Lastly, we call the updateLocationDisplay function, within which we display either the location name, country code, or both, dependant on what is available.

Adding Search Functionality

At this point, we have successfully displayed weather information for a user’s coordinates, and we can further improve our application by adding a search feature, so that we can get temperature information for practically any location in the world, based on user-entered text.

The input text field already exists in the HTML code, but is currently not functional. In this section we’ll go through the logic for using a search term. To reiterate, we want to do the following:

1. Listen for when the user submits the search form
2. Make an api request using the text they entered into the search text field
3. Parse the JSON data received from the API
4. If the location is found, display temperature information using the parsed data

We have already written the logic for #3 and #4, and we should re-use this instead of creating duplicate functionality. So, we just need to create the logic for #1 and #2:

(function (){

	var API_KEY = "YOUR_API_KEY_HERE";
	var API_UNIT_TYPE = "metric"; // otherwise change to 'imperial'.
	var API_URL = "http://api.openweathermap.org/data/2.5/weather?APPID=" + API_KEY + "&units=" + API_UNIT_TYPE;

	// Use '°C' for metric units, or  '°F' for imperial units.
	var UNITS_SUFFIX = API_UNIT_TYPE === "metric" ? "°C" : "°F";

	var MESSAGE_LOCATION_NOT_FOUND = "Location not found. Please search for something else.";
	var MESSAGE_API_REQUEST_ERROR = "There was a problem getting weather data. Please try again.";
	var MESSAGE_SEARCH_NOT_SPECIFIED = "Please specify a search term.";

	var _locationSearchForm;
	var _locationSearchInput;
	var _locationNameDisplay;
	var _temperatureDisplay;
	var _waitingForData;

	// Add an event listener to ensure the DOM has loaded before
	// initialising the application.
	document.addEventListener("DOMContentLoaded", init);

	function init ()
	{
		_locationSearchForm = document.querySelector("#location-search-form");
		_locationSearchInput = document.querySelector(".location-search-input");
		_locationNameDisplay = document.querySelector(".location-name-display");
		_temperatureDisplay = document.querySelector(".temperature-display");

		_waitingForData = false;

		// Add a listener for when the search form is submitted.
		_locationSearchForm.addEventListener("submit", locationSearchFormSubmitHandler);

		// Get the geo position of the current user (if they allow this).
		navigator.geolocation.getCurrentPosition(geolocationSuccessHandler, geolocationErrorHandler);
	}

	function geolocationSuccessHandler (position)
	{
		// Get lat and lon values from the position object.
		var lat = position.coords.latitude;
		var lon = position.coords.longitude;

		// Load weather data using the lat and lon values, now that we have the user's position.
		getWeatherDataFromCoords(lat, lon);
	}

	function geolocationErrorHandler (error)
	{
		// The user has disallowed sharing their geolocation, or there was a general error obtaining the info.
		// Even still, they will still be able to search for weather information.
		console.log("geolocationErrorHandler");
	}

	function locationSearchFormSubmitHandler (event)
	{
		event.preventDefault();
		
		console.log("form submit.", _locationSearchInput.value);

		if (_locationSearchInput.value !== "")
		{
			getWeatherDataFromLocationName(_locationSearchInput.value);

			_locationSearchInput.value = "";
		}
		else
		{
			alert(MESSAGE_SEARCH_NOT_SPECIFIED);
		}
	}

	function getWeatherDataFromCoords (lat, lon)
	{
		// Don't do anything if we are waiting on the response of a previous API request.
		if (_waitingForData)
		{
			return false;
		}

		// Disable API requests until we receive a response.
		_waitingForData = true;

		console.log("getting weather data...", lat, lon);

		// Build a request URL based on the current lat and lon values.
		var requestURL = API_URL + "&lat=" + lat + "&lon=" + lon;

		// Make an AJAX request to the API.
		atomic.get(requestURL)
			.success(apiRequestSuccess)
			.error(apiRequestError);
	}

	function getWeatherDataFromLocationName (locationName)
	{
		// Don't do anything if we are waiting on the response of a previous API request.
		if (_waitingForData)
		{
			return false;
		}

		// Disable API requests until we receive a response.
		_waitingForData = true;

		console.log("getting weather data...", locationName);

		// Build a request URL based on the current lat and lon values.
		var requestURL = API_URL + "&q=" + locationName;

		// Make an AJAX request to the API.
		atomic.get(requestURL)
			.success(apiRequestSuccess)
			.error(apiRequestError);
	}

	function apiRequestSuccess (data, xhr)
	{
		console.log("weather data received.", data);

		// Reenable data lookups now that the API response has been received.
		_waitingForData = false;

		// The data returned by the API contains a property called 'cod',
		// rather than 'code', for the response status code. This is not a typo!
		if (typeof data.cod !== "undefined" && data.cod === "404")
		{
			alert(MESSAGE_LOCATION_NOT_FOUND);
			return;
		}

		// Get the location name, country code, and temperature from the data object
		// returned by the API, ensuring that we round it to the nearest integer.
		var locationName = data.name;
		var countryCode = data.sys.country;
		var temperature = Math.round(data.main.temp);

		// Don't display anything if there is no name and country code.
		if (locationName === "" && countryCode === "")
		{
			alert(MESSAGE_LOCATION_NOT_FOUND);
			return;
		}

		updateLocationDisplay(locationName, countryCode, temperature);
	}

	function apiRequestError (data, xhr)
	{
		alert(MESSAGE_API_REQUEST_ERROR);

		// Reenable data lookups so that we can retry requesting weather data.
		_waitingForData = false;
	}

	function updateLocationDisplay(locationName, countryCode, temperature)
	{
		if (locationName !== "")
		{
			_locationNameDisplay.innerHTML = locationName + ", " + countryCode;
		}
		else
		{
			_locationNameDisplay.innerHTML = countryCode;
		}

		_temperatureDisplay.innerHTML = temperature + UNITS_SUFFIX;
	}

})();

We have stored references to the input text field and the form within which it is contained, allowing us to listen out for when a user submits the form, so that we can run the locationSearchFormSubmitHandler function. Within this function, the first piece of code to get executed is event.preventDefault(). This stops the default form submission action so that we can write our own implementation without the page being refreshed. We then check if the input text field is empty, and if so we alert the user, otherwise the getWeatherDataFromLocationName function is run with the value of the input text field provided as a parameter. We then clear the contents of the input text field to make it easier for the user to search weather data for somewhere else next time.

The getWeatherDataFromLocationName function is similar to getWeatherDataFromCoords, but accepts a single string as a parameter, rather than coordinates. Notice also that we have added conditional logic to both of those functions, which checks the state of the _waitingForData boolean variable. This check is done so that only a single API request can be performed at any given time – the value of the variable is set to ‘true’ when an API request is in progress, and then back to ‘false’ when we receive a response or error.

We then reuse the previously created logic to parse and display the weather information.

Making It Pretty

In this section we'll create some logic to dynamically update the class names of elements and then use some basic SCSS to style the application and make it look slick with CSS3 transitions.

Logic to Facilitate Styling

Our final JavaScript code is as follows:

(function (){
	
	var API_KEY = "YOUR_API_KEY_HERE";
	var API_UNIT_TYPE = "metric"; // otherwise change to 'imperial'.
	var API_URL = "http://api.openweathermap.org/data/2.5/weather?APPID=" + API_KEY + "&units=" + API_UNIT_TYPE;

	var TEMPERATURES = {

		FREEZING	: {MAX : 0, CLASS_NAME : "freezing"},
		COLD		: {MAX : 8, CLASS_NAME : "cold"},
		WARM		: {MAX : 16, CLASS_NAME : "warm"},
		HOT			: {MAX : 24, CLASS_NAME : "hot"},
		BLAZING		: {MAX : Number.POSITIVE_INFINITY, CLASS_NAME : "blazing"}
	};

	// Use '°C' for metric units, or  '°F' for imperial units.
	var UNITS_SUFFIX = API_UNIT_TYPE === "metric" ? "°C" : "°F";

	var MESSAGE_LOCATION_NOT_FOUND = "Location not found. Please search for something else.";
	var MESSAGE_API_REQUEST_ERROR = "There was a problem getting weather data. Please try again.";
	var MESSAGE_SEARCH_NOT_SPECIFIED = "Please specify a search term.";

	var _mainContainer;
	var _locationSearchForm;
	var _locationSearchSubmitWrapper;
	var _locationSearchInput;
	var _currentTemperatureClassName;
	var _locationNameDisplay;
	var _temperatureDisplay;
	var _waitingForData;

	// Add an event listener to ensure the DOM has loaded before
	// initialising the application.
	document.addEventListener("DOMContentLoaded", init);

	function init ()
	{
		_mainContainer = document.querySelector(".main-container");
		_locationSearchForm = document.querySelector("#location-search-form");
		_locationSearchSubmitWrapper = document.querySelector(".location-search-submit-wrapper");
		_locationSearchInput = document.querySelector(".location-search-input");
		_locationNameDisplay = document.querySelector(".location-name-display");
		_temperatureDisplay = document.querySelector(".temperature-display");

		_waitingForData = false;

		// Add a listener for when the search form is submitted.
		_locationSearchForm.addEventListener("submit", locationSearchFormSubmitHandler);

		// Get the geo position of the current user (if they allow this).
		navigator.geolocation.getCurrentPosition(geolocationSuccessHandler, geolocationErrorHandler);
	}

	function geolocationSuccessHandler (position)
	{
		// Get lat and lon values from the position object.
		var lat = position.coords.latitude;
		var lon = position.coords.longitude;

		// Load weather data using the lat and lon values, now that we have the user's position.
		getWeatherDataFromCoords(lat, lon);
	}

	function geolocationErrorHandler (error)
	{
		// The user has disallowed sharing their geolocation, or there was a general error obtaining the info.
		// Even still, they will still be able to search for weather information.
		console.log("geolocationErrorHandler");
	}

	function locationSearchFormSubmitHandler (event)
	{
		event.preventDefault();
		
		console.log("form submit.", _locationSearchInput.value);

		if (_locationSearchInput.value !== "")
		{
			getWeatherDataFromLocationName(_locationSearchInput.value);

			_locationSearchSubmitWrapper.classList.add("loading");
			_locationSearchInput.value = "";
		}
		else
		{
			alert(MESSAGE_SEARCH_NOT_SPECIFIED);
		}
	}

	function getWeatherDataFromCoords (lat, lon)
	{
		// Don't do anything if we are waiting on the response of a previous API request.
		if (_waitingForData)
		{
			return false;
		}

		// Disable API requests until we receive a response.
		_waitingForData = true;

		console.log("getting weather data...", lat, lon);

		// Build a request URL based on the current lat and lon values.
		var requestURL = API_URL + "&lat=" + lat + "&lon=" + lon;

		// Make an AJAX request to the API.
		atomic.get(requestURL)
			.success(apiRequestSuccess)
			.error(apiRequestError);
	}

	function getWeatherDataFromLocationName (locationName)
	{
		// Don't do anything if we are waiting on the response of a previous API request.
		if (_waitingForData)
		{
			return false;
		}

		// Disable API requests until we receive a response.
		_waitingForData = true;

		console.log("getting weather data...", locationName);

		// Build a request URL based on the current lat and lon values.
		var requestURL = API_URL + "&q=" + locationName;

		// Make an AJAX request to the API.
		atomic.get(requestURL)
			.success(apiRequestSuccess)
			.error(apiRequestError);
	}

	function apiRequestSuccess (data, xhr)
	{
		console.log("weather data received.", data);

		// Reenable data lookups now that the API response has been received.
		_waitingForData = false;
		_locationSearchSubmitWrapper.classList.remove("loading");

		// The data returned by the API contains a property called 'cod',
		// rather than 'code', for the response status code. This is not a typo!
		if (typeof data.cod !== "undefined" && data.cod === "404")
		{
			alert(MESSAGE_LOCATION_NOT_FOUND);
			return;
		}

		// Get the location name, country code, and temperature from the data object
		// returned by the API, ensuring that we round it to the nearest integer.
		var locationName = data.name;
		var countryCode = data.sys.country;
		var temperature = Math.round(data.main.temp);

		// Don't display anything if there is no name and country code.
		if (locationName === "" && countryCode === "")
		{
			alert(MESSAGE_LOCATION_NOT_FOUND);
			return;
		}

		updateLocationDisplay(locationName, countryCode, temperature);
		updateBackgroundColor(temperature);
	}

	function apiRequestError (data, xhr)
	{
		alert(MESSAGE_API_REQUEST_ERROR);

		// Reenable data lookups so that we can retry requesting weather data.
		_waitingForData = false;
	}

	function updateLocationDisplay(locationName, countryCode, temperature)
	{
		if (locationName !== "")
		{
			_locationNameDisplay.innerHTML = locationName + ", " + countryCode;
		}
		else
		{
			_locationNameDisplay.innerHTML = countryCode;
		}

		_temperatureDisplay.innerHTML = temperature + UNITS_SUFFIX;
	}

	function updateBackgroundColor (temperature)
	{
		// If we previously set a temperature class name on the main
		// container element then remove it here.
		if (typeof _currentTemperatureClassName !== "undefined")
		{
			_mainContainer.classList.remove(_currentTemperatureClassName);
		}

		// Set the '_currentTemperatureClassName' variable based on the
		// constants we defined earlier.
		if (temperature <= TEMPERATURES.FREEZING.MAX)
		{
			_currentTemperatureClassName = TEMPERATURES.FREEZING.CLASS_NAME;
		}
		else if (temperature <= TEMPERATURES.COLD.MAX)
		{
			_currentTemperatureClassName = TEMPERATURES.COLD.CLASS_NAME;
		}
		else if (temperature <= TEMPERATURES.WARM.MAX)
		{
			_currentTemperatureClassName = TEMPERATURES.WARM.CLASS_NAME;
		}
		else if (temperature <= TEMPERATURES.HOT.MAX)
		{
			_currentTemperatureClassName = TEMPERATURES.HOT.CLASS_NAME;
		}
		else
		{
			_currentTemperatureClassName = TEMPERATURES.BLAZING.CLASS_NAME;
		}

		// Set a temperature class name on the main container element.
		_mainContainer.classList.add(_currentTemperatureClassName);
	}

})();

We’ve added a function called updateBackgroundColor that accepts a single numerical parameter – the current temperature. Also, we’ve created a ‘TEMPERATURES’ object, which contains information that we’ll use within the updateBackgroundColor function to determine which CSS class gets added to the main container div element of the application. If the temperature parameter value is less than or equal to the maximum ‘freezing’ temperature, then we add the ‘freezing’ class name, otherwise, if the temperature parameter value is less than or equal to the maximum ‘cold’ temperature, then we add the ‘cold’ class name, and so on. Additionally, there is a _currentTemperatureClassName variable for keeping track of the current class name that has been added to the main container, so that the class name can be removed the next time the function runs. This ensures we don’t end up with multiple temperature class names on the main container.

Now that the main container has specific temperature class names added and removed, we target those class names using our SCSS code, so that the background colour is updated when we search for different locations, based on on temperature.

Lastly, we have created a _locationSearchSubmitWrapper variable. this will allow us to target an element wrapping the form submit button so that we can add a transition to show when the app waiting for a response to an API request. This will provide visual feedback to the user so that they understand what the application is doing, rather than blindly waiting for something to happen. We add and remove a ‘loading’ class to this element where appropriate.

Styling and Transitions

Let’s take a brief look at the way we will be styling the application using SCSS to illustrate some of the basic concepts of the language.

Partials

In SCSS, partials are simply files that have been broken up into logical segments, which we can include in our code using the @import directive. By convention, partial files are named with a leading underscore. Here is a basic example:

Main file – app.scss

body {
	background-color: blue;
}

@import "some-amazing-partial";

Partial file – some-amazing-partial.scss

body {
	background-color: green;
}

In the first file – app.scss – we simply set the background colour of the body element to blue and then import some-amazing-partial.scss, which then changes the background colour to green, overriding the previously set value. Note also that we don’t provide the ‘scss’ file extension when importing partials.
If we were to compile the above two files into pure CSS it would look as follows:

body {
	background-color: blue;
}

body {
	background-color: green;
}

so we are effectively just inserting all the content from a partial file wherever we use the @import directive.

Variables

We can also make use of simple variables in SCSS, the definitions for which start with a dollar sign. Variables make updating things such as colour schemes way easier than when using CSS alone. Consider the following standard CSS code:

.first-element {
	background-color: blue;
}

.second-element {
	background-color: blue;
}

.third-element {
	background-color: blue;
}

With standard CSS, if we wanted to change the background colour of all the targeted elements then we’d have to do so individually. Now that’s not so bad when there are only three elements, but imagine how long this simple update would take if there were hundreds of places throughout the styling code where this colour was defined! “Find and replace”, I hear you say, but what if there are some other elements that also use this colour, which we don’t want to change? Now that’s a lot of work!
With SCSS, we could simply define some logically-named variables for our colours, and when we need to update a particular colour all that would be required is a quick change to a single variable value. Here’s a simple example:

$color-nav: blue;
$color-examples: blue;

.navigation-element {
	background-color: $color-nav;
}

.example-element-1 {
	background-color: $color-examples;
}

.example-element-2 {
	background-color: $color-examples;
}

Here we simply create two variables for colours, one for navigation and one for some example elements. Now if we want to change the colour of our navigation we can do so very easily, and without affective the colour of the example elements.

On a side note, it’s normally a good idea to include the majority of your variables in a separate file (as we have done for this project), or group of files, so that they are always easy to find.

Mixins

In SCSS, mixins are effectively used to include snippets of code that we use regularly, in a similar way to JavaScript functions that return a value (but not quite the same way as SCSS functions). We can also pass parameters to mixins to alter the code the return. A good use case for a mixing would be something like including a clearfix:

Here’s how we could fix the issue with CSS alone:

.some-element-1:after {
	content: "";
	display: table;
	clear: both;
}

.some-element-2:after {
	content: "";
	display: table;
	clear: both;
}

Now obviously if we have many elements that need a clearfix then we’d have to be writing this a lot. Mixins to the rescue – here’s the same thing written in SCSS:

mixins.scss
A file to potentially contain many types of mixins

@mixin clearfix {
	&:after {
		content: "";
		display: table;
		clear: both;
	}
}

*app.scss*

.some-element-1 {
	@include clearfix;
}

.some-element-2 {
	@include clearfix;
}

Now that’s much neater :)

Transitions

Now, moving back to our application, we aren’t going to go into too much detail about the SCSS implementation, but one thing worth looking at briefly is CSS3 transitions. We’ll use transitions in order to give the application a nice slick look and feel – fading between background colours when the user searches for locations. To do that we simply add a transition property to the main container div element:

.main-container {
	transition: background-color 1s linear;
}

This basically states that whenever the background-color property is updated for this element, the browser should transition for 1 second between the old value and the new value. Very simple, yet very effective.

Finally, we will also add another transition for showing and hiding a loading icon in place of the form submit button, for when the application needs to show that it is loading:

.location-search-submit, .location-search-cloud-icon {
	transition: left 0.4s ease;
	transition-delay: 0.5s;
}

That just about wraps it up. If you have any questions about the application, including the logic, styling, or any of the concepts we’ve covered, then feel free to post a comment.

And as always, happy coding!

Recently, I wrote the first part of a tutorial on creating a web-app, walking you through the necessary steps to use Grunt as a build tool. In the second part of the tutorial, the implementation of the web-app – Breeze – will be explained, but as a sneak peek, you can find the finished product here:

https://ivanhayes.com/breeze

You can also fork the repo on Github and switch to the ‘tutorial-part-2’ branch.

Stay tuned for the second part of the tutorial, coming soon!

This is the first of a two-part tutorial, in which we’ll be creating a web-app – Breeze – that will load and display temperature information for various cities using data from OpenWeatherMap. In this part of the tutorial, we’ll be setting up a simple build workflow using Grunt and npm.

If you’re short on time and just want to see the complete code for this part of the tutorial then you can fork the repo on Github and switch to the ‘tutorial-part-1’ branch.

A Note for Windows Users

Throughout this tutorial I will be referring to the Mac command line application – Terminal, so if you are on Windows then you’ll simply need to use Command Prompt instead.

Development Environment Setup

Firstly we need to have our dev environment setup so that we can use npm and Grunt. To do this we just need to ensure Node.js is installed, as npm comes bundled with it by default. So if you haven’t already got this up and running then installing one of the pre-built packages from the Node.js website is probably the simplest method.

Next we need to install Sass. If you are using Windows then you’ll first need to install Ruby, whereas if you are using a Mac then Ruby comes pre-installed. To install Sass, open Terminal and run the following command:

gem install sass

This can take a few minutes to complete, so be patient, but if you are using a Mac and the above command is failing then you could use sudo gem install sass instead.

Project Setup

You will need to download a small library called ‘atomic’, which our project will use for making AJAX requests to the OpenWeatherMap API.

Now we need to setup the project files and folders – create the following structure:

breeze
│
├──• Gruntfile.js
├──• index.html
├──• package.json
│
└───src
     │
     ├───js
     │    ├───app
     │    │    │
     │    │    └──• app.js
     │    │
     │    └───libs
     │         │
     │         └──• atomic.js
     └───scss
          │
          └──• app.scss

The breeze directory will serve as the document root of our application.

Now that we have the basic structure, let’s add some content to the files we just created. The contents of index.html should be as follows:

<!DOCTYPE html>

<html>
	<head>
		<title>Breeze</title>
		<link rel="stylesheet" type="text/css" href=“dist/css/app.min.css">
	</head>

	<body>
		<div class="main-container"> </div>

		<script src=“dist/js/app.min.js"></script>
	</body>
</html>

Astute readers may have noticed that – within the HTML markup – we are referencing directories and files that don’t exist – dist/css/app.min.css and dist/js/app.min.js. These directories and files will be created automatically by Grunt once we set it up and run a build task.

For the contents of app.js, we will temporarily just add an alert message:

alert("Breeze");

And finally, the contents of app.scss will currently just contain the following styles:

html, body, div {
	margin: 0;
	padding: 0;
}

Installing Development Dependencies

We are going to use npm for installing development dependencies – those used by Grunt for the build step of our application.

The first thing we need to install is the CLI (command line interface) for Grunt. This will be a global install; it isn’t specific to our project and will be available system-wide, so you’ll only need to do this once per-system:

Mac users
You will need to run this command with sudo.

sudo npm install -g grunt-cli

Windows users

npm install -g grunt-cli

Next up, within the breeze directory, open the package.json file that we created earlier and add the following:

{
  "name": "breeze",
  "version": "0.0.1"
}

This simply defines some basic information about our application which is required by npm. Save and close the file.

Although the package.json file has many uses, within the scope of this tutorial – and other than the required name and version properties – it will simply be used to define the development dependencies of our application.

Note that the command npm init could instead be used to automatically generate a package.json file, but doing so adds many properties that we won’t need to use in this tutorial, so creating it manually is a simpler option in this case.

Now that we have our package.json file, using Terminal, change to the breeze directory. We will need to run all remaining commands from this directory. Install the development dependencies by running the following command:

npm install grunt grunt-contrib-connect grunt-contrib-sass grunt-contrib-uglify grunt-contrib-watch grunt-devtools --save-dev

This installs all of our development dependencies into a node-modules folder within the breeze directory. A ‘devDependencies’ property is also added to package.json, listing the names and current version numbers of our application’s development dependencies:

{
  "name": "breeze",
  "version": "0.0.1",
  "devDependencies": {
    "grunt": "^0.4.5",
    "grunt-contrib-connect": "^0.8.0",
    "grunt-contrib-sass": "^0.8.1",
    "grunt-contrib-uglify": "^0.6.0",
    "grunt-contrib-watch": "^0.6.1",
    "grunt-devtools": "^0.2.1"
  }
}

Doing the Grunt Work

We will be using Grunt – a JavaScript task runner – to carry out the build step of our application. Grunt works by running various user-defined tasks when instructed to do so. We are going to set it up in such a way that our tasks run when a change to JavaScript or SCSS files is detected.

To use Grunt, we first need to open Gruntfile.js that we created earlier within the breeze directory and paste in the following code, which we will discuss in more detail below:

module.exports = function(grunt) {

	"use strict";

	grunt.initConfig({

	});
};

When we use the Grunt CLI (more on this below), the version of the Grunt library specified within the devDependencies property inside package.json is loaded and the configuration within the Gruntfile is automatically applied. Currently our Gruntfile doesn’t contain any configuration options, so we’ll start adding these now.

Sass

First, we’ll add a config for compiling our SCSS code using the sass task (grunt-contrib-sass) – a wrapper for the version of Sass installed on our system i.e. the Sass Ruby gem we installed earlier:

module.exports = function(grunt) {

	"use strict";

	grunt.loadNpmTasks("grunt-contrib-sass");

	grunt.initConfig({
		sass: {

			dev : {
				options: {
					style: "compressed",
					sourcemap : true
				},

				files: {
					"dist/css/app.min.css": "src/scss/app.scss"
				}
			}
		}
	});
};

Here, we first tell Grunt to load the sass task and then we define the config for this task within the object that gets passed into Grunt’s initConfig method. Within the sass task we define a ‘dev’ configuration object. We can define however many configurations we like and call them whatever we like, but within these configuration objects we need to follow the rules of the task we are using, which in this case is sass. The sass task allows us to define an ‘options’ object containing various properties that affect how our SCSS is converted into CSS. In this case we are simply stating that we want the CSS to be compressed into one line with any empty space removed. The ‘files’ object contains two file path strings – the one on the left is the file path to which we want Grunt to output our compiled CSS, and the one on the right is the main SCSS file we want to use to start the compilation process.

To test that everything is working as expected, run the following command in Terminal:

grunt sass:dev

Doing that should compile the SCSS into an app.min.css file within the dist/css/ directory.

Uglify

Next up, we want to use the uglify (grunt-contrib-uglify) task to concatenate all of our JavaScript into a single file and then minify this file when complete so that it loads quickly in web browsers. This is also a good way to reduce the number of HTTP requests an application makes when developing with more than one JavaScript file; rather than using multiple script tags within the HTML markup we will only need to use a single one that points to the compiled file containing all of our JavaScript code – app.min.js. To carry out the concatenation and minification process we will add a configuration object for the uglify task:

module.exports = function(grunt) {

	"use strict";

	grunt.loadNpmTasks("grunt-contrib-sass");
	grunt.loadNpmTasks("grunt-contrib-uglify");

	grunt.initConfig({

		sass: {

			dev : {
				options: {
					style: "compressed",
					sourcemap : true
				},

				files: {
					"dist/css/app.min.css": "src/scss/app.scss"
				}
			}
		},

		uglify : {

			dev : {
				options : {
					compress : true,
					mangle : true,
					preserveComments : false
				},

				files: {
					"dist/js/app.min.js" : ["src/js/libs/atomic.js", "src/js/app/app.js"]
				}
			}
		}
	});
};

We have now also loaded the uglify task and defined a dev config for it within the object passed into Grunt’s initConfig method.

The ‘files’ object for uglify works in exactly the same way as the one within the sass config, with the exception that we are passing in an array of JavaScript file paths on the right. All of these files will be concatenated, minified and output to a single JavaScript file. When set to ‘true’, the compress option shortens variable and function names, and removes empty space in an attempt to reduce the overall file size. Similarly, When set to ‘true’, the mangle option performs various optimisations such as removing unreferenced functions and variables. We have set the preserveComments option to ‘false’ so that all comments will be removed from the minified file.

To test that everything is working as expected, run the following command in Terminal:

grunt uglify:dev

Doing that should compile the JavaScript into an app.min.js file within the dist/js/ directory.

A word of warning here – the files are concatenated in the same order that they are specified in the array of file paths, so you’ll need to ensure that dependencies are ordered correctly.

With all that working as expected, the project directory structure should now look like this:

breeze
│
├──• Gruntfile.js
├──• index.html
├──• package.json
│
├───src
│    │
│    ├───js
│    │    │
│    │    ├───app
│    │    │    │
│    │    │    └──• app.js
│    │    │
│    │    └───libs
│    │         │
│    │         └──• atomic.js
│    └───scss
│         │
│         └──• app.scss
│
└───dist
     │
     ├───css
     │    │
     │    └──• app.min.css
     └───js
          │
          └──• app.min.js

Connect

Now that we’ve setup a build for our SCSS and JavaScript, we are going to create a connect (grunt-contrib-connect) config that allows us to quickly start a basic server in order to run our application, which will be launched in the default browser. This is way quicker than configuring Apache, for example. And like Apache, the connect server runs our application using the http:// protocol – which allows us to use AJAX – rather than the file:// protocol which does not.

We will set this up in a similar way to the other configs:

module.exports = function(grunt) {

	"use strict";

	grunt.loadNpmTasks("grunt-contrib-sass");
	grunt.loadNpmTasks("grunt-contrib-uglify");
	grunt.loadNpmTasks("grunt-contrib-connect");

	grunt.initConfig({

		sass: {

			dev: {
				options: {
					style: "compressed",
					sourcemap : true
				},

				files : {
					"dist/css/app.min.css": "src/scss/app.scss"
				}
			}
		},

		uglify: {

			dev: {
				options: {
					compress: true,
					mangle: true,
					preserveComments: false
				},

				files: {
					"dist/js/app.min.js" : ["src/js/libs/atomic.js", "src/js/app/app.js"]
				}
			}
		},

		connect: {

			server : {
				options: {
					open: true,
					keepalive: true
				}
			}
		}
	});
};

As with the other tasks, we have loaded the connect task and defined a config, which this time we have called ‘server’. The only two options we need to use at this point are ‘open’ and ‘keepalive’ – both of which we have set to ‘true’. The open option simply launches the default web browser on our system and loads the index page within the same directory as the Gruntfile. By default, the connect task only keeps the server active for as long as our other tasks are running, so since we have no continually-running tasks, we use the keepalive option to force the server to stay active until it is manually stopped.

Run the following command to launch our application in the default browser:

grunt connect:server

Notice that, within the Terminal window, we can no longer run any commands now that we have the server running. To stop the server, on the keyboard hold the ctrl key and press c.

If you want to run Grunt commands while the server is active then you can open another Terminal window and once again change to the breeze directory.

Running Multiple Tasks with One Command

So far, we have set things up so that we can run tasks one at a time, but what if we want to run multiple tasks? We could run them one after the other in Terminal, but there is an easier way – we can register our own tasks with Grunt, which is much more straightforward than it sounds. Let’s start by creating a task that will first run sass:dev, followed by uglify:dev, and then finally connect:server. We’ll call this task ‘breeze’:

module.exports = function(grunt) {

	"use strict";

	grunt.loadNpmTasks("grunt-contrib-sass");
	grunt.loadNpmTasks("grunt-contrib-uglify");
	grunt.loadNpmTasks("grunt-contrib-connect");

	grunt.initConfig({

		sass: {

			dev: {
				options: {
					style: "compressed",
					sourcemap : true
				},

				files : {
					"dist/css/app.min.css": "src/scss/app.scss"
				}
			}
		},

		uglify: {

			dev: {
				options: {
					compress: true,
					mangle: true,
					preserveComments: false
				},

				files: {
					"dist/js/app.min.js" : ["src/js/libs/atomic.js", "src/js/app/app.js"]
				}
			}
		},

		connect: {

			server : {
				options: {
					open: true,
					keepalive: true
				}
			}
		}
	});

	grunt.registerTask("breeze", ["sass:dev", "uglify:dev", "connect:server”]);
};

So now instead of sequentially running each task manually, in Terminal, we now simply need to run:

grunt breeze

This will run all the tasks we specified in the array for the second parameter of Grunt’s registerTask method.

Automating Build Tasks

Now everything is set up and ready for us to manually run builds of our SCSS and JavaScript, and view our app within the browser. But, wouldn’t it be nice if we could go one step further and have Grunt run relevant tasks automatically when any of our development files is changed? That’s precisely what we’ll be doing in this section of this tutorial.

Watch

To automate the running of the tasks that we have already defined, we first need to setup a watch (grunt-contrib-watch) task which watches specific files and runs relevant tasks if any of the files changes.

Setting up the watch task is very similar to the way in which we setup all the other tasks (this is now the complete Gruntfile):

module.exports = function(grunt) {

	"use strict";

	grunt.loadNpmTasks("grunt-contrib-sass");
	grunt.loadNpmTasks("grunt-contrib-uglify");
	grunt.loadNpmTasks("grunt-contrib-connect");
	grunt.loadNpmTasks("grunt-contrib-watch");

	grunt.initConfig({

		sass: {

			dev: {
				options: {
					style: "compressed",
					sourcemap : true
				},

				files : {
					"dist/css/app.min.css": "src/scss/app.scss"
				}
			}
		},

		uglify: {

			dev: {
				options: {
					compress: true,
					mangle: true,
					preserveComments: false
				},

				files: {
					"dist/js/app.min.js" : ["src/js/libs/atomic.js", "src/js/app/app.js"]
				}
			}
		},

		connect: {

			server : {
				options: {
					open: true
				}
			}
		},

		watch: {
			
			js: {
				files: ["src/js/**/*.js"],
				tasks: ["uglify:dev"]
			},

			scss: {
				files: ["src/scss/**/*.scss"],
				tasks: ["sass:dev"]
			}
		}
	});

	grunt.registerTask("breeze", ["sass:dev", "uglify:dev", "connect:server", "watch"]);
};

We have loaded the watch task and created two configs – ‘js’ and ‘scss’. These configs could have been called anything else, but the names were chosen so that the nature of what the configs will be used for is clear. Within each config, using the files option, we specify an array of file paths that are to be watched for changes, and then, using the tasks option, we specify a list of tasks to run when any of the listed files is changed. In the js config we are watching all files that have a .js file extension within the src/js directory and its subdirectories. When any of these files is changed, the uglify:dev task is run automatically. Similarly, with the scss config we are watching all files that have a .scss file extension within the src/scss directory and its subdirectories. When any of these files is changed, the sass:dev task is run automatically.

At this point, it is important to note that we have removed the keepalive property from the 'server' config of the connect task, since it would have stopped the watch task – or any task, for that matter – from running afterwards. The keepalive property is no longer needed because we are now using the continually-running watch task, which will keep the server alive automatically.

Notice that – within the breeze task we created earlier – ‘watch’ has been added to the array of tasks that Grunt will run for us sequentially.

Now we simply need to once again run our grunt breeze task using Terminal (be sure to cancel any running tasks using ctrl + c first) and our app will launch in the browser, with the watch task waiting for changes on the lists of files we specified. To check this is working change the alert message in app.js to the following:

alert("Grunt is a breeze");

Save the file and Grunt should automatically run the tasks we specified in the watch:js config, so refresh the web browser and you should see the new alert.

Next steps

So far we have covered how to setup Sass and npm, and how to use Grunt to setup a simple workflow for the build step of a web application.

In the next instalment of this two-part tutorial, we will cover the logic of the breeze application – loading and displaying current temperature information for various cities by making AJAX requests to the OpenWeatherMap API. We’ll also briefly cover SCSS variables and mixins.

Feel free to ask questions in the comments below.

Happy coding!

Google Glass is a relatively new platform which enables people to view and interact with an optical head mounted display using either touch or voice recognition.

The Idea

We wanted to test the capabilities of Google Glass in combination with iBeacons, and create a simple contextually aware application. The app would look for specific iBeacons and, when detected, display information related to the area in which the found iBeacon was placed.

Where to Start?

When we set out to make Glassware, I had absolutely no experience with Android development, or the Java programming language in general. Luckily, due to extensive exposure to ActionSript 3.0, I had much experience with using a strict, statically typed language. So where to start? RTFM! Yes the documentation for Glass was my first port of call in order to gain more of an understanding of how to approach a Glassware project. There are various routes one can take, two of which being ‘activities’ suggested by the good folks at Google – Live Cards and Immersion.

So before deciding upon which route was right for us, I needed to take a step back and think about what exactly we were hoping to achieve, which in this case was a fairly simple contextually aware application. This would give us a clearer idea of how the app would function and allow me to focus on learning Java via the Android SDK and GDK add-on, based on our end goal.

With that in mind, one of the first questions I asked myself was “has this been done before?”, so I had a look online for similar projects and found a few, most of which being very old, with ‘very old’ in this case meaning a few months old due to the rapidly changing APIs for Glass and the introduction of their new development tool, Android Studio.

There was one project on Github – Glasstimote – which was very closely aligned to what we wanted to achieve, so instead of reinventing the wheel, I forked the project and got to work analysing every little part of the code to gain an understanding of how Android projects are pieced together.

The neat and tidy approach Google have taken with Android in terms of the XML format manifest, layouts, and string values, is very intuitive and I picked it up in no time.

In terms of the activity, I decided on an immersion approach, as we wanted the application to be constantly running and stop the Google Glass from going into sleep mode while in use. In order to ensure the application views would remain open, the android:keepScreenOn flag was set to ‘true’ within the XML file for each view layout.

Data

We experimented with a version of the app which updated its views by using async tasks to retrieve data from a MySQL database, with the advantage of this being dynamic data; it would be simple to update the view data without recompiling the application. This worked well in very controlled conditions, but suffered with the lack of a simple user experience, as when WiFi dropped out – something that happened frequently – the user would have to rejoin a network and resume the previously failed data update. It felt like this approach wasn’t quite right for our intended purpose, and so we shelved the prototype and went back to using static data.

A great user experience is key; the application could be doing all kinds of fancy things in the background, but if this makes for a lousy user experience then nobody will want to use the app to start with. Generally the users won’t care how the application gets its data if they’ve had a good experience.

Optimisation

Glass is only a small little thing and we want to avoid putting too much computational pressure on it, so optimising our application as much as possible seemed like a good option, since it was already necessary to rewrite much of the logic within the forked project in order for it to meet our requirements.

The original application worked by continually scanning for and displaying information about as many iBeacons as it could find. This behaviour didn’t correspond to our functional goals, for which we only needed to find one of three beacons at a time. Therefore, it made sense for our version to only scan for iBeacons until one specific to the application was found. In order for this to work I set up three distinct spatial regions within the output range of each iBeacon. The application would then stop scanning for iBeacons when in range of one of the regions and display information about that specific region. So, for example, it starts by scanning for three beacons, each with a named overall region – ‘kitchen’, ‘library’ and ‘creative’ – and when one is found, such as ‘kitchen’, and if within the entry region, it then stops scanning for the other two. If the application then detects that it is far enough outside the ‘kitchen’ entry region to be within, or further away than the exit region, it once again starts scanning for all three iBeacons. This simple optimisation saves us tons of unnecessary processing, in turn prolonging battery life of the Google Glass.

Another small optimisation was to use string values defined in the XML for updating views with region location information, instead of using string literals to display this data. This helps avoid unnecessary object allocation.

Testing

iBeacons in general seem to be fairly unreliable in terms of calculating distance. This is due to the changing nature of many environmental and atmospheric conditions, such as the number of people in a room, WiFi interference, and even the weather.

It’s also very difficult to debug Glassware efficiently when iBeacon regions are involved, due to the need for physical testing; much of the time I was walking around armed with a MacBook Pro, just so that I could read the logs in realtime.

I experimented with setting various signal strengths on the iBeacons and in the end found it easiest to use a strong signal in order to emit at a fairly long distance, but to have the application logic look for smaller ranges within this large area; the iBeacons were set to emit at a range of 30m and within this total emitted range a 2m radius was used for entry regions and a 3.5m radius was used for exit regions.

In the end the app worked really well, detecting iBeacons fairly reliably and providing a great experience for TMW Incubator Expo attendees. The final version of the app is open-source and can be found on the TMW Github repo: https://github.com/tmwagency/Glasstimote.

Final Thoughts

With interesting apps such as World Lens, which translates words in realtime both with and without an Internet connection, and the ability to display contextually relevant information based on the user‘s location via iBeacons, Google Glass has a lot of potential. It also seems to be very attractive to Android developers since porting existing apps to Glassware was made much easier after the release of the GDK, but it becomes apparent that there is a tough road ahead for the £1000 glasses when compared to extension-focused wearables such as smart watches from Samsung and the soon-to-be-released Apple iWatch, since the latter – in addition to being much more subtle in appearance – offers a less intrusive option for people wanting to interact with their digital world, as the watches are currently a simplified extension of smartphones and tablets; in contrast to Glass, they are literally not in your face when worn. Yet, Google Glass retains a certain charm, seeing as it is the first of its kind, and we at TMW are hoping the competition will spawn some even greater products from the technology giants.

Bullet is an ultra lightweight and simple to use pub-sub library with zero dependencies, AMD/module support and an intuitive API.
It was built to facilitate a simple and consistent system of communication across web applications and includes only the bare essentials typically needed to achieve this.

Usage

Firstly, grab either the minified, or non-minified source from Github.

Alternatively, you can install via npm with the following command in your command prompt:

npm install bullet-pubsub --save

Or you can install via Bower instead, if that's your thing:

bower install bullet

Include Bullet in your application

<script type="application/javascript" src="path/to/bullet.min.js"></script>

If using CommonJS then simply require Bullet as per usual:

var Bullet = require("bullet-pubsub");

API

.on()

Bullet.on("someMessageName", callback);

Register a callback function to get called whenever the specified message is triggered.

Example usage:

function helloCallback () {
    console.log("hello there :)");
}
 
// Register the 'helloCallback' function to be called whenever the 'hello' message is triggered:
    
Bullet.on("hello", helloCallback);
    

// Somewhere later in the application...
    
    
// Trigger the 'hello' message – Bullet will call the 'helloCallback' function:
    
Bullet.trigger("hello");

.off()

Bullet.off("someMessageName"[, callback]);

Remove either all callback functions or a specific callback function registered against the specified message.

Example usage:

function helloCallback () {
    console.log("hello there :)");
}

function anotherCallback () {
    console.log("hello again :)");
}


Bullet.on("hello", helloCallback);
Bullet.on("hello", anotherCallback);


// Somewhere later in the application...


// Trigger the 'hello' message – Bullet will call both the 'helloCallback' and 'anotherCallback' functions:

Bullet.trigger("hello");


// Remove all callback functions associated with the 'hello' message:
Bullet.off("hello");

// Attempt to trigger the 'hello' message again – Bullet won't call any functions:
Bullet.trigger("hello");

Example usage removing a specific callback:

function helloCallback () {
    console.log("hello there :)");
}

function anotherCallback () {
    console.log("hello again :)");
}


Bullet.on("hello", helloCallback);
Bullet.on("hello", anotherCallback);


// Somewhere later in the application...


// Trigger the 'hello' message – Bullet will call both the 'helloCallback' and 'anotherCallback' functions:

Bullet.trigger("hello");


// Remove only the 'anotherCallback' function associated with the 'hello' message:
Bullet.off("hello", anotherCallback);

// Trigger the 'hello' message again – Bullet will only call the 'helloCallback' function:
Bullet.trigger("hello");

.once()

Bullet.once("someMessageName", callback);

This function behaves in the same way as the the 'on' function, except that – once registered – the callback function will only be called a single time when the specified message is triggered.

Example usage:

function helloCallback () {
    console.log("hello there :)");
}


// Register the 'helloCallback' function to be called whenever the 'hello' message is triggered:

Bullet.once("hello", helloCallback);


// Somewhere later in the application...


// Trigger the 'hello' message – Bullet will call the 'helloCallback' function:

Bullet.trigger("hello");


// Attempt to trigger the 'hello' message again – Bullet won't call any functions this time:

Bullet.trigger("hello");

.trigger()

Bullet.trigger("someMessageName"[, data]);

This function will call all callback functions registered against the specified message, optionally passing in custom data as a payload.

Example usage:

function helloCallback () {
    console.log("hello there :)");
}


// Register the 'helloCallback' function to be called whenever the 'hello' message is triggered:

Bullet.on("hello", helloCallback);


// Somewhere later in the application...


// Trigger the 'hello' message – Bullet will call the 'helloCallback' function:

Bullet.trigger("hello");

Example usage with custom data:

function userAddedCallback (data) {
    console.log(data);
}


// Register the 'userAddedCallback' function to be called whenever the 'user-added' message is triggered:

Bullet.on("user-added", userAddedCallback);


// Somewhere later in the application...


// Create some custom data:

var customData = {
    someProp : "bro",
    someOtherProp : "awesome!"
};


// Trigger the 'user-added' message – Bullet will call the 'helloCallback' function and
// pass in the custom data that you created, which will be sent to the function as a parameter:

Bullet.trigger("user-added", customData);

About the Project

Bullet was developed and is currently maintained by Ivan Hayes.

Head over to the Github project page to find out more. Go ahead and star the project to keep up with its latest developments :-)

SwiftClick is a library created to eliminate the 300ms click event delay on touch devices that support orientation change and is designed to be super lightweight — weighing in at only 957 bytes minified & gzipped!

As many of you will have experienced when using touch devices such as iPhones, tapping on HTML elements sometimes feels a bit sluggish. This is because there is a 300ms delay before click events are fired. As a user experience this is clunky behaviour and so the exploration of potential solutions to this problem worked its way into TMW labs. Since the issue only occurs on devices that support touch events, the initial approach was to simply run a basic test for touch support and create a variable for the event name to use in click listeners – the value of which being either 'touchstart' for devices that support touch, or 'click' for those that don't:

var clickEventType = "ontouchstart" in window ? "touchstart" : "click";

The problem with this detection method is that laptops or monitors that support touch would expect a touch event, meaning that if a mouse was being used then click events wouldn't work. Because of this the detection method was refined to check if the device supports both touch and orientation change and only use touch events if both conditions are met:

var clickEventType = "onorientationchange" in window && "ontouchstart" in window ? "touchstart" : "click";

This detection method worked well in the majority of situations, with the 'clickEventType' variable being used in any event listeners that needed to get a click event:

someEl.addEventListener(clickEventType, fn, false);

This worked pretty nicely, with the main drawback being the fact that the 'clickEventType' variable would have to be used in any place where a click listener is needed, which could potentially become problematic when projects are picked up by new developers who may not necessarily realise that this variable is being used at all.

Other options were explored, including a really nice utility called FastClick, developed by FT Labs. When an HTML element is touched, FastClick hijacks the touch event and creates a synthesised click event if necessary, which is then dispatched by the touched element. This allows JavaScript event listeners to be registered using the normal 'click' event type, but has the advantage of these events being fired earlier than normal – effectively removing the 300ms delay. For the most part this worked really well, but it eventually became apparent that the util sometimes exhibited strange behaviour, such as ghost-clicks, or events not firing at all when links were clicked and then firing later on, at the same time as other click events when different elements were clicked. And at 25kb non-minified (2.4kb minified & gzipped) it is also a bit heavy in file size when considering the nature of the task for which it was created to solve. Therefore, the time was right to create a custom solution – SwiftClick.

SwiftClick is inspired by FastClick, but has been designed from the ground up to be super lightweight — weighing in at a mere 6.8KB non-minified and a teeny-tiny 957 bytes (yes, bytes) minified & gzipped!

In contrast with FastClick, which does a lot under the hood to fix obscure bugs in many crappy old mobile browsers for complex elements like <form>, <select>, and <textarea>, by default SwiftClick focuses on basic element types that are typically used in modern interactive development, providing an option to add in additional element types when necessary.

Usage

Firstly, grab either the minified, or non-minified source from Github, or install via Bower using the following command in your command prompt:

bower install swiftclick

Include SwiftClick in your application

<script type="application/javascript" src="path/to/swiftclick.min.js"></script>

Setup SwiftClick

Setting up SwiftClick is a very easy process, which mirrors that of FastClick in that instances must be attached to a context element. Touch events from all elements within the context element are automatically captured and converted to click events when necessary, minus the delay.

Start by creating a reference to a new instance of SwiftClick using the 'attach' helper method and attach it to a context element. Attaching to document.body is easiest if you only need a single instance of SwiftClick:

var swiftclick = SwiftClick.attach(document.body);

If necessary, multiple instances of SwiftClick can be created for specific context elements which, although not really necessary in most cases, can sometimes be useful for optimising applications with a large amount of HTML:

var navigationSwiftClick = SwiftClick.attach(someNavElement);
var uiSwiftClick = SwiftClick.attach(someOtherElement);

Default Elements

Once attached, by default SwiftClick will track events originating from the following element types:

• <a>
• <div>
• <span>
• <button>

Adding non-default element types

If necessary you can make SwiftClick track events originating from additional element types by adding an array of node names. This requires a reference to an instance of SwiftClick:

var swiftclick = SwiftClick.attach(someElement);
swiftclick.addNodeNamesToTrack(["p", "h1", "nav"]);

Replacing all stored node names to track

var swiftclick = SwiftClick.attach(someElement);
swiftclick.replaceNodeNamesToTrack(["a", "div"]);

Doing this will remove all default node names, as well as any that have been added, and replace them with the node names within the array that is passed in, resulting in only the new node names being tracked.

Automatically disabled when not needed

SwiftClick only intercepts events for touch devices that support orientation change, otherwise it just sits there looking pretty.

About the Project

SwiftClick was developed and is currently maintained by Ivan Hayes.

Head over to the Github project page to find out more. Go ahead and star the project to keep up with its latest developments :-)