On the surface, mobile application performance management is a tricky beast. A lot of variables exist that are outside the developer's direct control that can impact mobile app performance and result in a poor user experience. However, according to experts, the challenge is easily overcome if developers understand a few simple principles about mobile application development and performance.
"Mobile and performance is a big, scary topic, and the truth is there's no reason for it to be big and scary," said Scott Barber, president and CTO of Palm Bay, Fla.-based PerfTestPlus Inc., a software performance testing consultancy and service provider. "Unless you know how to handle it, it is certainly challenging. But at the end of the day, I will say this is not hard the way people think it is."
The challenges of mobile app performance
"Our performance challenges are based on the rather simple thought that we are trying to get laptop or desktop performance out of these devices that are less powerful than those bigger devices," said Barber.
"A mobile platform is a lot weaker than a standard PC, so the main challenge is to write an application that acts like a PC application but runs on a mobile platform," said Nazmi Savga, software architect, Imprezzio Global.
"It wasn't all that long ago that the way we had to build and deliver software in general was similar to the thought process we need to apply to mobile applications today," said Barber.
Stephen Pierzchala, a technology strategist at Detroit, Mich.-based Compuware Corp., agreed: "In terms of both the mobile Web and native mobile applications, it's a lot of the same rules that we've been using for a number of years for desktops. It boils down to one rule, and a lot of things come out of it: Know your customers."
Learn about the target audience
Knowing your customers from a mobile application performance standpoint means knowing what browser(s), operating system(s), device types(s) and connectivity customers are using, Pierzchala said. All of these factors put restrictions on the application that need to be considered -- and the earlier in the development process the better.
Ideally, teams begin thinking about the target device or devices that the application will run on during the concept phase, said Barber. He acknowledged that this can be difficult. If you're in a six-month development cycle, are you building for today's mobile devices or yesterday's?
"The truth is that everyone wants to design for the newest and greatest, and they decide later that they need to be backwards compatible, and this creates a nightmare," said Barber. "If you make that decision in the beginning, there's hope. If you make it at the end, then you're shooting yourself in the foot."
The features and capabilities that are available on the latest platforms are not necessarily available on previous versions, or from one mobile platform to another. "An architect should be aware of which platforms the application will run on and should consider the platform variances," said Savga. "The architect should be aware that it is a restricted platform or it has a lot of weaknesses compared to a standard PC, like memory and disk space."
Barber compared this approach to Web development, when developers would decide beforehand what operating system and browsers an application would run on. "It's just a dated concept in a sense," he said.
Are network calls getting in the way?
Here's another mobile application performance tip that will sound familiar to veteran developers: Always put network processing on a background thread. Matt Vlasach, director of mobile integration services for Mesa, Ariz.-based Unwired Revolution, a mobile solutions integrator, explained: "Be very careful when doing network stuff that you don't block the UI when waiting for a response. If you do any processing on the main thread, the application will freeze while you wait for a response to come back. Use asynchronous Web requests and handle that stuff appropriately."
This is the same approach you would use for developing a desktop or Web application, said Vlasach. "The practice is 'Don't block the user from doing things while you're waiting for the network to do stuff.' It is more complex, it takes more time and the user experience development takes more cycles, but it makes a dramatic difference in user experience and usage," he said.
Keep presentation separate from business logic and data
Savga advises developers and architects to be aware of the three layers that comprise a system -- the presentation (or user-interface) layer, business layer and data layer -- and to carefully architect the components for each layer. "A function in the code should not be replicated in any other layer or part of the program," he said. This will make it easier to maintain the code, as well as help performance.
When it comes to the presentation layer of mobile applications, architects need to think about screen real estate and how the user interface (UI) is presented. If a common layout is used for all the possible resolutions and the UI changes are handled according to the resolution, the application's performance will be impacted.
"The best approach is to create a different layout for each screen size so the application switches when it recognizes that it's on a different screen size. Otherwise, you experience a lot of performance problems when creating a common UI for all available screen sizes," said Savga.
And this brings us back to the principles we started with: "Know something about who your customers are and the restrictions they put on your ability to deliver the kind of content they're looking for," said Pierzchala.
About the author:
Crystal Bedell is a freelance technology writer. In addition to application development, she writes about cloud computing and information security. Connect with her via LinkedIn or email.
This was first published in June 2013