Zappos

What does it take to support multiple devices? A few top developers weigh in

Android runs on a variety of devices, which means it also runs on a variety of screen sizes and resolutions. Lots of folks call this "fragmentation." Never mind the fact that they've been using products designed and developed the same way for years on their desktop. Apparently if everything isn't exactly the same it gets the "fragmentation" label. 

There are different ways to tackle the problems that arise when you use screens with different sizes and densities. Apple has separate listings for apps designed for the iPhone versus the iPad. Microsoft creates a new eco-system for its big screen devices. Android provides a way for developers to make the same app work differently for different screens. There's good and bad about each method, but we're going to focus on Android here.

In Android, applications can adjust the layout for different size screens as well as resolution. This is all built in, but there are a few things developers need to declare in their code to make the app look good. The thing to keep in mind is how screen size and density will change the look of the app. The Droid DNA has a higher-res screen than the Motorola XOOM tablet, but we don't want to see a tablet layout for apps on the phone-sized screen.

A developer needs to provide assets (images) that are high enough quality to look sharp at high resolution (never mind insanely high resolution), and be sure to use density independent pixel units when designing their layout. This is what keeps things like buttons and other controls from being really big on low density screens like the Galaxy S2, or from being really tiny on high density screens like the DNA.

It sounds complicated, but most of this stuff is done for you when coding an app. All the developer needs to do is make the right declarations, and provide the right assets to support any size (both physical and resolution) or layout. Even multiple layout apps like the Google+ app use the same code to cover every conceivable screen.

We're not trying to judge developers here. Writing apps is tough. The Android developers have been preaching all this since the release of Gingerbread, but how practical is it? We asked a few developers about it, see what they had to say after the break.

More: Google's Android developer site

Android code

We asked a handful of developers (both big and small) a couple basic questions on the subject. 

  • How difficult is it to adhere to the guidelines?
  • It looks easy on paper, but are there any special issues you've seen or parts that Google hasn't covered?
  • How did this affect development time and costs, if at all?
  • Anything further about the subject you'd like to share?

I tried to make the questions as neutral as possible so that we don't go into this with some bias in place. When in doubt, you ask the people who know, right? I've done my fair share of programming, but coding in Java and building Android apps is very different from writing code in C or machine code, or even Perl. There are nuances I don't understand, even if I get the general methods of building an app. 

I imagine a good number of you guys are like me and don't know the intricacies of building Android apps. We only see what the Android developers say, and they make it sound easy. For them, it probably is -- they've been writing this stuff from the ground up since 2007. Let's see what the folks who have been able to follow them have to say.

Joe Simpson (@kennydude) -- Boid

Boid Speaker Pro

Joe is a member of Team Boid, and also publishes applications on his own. He (and the rest of his team) are a great example of independent developers with a passion for Android who have cranked out some amazing applications. 

