Develop Reference

Android Element Positioning in an Overlay Activity

I have an idea for an application for Android. I have a decent background in Android but I have never encountered a problem like the one I am currently facing.
Background
I am creating an overlay activity on top of WhatsApp. When you launch WhatsApp a red circle shows on the overlay activity and it needs to be entered exactly above the "new chat" button in the latest version of WhatsApp (Android Lollipop).
This is easy when positioning with DP on a specific device but this circle will not be in the correct location if I test the app on my LG G3.
The obvious answer is that I would create a xxhdpi layout too, but the problem is that this circle needs to be dynamic, so if I want it to be above the search button, it needs to be there.
Question in a sentence
My question is based on margins in DP on a specific device, how can I make sure the circle appears in the exact same position on all other devices that have the same version of WhatsApp?
Example: On Note 3 (1080p, 388 PPI) margin right is 30dp, How do I use the resolution knowledge and DPI knowledge to make the circle appear in the same place on my LG G3 (1440p, 538 PPI)
What I have tried
Firstly the dumb approach at positioning it correctly on phone one with dp and running on phone two (Failed)
Second I tried positioning according the width of screen in pixels times a percent (I.E. screen_width * 0.75) so the circle will appear always at position x 75% of the screen (Failed due to screen density? 1)
Thirdly I tried the same approach as my second attempt but instead of raw pixels I used the total screen DP and used that as my relative measure (I.E. screen_width_dp * 0.75) so the circle will appear always at position x 75% in dp of the screen. (Failed 2)
Notes
In all tests I made sure that the units I am working with are correct, for example if I had screen_width_dp x 0.75 I made sure to convert the DP into PX before setting the margins.
1 - Why would this fail? using screen resolution ratios.
2 - Why did this try fail as well?
This was tested on Note 3 (1080p, 388 PPI) as base phone, and LG G3 (1440p, 538 PPI) as secondary phone that the circle should move relatively to be placed correctly on.
Thanks!

9-patch with two stretchable regions doesn't work appropriately

I've a 9-patch image which contains 2 horizontal stretchable areas and 2 vertical stretchable areas like this. It looks good in draw9patch and the emulator.
Unfortunately it becomes strange in real devices, I tested it with Asus Nexus 7 (Android 4.4.3) tab and Sony Xperia Tipo ST21i (Android 4.0.4) phone. This is a view set that drawable as the background.
Why does this happen and how to fix this?

I suspect this was because of scaling of the base image to adapt screen density. The image in the question is for hdpi. Widen the stretching area from 1 px to 2 px solved this problem, but it is strange that the circle is not center aligned in Asus Nexus, it is slightly to the right than it should. However it looks fine in Sony Xperia (centered).
So, I still wait for another better answer.

Sizing widget equally (xml approach only)

I have one problem with UI widget sizing, see 2 devices below as an example,
1.) Samsung Galaxy Tab 2 7"
- Pixels : 1024x600 (mdpi)
- DPI : 160
- Density : 1.0
2.) Samsung Nexus 10 2013
- Pixels : 2560x1600 (xhdpi)
- DPI : 320
- Density : 2.0
If I place a widget with 50dp, by using px = dp (DPI / 160), it would be 50px for Tab 7" and 100px for Nexus 10. But in term of percentage, 50px is equal to 4.88% of screen width on Tab 7" while 100px is 3.9% of screen width on Nexus 10.
But, I need this widget to appear with same width percentage. So, I came up with 2 options.
A. Calculate at run time by getting the physical pixels and apply percentage, then resize the widget.
B. Calculate size and place in < dimen > in different xml file (sw600dp and sw700dp for my case).
As of now, I'm using option A to calculate size and set at runtime. It works well but I'm afraid that the calculation could affect the performance. If I choose option B, I will need to calculate size for every widget in every screen (50dp for Tab 7" and 62.5dp for Nexus 10 will result as 4.8% on both). But, if I want to change this value later or some manufacturer introduce new device with difference DPI or pixels (imagine, 7" tablet with hdpi resolution, 1.5 density, 240 DPI), I will have to redo all the calculation and update or provide new xml again.
So, my question is, is there an option C which will not slow down the performance and not taking a lot of manual calculation into account in future?
P.S. Sorry, I forgot to mentioned that I also using weight approach with my static widgets already, but my question is about dynamic-generate widget. For example,
a gridlayout that showing 5 columns on Landscape Tablet
a scrollview to show 4 rows per page on Phone
an ImageView with 5% padding
an ImageView with an aspect ratio on every device.

dp are almost equal on all devices in size, not in screen %
If you need same screen % then just get display size & calculate desired % of it. Then dynamically apply to your widget

How to make wallpaper image for android tablets

