Build Apps for the Connected Car

Brian Langel is the Co-Founder and Chief Technology Officer of Dash, a Vinli App partner that turns the driving experience into a game using data contained inside your car—and makes you a better driver at the same time. The former software engineer at HBO helped build the back-end architecture for the company’s streaming app, HBO GO. He’s upgraded the systems at Union Pacific Railroads to optimize cargo asset routing. And, on the side, he has yet another startup that offers hardware and software to analyze data to better track the migration patterns of wildlife for scientific research.

In this Vinli Dev Q&A, Langel shares some of his advice for aspiring connected car app developers.

For a beginning app developer looking to build a connected car app, what would you recommend they learn first?

Like many situations, I'd first learn about what has already been built. If someone has done the hard portions of your problem then leverage their work. Even though there are open standards to talk to vehicles, many of these standards require low level knowledge, present data in an unfriendly way and are more often than not inconsistently implemented at the vehicle level. Additionally, some of the high level notions, like whether the vehicle is on or off, are not represented by the specifications and so need to be invented by a developer. This is hard to do correctly and accurately across thousands of vehicles in the market already, let alone for all new vehicles being produced each year.

Because of the complexity of the problem space, I would highly recommend developers look first towards those who have already solved these problems. I would leverage the work of platforms like Dash and Vinli to accomplish this.

Where is your favorite place to turn for seeking developer help?

One of the most important things I've learned in seeking help within the developer community is that phrasing and coherently creating one's question is the most important part of getting a correct answer. I think about my question and try to look at it as if I were being posed the question myself. Does it make sense? Is it something I should provide examples when asking. I then try and search the web for answers. Sites like Stackoverflow and API documentations/forums can be extremely helpful.

However, if the question is in an area I'm not too familiar about (say I'm just learning a new language) the web can also be distracting as there are many half-right or even incorrect answers. In these cases I tend to pose the question directly to a person; either someone I know who has knowledge of the problem in person or on the web. I often find that posing questions directly on GitHub, Stackoverflow, etc will provide good results.

What was in the MVP version of Dash in 2012? How much time did it take to build?

The MVP version of Dash was, in terms of appearance, extremely different from the Dash in the app stores today. However, the bones of the idea were all present. We knew from the beginning we wanted to expose car data (in an abstract and generic way, i.e., the user shouldn't be aware of any differences across vehicles/devices) to the user in a useful and fun way.

We had many of the current features of Dash within the MVP, like utility features, cost savings features and social features. However, each of these was far more limited than what you'll see today. Additionally the platform was not yet robust. Many vehicles we hadn't yet tested and so Dash had to evolve to support them.

Like most MVPs it was simpler and less well designed than future generations of the same product but even today the core tenants of the product would be identified. It took a couple of months to build. Mostly this was to begin abstracting the vehicle data from the J1979 protocol.

What are five things you learned since first publishing the MVP app?

There have been countless things and lessons learned since the initial Dash MVP in 2012. Many of these lessons have been reinforcements or new manifestations of existing lessons I've learned or been taught in the past. Some of the most important have been:

Always collect metrics. Whether this is on new features, server health or mobile performance. This is the only way to have a glimpse into your system at large and make informed decisions about it.
Don't repeat yourself. As a developer if you find yourself doing the same thing over and over, abstract this. This has been most beneficial to Dash in terms of our device/vehicle abstraction layer. We are able to add new devices and vehicles quickly because we've built a great platform which is extensible and flexible.
Don't abstract too early. This is the counterbalance to the point above. It is often perilous to introduce an abstraction early before one knows the correct generalities of the problem. Don't abstract for abstractions sake.
Leverage the work of others. As new developers today should leverage existing car platforms, we have found ourselves needing to get help from communities at large. For instance, the bluetooth v2 specification and implementation (especially on Android) is notoriously inconsistent. Seeking help from others who have encountered similar problems have allowed us to shorten our own learning curve.
Don't be afraid to remove. Unused or abandoned features aren't failures. They're experiments which have led you to a better understanding of your users' desires and appetite for information. If you've developed a feature and it hasn't been embraced, don't be shy in removing it. There's a cost to supporting it and if there's no benefit being yielded, it's now taking time and energy away from other potentially great features you could be developing.

Dash supports a handful of OBD devices on the market. Are there consistencies when you're integrating with multiple OBD devices? What do you find most challenging?

Yes, there are definitely similarities. Because vehicles are regulated to support certain protocols and ways of communicating, interaction with much of the vehicle data is generic. Additionally because most OBD devices are simply routers to this data, many of the devices in market share similar ways of communicating with them over bluetooth. So in this regard, each new device integration or vehicle testing for Dash does not need to reinvent the wheel.

However, for every device and for many vehicles (across makes, models and even years within the same model) there are quirks. Vehicles do not alway implement the same portions of the specification. Some of the vehicles do not even implement the specification correctly. All of this Dash then must work around.

And at the device level, many devices have differences which Dash must abstract. Some have completely different methods of interaction with the vehicle (e.g., different message formats). Also devices have differences in their approach when providing data; some provide data serially and some send notifications when data has changed. Some devices use WiFi, some Bluetooth v2 and newer devices, like Vinli's device, use Bluetooth v4 (sometimes called BLE). Because of all these differences we've built up a great abstraction layer within our platform and so adding new devices is not really challenging but more the following of a sequence of steps in a playbook. It's tedious at times but no longer challenging.

The most challenging part has been developing ways of regression testing the large matrix of devices, vehicles and phones. We've done a good job at capturing and building ways of running these tests every time we make a change to our abstraction layer to ensure new changes do not interfere with work-arounds for quirky devices or vehicles.

What role will companies like Dash play in the age of internet-connected cars? Are there development standards that are taking hold?

Companies like Dash are helping to unlock vehicle data in a normalized and friendly way for developers. The abstraction allows developers to spend more time creating interesting, creative and novel applications within the vehicle ecosystem without spending time worrying about device or vehicle specific oddities. Vehicle data availability is leading to more research into fuel efficiency optimization across fleets and individual drivers.

It's also contributing to work into traffic management, usage based insurance solutions and other utility applications. In addition, it gives developers the ability to create fun driving applications, not only for the driver but also for passengers too.

How is the developer ecosystem evolving now that more car manufactures and technology companies are bringing new apps and platforms to market?

This developer ecosystem for vehicle data is relatively new and continues to evolve each week. The ecosystem itself is very large and holds opportunity for many new ideas, businesses and applications to take hold. The developer community is just beginning to form now that there are ways of easily accessing vehicle data in a cost effective manner.

In the next couple of years there will be even more growth and expansion of applications leveraging vehicle data because of the lower barrier to entry for developers. This lower barrier to entry is because of the great work being done today by the likes of Dash and Vinli.

Want to build apps for the connected car? Sign up on Vinli’s Developer portal for free today.