Native Text Fields are... wanting

Other
#41

Oh thanks I thought that this was an Apple thing :slight_smile:

#42

Folks,

I am intimately familiar with all of the short comings native text fields because I have been dealing with all of it’s deficiencies for the past month.  Everything I said was accurate and factual (no they do NOT work with groups).  Everything I listed was accurate and factual. 

Most of your are missing the point.  These are not IOS limitations. These are not Android limitations.  These are Corona limitations because Corona chose to NOT create their own text field functionality.  They are not providing us with this BASIC functionality.

1) We should not have to depend on native text fields since they are deficient.

2) Corona should be providing us with this code.  I should not have to go out and write a module.

  1. Corona’s implementation should be standard across all platforms.

My post was meant to inspire Corona to fix this.  I was not looking for a work around.

Regards,

Arthur

#43

I am using the native textFields and they do work with storyboard´s group in my current biz app (except for the “fade” transition)

#44

They won’t because it’s an enormous project to code their own keyboard implementation supporting all existing languages.

I did not link the thread to show you the shortcomings. It’s the best solution you will get on Corona.

Try it. Just give atanas a shout in that thread and he’ll send you the widget.

#45

If we take some step back, maybe the solution is in between. There is some quick fix that Corona could implement that will make our life easier even using the native object; for example :

  • Allow inserting the newTextField inside a display group and implement as a minimum de X and Y move.This would at least avoid us to implement a hack in a scroll view to change manually the position. We can accept the other limitation.
  • The could delete the newTextField when it is inside a group, so it work like any other object and avoid us to manually delete those items.
  • Fix the problem with font size inside a newTextField in some Android device and allow us to set the size of the font. Currently this is buggy and does not work well at all.

This is my humble opinion would be a nice step in the right direction and would allow us to accept more easily the current limitation.

#46

If you check the thread a linked before you will see that the widget being worked on there does all of that and A LOT more.

#47

Thanks Nmichaud,

I think those are good ideas.

To be perfectly honest, if the corona folks merely said they were doing something about this it would make me happy.

Regards,

Arthur

#48

Thanks Nmichaud,

I think those are good ideas.

To be perfectly honest, if the corona folks merely said they were doing something about this it would make me happy.

Regards,

Arthur

#49

Arthur, this is not something we choose to ignore because we don’t want to do it.  We don’t because we can’t.  Apple and Google have teams of engineers who’ve spent years building the keyboards you see on iOS and Android.   I’m guessing we would have to take every engineer we have and dedicate them to the keyboard project for at least a whole year to do this.

One little API doesn’t seem like that big of a deal, but this one is.  You have to support every device, every keyboard option, every font, every direction of writing (left to right, right to left), every language, every swipe action, zooming letters, etc.  This seems like a small thing but its enormous.  We could not work on any other aspect of the product if we did this.  Just to give you an idea, I built a custom keyboard for an app once.  It only supported English, only upper case letters, no punctuation, no swiping, only the custom font.  I had a basic cursor and deleting from the end working.  It took me a month just to get to that point.  I had no way of inserting or editing text in the middle of the screen, no copy-cut-paste support. 

Now to answer a few other things.  Inserting a native.* object into groups isn’t possible.  It may not throw an error, but it does not good.  Native objects sit on top of the OpenGL canvas and that’s the nature of Native vs. OpenGL.   While we might be able to engineer something to get a native field to move in conjunction with some display object, it’s easy enough for you to do that as we demonstrated in the tutorial on building a widget.newTextField() and that Atanas has adoopted (something similar) in his widget.newEditField() project.  We showed a technique that ties removing of the native.newTextField() when the parent group is removed as well.  

Believe me, we look at the feedback site and see how popular this is.  This is a major pain point and this hurts us that we can’t do this for you.  But it’s not something that’s currently not practical.

Rob

#50

Its going to be interesting how CL engineers tackle this issue vis a vis the upcoming Windows Mobile platform compatibility… 

#51

Thanks for the answer Rob.

I think what we want (at least me) it is not to Corona necessarily recreate all the keyboard stuff from scratch. Just the trick that you already blogged about (newText + native) made by Corona would be something 1000x better than we have today. (Anyone knows if that problem is specific a Corona one or other platforms like Unity also show them? It would be good to have that info)

Supporting some basic features like placeholder and basic display object features… I even don’t care about the misaligned on the android devices anymore…

