When developing for Android, the large number of different possible devices can seem daunting. There’s a large number of manufacturers each with a long history of devices. This covers many versions of Android with manufacturer amendments on top of these versions. The problem is so bad that some app developers such as Moment have been forced to discontinue apps.
Heavily funded developers can go the ‘lets test (nearly) every device’ route but this isn’t feasible for most projects. Here are some coping strategies:
- Avoid heavily branded apps and instead use the default Android controls. Heavily branded apps that scale across devices cost significantly more to create. Conversely, most Android controls will scale automatically. Instead think about how you can re-purpose and re-colour existing controls to get near to a branded look and feel.
- Design for Android. Again, including iOS idioms will cost more and will be less likely to scale well.
- Try to implement the same thing on all Android OS versions. For example, where you can, retrofit today’s Android UIs onto older devices.
- Analyse what devices are actually in use in the geographic region you intend to ship. The 80 20 rule usually applies – test 20% of devices and you will probably cover 80% of all devices.
- Analyse the functionality you wish to have in the app. The deeper you go into the OS, the more problems you will have across devices. Are your requirements to use some deep API essential to the working of the app or is it a misguided need? Keep it simple and you will have less technical fragmentation due to different APIs.
- Re-use rather than re-create. Use open source libraries. There are very many excellent Apache licensed Android libraries out there that have solved many of the technical fragmentation problems.
- If you have a limited budget then support the top x% of devices. It’s better to do something well for fewer people than something poor for all. With Android’s very large reach, you might find the ‘fewer people’ still actually represents a large number of people. Also, if you pick the correct top x% of newer devices then you might also be choosing those that engage more and/or are more willing to pay.
- Use automated testing to test the same app on many devices at once. Again, look at open source such as Spoon. Look for similar families of devices to test based on manufacturer and/or screen size.
- If you are an entrepreneur, think about vertical opportunities that use fewer types of device. In some specialist business scenarios you might be able to stipulate only one model by issuing new devices. This might even be advantageous in that it ensures devices are rugged enough for the given situation.
- Don’t be afraid. Be prepared. It’s my experience that Android fragmentation is over-hyped. It’s certainly less of a problem than the old Java ME fragmentation days. I suppose it depends on your perspective. Remember, you will always get a small percentage of people with problems, on any platform. Accept this and plan accordingly by putting in place measures to record and remotely track errors.