It might be me, but when I calculate minimum app widget sizes according to the formula given on the android page I don't get the right widget widths; The formula is as follows:
width(n) = (70 x n) - 30
When I want to have a 5x1 widget, the correct width would be (5 * 70) - 30 = 320dp. However when testing this on a motorola Xoom it resolves to being a 4x1 widget. I've tested different values and 400dp seems good for 5x1 on the motorola xoom with Honeycomb, but then I'd test it on a regular Galaxy Tab with Gingerbread and then it resolves to a 6x1 (like one would expect).
So two questions here;
What difference between Gingerbread and Honeycomb am I overlooking?
Since I know ICS widget size no longer has padding between widgets, is there some rule of thumb here as well?
In my 4x1 widget, I used these dimensions for res/values/dimens.xml:
<!-- size = (74 x n) - 2 -->
<dimen name="appwidget_margin">0dp</dimen>
<dimen name="appwidget_min_width">294dp</dimen>
<dimen name="appwidget_min_height">72dp</dimen>
and for res/values-v14/dimens.xml:
<!-- size = (70 x n) - 30 -->
<dimen name="appwidget_margin">0dp</dimen>
<dimen name="appwidget_min_width">250dp</dimen>
<dimen name="appwidget_min_height">40dp</dimen>
I used widget templates pack for background images .
In official guide there is written that default margin in res/values/dimens.xml should be 8dp, but if I use 8dp, my widget is smaller than standard widgets on the desktop (google search, weather etc.). Thats's because margin for v1-v13 is built in the background image:
I tested it on HTC Desire, Nexus S, emulator Android 2.2 and emulator Android 2.3.3. With the templates pack backgrounds and configuration above, my widget's size is the same as other standard widgets and looks good on all devices I tested.
There is also problem with various launchers. I recommend this article to read: http://radleymarx.com/blog/app-widget-padding-margins-in-ics-android/
Not too many devices fully follow Google's advised formula. You're better off using several xml-xxx folders that can specify more accurate minWidth & minHeight that correspond to the varying screens & OSes.
Right now I four solely based on OS:
xml // standard
xml-v11 // Honeycomb grid
xml-v14 // ICS's new extra padding
xml-sw552dp-v14 // ICS tablet padding
But as I fine tune, I may have to add a few new folders for particular dpis or screens.
Quick update:
Only some devices use automatic padding. Samsung & HTC have custom UIs that use full-width widgets, so they override the OS padding on their launchers.
In ICS there isn't no padding, there is automatic padding. And the formula that you used is for ICS.
For older versions there is another formula:
num*74 - 2
note: if you target pre-Honeycomb (or don't specify targetSdkVersion while specifying a minSdkVersion prior to honeycomb) then the honeycomb grid (and ICS grid) calculations don't take effect. Downside of this is you miss out on newer OS features, but if you don't actually need them then keeping target pre-honeycomb will save the hassle of customised xml folders.
Related
Currently, I'm developing Android app (phone only) and using only one size for different screen sizes, ie:
dimens.xml:
<dimen name="button_size">48dp</dimen>
<dimen name="text_size">16sp</dimen>
so in different screen sizes, we have only one size for components. And we go to this result: in small device, a textview can contain 10 chars but in larger device, a textview can contain 20 chars
And some developers use a gradle script to generate multiple dimens files in different folders based on the main dimens file like this:
values-sw320dp
dimens.xml:
<dimen name="button_size">48dp</dimen>
<dimen name="text_size">16sp</dimen>
values-sw480dp
dimens.xml:
<dimen name="button_size">52dp</dimen>
<dimen name="text_size">20sp</dimen>
...
so the system will use the dimens based on device size. And we go to this result: in small device and larger device, a textview can contain the same char, ie: 12 chars.
My question is: which one is better for UI, UX? (using Google Material Design)
You can use this library to support multiple screen dimen here
You can try this below, this will set automatically based on device.
?android:attr/textAppearanceMedium - For Medium font
?android:attr/textAppearanceSmall - For Small font
?android:attr/textAppearanceLarge - For Large font
Please check Material guidelines, To ensure usability for people with disabilities, give buttons a height of 36dp and give touchable targets a minimum height of 48dp.
Best practice is to use different dimens file for different devices. This will help you application view to be same across devices. If you keep same dimens for different devices then layout problem can also come. In some devices your layout will look perfectly fine but in another it will look very bad.
Android developer site also recommend to use different layout for supporting different devices.
I am using eclipse with the ADT.
For the activity I am using portrait view only and thus want to use the h<N>dp xml qualifier to specify a minimum available height for the layout.
When I name my folder layout-h641dp and choose the Galaxy Nexus (640 x 360 dp) device from the drop-down then Eclipse auto-chooses the lower layout-h450dp as expected.
When I rename the folder to layout-h640dp then I can view the layout with the Galaxy Nexus, but it shouldn't since the available height is only 519dp plus 48dp (for the action bar) = 567dp (see the image) and google states at Supporting multiple screens that
Note: The sizes that you specify using these qualifiers are not the actual screen sizes. Rather, the sizes are for the width or height in dp units that are available to your activity's window.
and
Also beware that the Action Bar is considered a part of your application's window space, although your layout does not declare it, so it reduces the space available for your layout and you must account for it in your design.
I am thus not allowed by Eclipse to design on the correct layout that will actually be chosen by the physical device.
When actually testing on a Samsung Galaxy S3 (also 640 x 360 dp) using layout-h616dp the Android system uses the lower layout-h450dp layout, which is correct according to the Google docs, and when I then rename the layout-h616dp to layout-h615dp the Android system chooses layout-h615dp for rendering which is as expected, since the available space is about 640dp (total) minus 25dp (for the status bar) = 615dp.
My question: Is this a bug in Eclipse and if so, is there a workaround so that it is possible to design properly on the correct layout?
EDIT: To clarify, in a nutshell, Eclipse uses the total screen dp whereas when actually running the app the Android system uses only the available 'dp' (as it should).
My BlackBerry Q5 can run Android applications and I'd like to optimize one of my existing apps for its screen. The resolution is 720x720, but the runtime also inserts a bar in the bottom of the screen, so usable resolution for Android app is 720x620 pixels, so I guess that's what the phone reports to Android app as the resolution.
Is there a way to make a layout that will apply only to 720x620px screens? The documentation for supporting multiple screen sizes says that there are w<N>dp and h<N>dp qualifiers, but they use scaled dp units and also means minimum available width in dp units, so they would not be useful in here.
I needed to solve your problem too, this is my solution.
The Q5 and Q10 screen density is xhdpi (scale factor of 2.0) so max screen size is 720x720px / 2.0 = 360x360dpi
Quoting from the documentation, Table 2, "Available height" row:
Specifies a minimum available screen height, in "dp" units at which
the resource should be used
[...]
When your application provides multiple resource directories with
different values for this configuration, the system uses the one
closest to (without exceeding) the device's current screen height.
[...]
Added in API level 13.
Based on these, for Androids with API>=13 (including Blackberrys) you can put your Blackberry specific layout in "layout-h240dp" folder and all the others in "layout-h361dp"
Blackberry height is greater than 240dp and less than 361dp, so it will use layouts in h240dp folder.
Notes:
- If you don't add the 361dp folder, the 240dp folder will be used for every device with height greater than 240dp.
- I choose 240dp because it is a common minimium dimension for today devices.
- 309dp should work too as it less than 310dp (minimum height of BB's screen with bars)
- For Androids with API<13 you have to put a default layout in the generic "layout" folder, because the previous "h*dp" folders are ignored. if default layout is missing, the app should crash.
I don't mean to turn this into a full-blown answer, but I need the extra space.
For your assets, if you'd like to target them specifically for Q5 or Q10 devices, place them in the drawable-square folder. This changed from drawable-small-square due to deprecation.
If you plan on deploying to OS 10.2.1+ devices and don't want that back-bar to show by default, you can add a small configuration file to your app so that the system knows not to show it.
For more information on that, take a look at my blog:
Android Developers: Eliminate the Back-Bar in Your 10.2.1. App
[Update] Thanks Kai, this issue is caused by #dimen/activity_vertical_margin in XML. The default value of dimens.xml is 128dp in values-sw720dp-land. (others are 16dp).
I create a new empty project, and run it on Android 4.2 and 2.3 (with Xlarge screen 10.1" WXGA 1280 x 800). Here are the screen capture. Why does "Android 4.x" and "XLARGE" screen cause the content indention?
(Android 2.3)
(Android 4.2)
Besides using the Xlarge qualifier for layouts you also can use version numbers. I'm not sure why it would be different if it is the same resolution and screen size but you can also use version qualifiers for your layout folders.
So, you could have one that is in res/layout-v15 (4.x) and one in `res/layout-xlarge(since its working in 2.3)
This should make devices with 4.x use use the layout-v15 and anything below with the appropriate screen size would use layout-xlarge. I don't know if this will take care of all your problems but it may help.
It looks like a very larg marginLeft and marginRight is applied to the 4.x version of the dialog:
You should check your XML and image resources to see if different margin is applied for different API level.
Users of my Android app report that the included app widget is too big.
I've used this formula:
width/height = (number-of-cells * 74) - 2
So I got 294dp width and 72dp height for a 4x1 widget. But, as I've said, users report that the widget takes more place than 4x1.
How can this happen? Does it differ with different Android versions?
Edit: I've set this as the minimum width/height and the resize width/height. My layout file for this appwidget uses fill_parent so it should not extend that size.
This documentation page (relevant for Android 4.x, I suppose) shows that the formula is:
width/height = `70 * n - 30`
... where n is the number of cells taken. It also mentions that...
When your widget is added, it will be stretched to occupy the minimum
number of cells, horizontally and vertically, required to satisfy its
minWidth and minHeight constraints
Based on the dimensions given in the question, your application would stretch to 5 cells (320dp; 250dp is not enough) width-wise and 2 cells (110dp; 40dp is not enough) height-wise.
To support different widgets for different Android versions is quite simple.
For supporting Android version >= 4.0, you have to put your widgets stuff in the right folder.
/res/xml-v14
/res/layout-v14 [optional]
-v14 means the API-Level 14 (Android 4.0). Android version higher or equals 4.0 will use the files in these folders. Don't forget to calculate android:minWidth and android:minHeight using the correct formula:
cell_size in dp = 70 × n − 30
You can leave your working widget in the existing folders:
/res/xml
/res/layout
Using the correct forumla:
cell_size in dp = 74 × n - 2
To keep it simple and reuse the calculated dimensions you can also create the correct dimensions in the correct folder and reference to the size.
Create a file /res/values/widget_size.xml containing the dimensions for Android version < 4.0
<resources>
<dimen name="cell_size_1">72dp</dimen>
<dimen name="cell_size_2">146dp</dimen>
</resources>
Create a file /res/values-v14/widget_size.xml containing the dimensions for Android version >= 4.0
<resources>
<dimen name="cell_size_1">40dp</dimen>
<dimen name="cell_size_2">110dp</dimen>
</resources>
Reference the size of the widget to the new created dimensions.
android:minWidth="#dimen/cell_size_2"
android:minHeight="#dimen/cell_size_1"
Unfortunately this does not work on my Galaxy Tab 7.7 running Android 4.04. A 3x1 widget is 2x1, although it shows the correct size on the emulator. I assume it is because of
While the width and height of a cell—as well as the amount of
automatic margins applied to widgets—may vary across devices, you can
use the table below to roughly estimate your widget's minimum
dimensions, given the desired number of occupied grid cells:
stated at App Widget Design Guidelines