Hacker News Reader

Comment by nsomaru | Hacker News Reader

I wonder if anyone who develops for Android could shed some light on the difficulties they encounter when developing for a fragmented platform?

View on HN

There are pretty major differences between pre Ice Cream Sandwich and post Ice Cream Sandwich. My app is almost entirely Fragments, the Action Bar, rich notifications. All of these things didn't exist in 2.2 or 2.3.

Thankfully between Google's support libraries and Action Bar Sherlock most of it can be papered over. I haven't had too much trouble with it so far.

We don't use fragments too much since they're so incomplete. We use ABS for everything.

Do you support < 4.0?

What is incomplete about Fragments? My company uses ABS for most of our apps, and support < 4.0 - most of our applications rely on Fragments heavily.

Each time we go to use them we find something is missing. PreferenceFragment is a good example. Google insists we use it but it's not backwards compatible, thus requiring two separate activities.

Are you using Fragments for phone/tablet/TV differences, or do you stick strictly to phones?

All 3, and I agree about PreferenceFragment - it slipped my mind but it is a pain in the ass.

I haven't run into many other issues(well, except Maps, though I believe this is handled with the new Maps API but I haven't worked on it yet).

Our best-selling app is a widget app so we probably have to contend with the most fragmentation: OS, screen size, device UI layer, device launchers, indie launchers, custom grid sizes, and mods. Then double that for screen orientations.

OS differences, screen sizes, and layouts are handled by a lot of XML resources. Memory limitations is a big problem in older devices and OSes. Flexible layout design is also a challenge since Google & Samsung/HTC have opposing ideas of how big a widget should appear.

Between Mike & I, we have 30+ devices for testing. I have the majority since I work on the UI and need to see how our widgets look for every possible layout. We don't need to buy one of every device made, we just cover new screen types (Droid DNA), platforms (Kindle Fire), and OSes (Nexus 4). We also make sure we have any standout devices (Google Nexus, Galaxy S3). We've been collecting phones & tablets since 2010, so we're pretty well covered for older devices.

We don't mod or force-update our devices; we remain stock. When a major device updates, we update too. We don't support mods/ROMs since it's too difficult to solve bugs on moving targets.

Most users understand Android has been changing exponentially over the past two years. The Galaxy Nexus is the tipping point. Anything made prior is simply outdated. Android 2.3 is our minimum supported OS, but we leave 2.2 open for those willing to try. Similarly, a few top developers are making new apps that are strictly 4.x & up.

Generally speaking you don't need to own and test all devices, the emulator does just fine. There are a few quirks here and there but as cryptoz alludes to I've never had more headaches than trying to support all the versions of IE and modern browsers.

Why not ask a web developer instead? Android is a lot less fragmented than the world wide web.

While this is true, owning and testing all the android devices is a lot harder than having a system with many web browsers on it.

Also asking customers to upgrade is usually downloading new software for websites, but is buying new hardware for many android users (as there is no released update nor will there ever be for their devices)

> a system with many web browsers on it.

Try multiple systems (multiple operating systems), with combinatorially many possibilities for the interesections of {operating system, browser type, browser version, screen size, resolution}.

Which is exactly the same situation for android. And android is a far smaller area so tricks like just using the center third in both directions for large screens doesn't work.

> Which is exactly the same situation for android.

Not at all - the difference between any two Android devices is far less than the difference between any two potential viewers of a website.

> And android is a far smaller area so tricks like just using the center third in both directions for large screens doesn't work.

Android also has an extensive set of well-defined guidelines for layout and constructing applications - the more you rely on the core API to handle these tasks, the more portable your app will be across Android devices.

That's a lot more than can be said for browser rendering in the general case.

Seems like a crucial distinction is that you can ask a user to use, upgrade, or install a different browser but not so easily ask them to get a new phone

Try telling that to a guy using IE on his locked down office computer.

I'll tell him go here (lifesaver): http://www.google.com/chromeframe?quickenable=true

Reply on news.ycombinator.com