For developers of apps that rely heavily on specific hardware capabilities – gyroscopes, accelerometers and cameras, for instance – developing for Android can be a major challenge. The sheer number of devices that use the OS makes it almost impossible to build in detailed hardware controls, which can in turn compromise the app’s functionality. As a result, many application developers relying on set hardware features are likely to gravitate toward the less diverse iOS environment to roll out their apps. But how can they then port to Android? According to one mobile CEO, the trick is in careful redesign and code refactoring.
For an app like home improvement tool MagicPlan, which relies on multiple sensors in the device to capture the dimensions of a room and create an accurate floor plan, it made sense to debut on iOS, Paul Gaubil, CEO and co-founder of Sensopia, which makes MagicPlan, wrote in a recent post for VentureBeat. For one thing, Apple was the first device manufacturer to include a gyroscope in its phones. As the app’s user base grew, however, moving to Android became the logical next step. The only problem was that, at the time, there were 11,865 unique devices running some version of Android, and the company would have to support 509 unique devices to reach 80 percent of the market.
“‘Fragmentation’ on Android tends to be mentioned almost exclusively with respect to versions of the OS or the (usually horrible) custom OEM skins/features,” Gaubil wrote. “These certainly did become an issue, such as when we found some manufacturers who had included a gyroscope in a device (and spec sheet), but had not enabled it in their software. In our case, though, the fragmentation and diversity of hardware was our largest challenge. We could not allow our software to run on devices we had not tested and certified, since the result of un-calibrated sensor fusion would do our customers a disservice and reflect poorly on our company and product.”
Simplifying the design
With such fragmentation, releasing an app that offered the same type of granular control and accurate calibration as the iOS version for every device using the current code was out of the question, Gaubil noted. However, by building the code with a simplified, common software development kit in a single language and using a unified multi-sensor architecture, the company could extend compatibility across both Android and iOS and handle the validation of sensor processing code on one platform. Doing so enabled simpler ports and allowed MagicPlan to offer SDK integration options for multiple partnerships.
The key to carrying out this simplification was code refactoring and restructuring, Gaubil wrote. Code restructuring allows developers to make code easier to understand and more effective by trimming superfluities and redundancies. It is not necessarily a redesign unto itself, but code refactoring is a critical practice in carrying out deeper overhauls, industry CTO Jim Bird wrote in a column for Java Code Geeks.
“You don’t decide to refactor, you refactor because you want to do something else, and refactoring helps you do that other thing,” Bird wrote. “The scope of your refactoring work should be driven by the change or fix that you need to make – what do you need to do to make the change safer and cleaner? In other words: Don’t refactor for the sake of refactoring. Don’t refactor code that you aren’t changing or preparing to change.”
App developers looking to simplify their code and overall architecture to universalize it and prepare for the more fragmented Android hardware environment can benefit from combining code refactoring and redesign processes. With automated code refactoring tools, this type of organization and compression is easy to carry out.