Long post warning - apologies in advance.
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?
Thanks for your feedback in advance.