I am not sure whether this is possible in Android which supports multiple form factors on various devices. This is one of the most painful scenarios which we usually face.
Scenario: A design team creates UI graphics for the application with all the UI widgets with their position pre-defined like buttons, edittext and so on. This is the UI which we need to use in our application.
Problem: There is no way to link UI widgets, for instance a submit button over the actual position of submit on the image. Is there a way to link them? And will it work on all form factors?
Current solution: Recreate the entire UI with all its component from scratch using layouts.
As I know in iOS, one can actually put the widget over the top with transparent background and it works out of the box. This is possible as you can play with absolute values of x and y.
I guess it was not so clear from the above description.
The issue is not which Android layout to use as that essentially means creating the layout from scratch using components using either LinearLayout or RelativeLayout.
The real issue is when we are receiving a UI design from designers who know nothing about Android or its platform apart from the standard screen resolution say 480X800, what should be our advise to them? Something like give me a design with all the components as layers which can then be extracted and used in Android layout from scratch.
Ok, now with the clarification on your question, maybe I can share some experiences.
Little story: I sent our designer to the Android UI Guidelines (http://developer.android.com/guide/practices/ui_guidelines/index.html) but he either didn’t had the time to read it or he didn’t care about it! Ha ha ha! Man… we had a hard time with the first App because of that!
It is true that at the Android Web Site there is a lot of information about how to do the design, but is scattered all over the place (a way to find information, that maybe only we, the Developers are used to right?).
So here are my suggestions, based on what I’ve got from the Android Web site and experience:
- Make a Story Board of the App to define the basic look, where the UI
controls will be, etc.
- Because an App needs a good launcher icon, first send to your
designer the Templates for Icons on the Android Web site
- Sit down with the Designer (or do a Skype meeting) and make sure
him/her understands all about densities, ldpi, mdpi, hdpi, and xhdpi
and the difference between PIXELS and DPIs. Make sure he/she
understands that very well to avoid future problems. (See
- Ask them to work with Vectors, because you will need 3 different
sizes for every resource.
- Explain them the naming conventions and folder structure. Ask them
to name the files using the ic_ prefixes and to save things on
its appropriate place. They can use Photoshop features such as
automated tasks to save the resources in different sizes on the
right folder, then send you a zip file with the resources.
- The guidelines recommend designers to work with mdpi resources
first, an then get other sizes to test.
- Ask your designer to create a “Functional Prototype” of the App. If
he/she worked on Photoshop, there are ways to use Dreamweaver to
export the design to an actual web site you can browse and go
through the Activities. And you can have a download page to download the complete set of
up to date resources on their correspondent folders as a zip.
- Tell them that Android uses styles and themes that are similar to
CSS, and that you will need colors in HEX. Ask for a document with
the colors for gradients, etc (you can use EyeDropper on Chrome or
CollorZilla on Firefox to extract them from the Functional Prototype
- Create a lot of different devices on the emulator with different
screen densities and sizes.
Finally, there is no “magic formula”… sending emails or even examples won’t work sometimes… the best thing you can do is to dedicate some time to get on the same page with your Designer, that investment of time will repay itself very quickly.
What I’ve mentioned here has worked for us, and believe me… I’ve changed the whole look and feel of the App and it looks really nice and let’s say that 99% like the design itself.
Good luck (and patience)!
I feel you. However when we need to understand and probably appreciate that iOS is available in only so many screen sizes. Android on the other hand is not. When designing for the android, it is imperative that we do not make any assumptions about the pixel sizes otherwise life is going to get more complicated. It is best to remain size agnostic, use relative sizes. It is similar to the process of designing html pages which can be displayed in any size.
Also, show them how .9.png images work and how they can create those images.
It saves you a lot of time, if you don’t have to create the images yourself. Additionally, designers tend to be much more creative with the possibilities of 9 patches.
It’s possible with AbsoluteLayout
But it’s depretated.
It’s not ideal to have fixed layout. You may design it, maybe one portrait and one landscape version, yet there’re still various aspect ratios of screens, so either you’d clip and have something cut, or fit to screen, and get empty edges in one direction.
I’ll suggest the use of a RelativeLayout.
With relative layouts you can “refer” to other components using their @ids and tell them to be above, below, toRightOf, toLeftOf of other UI components at the same level (inside the same RelativeLayout) and you can align them to it’s parent View’s Top, Bottom, left or Right.
The venue_row.xml, a layout file that I created for a row on a list:
<ImageView android:id="@+id/image_view_venue_row_thumb" android:layout_width="48dp" android:layout_height="48dp" android:scaleType="fitCenter" android:adjustViewBounds="true" android:src="@drawable/ic_default_map" android:background="@drawable/image_place_holder" android:layout_alignParentTop="true" android:layout_marginTop="4dip" android:layout_marginLeft="4dip" android:layout_marginRight="6dip" android:layout_gravity="center_horizontal" /> <ImageView android:id="@+id/image_view_more_arrow" android:layout_width="18dp" android:layout_height="18dp" android:src="@drawable/ic_view_more" android:layout_gravity="center_vertical" android:layout_centerVertical="true" android:layout_alignParentRight="true" /> <TextView android:id="@+id/text_view_venue_row_distance" android:text="0.5 Miles" android:layout_width="75dp" android:layout_height="wrap_content" android:minWidth="44dp" android:maxWidth="44dp" style="@style/VenueRowDistance" android:layout_centerVertical="true" android:layout_toLeftOf="@id/image_view_more_arrow" /> <TextView android:id="@+id/text_view_venue_row_name" android:singleLine="false" android:focusable="false" android:layout_width="fill_parent" android:layout_height="wrap_content" android:gravity="left" style="@style/VenueRowName" android:layout_toRightOf="@id/image_view_venue_row_thumb" android:layout_toLeftOf="@id/text_view_venue_row_distance" android:layout_alignParentTop="true" /> <TextView android:id="@+id/text_view_venue_row_description" android:singleLine="false" android:focusable="false" android:layout_width="fill_parent" android:layout_height="wrap_content" android:gravity="left" style="@style/VenueRowDescription" android:layout_below="@id/text_view_venue_row_name" android:layout_toRightOf="@id/image_view_venue_row_thumb" android:layout_toLeftOf="@id/text_view_venue_row_distance" />
That will produce a layout that will remain consistent no matter what orientation or screen size you may have.
Hope it helps.
The best solution to this problem is a Linear Layout.
What I do in these cases is to have nested Horizontal Linear Layouts within Vertical Linear Layouts, and adjust the positions using weights, surrounding my actual button control by blank TextViews.
Depends on what you are developing – if you develop game or something else with full custom design, there is no special guidelines, but if you want use standart controls, here is som useful links:
i vote GLes 1.0.
most target audience, easiest to grok and most familiar code. most programmers dream in vertices, indexes and faces thanks to the rich kids.