After the hilarity and hijinks we had with the WebSocket and Raspberry Pi controlled car, my colleagues (Prashant Khanal and Vikram Dave) and I were excited to attend last weekend’s Hertz Mobility and Connected Car Hackathon. Hertz was looking for creative ideas and apps for a more connected traveler and transportation experience, and coordinated this event with AT&T, Nokia, Twilio, and others.
Inspired by one of our favorite apps, Waze’s drive sharing, we wanted to create a real-time location sharing experience among travelers: people driving in cars with navigation systems, people on foot using mobile devices, multiple people traveling in different cars, and so on. One of the issues we have with current apps is that the experience is almost-real-time, but not quite. When traveling together, we feel it’s important to have an accurate real-time experience to ensure that the shared information reflects reality. To that end, we wanted to create a truly real-time sharing app for travelers.
To put this into context, we thought of three basic scenarios where travelers might share their location:
- Mobile and Desktop Sharing: You’re heading over to your friend’s house for lunch and want to share your trip with her, so she can track your path at home and be able to predict when you’ll arrive for lunch. In this case, you’re just sharing your location (a single path) with person using a browser. (This is the one Waze targets.)
- Mobile to Mobile Sharing: You and your friend have decided to meet in the city. You’re driving in from out of town and she’s on foot, and you need to find a safe place for you to pull over and pick her up. In this case, both you and your friend share your locations mutually with each other; your friend is on a smartphone while you’re using the navigation system of your car or your mobile device.
- Multiple Mobile Sharing: You’re on a road trip with a large number of friends, divided among a caravan of three or more cars. The party in each car wants to track the other cars in the caravan using either a mobile device or the car’s navigation system.
The following sketch outlines these three scenarios. The connection between these parties is provided by Kaazing WebSocket Gateway, depicted by the orange box in the middle.
About the Application
We built the solution as an HTML5 app that enables another party to track the user’s location. HTML5 is especially powerful when you want to invite others to the experience ad hoc. All you need to do is share the URL of the app; no application installation is needed. Using an HTML5 app ensures that the solution works across desktop browsers, smartphones, and tablets. The navigation system of the car may be browser-based, but it could be a hybrid, or even a native application.
For our demonstration we had the following considerations:
- Invitation: Invite others to view your location and information. To send the invitation, we used Twilio, one of the hackathon sponsors. Twilio allows you to send text messages or place phone calls (text to speech) by invoking a Twilio API. The text message we send contains a link pointing to the web app rendering the trip.
- Map: Map the coordinates and path. We used Nokia’s map software. Nokia was another one of the hackathon sponsors.
- Real-time communication: Enable travelers to view shared information in real time. To achieve this, we used the Kaazing WebSocket Gateway to send messages in real-time.
- Simulated location data: Simulate data for testing. Since we were not physically driving around, we recorded a handful of latitude/longitude pairs and played it back from a JavaScript client through Kaazing.
Sending an Invitation with Twilio
Inviting another person to follow your connection can be done in a number of ways. Since we have always wanted to integrate Twilio with WebSocket, and they were a sponsor at the hackathon, using Twilio was a natural choice.
We built a simple Java app that invoked the Twilio Java APIs that sends the text messages on our behalf to the person we want to share our trip with. All you need to do is pass in the phone number and the message you want to send.
The Java app (pink on the figure below) is loosely coupled with the Web app (gray on the far left in the figure below) that prompts you to enter the recipient’s phone number. After submitting the HTML form, a JMS message is sent through the Kaazing WebSocket Gateway to the Java app, listening for the message. When the message arrives, it invokes the Twilio Java API to send the text message to the phone number received. The text message contains a URL, pointing to the app with the Nokia Map (see below).
Here: Nokia Map
While we have seen Nokia’s map at various conferences, we haven’t had first hand development experience with it. We were pleasantly surprised how straight-forward and well documented the API is and how little effort it took to achieve want we wanted to: moving several custom pins on the screen, driven by incoming WebSocket messages.
The Web UI is snappy and works flawlessly on desktop browsers, Safari on the iPhone and iPad.
For simplicity, when the app first starts, it shows your geolocation. In this screenshot you can see downtown Mountain View, in California, where Kaazing is headquartered.
The app is listening on a topic, that we called /topic/tripzing. As the messages start arriving, the map pans to the location sent in the message.
WebSocket Communication with Kaazing
For real-time Web communication, we decided to use JMS as the messaging API, offered by Kaazing. Kaazing provides a very straight-forward pub/sub abstraction that allows you to easily connect various WebSocket clients as if they were peers to each other. The concepts we leveraged are explained in the Step-by-Step Tutorial of Building a Simple Peer-to-Peer WebSocket Application.
Simulating Location Data
Since we didn’t have location data readily available, we built a simple JavaScript simulator that when needed, published geolocation data of one more more cars to the JMS topic, which could then be consumed by the app hosting Nokia Map. We arbitrarily chose to send the geolocation data once every two seconds, but obviously it could have been way faster or slower as well.
And here is the end result: the simulator publishes the location of the cars. The data is consumed of the same app running on a desktop browser, a smartphone, and a tablet.
More Information
- Check out the project on github.
- Try following the tutorial for building a simple peer-to-peer application yourself.
- Learn more about Kaazing WebSocket Gateway – JMS Edition, which is a messaging over WebSocket solution using the Java Message Service API.
- Check out the API documentation and other how-tos for building clients using Kaazing WebSocket Gateway – JMS Edition.