For all other users, the best textField “widget” solution that I encountered until today is the one made by atanas (http://forums.coronalabs.com/topic/42977-widgetneweditfield-beta-testers-needed/)

#52

The process of trial and error is very time consuming for new users. In most cases a new user is not going to read the documentation from A-Z and process 100% of information there before diving in.  

So my 2 cents:  Emulate the new text field limitations in simulator as closely as possible. Do not allow things that are clearly not possible on device to work in simulator. At the very least show error on group inserts and warnings for impossible textfield transitions. 

My use case long time ago:

  • Got my textfields perfect in simulator.
  • Days later start testing something on iOS device and notice my textfields are not transition with the scenes. I guess that is the “can’t insert into groups” thing the docs talked about.
  • I decide to make a nice fade before the rest of the objects woosh off the screen.
  • Test on iOS device. Yup that works. 
  • Days later and multiple textfields later I start testing in Android. Oops that fade workaround doesn’t work in Android.

After reading about the Android textfield font scaling issue I ended making a fake input module with a fake blinking cursor and all the works. Now I regret that because I’m watching users scratch there heads when they are trying to move the cursor etc.  Next step is to test the Atanas module. But boy, the time that has gone into these textfields, phew…

Ps. Also please explain in newTextField documentation the Android text scale issue and recommend best possible workaround. There are pages and pages about this on the forum, not sure if Corona has said anything officially.

#53

Just wanted to clarify some of the “fog” around edit fields, providing my point of view

  1. The history of “better” edit fields for Corona :

  First there was a blog post from xdee - http://xdee.net/?p=4

  Second was implemented a widget.newSearchField “under the covers” matching the above blog post

  Lastly was Rob’s blog post

  My own implementation started from the newSearchField design, mostly to match the widget library coding and naming conventions, as well as reuse the 3 slice frames that Corona provides with the default themes for Androids and iOS7/iOS

  1. Credits

Rob’s blog post does not treat at all replacing the newTextField with a display.newText - this is something I asked him if it would be possible to do in a reply to the thread about his blog post but received no answer and went ahead to implement it and clean it up over the holidays with the immeasurable and dedicated help of Kerem(ksan). I would also like to give all the credit to everyone (including Renato) who submitted and keeps submitting calibration data, bug reports and enhancement suggestions to make this a workable solution for the community. However it should be made clear that I received zero assistance from Corona on this and also that the part from Rob’s blog post that I could have used - namely the font Scaling, simply didn’t work. 

  1. Font scaling “fog”

Rob’s blog post suggests a fontScaling mechanism and before that mpappas had a different implementation. I have tried both and unfortunately they fall short on some devices. In the calibration screen, I output the values of both Rob’s and mpappas’s font scaling factors and everyone can check when they work and when not. Rob’s font scaling doesn’t work on some iPads as well. I would assume there is a fog surrounding the fontScaling issue simply because no one from Corona currently has an answer to it or they would have published it already. As we keep collecting more calibration data, the hope is that we can “reverse engineer” an universal font scaling formula but to this moment such a formula eludes me.

  1. Corona’s part 

Even though implementing an edit field with OpenGL from scratch might be a very time consuming task, there are a couple of things that Corona could do to make widget.newEditField work better

  - Fix the display.newText text alignment and word wrapping to match the native.newTextField

  - Provide an API to retrieve the zoom factor from the simuator

  - Provide a way to send touch events to the native.newTextField , so I can position properly the cursor on the first touch of the fake label

  - Provide an event to stop/allow some characters (ala “beforedit”) so I can make the edit field validation without flickering

  - Provide a correct font scaling mechanism

  - Provide help with their own arsenal of testing devices to contribute to the calibration database

Should we expect any of the above to be addressed by Corona? I didn’t and that is why I expended a significant amount of time and resources trying to implement the best possible solution I could with the current means.

Thanks to everyone that recommended my attempt at solving the newTextField issues. The help and support of the community have been more than I expected and that is where I would like all the credit to go. 

#54

@atanas Completely support everything you have said. And if you need something done with the newEditField that maybe you have a problem with or don’t have time for, don’t hesitate to pm, email, or just give a shout in the forums. I’ll be glad to help.

You could post the calibration data that you have gathered and maybe we will come up with a solution for a common formula if one actually exists.

#55

@primoz - thanks, would love to get your help and expertise.

The latest calibration db is uploaded to github - https://github.com/atanasster/framework-widget/blob/master/widgetLibrary/editfield_calibrationdb.lua , together with the newEditField sources

We are also creating a site and forums for documentation, discussions, blogs. Currently in testing mode but would love to hear everyone’s feedback.

Here is the docs page - http://widgetstown.com/corona-view/widget-neweditfield-1-0/widget-neweditfield-1-0-docs/

Will publish on the site the full details of the collected calibration data, I am positive together we can tackle this font scaling beast.

#56

So… Having read all of this…

First off thanks for all of the clarification and ideas.

That being said Rob at very minimum Corona needs to document this much better than it is now.  I did the same kind of things atanas did.  Had I known you can’t do that I would have coded differently.

Regards,

Arthur

#57

I will pass this thread on to the engineering team and see what they can do.

#58

@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” )?

#59

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

#60

edit:

sorry wrong  thread