Yes that’s exactly what bugged me. I wen’t with just hiding the content (leave background) and show just the label, edit and done button on the top of the screen, so the user wouldn’t get the screen where the keyboard is gone but the content is shifted up and emmpty in the bottom. I may be exagerating the issue but it really annoyed me.
I wouldn’t get too fixated on it - I suppose all apps under Android would exhibit the same behavior
They don’t as they use the system function to slide up the content which resets when the keyboard is canceled.
atanas, thanks for letting me test your widgets.newEditField. I’ve run the test app and the first thing I noticed is the text doesn’t show up until I’ve finished typing. Does this only happen in the simulator? I haven’t test it on the device yet. Here’s a video capture of what’s happening.
Hi hectots, This problem is due to an incorrect font scaling in the simulator. In the simulator, the font scaling can be off because i do not have a way to retrieve the simulator Zoom factor from Corona. For practical purposes, any devices that have a height of more than 1000 pixels, I assume the simulator will be zoomed out 1 time. While if the device height is less than 1000 pixels high, then you need to zoom in all the way to get the fony scaling correct. This is done assuming a screen like a standard Macbook Pro. This issue does not happen on actual devices and is only related to the simulator’s zoom factor, which I wish could be retrieved.
hectots, here it is working fine in the simulator.
What Corona build are you using? I would say that it appears that your editFontColor is with alpha 0, making the text invisible…
@atanas I sent you calibration data from Galaxy S2 which is way off.
I’m a bit worried though whether people knew what to do in the calibration screen.
I want to check if this is what I was supposed to do:
-
Increase height until line is in the middle of the edit field.
-
Increase height adjust so no text is cut-off.
-
position label on the line (though x is subjective so I just put it on 0 cause i think it’s far enough from the edge)
-
adjust font scale and position to match and overlap red text
Is that right?
Renato, I’m using build 2013.12.7. I haven’t changed the code on the sample project, which is the one I’m running in the video.
I’m sure Atanas will chime in regarding your questions but I think you are right about your assumptions.
What your questions highlight for me though is the fact that the current calibration screen is not something we can throw at end-users and expect them to survive. I know Atanas designed it as a quick tool for us, developers so please don’t take this as criticism.
I made a version, a mockup for what an end-user version of the calibration tool could be like. Please see attached image. Comments welcome as always.
@primoz, you are on the right track, just you dont really need to adjust the height of the font, the horizontal line alignment is optional
Thanks kerem, the screen looks great
@ksan that looks great although I would add +/- buttons like there are now so you can fine tune the settings.
Also this is to adjust the font scale but if ou want the calibrate the positioning also then I would suggest a horizontal line like there is now to center it and also vertical line indicating where the start of the text should be. I think vertical positioning will be just as hard to tacle for this devices as the font scale. Although, as atanas has just figured out, it might just be the android 2.x.x devices that have this issues, so maybe a y/x offset can be set for all of them as well.
I know what you mean. I was thinking about how we could offer a simple looking UI if we were to ask an end-user to calibrate so I chose to eliminate some of the extra details etc. In any case, I think Atanas is very close to making all this unnecessary.
I just received an update which seems to be very close to perfection on my Android 2.2 device right out the box without using any calibrationdb entries. It would be great if all beta testers could update and run their Android device testing and send results again to Atanas. Thank you so much for all your help.
Hi Renato, the bug you identified is now fixed right? So we should take out the workaround from the newEditField code. Can you kindly confirm? Thanks
Yes, and I think atanas already removed the turn-around for that bug.
Super. Thanks for confirming.
We would really appreciate the opportunity to try your widget in our business apps!
I would really like to try your widget!
You can visit http://widgetstown.com/ and register for a free account to gain access to the sample & documentation. The widget itself is on Atanas’s GitHub link already.
Are you still looking for Beta testers for Widget.newEditField. ?