Native Text Fields are... wanting

Other
#21

@atanas just a few questions.

Rob posted this mechanism:

deviceScale = ( display.pixelWidth / display.contentWidth ) * 0.5

textField.size = fontSize * deviceScale

Another one I found is this:

textfield.size = fontSize / display.contentScaleY

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.

  1. Did you collect all this values in your calibration app and do you have them posted somewhere?

  2. 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” )?

#22

@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.

#23

edit:

sorry wrong  thread

#24

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 : 

  1. 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. 

  2. 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.

  3. 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.

  4. 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. 

  5. 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.

  6. 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.

  7. 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. 

  8. 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. 

#25

Wow, I think Corona finally listened to us! :) 

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.

The docs can be seen here: http://docs.coronalabs.com/daily/api/type/TextField/placeholder.html  (btw, the docs doesn’t mention anything about only working on Android, as the daily build specifies)

I didn’t test it yet, and of course, we still have a long road ahead, but that is already something.

#26

It was already working on iOS and OS-X already, it just wasn’t documented.

Rob

#27

What about the text color on Adroid using 0-1 values?

#28

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.

Thanks

Rob

#29

It was already filled and fixed

#30

I am pretty sure someone filed a report, it was fixed for iOS but wasn’t yet for Android.

#31

Got it here.

I filled (#29756) and received an email from Corona saying that the fix would be available on daily build > 2148.

I don’t see on the Release notes any mention to that but I think the fix is there.

#32

If this has not been fixed, I’ll check with engineering?  Do one of you  have a quick way to verify it?

Rob

#33

Yes, give me a sec

#34

Yes, just checked. It is fixed.

Tested on build 2014.2162

#35

Great, so I can remove my workaround in newEditField, Renato?

#36

Yes. I though that I had notified  you about the Corona reply. If not, my mistake. 

#37

Yes, just never saw it in the release notes for daily builds

#38

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… 

#39

As far as I know you are able to insert textfields into display groups, e.g. storyboard´s scene view.

Transitions like “slideLeft” do work but “fade” does not.

Regarding testing iOS fields in the windows simulator:

This has nothing to do with Corona - this is one of these Mac/iOS exclusive features that won´t run on Windows.

I would suggest to put this into feedback.coronalabs.com

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.

#40

Many of us have struggled with this. Check out this thread:

http://forums.coronalabs.com/topic/42977-widgetneweditfield-beta-testers-needed/

Atanas has done a great job with it.

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.