mpappas’s version is a bit more involved but it basically relies on:
system.getInfo( “androidDisplayHeightInInches” )
system.getInfo( “androidDisplayWidthInInches” )
which on some devices is reported wrong.
Here are the questions.
Did you collect all this values in your calibration app and do you have them posted somewhere?
Does mpappas’s or rob’s or the third one work on devices that report the correct values for system.getInfo( “androidDisplayHeightInInches” ) and system.getInfo( “androidDisplayWidthInInches” )?
@primoz, Yes, i collect all the available values and will post them on widgetstown.com, but still working on the web site. None of the methods work on all devices, even if they report the values correctly and i use a mix + the calibration db for some Androids.
Quite frankly, I am a little skeptical about our ability to find a magic formula. The device fragmentation is a very ugly beast. I am of the opinion that unless a native solution (ie a plugin) etc is offered by CL we will always be in this boat. Atanas’s newEditField is a wonderful implementation and has the ability to fit many different devices through its calibration data tie-in and I think this is what we need to work with and strengthen.
Currently, calibration data comes in when a beta tester runs the sample app on an Android device and takes the time to calibrate and send results to Atanas via email (built in capability in sample app). Atanas then collects the new information and incorporates it into the editfield_calibrationdb.lua which lives on his GitHub. It is then up to the devs (us) to download a fresh copy and build their apps and release it again to the Android store so the app users can benefit from this additional calibration data. You can see where I’m going with this. While this approach works well, the whole process is time consuming and does not allow the apps to make use of additional calibration data without a re-build and re-submit to app store. Not a viable solution for real world solutions IMHO.
So what do we do about this? Well, taking advantage of my Coronium testing experience I took the plunge to connect Atanas’s newEditFields sample app to the world… The version of the sample code I have has been changed in the following manner :
It does not make use of the calibration data from Atanas. This is just to test my concept. In real life we would still continue to supply a local calibration database to cater for known calibration situations.
It makes use of the mod_coronium library from @develephant to talk to a simple web database (MySQL) fronted by a simple PHP based CRUD application.
It makes use of GGData to save and recall data in JSON format on device disk. In this case I am using it to save/recall a table containing calibration data. The file it creates currently lives in systemDocumentsDirectory.
When you first run your app, code in edit_defaults lua checks to see if there is a locally saved calibration file. If so it loads it and applies calibration.
If no local calibration file exists, code in edit_defaults lua checks webDB to see if there is calibration information saved there. Is so this information gets downloaded and saved into local calibration file and gets applied to the app.
If no web calibration for this device exists then you get a prompt that says “No calibration data found locally or on web, would you like to calibrate now?”. If you choose Calibrate you are then taken to the calibrate screen.
Using the calibration screen in the sample, you calibrate as usual and hit save. Now this routine goes and saves a copy of your calibration to the local file and also uploads a copy to our webDB. You can straightaway go to the web application and see the data uploaded from your device. Not only do we get the calibration data but we also get the whole contents of the email containing device information such as system.getInfo( “androidDisplayWidthInInches” ) etc. Good news is from now on the saved calibration is applied (locally) each time the user runs the app so he does not need the dev to update the app with new calibration data on Google Play Store etc.
My sample app code also allows a user to update calibration and save again to local file + web etc. This could be useful for small tweaks etc.
With Atanas’s blessing, I wanted to float this idea here and see what kind of feedback we get from all of you about this idea. How do you all feel about a central webdb for calibration data that you can all tie in with your apps. Obviously we would still need to provide a local calibration data file which gets updated from time to time by harvesting our webdb. The calls to webdb typically would be during the first time an app is used.
How does this all sound? Workable or unrealistic? Do you think a reworked, simplified calibration screen can be included in our apps supplied to end-users such that if things don’t look right on their device the end-users can be instructed to calibrate the app for their device and submit their calibration data?
In today’s daily build they implemented the placeholder property for textField/Box for Android. It appears to be a simple thing but placeholder/hint is something extremely important for non-games apps.
Release notes for build 2014. through 2014.2169
Android: Added textfield.placeholder and textbox.placeholder.
I don’t see a bug report for that. I’ll mention it in my report, but I know Engineering is going to ask me if there is a bug report. If you can file one that would be great.
Not the first time we are surprised like this. The other day there was that getDefault stuff… then the scrollbarAutoHide because autoHideScrollbar suddenly… Who knows what else is going on in there. If they can’t keep up with the changes then perhaps they should introduce less new features and focus more on quality of code and documentation for a while…
But honestly if this is really something you *need* right now then feel free to write your own module for this. This way you do not rely on native textFields.
You still can’t input in windows simulator though but you can see it and it plays well with corona objects when you’re not editing it.
There are still some hickups with different android devices positioning and font sizes but it’s being sorted.
Oh and by the way text fields not working on simulator is not an Mac/iOS exclusive thing as it has it’s own implementation for every OS. Corona just didn’t implement it for windows.