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
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 have created a demo application in Android using Nexus 9 2048 X 1536
I have added an EditText and assign width as 1000dp it is working fine in Nexus 9 Emulator. But When I change the Emulator as Nexus 5X 1080 X 1920 to test the dp purpose, Then the EditText goes out of the layout and shown about half of it.
Why it is happening even I assign the width in dp. It should adjust the width by screen-resolution.
It should adjust the width by screen-resolution.
No, it does not. dp will adjust the width by screen density, not screen resolution. You asked for it to be 1000dp wide, and so it will be 1000dp wide, regardless of screen resolution or screen size.
You have a few alternatives:
1) The right and recommended one is to make different layouts for different screens. For this alternative see Supporting multiple screens
2) Another alternative I used to use before ConstraintLayout was to make everything proportional. When the app starts I take the meassurement of the Display and layout everything based on that. This is done mostly programatically not using the xml layout file.
3) Use the new ConstraintLayout from the support library. Using this layout you can constraint your widgest relative to each other and or to guidelines you can add to your layout to delimit sections of it. Your widgets that need to adapt will mostly have a width of 0dp or wrap_content and the constraints will take care of resizig them accordingly.
Using ConstraintLayout
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
I'm trying to create an appwidget that has a standard size of 4x2 tiles.
Currently, I'm using these values:
android:minHeight="146dp"
android:minWidth="294dp"
On my Desire running Gingerbread, the widget shows as 4x2.
On my Asus TF101 tablet running ICS, the widget gets a size of 4x2.
Finally, in an emulator 720x1280 running ICS, the widget gets a size of 4x3.
So I'm a bit confused here. What are the correct values (perhaps using different resource folders) to achieve a 4x2 widget on all devices?
I've found that working on approx. 72dp x 72dp per 1x1 works best. So for a 2x2 widget I would normally use 144dp x 144dp, however google recommends 110dp x 110dp.
This page from Google gives a better description of what size to use and how to calculate it:
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
According to google guidelines you should use this formula : 70 × n − 30
For a 4*2 widget that means you should use 250dp * 110dp.
More infos : http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
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.