Now I'm making wallpaper image for android tablet devices like Motorola Xoom or Galaxy Tab.
In android phones, typically wallpaper image size is 2 * screenWidth x screenHeight, but in Motorola Xoom it doesn't seem right because it automatically centered and scaled in weird way.
Is there anyone who knows about the exact image size for these devices or mechanism of wallpaper manager?
Thanks

If you have a Super TFT screen like the newer HTC phones, your phone has good (not great) black levels, sharp lines, and fairly good colors. Something with some black will be good, but don’t overdo is as you might notice some bluish tones when the brightness is cranked up. You can however do more intricate images thanks to the high sharpness of the screen. For regular LCDs, just avoid a lot of black and it should look fine.

Ideally,
the Height of the wallpaper should match with the height of the device (or some multiple)
the width can be anything more than the width of the device (keeping the aspect ratio and point 1 in mind)
The android launcher will automatically center the image and then divide the image across all its home screens, let us illustrate this with an example:
Say if there are 3 homescreens, the screen will focus at the center right away and if you flick towards the left or the right, it will scroll to that screen. In other words it the homescreen wallpaper will move 2 times.
(Taking that logic forward, if we have 5 screens, we will be able to move 4 times, if there are n screens, one is able to move n-1 times!)
This is how the formula works:
device_screenwidth + (number_of_homescreens - 1) x distance_moved =
image_width
Say we have an image with height = 800 pixels and width 1280 pixels, applying the formula
=> 1280 + (3-1) x distance_moved = 2000
=> distance_moved = (2000-1280)/2 = 720/2 = 360
in other words, the central 1280 pixels of the walpaper are displayed first, but every time you flick left or right the walpaper shifts by 360 pixels at a time.
This is how the wallpaper is displayed over the 3 screens:
screen 1: 0 to 1280 pixels
screen 2: 360 to 1640 pixels (1280 + 360) (This is the default home screen)
screen 3: 720 to 2000 pixels (1640 + 360)
That is how an image/wallpaper with a width of 2000 pixels and a height which is the same as that of the device (800) is mapped across 3 home screens on a device with a resolution of 800x1280 pixels

Android: how to draw an ImageView with the same size regardless of device?

I want to put a toolbar in my application. The toolbar will use ImageViews as application buttons. I would like the ImageViews to be the exact same size regardless device; by "same size" I mean that, when rendered to the screen, if I measure them with a ruler, the dimensions will be the same. I would like this size to be ~10mm (the width of my index finger).
I have been completely unsuccessful in accomplishing this.
I am testing on a MDPI, large screen Acer Iconia Tab and a HDPI medium screen Samsung Galaxy Tab. If I set layout_width="50dip" and layout_height="50dip", the buttons render as ~10mm on the Samsung, and ~8mm on the Acer. If I set the buttons as layout_width="12mm" and layout_height="12mm", they render as 12mm on the Acer and ~9mm on the Galaxy (confusing that 50dip renders bigger on the Galaxy than the Acer, but 12 mm renders smaller on the Galaxy than on the Acer).
If I place a 32pix x 32pix icon in my drawable-mdpi folder (and no equivalent in the drawable-hdpi folder), and set layout_width="wrap_content" and layout_height="wrap_content"; the results are similar to if set to 50dip, the Samsung is about 10mm, the Acer about 8mm. If I add a 48pix x 48pix icon to my drawable-hdpi folder, there is no change; presumably because the Acer still uses the mdpi icon and the Samsung uses the bigger one, but scales it down by 50% because it knows its hdpi (if am confident that this surprising scaling occurs because if I move the 48pix icon to the mdpi folder, and have nothing in the hdpi folder, the icon shows very large on the Samsung).
I am confused and could really use advice. How do I make my button fingertip sized regardless of dpi and screen size?

Ok, I finally figured out what is going on:
The problem is that a image button who's width is specified as 10mm,
shows as about 7mm on my Galaxy tab, and about 9mm on my Iconia Tab.
There are 2 reasons for this rather significant difference:
The Iconia Tab reports its xdpi as ~160, when its actual xdpi
is ~150.
Honeycomb uses a new drawable for its button background, with
significantly smaller margin than the drawable in Froyo.
Issue 1 accounts for about .6mm of the difference, Issue 2 accounts
for the remainder. Issue 2 can be solved by choosing one of the two
backgrounds, packaging it with the application, and specifying it as
the background for the ImageButton. Issue 1 cannot be resolved, but the difference it creates is relatively minor once issue 2 is dealt
with.

You have two basic approaches:
Use supplied resource indentifiers - hdpi/ldpi/etc - and just rely on the OS.
Use xdpi/ydpi in DisplayMetrics class. They are supposed to return the exact physical pixels per inch and scale the image manually with a corresponding scale factor. This, of course, will slow down performance. What is more - I am not sure whether these readings will be correct.

Did you try stuff in the no-dpi resource identifier. Honestly I'm not sure what you would get out of this but it's worth a shot.