Developing Augmented Reality Application For Android (Part 1)


Can It Fit? is an Augmented Reality (AR) experience where a user can see how a car of their choice fits in a parking space. It’s currently available in Edmunds for iOS and Android. In a series of articles, we will discuss the journey we took to develop Can It Fit?

Can It Fit? was conceived as proof of concept for multiple AR-capable devices that were in development stage (Microsoft Hololens and Google Tango). Shortly after Apple announced ARKit, the team decided to focus on an iOS implementation and released Can It Fit? on iOS in August 2016. Most recently, we ported Can It Fit? to Android, using ARCore - Google’s platform that utilizes device capabilities to bring users augmented reality experience. This series of articles focuses on the journey of porting Can It Fit? experience to Android.

Can It Fit? requires the user to follow these steps:


As you could see from the above instructions, the main AR components are a box (representing the parking space) and a vehicle. Our initial goal was to build a prototype Android app that implements both of these components and the interaction between them. The prototype was expected to do the following:

When we began working on the prototype, we used one of Google’s example projects and kept modifying it until it fit our requirements. That way the code was separate from our Android codebase, and we did not have to worry about making mistakes. This decision allowed us to iterate quickly and fail fast. The code base was very experimental, sometimes containing multiple solutions for a single problem (for the benefit of comparison). The code architecture was fairly undefined and most of the code resided in a single class.


We decided to split the work into two separate components: User Interface (UI), which controls the user flow and stage transitions and the Augmented Reality engine, which does the rendering and updates the logic. The UI component is simply a native Android integration, whereas the AR engine required more platform-agnostic computer graphics knowledge.

Once the prototype app met its requirements and the entry point to Can It Fit? was implemented in the Edmunds Android app, the two were integrated into a single code base. Specifying a clean interface helped make the integration very smooth. To keep the interface lean, we made sure to identify a minimum set of actions that the UI component may need to perform. Everything else was hidden in the implementation.


Today, ARCore can be supplemented with Sceneform, a library that abstracts away graphics drawing API and other ARCore consideration. It also adds a useful math library, scene-graph API, and asset loading among other things. Unfortunately for us, Sceneform didn’t yet exist when we began working on the prototype. We were responsible for writing code required to process computer graphics and draw to the screen using OpenGL ES. Our Can It Fit? code quickly became consumed with OpenGL ES calls, shaders, and arrays of float values representing geometric vertices and indices. At this point we determined that our Can It Fit? implementation was no longer viable for long-term maintainability.

When Google released Sceneform, it became clear that it would ease many of our pain points and let us focus on application logic. We immediately jumped on migrating the prototype.


In this first article of the series, we covered Can It Fit? user flow, building the prototype, and the architecture. We also touched upon our choice of Sceneform as the library to handle lower-lever considerations. In future articles, we will break down development with additional detail.

Denys Vorontsov is a Senior Software Engineer at

At Edmunds we’re not just about making car buying easier, we're also passionate about technology!

As with any website that has millions of unique visitors, it's a necessity that we maintain a scalable and highly-available infrastructure with reliable services.

We are excited by software design and strive to create engaging exper-iences while using coding practices that promote streamlined website production and experimentation. We embrace continuous delivery, dev ops, and are constantly improving our processes so we can stay lean and innovative. We also prioritize giving back to the community by providing open APIs for our auto-motive data and open sourcing projects whenever possible.

Recent Posts