Following the guidelines is fairly difficult, especially if you want a lean app but people want back-compatibility. One of the most annoying things is seeing what something looks like on d.android.com/design [Google's Android developer design site] but nothing on how to actually do that.

A weak point is refreshing when you physically can't use GCM [Google Cloud Messaging] due to Twitter, and you don't want to use PtR [Pull to Refresh]. Also, Google's apps make up their own guidelines. Take the slide-in pane for example, Google+ does it differently than YouTube (although I know the support library is going to hopefully settle this).

Also, you can get to a point and there is no documentation on something (EdgeEffect for example).

I'm a student, so costs are something I don't look it, and yeah it takes time, but your users will love you. Basically, the Live Shows (ADiA, App Clinic, Office Hours) are a must (unfortunately) although they can't offer feedback about  Google's apps.

Boid is soon to go open-source (yay!), and you can find the app itself in Google Play. You'll also find all of Joe's apps (there's some jewels there) right here.

Christophe Versieux -- BeTrains - SNCB Belgium; HoloEverywhere

BeTrans  HoloEverywhere

Christophe has built numerous Android applications, including BeTrains - SNCB Belguim -- an app with a gorgeous layout that shows what can be done with a well-built application. While most in the US will never use it (it's a train schedule app for Belgian rails) it's worth installing just to see how well it's done. The folks in western Europe certainly know about this one.

In addition, he has co-developed HoloEverywhere, a library that other developers can use to build Holo style applications for Android 2.1 and higher. With many phones still running Gingerbread, this is a real treat for developers who want to keep their apps looking current.

It's not difficult at all. Seriously. The difficult part come when the customer asks to get away from those guidelines!

I remember a customer that wanted me to put tabs on the bottom of the screen, iPhone buttons everywhere, iPhone-style toggle and this project was really hard to achieve and I really lost a lot of time and money on it.

I was really angry at him when he asked all these stupid stuff, and he just thought I was a lazy developer.

I have now a lot of contact with him and we are totally rewriting his app, create awesome code by removing all these useless features and creating a "pure" Android app. The customers and companies just need to be aware of those guidelines, I strongly believe.

Libraries like ActionBarSherlock, HoloEverywhere (my creation), UnifiedPreferences, and SlidingMenu are really easy to use and provide in a few lines of code an awesome user experience.

Time and cost, as I said are minimized by following Google guidelines. Fragments and layout folders are really easy to use (and more important to re-use) : a tablet app just grab piece of code from the phone layout and nothing must be rewritten. Small changes in the phone app are immediately reflected in tablet app, as the same Fragment is used.

Some amazing projects are created by the community, not always by Google. Some people, very active on Google+ like Roman Nurik (Google), Reto Meier (Google) Juhani Lehtimäki, Jake Wharton, Taylor Ling, .. (I am always afraid to forget important people) are very instructive. Developers just need to know where to look and Android development will be easy for them!

You can find BeTrains on Google Play, and you'll want to take a look at HoloEverywhere if you're interested in Android development. 

Matthew Runo -- Zappos

Zappos

In contrast to some of the smaller independent developers we talked with, we also heard from Matthew at Zappos. Zappos is a web retail corporation and likely has a dedicated budget for design on both their website as well as their applications. It's also a company that I purchase from regularly, but this had no bearing and the Matthew was unaware that I am a frequent customer when he volunteered. 

At Zappos, since we're a retailer, we have to stick first and foremost to our own brand. Wacky, fun, and a little off the wall. That said, both of us are strong believers in the Android design guidelines -- and everything that we do in the UI is taken from the spirit of those rules. A year ago, our app was mostly an iOS port from how it looked and worked. Today, it's (I think) a gem of what you can do in Android. We adhere to the guidelines whenever possible - and our designers work from them as a starting point.

The design guidelines are not a be all and end all - in the end they're just there to try to push along the design of android apps so that they're more consistent. We've found that most of the common "new" open source libraries that we've used have ended up as part of the guidelines (sliding menu, crouton).

The guidelines should never be a hold-back. Certain things -- overall navigation -- need to be consistent so that your app "just works." Everything else -- start at the guidelines and run with your design. We want our app to be OUR APP -- so we can't just do the baseline holo theme.

This year we have basically started from a ground up rewrite of our app to work with fragments. In the past 6 months we've worked hard to add 7" tablet support, and we're currently working on 10" support. The hardest thing to do is testing on devices, but we have a great QA team that helps with that. We have had 2 people working full time on our app since August or so, before that it was 1 full time person. 

Bottom line is, I think, the android design guidelines help us streamline our process - and thereby reduce costs. Let's face it, most designers from from iOS - so having a great resource like design.android.com is a wonderful help to get them kickstarted in the android ecosystem.

I can say that Zappos' design choices work well, and my wife has a closet full of clothes, purses, and boots that reinforce my claim. Check out their Android app from Google Play.

Josh Burton -- jRemote

jRemote

Josh has authored numerous small applications for Android, and his jRemote application (it's a controller for the popular jDownloader PC program) is a perfect example of how to use layouts to create an app that looks great on both the phone and a tablet. It maximizes the use of the device screen, and gives you the information you're looking for exactly how you would expect it. 

Adhering to the design guidelines is pretty straight forward, as long as you stick to them from the get go. Developing an entire app and then at the end going back and trying to implement fragments/tablet layouts etc is going to be a waste of time, effort, and frustration. But if you plan out your app, develop using fragments from the start, and create your resources for all the right dpi buckets, it makes developing a breeze, and you really don't need to spend much time thinking about the guidelines at all. And if you do get stuck, the design docs are only a click away. They are a great resource. 

It really frustrates me that so many devices don't have tablet layouts. If your app is built using fragments, adding a tablet layout can be done in 30 minutes. Honestly, it's that easy.

I think for a lot of developers, they don't have tablet devices to test on, and using the emulator can be a pain. But the new ADT tools just released make it a lot easier. The multi configuration view in the layout editor means you can see what your layout looks like on 5-6 different screen sizes all at once. And its fast. Of course you will still need to test on an emulator/device eventually, but it definitely speeds up the workflow.

jDownloader is a handy program to use on your desktop, and jRemote looks like a wonderful way to control it. If nothing else, download it from Google Play and have a look just to see how an app can be simple and beautiful at the same time. 

We heard from plenty of other developers who pretty much say the same things. We're just out of room here to list them all out. The gist of it all is that if you plan ahead, the Android developer guidelines really do work for most cases. We're glad to hear it, and will continue to enjoy great apps and support hard working developers.

 

Reader comments

Tackling 'fragmentation': Developers sound off on supporting multiple screens

40 Comments

Very nice article. It would be great if some of the large companies *cough*cough*Facebook*cough* would look at some of these design principles and apply them in their lackluster applications.

Design-wise, the Android Facebook app all that bad. Performance-wise, however... Add to that all the times they have put out an update that has *completely* broken the app. As of the last update, clicking a notification doesn't actually take me to that post, but just opens the Facebook app at the last thing I was looking at. And don't even get me started on the image loading.... Facebook's problems are functional, not design.

The main reason for facebook issues is that it is a HTML5 app. Facebook is rewriting it to be native, just like they did for iOS.

This was a good read and I didn't even mind the slightly thick pro-android snark. The one group absent from the above list of opinions is game programmers. Games are traditionally the biggest challenge to program (for any platform) and screen size/pixel density, cpu performance, input devices, etc. can make a huge difference and must be accounted for to avoid a terrible experience (since game mechanics are often based on a combination of all of that, plus underlying logic).

that would be pointless. games will/should be developed with opengl...which you specify your own working resolution and maps to your own images. you could certainly implement something similar, but it would be you manually implementing something that just comes naturally when using canvas/native app development.

It's good to hear from the developers themselves about how coding for android is different from other ecosystems. I have always been curious about how much more work it is to compensate for the plethora of screen sizes and resolutions on android vs. , for instance, iOS. From what I'm understanding, it is more work, but not that much work.

I suppose it is just that developers write for iOS initially and then attempt to port their project over to Android? Maybe if they developed for multiple platforms in unison, it would be more beneficial in the long run. I'm not a developer, so I don't know. Just a thought...

iOS and Android is comply diffrent in coding. iOS use more traditional programming that you see in desktop computers as it using standard native apps. In Android with Java fully use class based, Android app kind of reminds app as being part of thee system and it's just being called out (thats why Android have so much fell of app being integrated with system). Only people having easier to port is game developers because Android offers NDK allowing to run native apps and if your game does not use any system UI there less to work, as both systems offers OpenGL ES

Don't see how iOS would equate to "traditional programming" especially if you're going to say desktop. If you are writing for Windows then you are writing to an API that sounds more like your description of Android apps being a part of the system and "called out".

In the end its all code. Developer develop with APIs all day every day. Doing it for Android or iOS is no different. What causes this backlash at Android from iOS devs stem from a couple of things. I think iOS became popular and lots of people wanted to learn to make apps that probably had not done any development in their life before. So to them iOS is normal development and anything else is weird or hard. The other is that many of these iOS "devs" are really designers dragging and dropping their way to apps. They then meet Android where you need to be a real developer and they complain.

I dont think its difficult to make apps to adapt to different screen sizes at all. Its a few easy lines of code that will adapt the app to the screen size. To make the app even lighter weight, use vector graphics. They will re-size appropriately to any screen and still be sharp and light weight. The only time vectors wont work is when the graphic has to be photo realistic. Like it was mentioned in the article, developers have been doing this for desktops for many years and no one complained...until they had to do it for android.

Android does not support vector graphics on UI or else you hack it someway. But you can easy easy tool or even make script that with raster vector graphics for each screen density :)

Know what I mean, not what I say. I get tired of saying raster or throwing scalable in front of vector all the time. I mean, really, to get graphics for multiple screen sizes is not too big of a deal, especially if you have a high rez available, its quite easy to make lower rez ones.

Interesting article Jerry, thanks. This gives insight into what most Android Users probably had no clue about (including me).

Great read. Been wondering about his myself. Basically confirms that the "lack of tablet friendly apps" that everyone trys to use against android is just lazy ass developers.

As a web developer, I think it's cute when newbie phone app developers cry about fragmentation. Until you've learned to cringe at "We need to support IE7 and up", you don't know the pain of fragmentation.

Hehe i always been saying that Android suffers the same thing as web development ^^ good to see web developer to agree to that

LOL +1, sir.

I work for a IT department in a county office. Our project manager noticed one of the developers had used a table to get a 60/40% dynamic layout on a page and threw a fit. "We should be using display:table-cell!"

"Um. The client department has mostly old computers running IE6 and IE7, right? Well..."

Web developers are all snickering, at this point, at Microsoft's laziness in implementing CSS3 standards. Everyone else is probably just lost :)

Actually impelmenting new thing is not a problem and MS did a lot of catch up lately, true problem exacly it's same problem in which Android suffering.... slow migration process, number of users stack in IE6 and IE7 sometiems due there non-awareness and careness (which MS should deal about), sometimes not having other choose as you need to get better Windows to get better IE :> But major source is fact that IE unlike other browsers don't yell at user that browser is outdated. What is good if MS trying to implement something is users don't use it at all.

Microsoft has been trying to deal with it though. IE9 and IE10 have been major improvements, they made IE10 the default on Windows 8, they've been doing marketing campaigns getting the word out to people that they should upgrade. Microsoft has been doing plenty to encourage people to move on to more current versions of Internet Explorer. I think that leaves the blame on people who just won't upgrade, or people who just can't upgrade due to legacy software. In the latter case, there really isn't much Microsoft can do about it.

You couldn't be more right. I took a few web development classes in college, and just getting some things to work between IE and Firefox was a major pain in the ass. Fragmentation has been around for a long time, people just didn't realize it existed.

I'm an aspiring Android app developer and this was a great article. I've heard of and used some of the libraries that Christophe talked about and they really make it easy.

Graphics is really not a problem, you just make high resolution images or raster vector graphics to specific scales for each density and the rest is done by Android Recource system :)Bah latest SDK gives tools to scale graphics for you.

Screen size is really not much a fragmentation problem (i really don't understand why people still talk about it, Android is the best mobile system that handles that problem), at least not as fatal as Android's hell slow user migration processes which cause that lot of apps don't use post-Honeycomb APIs directly (Need of Sherlock or HaloEveryhere is proof of that)

A little off topic but related...

I was a visiting a start up incubator the other week that had a ton of app developers in it. Lots of people building.

I asked them how they were building for Android these days, given the fragmentation.... and the answer they gave was simple... "We're just building for Samsung devices we think will be popular". 

Surprising but brilliant answer from a developer standpoint... focus on the manufacturer that gets the most devices out there, and the resolutions they use. Gets you the biggest piece of the pie the quickest... then if you want you worry about other stuff.

"We're just building for Samsung devices we think will be popular"

Speaking as a dev (check out Shot Control), that view is totally wrong, and sounds like it was said by a developer without any real world experience launching a successful app.

If you only care about Samsung devices, you will end up with tons of really bad ratings from users of other devices...and those reviews will destroy any potential success your app may otherwise have.

My own personal strategy is to write to support everything well, but tune and tweak for the most popular devices.

I've never thought about it that way, but you really have a point there. We've had "fragmentation" for a long time with all the different capabilities and screen resolutions our desktops and laptops have. Most computer games give you a wide variety of resolution options. Most desktop applications adjust to different window sizes without breaking a sweat. If desktop applications could handle "fragmentation" just fine, why is this a problem on mobile?

Because as i said, screen sizes is not a real problem, Android can deal with it for you even without you thinking (or else made some crazy code), why do you think phone apps work on tablet? :p Real problem is 50% of user base stuck in Gingerbread that developer need to reach without breaking app.

Jerry - I know you know this but when people talk about Android and fragmentation, it's not about screen size. I'm talking about the fact that I still have to write to support 2.2 if I want to reach everyone. All the cool stuff in ICS and JB? Yeah, I can't code for that because so few devices have it. And while I'm writing in an old SDK, I have to consider that my app might run great on an HTC, but crash on a Samsung. You see what I mean? You know the hundreds of various of OS/manufacture/screen sizes there are out there for Android.

It's not the screen size. A properly coded app will scale and look fine on anything device. And it's not even Android itself. It's the manufactures "skins", and carriers not pushing updates. It's all the proprietary crap that phone makes add to Android.

I really wish Spotify would code its app to display differently on a tablet. I love Spotify and I think its phone app is great, but it's not such a great experience on a tablet. I like to plug my Nexus 7 into my stereo and leave it standing in landscape (using the case I have it in) on the top of my A/V setup. It would be nice to not have Spotify display sideways.

Seriously, thank you for that app.

Its been bugging me for ages, love the Spotify app and service and they really should allow it to rotate but this will do for the times I do need it in landscape for now :)

Awesome. Thanks for sharing this. Spotify is on the record for not caring about Android's Landscape capability. I hope this eventually changes, but their developers seem like an iOS weened lot that grudingly coded an app for the competing mobile OS.

webOS's framework Enyo is a nice option too.

I'm wondering, is it possible to use SVG pictures for UI images?

Clearly it's a problem for developers, yet go in the forums and there are many that act like everything's fine.

No. Developers can do better. Support them and they will.

I really think it comes down to developing for the devices you have access to and watching your users while they use the app you created. Be responsive to reviews. If people complain about a device you don't have a way to test on - be creative, find a way to reproduce the crash and it'll probably be easy to fix.

I forgot to mention it, but exporting graphics for all the various screen sizes is a bit of a pain. And now we've got xxhdpi too!