AngularJS and Google Maps – dynamic marker updates

I have a need to dynamically create and display markers on a Google Map. Statically declaring a single or an array of markers seems pretty easy, but updating an array of markers so they are displayed and removed over time seems more tricky using the available AngularJS libraries for Google Maps.

The two libraries I have looked at are:

Both offer AngularJS directives to insert a Google Maps into an existing page. Let’s take a quick look at each approach.

Angular Google Maps

With Angular Google Maps, use the provided directives to insert the map and an array of markers:

[code]
<ui-gmap-google-map center=’map.center’ zoom=’map.zoom’>
<ui-gmap-markers models="markers" coords="’self’" modelsbyref="false"/>
</ui-gmap-google-map>
[/code]

In my Controller I’ve added a map object to $scope with values for center and zoom:

[code]
$scope.map = {center: {latitude: 37.7699298, longitude: -122.4469157}, zoom: 12};
[/code]

… and to add the initial array of markers (random markers in SF):

[code]
var marker1 = {id: 1, latitude: 37.7699298, longitude: -122.40};
var marker2 = {id: 2, latitude: 37.7699298, longitude: -122.45};
var marker3 = {id: 3, latitude: 37.7699298, longitude: -122.46};
$scope.markers = [];
$scope.markers[0] = marker1;
$scope.markers[1] = marker2;
$scope.markers[2] = marker3;
[/code]

Since the markers array in $scope is reference by the ui-gmap-markers element, setting the markers array to [] deletes the markers from the map, and adding them back re-adds them back to the map. The property ‘coords’ is the name of the property on the object passed to models that contains the objects with the latitude/longitude properties for each marker. modelsByRef=”false” seems to add support for watching changes to the model.

ngMap

The ngMap approach is very similar. To add the map to a page with a repeating list of markers:

[code]
<map style="height:100%" center="37.7699298, -122.4469157" zoom="11">
<marker ng-repeat="pos in positions" position="{{pos.lat}}, {{pos.lng}}"></marker>
</map>
[/code]

To create the markers, create an array of markers with lat and lng properties, similarly to Angular Google Maps:

[code]
var marker1 = {lat: 37.769, lng: -122.44};
$scope.positions = [];
$scope.positions[0] = marker1;
//etc
[/code]

Summary

Since my app needs to dynamically add and remove markers for display to the Google Map, this was my primary requirement for selecting one of the libraries. I struggled to get this working initially with Angular Google Maps, but seemed to work straight out of the box with ngMap. Most of my struggles though may have been related to my misunderstanding of how $scope works in AngularJS (which I’m still learning), so maybe at some point I should go back and re-evaluate both of these again once I have a better understanding of AngularJS.

I put together a sample app that uses both of the libraries, which you can find on GitHub here: https://github.com/kevinhooke/AngularJSGoogleMapsExamples

Also, my final usage for ngMap you can see in action in my app, SpotViz, which is available here: http://www.spotviz.info/ . It allow Amateur Radio operators to playback an animated display of received station locations over time from log files from a digital mode application called WSJT-X.

 

OpenShift 2.0 Hot Deploy option

I’m not sure why I haven’t tried this earlier, but by default, when you git push your updates to OpenShift Online, it stops all your cartridges, builds, deploys and then restarts everything, which can take a few minutes.

OpenShift 2.0 supports a hot deploy option to minimize the amount of time that your app is down – details are in the docs here.

Hibernate OGM / JAX-RS / JAX-WS redeployment issue on WildFly8.2: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel

I’ve been struggling with failing redeploys on WildFly8.2 while I’m developing my app. If the app is deployed, on first server start it starts up fine, but then if I redeploy some code changes I get this NoSuchMethodException in the asm library, suggesting I’ve got some conflict of versions of the asm library used by my app:

Caused by: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label)
 at java.lang.Class.getMethod(Class.java:1773) [rt.jar:1.8.0_20]
 at org.apache.cxf.common.util.ReflectionInvokationHandler.invoke(ReflectionInvokationHandler.java:85)
 ... 28 more

Luckily I came across this post with the same error, putting me on the right direction about the possibility of my app being packaged with a conflicting version of asm. Looking at a ‘mvn dependency:tree’ on my app, I could see asm being pulled in from my use of Hibernate OGM and Jersey as transitive dependencies.

Despite trying to add excludes to not get asm included in the packaging of my app, I eventually gave up and decided to just remove my luckily minimal use of Hibernate OGM. I think the issue was caused my OGM’s deployment of modules onto the WildFly server, one of which was asm. After I had removed OGM from my app, removed the modules, I was back to speedy redeploys of my app.

I’m sure there’s a way to get OGM to deploy happily, or maybe I had just ran across an asm version conflict with other libraries my app is using (Jersey?), but I don’t have time right now to deal with it. Another project for another day 🙂

Windows 10 Users “34 per cent more likely to be strongly satisfied with the filtered Taskbar”

Let that statement sink in for a minute – in Windows 10 Insider Preview builds, users have indicated they are:

"34 per cent more likely to be strongly satisfied with the filtered Taskbar"

… and based on that not-so-convincing statistic it’s been decided that the taskbar for a virtual desktop will only show apps running on that desktop (presumably hiding others that are running on other desktops at the time time?).

Gabe Aul at Microsoft describes in this post the latest features in the Windows 10 preview build and how feedback from preview build users is helping Microsoft decide what new features will make it into Windows 10, and which won’t.

And there you have it. Apparently the design of the Ribbon Bar in the latest Office versions was also designed the same way, based on observed/recorded usage patterns of ‘actual users’. If you think the Ribbon Bar is actually a good design then I won’t waste my time arguing with you, but most would probably agree from a usability point of view it’s a horribly cluttered, confused mess of somewhat related options. The Ribbon Bar reminds me of a set of cluttered drawers that are where you stuff your junk that you don’t have anywhere better to put. Each drawer has vaguely related things in it, but good luck trying to find something specific – you open a drawer and spend 10 minutes digging around in there trying to find what you’re looking for. Similarly for the Ribbon Bar – good luck finding that one specific feature.

So at some point if your’re lucky enough (?) to have Windows 10, you might wonder exactly how Microsoft arrived at a decision for why a certain feature is a certain way. And you can be assured that it was designed that way because 34% of preview build users (by a long way as far from a typical user as you can get) decided they were ‘most likely to be strongly satisfied’ if it was that way.