Uh, no. There is no standard resolution on Android. You shouldn't make any assumptions about it. Build layouts that scale themselves and adapt based on the screen width & height in density-independent pixels.
> Fonts are unfortunately device-specific so better expect crappiness on some devices.
Fortunately, starting with 4.0 you can force the stock Holo theme in your app. Unfortunately, the manufacturer apps are stuck somewhere in the 2.x era and have completely alien user interfaces in comparison.
> In 2x, the minimum pixel dimension should be 28px for text, 96px for menus & header and 116px for the footer.
It's a bad idea to talk pixels in Android at all. Instead, use density-independent pixels (and the sp unit for font sizes which also scales with the global font size) which are calculated based on the screen resolution and size/density. As two examples, the minimum size for a touch button should be 48x48dp to ensure it's big enough to touch, and a 7 inch tablet is at least 600dp wide.
No, there are not. A 720p screen might be a de facto standard on many devices right now, but if you are designing your app for a couple of resolutions and not resolution independence, you are in for a world of hurt.
For example, the Nexus 10 has a 2560x1600 resolution. Flagship phones this year are expected to go 1080p (the same way they went to 720p from 800x480 which was the most common resolution in 2010).
There is no standard resolution. Don't count on it. End of story.
> especially when you use dp instead if dip
dp and dip are the same thing.
I will concede one big difference: a lot of designers work in Photoshop so they're dependent on pixel resolution. I do everything in Illustrator, so I rarely think pixels.
If I think about resolution in old terms of strictly pixels then yeah, I'd be lost. But since I do everything in vector format, I still do my basic phone layouts at 320x480 and then scale from there.
There's 6 resolutions: ldpi, mdpi, tvdpi, hdpi, xhdpi, & xxhdpi. Of these, ldpi is often skipped, and tvdpi is optional (the Nexus 7 and Google TV use it). The new one, xxhdpi is important for new 1080p phones like the Droid DNA and upcoming Galaxy S4.
Resolutions are multiples. It's easiest to remember them as 48, 64, 72, 96, 144 (these are the sizes of your app icon). xhdpi is 2x mdpi. hdpi is 1.5x mdpi. tvdpi is 2/3 of xhdpi. xxhdpi is 3x mdpi & 1.5x xhdpi.
It's not pixels, it's usually dp (density-independent pixels) which are based on mdpi. As such, it's a good idea to design layouts at mdpi scale - it just makes it easier to match your dp values. I lay out for 320x480 and 1280x720.
I wrote a detailed blog post on 9-scale (http://radleymarx.com).
For most Nexus devices, the Action Bar is the only access to the Overflow Menu (aka the old Options Menu). So although it's only "recommend" to use it, there's no way to use the menu without it.
Fonts can be specified in the layout XML. You just need a custom TextView class. Note: widgets won't let you use custom class layouts. Fonts are added in the assets folder of the project. Some devices are picky about how you name fonts so it's best to name them as lowercase-name.TTF (uppercase file type).
Most often you'll want to match font sizes that other apps use. The minimum font size you can clearly get away with is 10sp on phones & 11sp on tablets. Users can change text scaling in their device so you should use sp instead of dp for text. If you don't want it to scale (i.e. a decorative layout) you can use dp instead.
The best way to design for devices is to buy one of each screen type. Some groups start a pool of devices to share for testing. For widgets I design for GS3 & GNexus simultaneously, along with a Nexus 7. When the layouts are complete, I start checking on other devices.
Widgets are a different matter. Suffice to say the big difference there is between Samsung/HTC who displays full-sized widgets and Nexus/Motorola/Asus who force widgets to use way too much padding.
The "up button" description is a bit oversimplified but probably sufficient for an intro to design post.
Also fonts aren't exactly "device specific" as stated in the post. You can embed your own TTF or OTF fonts into your app as a resource and use them. There are some annoyances to doing this (particularly when viewed from a designer's standpoint, so I'll let the article slide on this one) like the XML layouts won't recognize these fonts but you can programmatically assign the embedded fonts to Android's various text controls very easily.
Of course the hardest part as always when dealing with fonts is the licensing which is slowly getting better but remains years behind the licensing of other digital media formats.
Also on the issue of fonts, he mentions that Droid Sans is popular (since it was previously the default system font) but he should probably have mentioned Roboto, which is the newer and IMO much nicer default font, which is also freely downloadable, the entire set of Android fonts are available for use under the Apache license and can be used freely even in non-Android contexts.
Also, can you elaborate on the "up button"?
At this point if you click the back button you will be returned to the browser session you were previously viewing. If, however, you were to click the up button instead you would remain inside your mail app and go “up” from your message to the inbox.
If I'm in the browser and click a mailto link, it opens the email client. The 'up' metaphor should return me to the inbox. The 'back' metaphor would return me to the web browser/webpage. (Did not realize I was using the exact same metaphor as my sibling, sorry)
Similarly, he has the density classes wrong. There's XXHDPI, XHDPI, MDPI, and LDPI and they don't correspond to set resolutions. It's recommended by the Android Developer blog to actually change layouts based on a certain DP width (DP being a density independent pixel that normalizes measurements across density classes) rather than do x sizes of the same screen for each density. E.g. so screens with a lot of pixel real estate across get an extra list on the left, things like that.
Custom fonts are a problem, but there's a nice way to implement them (backwards compatible and all), and when you do it once, it will always be very easy. I don't have a code example nearby, shoot me an e-mail (in the profile) if you are interested, and I'll make sure to get a proper answer to you.
> Finally, if you respect their guidelines, all actions should be on the far top right. That includes functions like Refresh (because Pull to Refresh is extremely uncommon on Android)
Pull to Refresh feels really out of place in an Android app, don't use it! Most apps do not, but Twitter apps seem to be the exception, for obvious reasons.
I wish Adobe would make a 9-patch tool that works with their stuff. draw9patch isn't that good.
Fonts are a true point of pain in Android dev.
Font rendering on Android is bulky, blocky, and fails to consider how humans read letterforms. So, even if a designer can convince the team to license a better font, it’ll end up a smeared mess on users’ screens.
The API calls to layout type on Android suck. (iOS sucks slightly less depending on how willing your UI engineer is willing to devote to this most basic foundation of design.)
“U MAD, BRO?”
Yeah. I get paid to be a picky snob about what the user sees and how they feel about the product. It pisses me off to look at Android because its not disappointing, the way Win8 is, but actively anti-design. Why pay to license good fonts? Why make a system for rendering type nicely? Because this stuff is basic user experience. It's like going into a hotel and discovering that the paint is yellowing. That hotel is more likely to have dirty towels, no hot water, smelly sheets, and bed bugs.
I like Roboto, but what do you find to be bad about those fonts?
> Font rendering on Android is bulky, blocky, and fails to consider how humans read letterforms. So, even if a designer can convince the team to license a better font, it’ll end up a smeared mess on users’ screens.
This isn't really true when setting custom typefaces on various views. Just subclass them and set up the typeface in the constructor and you are done. You just end up using that subclass your in layouts instead of a standard TextView.
> It pisses me off to look at Android because its not disappointing, the way Win8 is, but actively anti-design.
I'm not really sure what you mean w.r.t to text. The text views and code cover most use cases and offer ways to handle flowing text in some cases, but you can always fall back to WebView rendering text content (which is easier for writers or editors to handle when making the text content).