{ "id": "61981", "key": "TIMOB-1349", "fields": { "issuetype": { "id": "1", "description": "A problem which impairs or prevents the functions of the product.", "name": "Bug", "subtask": false }, "project": { "id": "10153", "key": "TIMOB", "name": "Titanium SDK/CLI", "projectCategory": { "id": "10100", "description": "Titanium and related SDKs used in application development", "name": "Client" } }, "fixVersions": [ { "id": "11225", "name": "Release 1.5.0", "archived": true, "released": true, "releaseDate": "2010-12-14" } ], "resolution": { "id": "1", "description": "A fix for this issue is checked into the tree and tested.", "name": "Fixed" }, "resolutiondate": "2011-04-17T01:55:56.000+0000", "created": "2011-04-15T02:50:07.000+0000", "priority": { "name": "Trivial", "id": "5" }, "labels": [ "density", "dpi", "iphone4", "patch", "resolution" ], "versions": [], "issuelinks": [], "assignee": { "name": "rseagraves", "key": "rseagraves", "displayName": "Reggie Seagraves", "active": true, "timeZone": "America/Los_Angeles" }, "updated": "2011-04-17T01:55:56.000+0000", "status": { "description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.", "name": "Closed", "id": "6", "statusCategory": { "id": 3, "key": "done", "colorName": "green", "name": "Done" } }, "components": [ { "id": "10206", "name": "iOS", "description": "iOS Platform" } ], "description": "{html}
In StatusNet Mobile, I'm trying to check the display resolution\nto see whether higher-resolution avatar images should be fetched\nwhen running on an iPhone 4 or high-resolution Android device.
\nExpected behavior:
\nOn iPhone 4 (or iPhone SDK 4 simulator with hardware set to\niPhone 4), Titanium.Platform.displayCaps.dpi should return 320.
\nActual behavior:
\nTitanium.Platform.displayCaps.dpi is currently hardcoded to\nreturn 160 for iPhoneOS/iOS unless on an iPad, in which case it's\nhardcoded to return 130; this leaves apps unable to distinguish\nbetween an iPhone 2g/3g/3gs and an iPhone 4.
Fix calling the existing scale check helper functions on\nTiUtils:
\n\nhttp://github.com/brion/titanium_mobile/commit/778cf65ca1aaa47d0e14...
\nNote that this leaves the details of 160/320 as two hardcoded\nalternatives; also the existing code returns \"high\" density for\niPad, which I did not change although it looks wrong -- iPad's\ndensity is around 130 dpi (which it does report\ncorrectly), the lowest of any iOS device.
The above commit had a stray { sneak in which breaks building;\ncorrected version here:
\n\nhttp://github.com/brion/titanium_mobile/commit/2b279bf36d5086a10c73...
Adding \"[PATCH]\" to title.
+1 for this. I have the same need: deciding whether to fetch\nhigh-res resolution images from our servers.
Assigning open patches from StatusNet to our support contact per\nrequest.
I've never heard of a 'dots per inch' measure in a context not\ninvolving printers or documents.
\nDoes 'dots per inch' mean the same thing as 'pixels per\ninch'?
\nIf so, values of 160 and 320 are both wrong -- they should be\n163\nand 326.
'dpi' is very often used to describe logical on-screen pixel\ndensity in the fun world of software, as anybody who's done\ngraphics programming on Windows or Mac OS in the last 25 years can\nassure you. :)
\n163/326 are more correct for the hardware, but whatever the case\ncurrently rounded values are being returned. (On Android, the fixed\nvalues 120, 160, or 240 are returned, as these are what's defined\nas available on the platform, though honestly I'd be surprised if\nevery phone has those EXACT resolutions in hardware. On regular\ncomputer screens, standard logical values like 72, 96 or 120 are\nusually returned for the logical screen \"dpi\" despite having only a\nvery approximate correspondence with the actual screen's\nresolution.)
\nI can't find an actual dpi/ppi/whatever check in iOS's available\ndisplay caps checks (just the scale factor from the logical\ncoordinate system to the framebuffer's pixel grid), so I don't know\nwhat Apple would like to \"call\" it in software, but returning 160\non iPhone 4 definitely is wrong -- it should be twice what\nwe get back from an iPhone original/3G/3Gs.
\nOn Android we get the defined value for the framebuffer space\n(120, 160, 240) for dpi, while platformWidth and platformHeight\ngive us logical coordinates. If that's the correct behavior there,\nthen we should be getting 320 (or 326, or whatever) as dpi on\niPhone 4. Main point is, we need to be able to distinguish between\ndifferent screen resolutions so we can ensure we are working with\nimages of the appropriate resolution.
Any issues with this patch? Anyone whose attention I should\nbring it to specifically?
merged.
iPad - 130 (160 in compatibility mode)
\n3g/3gs/ipod touch (3rd) - 160
\n4g/4th gen ipod touch - 320
Closing as resolved.