Mobile Monday Presentation – Domino’s AnyWare
On Monday I attended a presentation on the Domino’s AnyWare application.
A large portion of the talk from Domino’s was about their working culture. They utilize agile and scrum processes, with stand ups and sprints.
Their development is very open, with 200+ employees on their dev team, which handles ALL of the development needed for Domino’s to work. Their work space is situated a lot like we are in our office – long wide tables with developers situated on either side. This makes the development process very open as they can just talk across the table.
In accordance with their open policy, the developers work directly with marketing.
They do however have a no jeans policy.
The mobile development is centered around two teams – the Android team and the iPhone team. Both apps are native, with the iPhone app being in objective-c.
The original iPhone app was developed over two years ago by a single individual. Most of the original app is still there, but it has been refactored over and over again in order to modularize all of the business logic into “services”. These services are not physical services, but logical services inside the app, much like how angular services work.
These services interact with the actual API which is a rest API that they call Power. This separates the application logic from the API by the service layer. This is done to reduce code duplication when functionality needs to be used by the Domino’s AnyWare extensions such as Apple Watch.
Refactoring and code cleanup is done on a daily basis. This leads to cleaner, and more extensible code. It also allows the use of newer developing techniques as they come out.
The only thing non-native in the apps are the pizza builder. The pizza builder written using OpenGL.
Ordering System / Voice
The core of the mobile system is the ordering system. The pages of the ordering system are observers as part of the observer pattern. Click event triggers subjects that are registered with the pages which then triggers the correct function on the page. This means that they can add new processes which control the UI, as the new process only needs to understand the subjects to notify.
The ordering process is also part of a rather large state machine. Each action that is made adds to the state, and by clicking back, it will go back one step in the state machine. This means if you add an item and click back, it won’t go back to the previous page, but simply remove the item. This reduces user error and loss of information.
The voice system, named Dom, was created using a technology called Nina. Nina was made by a company called Nuance Communications as a digital assistant platform. The development and integration of Dom into the ordering system took roughly one year from start to finish, about three months of that time was spent learning the Nina platform.
Dom isn’t just voice commands. It is a second system which drives the UI. Anything you can click, you can tell to Dom and he will make the action. This means that he is also driven and drives the state machine. When you click back, it not only moves the state back, but it will also move Dom back in the conversation.
Domino’s AnyWare is a set of apps that integrate with other devices. Using the phone as a medium, the apps provide the options of an “Easy Order” or a recent order. Some also have a live-tracker.
Microsoft Sync was the first platform that was developed for Domino’s AnyWare. The biggest challenge here was that the Sync API was very rigid, they had to modify the code on the apps to allow deal with the non-standard methodologies used in the Sync API.
Android Wear was the second implementation. As they already had the code refactored to deal with the external extensions, android wear was relatively easy to implement. They went from start to ship in three months.
Pebble watch presented a number of issues. The first being that the code was all in C. That’s right C, not C++. The second being that the connection would only allow extremely small amounts of data through the bluetooth connection. Even for short sentences they would have to chunk the data and send it piece by piece.
The biggest challenge with Apple Watch is that it was the first version, and not a lot of features existed in the API. Not being able to put any data directly on the device also proved challenging.
The samsung TV implementation only contains the tracker. They partnered with Samsung to make the app, so they didn’t have much of an issue with it. The biggest problem is that Samsung changed the backend of the new TVs, so the app won’t work with the new TVs.
There wasn’t much in the way of technical details during the talk. The majority of it was a high level architecture about the processes that drive the apps. Most of the talk dealt with Dom the voice assistant and the Domino’s Anywhere implementations. I do believe this information is useful. Especially the time constraints that they gave could be a benchmark for development of the same types of products.