Dealing With Android: The 5 Pains And The Remedy

Android is seeing a lot of traction. When you will be planning to build your Android app, these are the 5 pains to be aware of. Use the remedy checklist below to select your Android contractor thoughtfully.

P1. Fragmentation

According to OpenSignal, Android device fragmentation has gone up from 18 796 to 24 093 in the last year and continues to increase every year, and the main reason for this is customization. Smartphone manufacturers can change anything from visual elements to the internal logic of the device, which has an impact on how the applications work and look like. Moreover, different official versions and subversions of Android are still being used. These circumstances make the creation of a quality Android application anything but a simple task. Let’s have a closer look.

P2. Screen types

The diversity of Android device screen sizes and densities call for a thoughtful approach to both layout and graphics. Elastic layout is a great solution for the majority of the devices as it can stretch depending on the size and density of the screen and the carefully sliced graphics which are distributed according to the required range of supported screens.

P3. Hardware

Android is intended to be functional on both high and low end hardware. Low end models are different from «flagship» devices mostly because of insufficiently powerful CPUs, low RAM speed and capacity, low end graphical chips and lackluster screen displays. All of this impacts the app’s behavior, performance and color rendering. Consequently, a low-performance hardware component could prevent the implementation of the required features.

P4. Different OS and system API versions

Every year new versions of the Android operating system with partially or fully re-developed API become available, which forces developers to keep up with the changes. Starting from Android 1.0 and up until today 22 API versions have been released. The first most stable system is considered to be Android 2.3, API version 9 (less that 7% of devices on the market). Android 4.0 (API version 14) and higher are considered to be the most popular, with Android 4.4 (API-19), 5.0 (API-21) and 5.1 (API-22) being the most well-received by users.

Each new operating system includes new features which often don’t work in the older versions. The first global example of this is NFC payment system which became available only in Android 4.4. The second is Material Design introduced in Android 5.0. The Support Design Library may be used as a substitute, it only partially supports Material Design for older version devices, and many visual effects are not implemented in it.

The majority of the new applications have been created for Android 4.0 and higher to span the most system capabilities and allow for higher reliability. A great deal of features, both logic and visual, are unavailable in API version 9 (Android 2.3), which forces developers to employ unconventional and «duct tape» methods and use third party libraries, resulting in more working hours spent and a general increase in development time.

P5. Vendors and Android customization

When creating the system shell, vendors customize the default system elements of the interface, causing mismatched design, skewed layout, crashing and so on. For instance, Samsung Note 2’s developers have inverted the default Android color scheme. As a result, the text in some parts of the app could blend in with the background.

The Remedy Checklist

When selecting Android development team for your app, remember to:

1. Review their portfolio and let them tell you about their most challenging projects

Challenging projects are critical for a team to gain experience. Estimate the complexity of your project and make sure that the team has similarly challenging projects in their portfolio.

2. Ask them what libraries and tools they would use for your project

There are many awesome third party tools available out there, that may help you to cut down the price and the time in your specific case. For instance, we use Retrofit, Picasso, OkHttp, Otto, Cupboard ORM, Dagger 2, Realm.

3. Make sure their UI designers are familiar with Android guidelines

Designing for Android is different. Following the design guidelines makes implementation easier. And the nicer your UI design is, the higher are your chances to attract user’s attention.

4. Check their pool of testing devices

You may want to target 4», 5», 7» and 10» devices made by various vendors. With different Android versions installed. With different screen resolutions and pixel density per inch. You will have to test your app on those devices to monitor app’s behavior and to troubleshoot during in-house testing stage, thus keeping the end users happier.

5. Get a detailed estimate

The estimate should include milestones, price, and timeframe. Milestones would be: creating wireframes, realistic UI prototype, graphic design, then building and testing in stages. Expect to get estimate in the form of a spreadsheet with features or app screens and related work hours of designers and engineers.

6. (Optional) Ask them what thought leaders and companies have influenced them

Our influences are Jake Wharton and Jesse Wilson, Square Inc. employees, prominent visionaries and preachers of the Android community, and Lars Vogel, independent consultant and coach and established speaker at Devoxx, EclipseCon, O’Reilly Android Open, MobilTechCon and Droidcon international conferences. Lars has his own website containing lots of tutorials.