@Fidelis - I tested today on a new nexus 7 running 4.2.2 and it works… I’m using the daily builds, but I thought that functionality was in the last public release too… Maybe it is related to your changing screen resolutions on the nexus 7 (using adb?).
@mpappas - I realized Im using the previous version of Corona. I downloaded the latest public release and it works! thanks a lot!
Thanks for the good work!
so I sum this up,
I got this in my main view:
local fieldSize, fontSize if android() == true then fontSize = getAndroidFontSize(18) fieldSize = 25 / display.contentScaleY else fontSize = 18 fieldSize = 25 end url\_textfield = native.newTextField( 28, 219, 180, fieldSize) url\_textfield.font = native.newFont( "Arial", fontSize ) url\_textfield.size = fontSize url\_textfield.text = "" url\_textfield.inputType = "url" url\_textfield.hasBackground = false url\_textfield:addEventListener( "userInput", input\_listener )
and Mpappas routine as a function:
function getAndroidFontSize(targetFontSize) print(" -- calcFontSize()") print("-----------------------" ) local sysType = system.getInfo("architectureInfo") print(" -- sysType == ", sysType) print(" -- display.contentScaleY == ", display.contentScaleY ) print(" -- display.screenOriginY == ", display.screenOriginY ) inputFontSize = targetFontSize / display.contentScaleY -- old method is fallback (ends up being sim setting) if android() == true then -- try and get the real width / height and deal with it print(" -- -- Android font size calc...") local missingInches = display.screenOriginY \* -2 -- account for both top and bottom area (x2), and change the sign sign since originY is always negative, if it exists... missingInches = missingInches / 320 -- 320 is 1 inch, in my 640x960 virual content space (960 == 3 inches for my app, designed for a standard iphone 4 display) -- different contentScale sizes will use a different virtual pixel / inch value (eg, 320x480 virtual content = missingInches / 160) print(" -- missing inches == ", missingInches) local fontScale = 1 local heightIn = system.getInfo( "androidDisplayHeightInInches" ) local widthIn = system.getInfo( "androidDisplayWidthInInches" ) print(" -- original height == ", heightIn) heightIn = heightIn - missingInches --Make sure its not nil... e.g. the simulator will return nil, perhaps some bad devices will too... if heightIn ~= nil then -- heightIn is height of actual droid app is running on fontScale = heightIn / 3.0 -- 3.0 is actual iPhone 3gs /4 /4s height print(" -- fontsize set on actual droid screen inch height") print(" -- widthIn = ", widthIn) print(" -- heightIn = ", heightIn) else fontScale = 4/3 --Default to a 4 inch diagonal (iphone is 3.0) print(" -- fontsize set to 4 inch phone size") end print(" fontScale == ", fontScale) inputFontSize = targetFontSize\*fontScale end return inputFontSize end
this works fine on my samsung galaxy I
I removed the iOS part because on iOS it just works fine the way it is.
Is this correct? Can someone confirm?
It’s working fine for me - on an old motorola atrix, a new nexus 7 and an LG Optimus. Font sizes on all 3 match each other (not literally, but proportionally to the app content), and match the size on my iOS devices.
You said you dropped the ios side because it already worked. There’s two cases that might give unexpected font sizes if you don’t do this technique on the iOS side – the 3GS (non-retina device, 1/4 the res of the 4 or 5) and the iPad mini. I think you’d see giant text on one, and small text on the other if you use the older techniques (fontsize * display.contentScaleY).
Thanks for your quick reply! I understand.
I just have one question: what value do I have to set the height of the textfield when I’m using your code?
Is this it?
originalHeight / display.contentScaleY
because contentScaleY doesn’t seem to do the right job. What’s the code you create your newTextField with?
I’m asking this because when I use your code it seems to scale the font-size properly but the text still get’s chopped of at the top
My code that creates the editfield is pretty customized… My app uses white roundedRects on screen for the input field areas, and my native field creation code (my editing code) is passed in a the onscreen rectangle object – which it then uses as the background area for the native text editing. (it creates / positions a native field for editing on top of the passed in rectangle object).
The native field itself is set to no background when it is created (so my white rounded rect is the only thing behind the native text - the field itself has no bg, just text).
The actual creation of the native field won’t tell you much (the tempx,y etc is data grabbed from my onscreen rounded rect input area).
[lua]
editTextField = native.newTextField( tempX, tempY, tempW, tempH, keyboardHandlerEditText)
editTextField.font = native.newFont( native.systemFont, inputFontSize )
editTextField.inputType = keyboardType – passed in
editTextField.align = ‘left’;
editTextField.text = editText
editTextField.isEditable = true
editTextField:setTextColor( 0,0,0 )
editTextField.hasBackground = false
editTextField.isSecure = isSecure – passed in
print(" editTextField created – textSize ==", tempSize)
[/lua]
One note I discovered regarding android text – corona(?) or something screws up positioning of native android text if the height variable you pass in to the newTextField call (param 4) is not pretty oversized. It doesn’t matter in my case, as the background for the native text is disabled (so it’s invisible).
What I noticed is that if the height is set at like 30 pixels or something, and your font size is anywhere close to that, the font starts creeping up vertically out of its correct position – and is not positioned well. I added a little code to double the height of the editfield bg for android, and it seems to position fine vertically
[lua]
if( utils.isAndroid == true ) then – Special issue with android
– Corona / opengl is causing the height to be used weird / incorrectly…
tempH = tray.height * 2
tempY = (tray.y - tempH/2) – a little extra height is required for android for some reason (corona? opengl?)
else
[/lua]
wow!
I tried it on a real Samsung Galaxy I device and it works.
Also tried it on 3 different devices on the emulator and it works flawlessly, even with a small 240x320 resolution.
doubling the size of the initual height does the trick.
I have the background hidden and an underlying image too, so that’s just great.
you’ve done some great work here. much appreciated!
bravo!
Hmm. When I used mpappas with a virtual size of 768x1024 (tablet-only app) and 7.75 inches high for virtual device height (iPad), I got crazy-small font size of 10 for the Kindle Fire:
missingInches = (-143 * 2) / 132 = 2.16
(132 is virtual pixel dpi, which should really be DEVICE pixel dpi, I think, but at 170 device dpi, this is still too big a value for missingInches – 1.68 inches)
fontScale = (6 - 1.68) / 7.75 = .557
18 (font size) * .557 = 10 for the Kindle font size when given 18 as iPad font size. Super small.
But 14 is the right size when doing testing. Leaving out missingInches entirely gives 13.9 (18 * (6/7.75)), which looks just right.
This topic is immensely frustrating (as in, I don’t get why Corona can’t make this a non-issue for non-weird Android devices).
Anybody else working with tablet-size apps, and/or just realizes why I need to not use missingInches to get the right font sizes?
And why is screenOriginY -143 for Kindle for a 768x1024 letterbox? Kindle is 600x1024. 768/600 = 1.28, which is contentScaleY. Well, 1024/1.28 = 800, so shouldn’t screenOriginY be -112 (since 800 is 224 less than 1024, and 112 is half of 224)?
If you look at the two Sample apps for text input, you will see that we add 10px to the height of the native.newTextField() entries on Android. This is because Android has extra chrome that has to be compensated for. After some tests, it’s not relative to the display size or the font size, but a fixed 10 pixels. Simply make your textField’s 10px bigger if you’re on Android.
Rob
Rob,
Thanks for the quick reply. I was whining about the font size issue, though, not the “need to make the text field height larger” issue. I’ve already dealt with the ride-up/lop-off with my own field height adjustment. My concern was with the inability to get to the right font size in a newTextField on Android, even with the mpappas stuff.
I’m using mpappas but without the missingInches part – that makes my Android text field sizes way too small.
HI RH,
I too was pretty frustrated with the SDK’s ability to deal with native cross platform text input (which is why I developed the code above, based on an idea of ksan).
It works for me on all iOS devices and (straight up) Android devices I’ve tested on. BUT, I’ve never tried it on any amazon product.
Regarding the missingInches variable, I developed that portion last, to deal with the “soft keys” they are putting on the screen on newer androids (they used to be hardware buttons under the display). So for those devices, although the screen is 7.5 inches say, a half an inch would be taken up by the soft keys, so the effective inches for the device would be less… That was the idea…
In the case of Amazon devices, although I would hope they didn’t, they could be dealing with soft keys / display size differently (they are soft keys, right?)
In any case… I feel you pain… Cross platform text input should be, well, cross platform…
Hmm. When I used mpappas with a virtual size of 768x1024 (tablet-only app) and 7.75 inches high for virtual device height (iPad), I got crazy-small font size of 10 for the Kindle Fire:
missingInches = (-143 * 2) / 132 = 2.16
(132 is virtual pixel dpi, which should really be DEVICE pixel dpi, I think, but at 170 device dpi, this is still too big a value for missingInches – 1.68 inches)
fontScale = (6 - 1.68) / 7.75 = .557
18 (font size) * .557 = 10 for the Kindle font size when given 18 as iPad font size. Super small.
But 14 is the right size when doing testing. Leaving out missingInches entirely gives 13.9 (18 * (6/7.75)), which looks just right.
This topic is immensely frustrating (as in, I don’t get why Corona can’t make this a non-issue for non-weird Android devices).
Anybody else working with tablet-size apps, and/or just realizes why I need to not use missingInches to get the right font sizes?
And why is screenOriginY -143 for Kindle for a 768x1024 letterbox? Kindle is 600x1024. 768/600 = 1.28, which is contentScaleY. Well, 1024/1.28 = 800, so shouldn’t screenOriginY be -112 (since 800 is 224 less than 1024, and 112 is half of 224)?
If you look at the two Sample apps for text input, you will see that we add 10px to the height of the native.newTextField() entries on Android. This is because Android has extra chrome that has to be compensated for. After some tests, it’s not relative to the display size or the font size, but a fixed 10 pixels. Simply make your textField’s 10px bigger if you’re on Android.
Rob
Rob,
Thanks for the quick reply. I was whining about the font size issue, though, not the “need to make the text field height larger” issue. I’ve already dealt with the ride-up/lop-off with my own field height adjustment. My concern was with the inability to get to the right font size in a newTextField on Android, even with the mpappas stuff.
I’m using mpappas but without the missingInches part – that makes my Android text field sizes way too small.
HI RH,
I too was pretty frustrated with the SDK’s ability to deal with native cross platform text input (which is why I developed the code above, based on an idea of ksan).
It works for me on all iOS devices and (straight up) Android devices I’ve tested on. BUT, I’ve never tried it on any amazon product.
Regarding the missingInches variable, I developed that portion last, to deal with the “soft keys” they are putting on the screen on newer androids (they used to be hardware buttons under the display). So for those devices, although the screen is 7.5 inches say, a half an inch would be taken up by the soft keys, so the effective inches for the device would be less… That was the idea…
In the case of Amazon devices, although I would hope they didn’t, they could be dealing with soft keys / display size differently (they are soft keys, right?)
In any case… I feel you pain… Cross platform text input should be, well, cross platform…
Ok, my research shows that on android we must take DPI into account. Something like
fontSize = fontSize * 120 / system.getInfo(‘androidDisplayYDpi’)
Adjust 120 value for best result. Maybe 96.
Ok, my research shows that on android we must take DPI into account. Something like
fontSize = fontSize * 120 / system.getInfo(‘androidDisplayYDpi’)
Adjust 120 value for best result. Maybe 96.
Rob Miracle’s formula worked out fine for me for all of the Android phones I was able to test on.:
local inputFontSize = 22/display.contentScaleY
local tHeight = 80
myData.username = native.newTextField( myData._W*.11875, 300, 216, tHeight )
myData.username.font = native.newFont( native.systemFontBold, inputFontSize )
myData.username.size = inputFontSize
It’s still totally cut off by using the code you suggest (getAndroidFontSize).
The upper half is always cut off. I don’t understand why increasing the height for the input bar or find a good font size can solve this problem?
I make the input box large enough but the texts are placed in the upper half. If I increase more height or decrease the font size, it will only make it odder and odder.
Before I give it up, anyone can sum up the finalized solution? Maybe I miss something.
Rob Miracle’s formula worked out fine for me for all of the Android phones I was able to test on.:
local inputFontSize = 22/display.contentScaleY
local tHeight = 80
myData.username = native.newTextField( myData._W*.11875, 300, 216, tHeight )
myData.username.font = native.newFont( native.systemFontBold, inputFontSize )
myData.username.size = inputFontSize