: How to prepare (what all sizes and resolutions) mockups and UI graphics for an Android app in PS I've seen similar questions asked here but they did not answer my question 100%. So please

@Samaraweera207

I've been designing for iOS for some time now but Android is totally a new thing for me. Android has so many devices at so many different resolutions and sizes that it is actually quite confusing to me at this point as to where to begin.


If you have a good workflow for iOS, you’ll be in good shape.

Pixel density

iOS has three main pixel density targets:


1× (non-Retina).
2× (Retina).
3× (Retina HD, which is iPhone 6 Plus only right now).


Android is really similar:


1× (not really used any more).
1.5× (not really used any more).
2× (xhdpi).
3× (xxhdpi).
4× (xxxhdpi, still reasonably rare, but on some high end devices).


So it's typically 1×, 2× and 3× for iOS, and 2×, 3× and 4× for Android. Very similar.

If you want to construct your documents in a way they'll scale up and down easily, you'll need to predominately use vector shapes and layer styles if you're using Photoshop. If you're using Illustrator… well, you probably shouldn't use Illustrator. It's great for creating print design and SVGs for web, but has some issues that mean it can be less than ideal if you're expecting to get PNGs as production assets.


Is it possible to create your elements for the highest resolution and then use some method to scale them down for other smaller sizes?


You should avoid bitmap scaling at all costs. It looks horrible — please do not create xxxhdpi assets as PNGs, then bitmap scale them down. You should scale the document while everything is still separate layers and constructed using vector shapes and generated effects (like layer styles).

I really like working mostly at the 1× scale. This means you have a lower resolution document, but everything scales up to 2×, 3× and 4× perfectly. Or, you could work at 2× and try to ensure everything lands on an even pixel grid etc. There's a few different approaches with pros and cons. If you've constructed your document well, you should actually be able to resize the document and jump between the display densities as needed.

Exporting


Or do we HAVE to do it manually and create them for each of the different sizes?


You definitely need to have multiple sets of assets for the different display densities, but there are quite a few strategies to automate the process a lot.

Generator is one way to do it: blogs.adobe.com/photoshopdotcom/2013/09/introducing-adobe-generator-for-photoshop-cc.html
I use slices, and build documents with all the assets laid out in a grid, so I can batch export, scale the document and re-export. It's a bit harder, but it means I get finer control over the process.


What are the best practises and ideal flow for any such multi-platform requirement. Is there a way to easily reuse the iOS graphic assets?


You can definitely reuse certain assets, but you should probably assume you'll have to remake most of the app in a way that's native to the platform. If nothing else, to take advantage of platform features, like Android's 9-patch images:
developer.android.com/tools/help/draw9patch.html
Physical size and aspect ratio

iOS uses Auto Layout to help cater for different sized devices. This means you can build a mockup for the iPhone 6, but with a bit of work, you should be able to get the same design to work for all iPhone sizes using Auto Layout in Interface Builder.

Android has a similar(ish!) system in the form of XML declared layout.

This may not be something you'll actually build, but you should be aware that you'll need to cater for portions of the app to expand, contract, hide or be shown, based on the device size.

Vote Up Vote Down

@Rivera951

Yes, and you should. Android Design Elements can be generated wit a 9-patch generator. A system where all resolutions are supplied based on one png.


The nine-patch generator allows you to quickly generate simple
nine-patches at different screen densities, based on the specified
source artwork.


Your design should be flexible enough to honor this system. But this is all very well documented, so repeating it here seems out of the scope: Android Design Guidelines

Also consider reading this introduction:


While I was working on my first Android app, I found 9-patch (aka
9.png) to be confusing and poorly documented. After a little while, I finally picked up on how it works and decided to throw together
something to help others figure it out.

Basically, 9-patch uses png transparency to do an advanced form of
9-slice or scale9. The guides are straight, 1-pixel black lines drawn
on the edge of your image that define the scaling and fill of your
image. By naming your image file name.9.png, Android will recognize
the 9.png format and use the black guides to scale and fill your
bitmaps.




As for Mockup Best practice:
Use the resolution of your test-device, or rather, in it's dp size (the MDPI or unmultiplied aspect ratio of the screen).

Vote Up Vote Down