Guide to cloud application testing
A comprehensive collection of articles, videos and more, hand-picked by our editors
Erdal Tuleu and the developers he works with have taken a successful Web-based messaging and communications application and created equally successful mobile versions for both iOS and Android platforms. Tuleu is director of engineering at imo. Similar to Trillian, imo lets users combine instant messaging profiles and maintain conversations. We recently got the chance to ask Tuleu several questions about building native mobile apps to fit existing Web applications.
As the team moved from a Web application with a single Web interface into the mobile Web application world, Tuleu et al. had to overcome several challenges. Designing applications for the constrictions of mobile device hardware can be more challenging than designing applications that run in a full Web browser on a desktop or laptop computer. Even more challenging, the team built out mobile apps for both the Android and iOS platforms at the same time. This required the team to split into and coordinate multiple development teams. Those development teams still need to coordinate their code both with each other and with the back end, and the apps have to be tested on multiple devices under as many conditions as possible.
Tuleu has proven his expertise and initiative with imo over the past three years. He joined the team as an intern and has risen quickly to the rank of director of engineering. Before finding his home at imo, Tuleu spent time as an intern first with Google Inc. and then Microsoft.
SearchSoftwareQuality.com: What sort of challenges did you run into taking the Web app and moving it over to mobile Web applications?
Erdal Tuleu: We had to keep efficiency in mind for mobile devices, compared to the Web app where we didn't have to care as much. We had to adjust how much data we send back and forth between the client, how we send it and when. We want the phone to be efficient because we don't want to use up all the phone's battery and memory on the device. We don't want the app to take up too much space.
But there are also changes that have to be made to support the way people use mobile devices. One of the data points we noticed is that users type a bit more when they are using a large keyboard on a laptop and a bit less on their phones, which makes sense. People also use more voice features on mobile devices and that makes sense, too. And people stay signed in a lot more on their mobile devices. On your desktop or laptop you're more likely to sign in and out or turn the device on and off. With a smart phone, that pattern doesn't make sense anymore. Plus, there are often connectivity issues that spring up from spotty mobile network coverage.
In each of those areas there were some engineering choices that we could make without cutting out any features. There were also features that we found ways to make simpler. And we're still repeating the process today, trying to make the mobile apps simpler and faster.
Another challenge is that we wanted to build native clients because we felt that would be a much better experience for everybody. But that meant we had to develop independent clients -- mostly independent, they all use the same back end -- but each of the clients themselves has a separate code base. That, in turn, meant we had to have different teams for each client.
What was the biggest challenge of having to support two clients?
Tuleu: Most of the logic is the same, but there are some particular things for each platform. For example, with Apple you have to use their push service, whereas for Google there is a different strategy. There are significant differences; it's not just translating the same app into different languages. There are different challenges for different platforms, of course. Some parts have better documentation than others, but each team had to figure out what to do to overcome particular challenges with the mobile apps.
Recently, we started working more in parallel on the same features. For example, we decided we wanted to work on voice-activated controls. As soon as we started with that, we thought about the back-end design so that it would work on both platforms. Then we started prototyping something on Android because it would be easier to launch an app and make updates. Once we saw that everything was stable, we worked on the iPhone app as well.
The teams work pretty close together at times, depending on what stage of development we're at. But, they're also different at times. For example, when we're doing more user interface (UI) oriented stuff, there are more differences so there's not as much to share. But when it comes to talking to the back end and such, I think the teams work really closely together. And because the back end is shared, both teams can contribute to that.
This is part one of a two-part interview. Please check out the second half to learn about the differences between mobile applications and Web applications and how to test mobile apps.