Who wants ice cream!? — A HERE Maps API for JavaScript Tutorial (Part 5: Refactoring)

08 November 2016 by Teemu Kallio and Florian Plank


Who wants ice cream?! — In this series of blog posts we are going to develop a small web application called "Gelary" using HERE maps and services. Gelary aims to disrupt the ice-cream market by enabling ice-cream producers to deliver their sweet goods directly to their customers, wherever they are.

The final application will resemble a mobile dashboard view for the employees of our little start -up which they can either take on the road or use at Gelary HQ to plan their work. It will consist of a map and a floating control panel behind a menu button. The map is used to visualise a route, starting from the user's current position along a series of customers, and the traffic situation along the route. The control panel will enable our delivery drivers to search for nearby ice-cream shops, display turn-by-turn directions as well as to calculate the best pick-up location for a group of selected customers. The app will also be able to handle order changes: e.g. if a customer cancels or updates his or her position, the route will automatically be recalculated.

To keep things simple our application will use plain Javascript (ES5) and front-end technologies and will target mobile and desktop browsers alike.

What will we learn in this tutorial?

In the previous post we had learned how to display multiple routes as well some detail information for each and enable the user to select the best one. If you haven't read it yet, you might want to take a look at it first before going on.

Since the last part was so long, we're going to take it easy this time and just do some refactoring to get our code ready for the next set of features. Let's get going.


As already indicated in the last post, it's time to clean-up our route.js. Let's get to it before we dive into new features!

The first thing you might have been wondering about is actually the name. As we're now dealing with multiple routes and related functionality the singular Route is simply no longer appropriate. Let's change it from route.js to router.js and rename the contained class to HERERouter. This should cover our new scope nicely.

Let's keep going! Currently our class is a really just one constructor function which in turn contains a bunch of local functions. Let's make better use of JavaScript's prototypical inheritance model and move some functionality into actual instance methods. In this sense we'll introduce three new methods:

getRoutes will contain all code needed to retrieve the routes from the API:

getRouteLine will hold the code necessary to create the visual representation of the route and return a PolyLine instance:

onRouteSelection will define the piece of code called once a route has been selected, e.g. via the panel:

With this change in place our constructor shrinks quite significantly in size:

As you can see we had to make a few formerly local variables available across the instance for this update to work. Furthermore we have opted to create a routePanelOptions for readability instead of passing it into the HERERoutesPanel constructor inline.

Looks like a lot has changed but we really have just split our code into more digestible chunks which makes the end result right away a lot more maintainable. — Nice!


With our new HERERouter class in place we'll need to update also the HEREMap class which relies on the routing functionality. In the constructor we instantiate the new class:

With the router variable available across the instance we can also update the drawRoutes method and replace

with the following:

In the last installment of this series we had also hinted that the marker handling might require a bit of refactoring. It might make sense to extract the marker-related functionality at some point into its own class but for now we can get by by cleaning things up a bit. Let's start by creating a markers instance variable in the constructor to hold information on all of our markers:

With this change in place we can now simplify the updateMyPosition method:

As you can see we have introduced a new updateMarker method to help us with moving markers after they have been created. It takes the name of the marker (a key used with the aforementioned markers container object) and a coordinate pair as parameters.

Finally we will make use of our new router variable in the drawRoute method by replacing


Wrapping up

House keeping isn't exciting work but it sure feels good once it's done! We can now feel a lot more comfortable moving forward and introducing new functionality and are fully set to continue on to the next part: Reacting to outside influences.


You cannot use this account to purchase a commercial plan on Developer Portal, as it is already associated to plans with different payment methods.

To purchase a commercial plan on Developer Portal, please register for or sign in with a different HERE Account.

Something took longer than expected.

The project should be available soon under your projects page.

Sorry, our services are not available in this region.

Something seems to have gone wrong. Please try again later.

We've detected that your account is set to Australian Dollars (AUD).
Unfortunately, we do not offer checkouts in AUD anymore.
You can continue using your current plan as normal, but to subscribe to one of our new plans,
please register for a new HERE account or contact us for billing questions on selfservesupport@here.com.