AR FreeFlight as a case in question
Both Android and iOS app markets are now booming. Even as Apple’s app store is at its peak, Android Market (as of recently Google Play) is gaining momentum as ever in today’s wireless world. That’s why every smart company out there wanting a mobile app created to promote its business is faced with a challenge: how to get both iPhone and Android users engaged in the app?
Eventually, many businesses opt for an iPhone app. By and by, they may find it necessary to port it to another platform. Android and iOS vary a great deal. And when you are extending an app to a new platform, you surely need to test how it looks and works. The web is swarming with various device emulators, making development and testing instantly available from your desktop. But how efficient could this be - especially given the variety of Android devices of all shapes, sizes, screen resolutions and brands currently in use? Only real devices, and a lot of them in fact, prevent developers from releasing an app ‘on a wing and a prayer’.
Porting to Android from iOS and vice versa is far from the same. The chief difference is that there are only as much as three iOS devices - iPhone/iPod (same screen resolution and other properties) and iPad (different OS versions don’t pose much difficulty), as opposed to the huge variety of Android powered devices in the Android world now, with more springing up at a rocketing rate.
What’s more, Android devices are all unique and specific: they have different screen shapes, screen side correlation etc. All these things considered, there will undoubtedly be difficulties when porting an iOS app to Android. What are the most common of them?
Porting a multilingual app
Very few apps have only one language version - many more apps have two or more. And a lot more apps are multilingual. It’s a known fact that languages differ and the same word is written in a different way in English, French, German, Italian, Russian, Chinese etc. That’s why text may be displayed differently in every language version of an app.
Some unconscientious developers would typically simply shorten words when they do not fit into a text field. Of course, it’s an easy and non-time-consuming way. But the results of such approach may be dramatic. A user will get smth like “Derz. gibt es keine Internetverb. zur Verfüg.” And who wants to read those cryptic words and end up guessing their meaning?
Let’s see - a recent example is AR.FreeFlight version 2.0., with its interface available in 9 languages! (Japanese and Chinese included). Keeping the text intact was of great priority, so we made use of the tools available. Every screen for every language was copied and modified if necessary. By modification I mean playing around with font size, changing line spacing options, and introducing indentations.
Android OS does not natively support Arabic symbols. When we were faced with this problem (there was an app with the Arabic language in it), we decided to generate every screen (text screen) as an image (through a Java desktop application). Only then were the Arabic symbols displayed in a proper way!
That solved, there may be issues with custom font. Sometimes devices don’t support some font types - but how to know for sure? Testing on as many devices as possible seems like a good option.
Interface and design
A typical mistake is simply copying the iPhone app interface. We should keep in mind that iOS users (as well as Android owners) are used to a particular interface, and seeing an absolutely different layout may be somewhat confusing for them.
Know the platform properties. A typical example: current time and battery charge indicator on Samsung Galaxy Tab, Motorola Xoom and most Android tablets are displayed on the bottom of the screen by default. iPhones don’t have this feature and a typical solution is to place those gadgets directly in the app. However, when are porting an app from iOS to Android, you should think twice before reinventing the wheel!
Every smartphone has its original colour palette. But some companies that produce Android devices are extremely fond of changing a default theme to a branded, custom-made one. That’s another feature you should be aware of when porting an app (default design of a device may be changed sooner or later).
What is the solution? For successful development, one should make their own copy of the graphics. It is good idea to get in touch with a designer. Yes, it is a more time-consuming and challenging task, but it’s worth the effort.
Yet another thing we have recently noticed about Android devices is the app-device communication for determining the screen resolution:
- for tablets with OS version 3.0 and higher: an app with its Android manifest file saying nothing about tablet support is usually scaled (the device can “fool” an app into thinking that its screen size is 480х768 pixels (or a different set of digits altogether), while it really is 1280х800. The resulting image the app displays is far from perfect.
- in the majority of latest devices with OS 3.0 and higher, system buttons that once used to be hardware are now software (they have become a part of the screen). Thus, now the app can only use 1194х800 of the declared 1280х800 pixels. This makes it hard to choose the right size for resources to be displayed - and having the button cover a part of your app’s display is a punishment large enough for neglecting this fact.
Potential issues with media files
iOS is more likely to reproduce video files accurately and smoothly. Android powered devices (especially the older versions) are not so good at reproducing video files: you should be ready to deal with unexpected crashes such as various UI issues: screen blinks on video start, poor performance when you try to put UI elements on top of the video track etc.
Let's take a look at, say, Kindle Fire. There is a curious fact to know about it: Kindle Fire cuts off the last 300 milliseconds of each audiotrack it reproduces. There’s a smart way around it - adding 300 extra “empty” milliseconds to each audiotrack.
One more extraordinary thing about Kindle Fire: as usual, system dialogue boxes have transparent and narrow borders. In the Kindle Fire dialogue, the borders are much thicker. That way, a part of interface in some dialogues (i.e., Facebook dialogues) is not displayed. It is also because of Facebook native library feature that was built taking into account the display’s width, but not the dialogue box size. However, this also needs finding a workaround.
Bluetooth connectivity
For some apps, connection to third-party devices through bluetooth is essential - a good case in point are certain types of healthcare apps aimed at healthcare professionals. They have to connect to one or several devices by means of bluetooth to collect and transfer patient data etc. That said, if such app is functional on iOS, Androids are a whole new dimension to work in.
First of all, you should always check whether bluetooth connection is running on every of those devices. For instance, in Kindle Fire and Nook Tablet bluetooth is not available at all (as well as GPS). It should be explained to the customer that the app will not run on these devices due to their limitations.
To avoid user’s confusion (“Why is this app not running on my Android device?!”) developers should place hardware requirements inside the Android app’s manifest file. That way, Google Play simply won’t display the app to the user whose device doesn’t have the required hardware features.
Android is only properly connected via bluetooth when it is paired with another device. The mobile device will prompt the user to select another device for connection, so it is a smart solution to predict a “Scan for available devices” button.
One other feature you should be aware of: there is a limited number of simultaneous bluetooth connections a device may have and this number varies with every Android device.
How to ace the market?
All this considered, to stay on top of things with Android app development, testing on the actual smartphones and tablets is essential for quality assurance services. In other words, in-depth knowledge about the different devices’ peculiarities is a great boon, and releasing an app without proper testing is a bane and is a lot like taking a new route while driving blindfolded: you never know which detour you will end up crashing, like you never know on which Android device the app will end up crashing.
SEE ALSO: