The Android SDK recommends the use of
ViewConfiguration.getScaledTouchSlop()
for detecting if the finger on the touch screen has been moved. According to Android, the ScaledTouchSlop depends on the device, and with that upon resolution and screen sensitivity.
I have written a view where the user can use Canvas for painting on the screen, and I have realized that painting works differently well on different devices. Further investigation showed that ScaledTouchSlop seems to be defined by the device manufacturer and varies a lot between manufacturers. For example
The ASUS Memo Pad 7 has a ScaledTouchSlop of 11 pixels on a 7 inch screen with approx. 1280x720.
The Samsung Galaxy Note 2 has a ScaledTouchSlop of 32 on a 5.5 inch screen with approx. 1280x720.
Both screens have about the same resolution, so when looking at the ASUS device, I would have expected ScaledTouchSlop to be around 14 on the Samsung device (11 pixels * 7 inch / 5.5 inch), but it is 32. This results in not being able to fluently draw on the Samsung, as smaller strokes are often not recognized.
Sure, I can just define my own "slop" for drawing, and if I do drawing works perfectly well, also on the Samsung device. But I guess that would cause trouble on other devices, which are smaller or have a less sensitive screen.
Is there are a way how the touch slop should be calculated for drawing or does anyone have a recipe that works well on all devices?
Related
I'm having an issue with getting all the fields to fit on an 800 by 480 display because the submit button disappears off the bottom. That got me to wondering if I really need to support a display that small. The app I'm working on is not for mass-consumption, max usage of a few thousand people, but it is targeted at "normal" users, i.e. the group profiles to the general population.
I did some checking and found two interesting links, especially this one:
https://gigaom.com/2014/07/09/android-screen-sizes-arent-as-big-a-challenge-for-developers-as-you-might-think/
It states that the 10 most popular phones used by the developer's customers corresponded to the 5 following layout sizes:
720 x 1280
768 x 1280
800 x 1280
1080 x 1920
1440 x 2560
The next link:
http://developer.android.com/about/dashboards/index.html
shows that just 6% of phones checked into Google Play are using versions of Android less than Android 4.0, and only 10% are using less than Android 4.1.
I then checked the history the screen sizes for the various versions of the Samsung Galaxy S series, and you have to back to the Galaxy S2, issued in April 2011, to find the one with 800 x 480 screen size. The next S version, the Galaxy S3, was issued in 2012 and has the lowest screen size found on the list of layouts shown above.
The issue is that although the minimum supported Android version in my app is 4.0, someone with an S2 could have upgraded to it. Plus there are some phones issued even recently which have have 800 x 480 displays, e.g. the Samsung Neo. The S3 was the first one issued with 4.0 as the native OS, so if the S2 users didn't upgrade, they wouldn't be able to use the app anyway. Most of them probably have a new phone by now, I'm hoping.
I'm probably going to try to wrap the submit button inside of a relative layout and see if I can let the 800 x 480 users scroll to it, but that display is so tiny I'm not sure I can make it work.
So I guess my question is, how concerned should I be with the 800 x 480 display issue?
I myself used the link you provided for research for my internship a couple of months back as well. The images I provided below indicate that a normal hdpi screen takes up 38.3% of all phones. This would be either 480x800, 480x854, or 600x1024 (if I interpreted it correctly). 38% is a serious amount and should not be discarded.
Not to sound degrading, but did you consider using a ScrollView in combination with sizing in dp?
I'm creating a compass application in which image of the compass should be straight at 267 degrees. The results are so accurate in my 'Q mobile noir A51' which has 4.5" screen and have android version 4.3 jelly bean. But when I'm testing it in 'Samsung Galaxy Grand' which has 5" screen and same version of android it will give different results. Then I test it in 'sony xperia L' which have 4" screen and same version of android again the result is different than Galaxy grand and Qmobile. Please tell me what will be the reason behind it? Is there a problem with the screen size or the sensors of every smart phones are different? I'm putting the images of the result below.
Galaxy Grand result is this. The result should be 267 degrees at this point and image should be straight.
Sony xperia is not available right now so i could post it's result but it's also giving the different result.
P.S: result in galaxy grand is keep on changing as the screen lock button press. When the scree open the result changes itself.
It is what you say in principle this depends on the hardware of each manufacturer, the accuracy of hw.
So many sides talk about the compass calibration software, hardware and even some mutts.
This is an example:
http://www.youtube.com/watch?v=sP3d00Hr14o
I have a requirement in android to support my app in different tablets like google nexus 10 and samsung galxy 10 inch tablet. Nexus 10 is double the resolution of samsung 10 inch tab. I need to place different images for nexus 10 to make my app looks with better clarity for nexus 10 . But both the devices are taking the image from the drawable-xlarge. How can I differentiate between these two devices in drawable level and layout level. Same case is applicable for phones as well where I need to differentiate Samsung galaxy s4 which is double the resolution of xhdpi phones.
-xlarge is a screen size qualifier. Your drawable folders should use screen density qualifiers (-mdpi, -hdpi, -xhdpi, -xxhdpi). If you must, you can use both, e.g -xlarge-hdpi
Don't forget the new smallest width qualifiers. They are of a great help when you need to differentiate based on screen resolution.
I wouldn't consider a non-Nexus tablet anymore, based on how bad manufacturers have been at bothering to update them. The Nexus devices being "Official Google" devices and getting updates from Google means that they're going to be updated for a long while going forward, and once that ends, you can still unlock and root them through a defined process & update things yourself if you care to do so.
I can't think of any 10" Android tablet I'd have other than the Nexus 10. They're really that good.
I have a Nexus 7 tablet which should have a resolution of 1280px by 800px (WXGA). I develop on Eclipse and my layout is set to display at WXGA. Then, I can place my button and object and choose their size according to what I see on the Eclipse display. The problem is that what I see in Eclipse is very different from the display on the tablet. Everything is much bigger on the tablet and it causes me a lot of troubles.
I wonder if someone have an idea about this?
Edit
For some reason it seems like the 7inch WSVGA is the exact replication of my Nexus 7 screen. It is strange since it offers only 964×544 pixels while the Nexus 7 should give 1280x800
WXGA means nothing by itself. You should look at the density too. Nexus 7 is 213dpi (tvdpi) while a Galaxy Nexus is the same res but 240dpi (hdpi).
You should try to detect the screen size that the Android device has and then run code to re-position screen elements accordingly
In Unity scripting you would get the vars Screen.Width and Screen.Height , I'm not sure what the vars are called in normal android , but you would then set your screen elements to react to what ever size the screen it .
i recently developed a game, for Android 2.3.3, and strangely im finding few weird behaviour in different phones,
for example
An explosion sprite(256x256 pixels) divided into 4x4=16 images, when displayed is being displayed as a 2x2 image in Samsung Galaxy Ace 2.3.3 and Samsung Galaxy Y, 2.3.5 ,
Also, the accelerometer works in a haphazard form in Sony Xperia 2.3.3 and Samsung Galaxy Ace.. either its too slow(and takes touch gestures after 3-4 second gap) and Android OS throws a Alert box saying, the app is not responding, else its too fast.
Strangely, The game works perfectly on a Samsung S2, just like it plays on the VirtualBox..
please help me, b'cos this is my college project, and I wont even be able to put this up in the market if such a queer problem exists!!
Thanks in Advance!!
I think I have the same experience with the graphics problem:
From your code, I'm guessing you may have pre-computed "width_explosion" and "height_explosion" from the image height/width you have seen in an image editor and using the same values on different devices.
The device you have listed have two different DPI values as Android knows: 240, or MDPI (Galaxy S2) and 120, or LDPI (Galaxy Ace and Galaxy Y). Note that Galaxy S2's DPI is exactly twice as Ace's and Y's.
Android makes it handy for app authors by assisting them in manipulating images. When images are read from resources through getDrawable and are ready for rendering on screen Android resizes the images with respect to 160DPI, so that they will have the same length measured with a ruler on screens with different pixel densities. For example, if an image with 128x128 pixels is 2cm long and 2cm wide on Galaxy S2, it should be 2cm long and 2cm wide on a Galaxy Ace. However, to cover the more pixels on a Galaxy S2, it's resized to 192 x 192 pixels when drawing on a Galaxy S2, because its DPI as the Android system knows it is 240, 1.5 times the DPI of an ADP1 (HTC Dream). Similarly, the image will be resized to 96 x 96 on a Galaxy Ace or Galaxy Y.
The source rectangle in canvas.drawImage, unfortunately, refers to the number of pixels in the resized bitmap. That means the same source rectangle used in your code sample covers 4 times as many pixels on a Galaxy Y as it does on a Galaxy S2. I guess you are describing in the question that "the same sprite file looks like it was divided in 2x2 on a low DPI device but it should be divided by 4x4".
The following example illustrates what happens when I'm trying to replicate your question with devices with different DPIs.
I cannot post images, so I have put the images here (it's my blog):
http://edgeofmap.com/blog/2013/05/android-bitmap-over-devices-of-different-dpis/
Not sure what to do about the graphics issue, but for the accelerometer each device acts differently. Use event.sensor.getMaximumRange() in your onSensorChanged() to get the maximum value and base your actions on that or a percentage of that.