ngCesium – integrating angularjs and cesiumjs – part 2

In part 1, we got cesiumJS running in our angular app. We saw how we can add entities to it. It is also reusable using the directive we’ve built. Check this out – two 3d maps in one page, isn’t it cool:

But that’s not all we are using angularJS for.  One of the greatest features of angularJS is its modularity.  You can build your app from modules, and divide each module into sub modules – virtually infinitely.  This helps you to create an easily maintained and testable app.

We ran into the module app as we created the cesium module.  Now we’re going to create ngCesium as a module and push it into a “bigger” app.  Here’s the code:

What you can see here, is actually an angular app (let’s say, your big data analysis app).  Into it, I’ve injected the ngCesium module we’ve created in part 1:

angular.module(‘myApp’, [‘ngCesium’])

This way, you can just take your ngCesium code, inject it into any angular app, and just “plug and play”. So… what’s so special about this way of creating a module? It’s much more scalable.  In this framework, you can add more controllers, services, filters and directives to the ngCesium module.

On part 3 and on, we’re going to add these “heavier” extensions, but first let’s see a simple example before we dive into a more complex usage:

So what do we have here?

We have our ngCesium module, just as before. This time, we’ve added a factory to it. A factory is an instantiable angular object. This way, I can create a “class” I can instantiate as many times as I need. With ES6, it becomes much easier and native, but that is beyond the scope of this tutorial.

What does the factory do? It holds our cesium viewer (which instantiates in the directive), and we add methods to it, which use the same viewer (which is stored in the magic “this”).  This is very much like a C++ class…

Another thing added to the directive is the binding with the mainAppCtrl. Notice that in the mainAppCtrl I define a cesiumConfig variable, and inside I define the cesiumInstance property. This is the beginning of an API, because in the directive the cesiumConfig.cesiumInstance will point to our cesiumService factory instance, which in turn holds our cesium viewer and methods.

Then, just for show, I’ve added 2 functions to the controller that use our newly created API to add and remove entities from the map.  You can try it out (yes – you can actually click and see things moving on screen – AMAZING!).

Another small perk – I’ve bound the “Remove Entity” button disabled property to the entities array length, so that it will be enabled only when we actually have entities to delete.

This gets more and more complex, but very logical and scalable, because from now on, we mostly need to add methods to our cesiumService and use them in order to implement our bigger main app business logic.

If you have any questions, don’t hesitate to ask below.

In the next part, we’re going to expand our ngCesium module by building another sub module.  This will help us to build our first “real life” module – the polygon drawing module.  Sounds good? Let’s go…

3 thoughts on “ngCesium – integrating angularjs and cesiumjs – part 2

  1. Ram Tobolski

    Hi, great post. A small comment regarding

    “Notice that in the mainAppCtrl I define a cesiumConfig variable, and inside I define the cesiumInstance property. This is the beginning of an API, because in the directive the cesiumConfig.cesiumInstance will point to our cesiumService factory instance, which in turn holds our cesium viewer and methods.”

    In fact, the cesiumConfig variable is initialized as an array of two empty objects. The name “cesiumInstance” is used only as a scope parameter of cesiumDirective.

Leave a Reply