Tompee is originally from the Philippines. After graduating from university, he got a job as an embedded developer at Canon’s Philippine office, where he worked on things like WiFi drivers for Linux systems. While at Canon, he had several occasions to come to Japan on business trips. He said, “That’s what made me interested in coming here, because I already experienced the culture and everything.”
He got the opportunity to move to Japan by joining an outsourcing company based in Yokohama. After a couple of years there, he was looking for a new opportunity and found Drivemode, where he was initially attracted to its startup mentality and multicultural environment, with everyone from the engineers to management communicating in English.
Drivemode is a user-first company. We rely heavily on user feedback when designing features and implementing apps. We do not assume what a user wants, and rather we’ll implement something, gather a lot of feedback, and then iterate on it.
Since joining the company, he also appreciates how Drivemode approaches product development. He said, “Drivemode is a user-first company. We rely heavily on user feedback when designing features and implementing apps. We do not assume what a user wants, and rather we’ll implement something, gather a lot of feedback, and then iterate on it. It is a first for me to be in a company that is user driven. It’s really interesting.”
Tompee is passionate about Android development, having started his own online publication about it, and writing apps in his spare time. So he was glad to join a team of highly skilled engineers. He said, “The engineering team is very passionate about what they do. There are some details that I would normally take for granted, but there are people at the company that really care about them. For example, performance and other limitations. Normally people would dismiss this for being a framework limitation, that for being an SDK limitation, but some people in the company really like to work around these limitations. That drive from them, I really like that about them. As a consequence, they’re really good at what they do. They can deliver their outputs ahead of time and without supervision, so it makes everyone’s job really easy. As everyone is pretty skilled, we manage our own tasks, and the structure is pretty flat.”
Basically if I would describe our work, as simply as possible, it’s probably hacking Android.
Having such talented peers helps as the work they do is quite technically challenging. He said, “Basically if I would describe our work, as simply as possible, it’s probably hacking Android. The app is so technical that we had to employ non-standard methodologies to make the app work. We support some use cases that are not natively supported by the framework itself or the system itself.”
He continued, “For example, with our app, you pair your phone with your motorbike, and you can control your phone on the handlebars using directional buttons. You can use the app to perform navigation, calls, messages, music, all of these usual features in your infotainment system. One of the challenges is to support third party apps. If a messenger app receives a message, you have to find a way to let the user know that the third party app received the message, and then allow the user to reply to that message using that third party app. If you’re familiar with Android, every year inter app communication becomes more strict, and basically there’s no official communication channel for those apps any more, so we have to find a way to work within those restrictions and cleverly detect all of these events and support these features.”
Though they may need to rely on hacks to do this integration, Drivemode structures their apps to cleanly contain this code. Tompee said, “Internally we create a lot of libraries to abstract all these features. For instance, a clean API to send and receive a message with a third party app. Inside of this library is all the ugly code to do the hacks.”
Sometimes even the official extension libraries from Android don’t work for our use case, so we have to create something similar. This is fun for me, as I get to learn all of the low level details that I usually take for granted because the library already does it for me.
In pushing the limits of Android, Drivemode sometimes finds themselves having to create their own low level libraries. Tompee said, “Sometimes even the official extension libraries from Android don’t work for our use case, so we have to create something similar. This is fun for me, as I get to learn all of the low level details that I usually take for granted because the library already does it for me.”
Furthermore, they take advantage of truly the latest Android tools, going so far as to using the Alpha build tools in their production app. He said, “Some of our requirements are not yet supported by the official stable releases of the Android build tool, so we tend to opt into alpha tools for android. They call it the bleeding edge tools. It’s very risky I know, but it says a lot about how far we go to be able support your use cases or requirements.”
Tompee thinks Drivemode is a great place to see the limits of Android being tested. He said, “I’d like to think not all Android apps are created equal, and if an Android developer gets a chance to see how we built our app, they’d be pretty interested in working with us. When I joined Drivemode, I actually had a lot of eureka moments, like oh, I didn’t know you could actually do this or I thought this wasn’t supported at all. So I think another developer will learn a lot of stuff just by reading the source code. Most Android development is being reliant on SDKs, just creating views and communicating with a server. But our app is not that simple. We use a lot of features in the phone, such as GPS, WiFi, and Bluetooth, and do some pretty low level stuff. I’d like to think another developer would learn a lot of stuff.”