I’ve spent the past few years working on iOS apps, and I’m now giving some serious consideration to creating an Android port of one of my apps.
I’m sure that complaints about fragmentation are a frustrating cliche to experienced Android programmers, but as an iOS programmer, I’m quite honestly overwhelmed by the number of configurations and devices that my app might end up running on.
There are literally thousands of Android devices in the wild, but I know there are successful Android developers in the world and I know they’re not testing or developing for thousands of different devices.
So how can a relatively small company deal with fragmentation? Is it possible to pick the five or six most popular devices, focus on those and prevent the app from being installed on any other devices? Are there any other strategies for practically dealing with the number of different configurations an app will face?
8
Android is great at dealing with flexible designs that run across multiple devices. It’s a huge topic that can’t be expanded in detail as an answer, but I think fragmentation has gotten a bad rap. It really isn’t that bad, and isn’t that hard to handle.
It’s great to see your App run from small screen phones to large 10″ tablets, and Android handles all the layout of the fragments for you. I think you’ll find iOS development could take a thing or two from Android ;).
What I’ve found is the App often has an objective of what it needs to achieve. As you develop you discover that the lower Android API levels don’t meet those needs. So rather then thinking about what devices you need to target. Decide first on what Android version you must use to build the App.
Also, people using older Android platforms also might have a phone that can’t handle the needs of the App anyway. So dropping support for older versions isn’t really a loss, because it wouldn’t have worked very well for them anyway (but that depends more on the App).
2
I think the biggest difficulty is supporting various screen sizes, especially in very graphical interfaces. Display size can vary quite a lot and also h/w ratio and number of pixels. In Android you can specify different resources for each of these cases, and possibly for all their combinations (long/hi-res/small, square/mid-res/medium,…), which would mean a large amount of configurations – which would mean quite a mess of course.
So it might not be easy to come out with a layout and small set of resources that can support most configurations, and it’s important that graphical designers learn the tools and tricks they can leverage to achieve this.
On the API side, I think Google does some good efforts in backward compatibility, also mantaining a nice backport of the most useful new features.
One resource to consider is vendor loaner or rental programs for development partners (developer partner programs). Some provide short-term access for testing purposes affordably, perhaps even free.
Most of the hardware vendors have developer programs, which offer hardware for reduced costs or even free (e.g. Samsung, Motorola, Apple, BlackBerry (for BlackBerry Alliance Members), LG). Check them out for the devices you want/need.
There are publicly accessible ‘physical’ test labs that you can just walk into (or reserve time). They are usually called open device labs: starting point, Google search. Check out if there are any in your neighbourhood and what devices they have.
There’s the occasional ‘crowdsourced’ testing community like uTest that you can ask around.
Note that there are also many on-line services for testing your apps on many devices like AppThwack, TestFlight, TestObject, TestFairy, Keynote a.k.a. DeviceAnywhere, or Xamarin test cloud that maybe have the device you want to test on.
You would also use these before releasing your app, and although these are not ‘definitive’ testing platforms (there’s much to be said for testing on real devices), any tests helps.
Note: Useful overview article