The Roll Call App: Integrating Beacons with Node.js and MongoDB

by dcinglis

For this project I wanted to extend the functionality of the beacon explorer app described in my last blog post, creating something practical that could be used within the office. I decided on a “roll call” style project to see which people are in the office at any given time. With so many people here working from home or out on business trips, it’s nice to see who is actually around when trying to make lunch or meeting plans. Before I launch into explaining the project, here is a link to the website.

To build this application I needed some way of receiving and storing data from multiple devices. Node.js is well suited to this task as its non-blocking event loop makes handling multiple communications at the same time a breeze (given the current size of our office this would never really be an issue, but it makes scaling really easy if I ever wanted to use the project in a larger environment). Progress recently acquired the Node application hosting service Modulus, so I decided to give them a try for hosting the web server. Modulus has built in MongoDB support, so it made sense to use Mongo to store the information.

With my technologies in place, next I needed to figure out how to make them communicate with each other. As my Node application is an HTTP server, I need to send data to it using POST requests and respond to GET requests asking for data. The Express framework greatly simplifies all web interactions within Node, so I chose to run that on my Node server to handle all the requests from iOS and web browsers. iOS in turn can send POST requests using the NSURLSession class. For interacting with MongoDB, another Node framework called Mongoose comes in handy. Mongoose simplifies all the connecting and data organizing difficulties of working with a database. Here’s a quick diagram of the full setup:

Screen Shot 2014-07-15 at 2.38.46 PM

So what does this project actually do? All our office members have the Roll Call iOS app installed on their phones. Upon startup the app prompts for the user’s name, which is cached in the iPhone’s memory using NSUserDefaults, a class for storing simple data between user sessions. That’s the extent of user interaction with the app; it never has to be opened again. Since this app utilizes Apple’s Location Services, iOS searches for the office beacon region even when the app isn’t running. When iOS detects nearby beacons, it passively opens the app in the background for about ~10 seconds. In this time, the app sends a POST request to the Node server with 3 pieces of information: the name of the user, the timestamp of the request, and a boolean representing whether the user entered or left the building.

The request containing this information is processed by the Express framework in Node. Once the data is extracted, Node converts it into the JSON format utilized by Mongo and passes it on to the database. If this is the first database entry for a particular name, a new user is created. Otherwise, the user’s data entries are updated to reflect their latest actions. Finally, this data needs to be displayed somewhere. Modulus provides a client-facing URL for each hosted application, which I’ve populated with the MongoDB content through Node. When the user types in the project URL, it sends a GET request to the Node server, which in turn pulls the user table and action log from MongoDB and formats it with html tags for the browser. The website can be viewed here, and looks like this:

Screen Shot 2014-07-15 at 3.52.48 PM

(this data was “faked” by me walking in and out of the building a couple times, in a real application of the project I would add a password to protect privacy)

Nothing fancy, but a simple and clean way to keep track of who’s around. This project could easily be extended to a larger office by simply placing more beacons around the office. Or a warehouse manager could use it to keep track of employees within a large space, even dividing the warehouse into regions based on different beacon major and minor IDs in order to pinpoint an employee’s location within a warehouse. Software models could be run on this data to improve efficiency within the warehouse. There are many potential ways to expand this project into a full commercial product.

Finally, I just want to say that I think that the coolest aspect of this project is how the user never needs to open the iOS app for the project to function, other than at the very beginning to input their name. Apple has implemented some powerful functionality into their Core Location service, and developers can take advantage of this to implement useful and relevant location-specific projects without ever having to bother the user. I would imagine in the future that more and more apps will shy away from dependence on foreground use and instead lean towards the background monitoring + notification system used here, as it provides a simpler and more streamlined user experience.

I’ll post a Github link to the project soon.