Mobile apps for smartphones and other devices are increasingly in demand in today’s enterprise. While development...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
challenges are similar to desktop and Web apps, there there are some uniquenesses as well, according to Robert LeRoy, director of Sogeti USA’s IBM and Open Solutions practice, who has led teams in classic Java development, Web pages, smartphones and settop appliances. In this interview, he discusses some do’s and don’ts, current trends, and talks about two primary challenges: cross-platform development and building context-aware apps.
There seems to be an increasing amount of embedded software. Have the skills and resources kept up with development demand?
Robert LeRoy: It depends on the platform. If you look at an embedded platform like smartphones, some use the Java programming language, so it’s easy to take a Java programmer who knows the classic Web development environment and move to Android. The same is true for Microsoft. When you get into iPhone development, the learning curve is steeper. But there’s much interest there, and developers are investing their own time and money and learning on their own.
One place there might be a technology/skills gap is when you get into embedded systems like in an automobile or exercise equipment or home appliances. Those are more real-time systems, and the programming skills involved are significantly different than a smartphone. If you’re building an application that’s going into a hospital, failure rate has to be zero. It has to be real time, and react at moment’s notice. That’s a different programming model than what many are used to.
Does the lifecycle for a mobile app get managed in the same way as desktop and Web apps?
LeRoy: It’s slightly different. The software development lifecycle is very similar, but you might spend more time focusing on the user experience to make sure it’s easy for a consumer audience. But the product lifecycle is definitely different when talking about consumers; they’re looking for added features and updates. The smartphone applications we work with [in enterprise organizations] typically come out of the marketing group, unless they’re for the internal organization, say a bank with folks who do appraisals on houses. What we’re seeing a lot of today are applications very much geared toward consumers, so I can build a tighter intimacy with my customers. The analogy is like the early ‘90s when people were building web pages, but they weren’t sure why. Now we’re seeing that more with embedded systems -- they’re not sure why they have to have one. For example, a medical supply company gets a new application where you can order medical supplies right from the smartphone; competitors see that and they have to build one for their people.
What are some do’s and don’ts for developing smartphone apps?
LeRoy: There are two simple do’s: First, you have to find where the business value is. You don’t want to build it because you can, but to have an impact on the business, or to make products easier to use, or to increase revenue. Focus on the business value. If that means the best way to create an application is as a smartphone application, then that’s when to do it. If SMS is a better approach for your business, you should do SMS. The other [do] is common sense—how to architect them. Start small is a best practice. You likely have these enterprise applications in-house, and you’ve taken a subset of them and exposed them to the Internet. Now you’re going to take a subset again and move that out to an embedded device. Perhaps it’s a document management system. You don’t want the full capability on the device.
And what are some don'ts, or common mistakes?
LeRoy: One is the expectations of the device weren't clearly understood. There are certain assumptions during development about how things could be done, and you have to be sure of the capability of the device before you start. For example, the BlackBerry doesn't store data on external storage, and we designed a system to do that, so we had more data than would stay in core memory and we couldn't put it in an external source, so we had to change the design to fit the device. Another one people forget is security. Think about smartphones. If you lose it, someone can break into it pretty easily, so secure data and secure access to the application.
Is the methodology for developing mobile apps similar to developing desktop or web apps?
LeRoy: It's closer to a Web app, because a lot of time is spent on branding and user experience. The projects typically are shorter and tend to recur more often -- you do version, release it, and your back into another [release]. A trick we have used is embedding analytics into the application, so you can measure usability remotely; for example, if you use Web services, if each service is tied to a function on the device you can put analytics against the services so you know which features and functions are most used, and you can focus on that behavior and add more value in those areas.
What are the trends with mobile app development?
LeRoy: There's a big push to identify how to get cross platform with a single code base; everyone is trying to get to a single code base, while trying to minimize how much code is on the device and push as much as possible up to the server. Another trend is [the use of] frameworks; they do coding for a mobile device.
Applications are also getting more sophisticated, trying to get to the context-aware app, which is the driving force for all these mobile apps. If you can get them to [be context aware] it's easier for the user, but from the developer point of view it's far more complex. A context-aware application knows who I am, where I am, when it is, and should change itself automatically and know what data or function I need. That's where we should be going with embedded devices like iPads and smartphones. If I'm a service guy at a customer site for a call, it should automatically show me the data; or if I'm in calendar it's showing what I'm doing now, but behind it and getting larger is directions to my next meeting. That's what we're working toward; Sogeti is building frameworks to support that model now.