We have been busy polishing up the code with Kerem (ksan) and ready to accept a couple more beta testers.
Widget.newEditField encapsulates edit field functionality for business type apps and addresses most of the shortcomings in the Corona newTextField
allows you to display overlays and scenes on top of edit fields
manages and moves edit fields automatically with groups
supports 9-slices , 3-slices and roundect frames
supports labels for edit fields
error frame to indicate required fields to the end user
allowedChars and maxChars to limit the user input
supports icons and buttons for the edit fields
supports clear button
gives you an onSubmit event
supports custom sizes edit fields
automatic font scaling
automatic slide to unveil keyboard
native mode if there are no scenes or overlays on top of the edit fields
selection list functionality paired with a pickerList to select values from a pre defined list
calibration support to adjust font scaling and offsets on android devices
Atanas has done such an outstanding job with this widget!!! It is very very versatile and robust. You will be seriously impressed.
On Android, due to device variability the font scale results might vary so please bring as much device testing as you can muster to the table. There is a calibration function in the sample app from Atanas where you can tweak various parameters to get the editField to work perfectly on your device and then report the calibration data back to Atanas for inclusion in the widget calibration data. The more people test this code with different devices the better.
So in a nutshell, please test on device. Don’t just look at this on simulator. Looking forward to all your feedback.
The only problem is the one that you guys mentioned about font size on android devices.
I also noticed that on the “Super Size” scene, when I click outside the textField it is not losing focus automatically… I think that could be something to add… on the “Editors” scene, when I click outside, it is having the same behavior of the submit event. I don’t know if myself as user would expect that. If I click outside a field, I just want to get out of it, not necessarily submit it.
Thanks for the great feedback. The more Android devices we can run this test on the better. Can you use the calibration screen to get the native and display object to match in size and position and then hit the email button on the Android device? This will send Atanas info about this particular device which will then be added to a calibration file. The more the merrier.
Not sure if I understand the comment about SuperSize scene. It seems ok on my end. Is your comment specific to a platform, ie on Android etc?
I agree about your comment on tapping outside a field. Ideally we should be able to do either way depending on the situation. Atanas might have already put this capability in but if not perhaps he can do the same thing he did for the pickerlist where cancelOnBackgroundClick = true, gives you the exact behavior you describe.
The comment relative to the SuperSize was that when I was inside the textField and clicked outside, it was not losing focus. Perhaps that cancelOnBackgroundClick param is not being used… (I didn’t look the code to check)
Ahh, I see what you mean. There is no cancelOnBackgroundClick parameter on the editFields yet. Based on your feedback we can ask Atanas to put this in. Meanwhile for the super-size scene if you could add the following on line 15 you will get the same response as on the editFields scene.
bg:addEventListener(“touch”,function (event) native.setKeyboardFocus(nil) end )
Kerem is correct about the background click - in the Super Size scene, the event is simply not added so you can see it work either way. In the other scenes, the event is added in the sample app.
About adding a generic handling of the background touch events in the editField widget itself, not sure how the editField would do it since it does not know what exactly is the background group (opposed to the pickerList case, where it creates the background itself and has a cancelOnBackgroundClick property).
Renato, can you please forward me your Android calibration data.
Does this do anything to address the problem where you can’t display a navigation bar (next, previous, done etc) that sits above the native keyboard?
I am really in need of suggestions as to how to best handle closing the keyboard and moving to different fields when using number only keyboards etc.
I stuck a navigation bar at the top of the screen to do this, but it just looks weird at the top of the screen when it should be directly above the keyboard.
@euphoriacorona, I think you are asking about the use of keyboards which does not have a Done/Return type of button right? We encountered this use case and Atanas made it possible to create the onSubmit event when user touches another field on the screen or simply the background. So your navigation buttons could be made redundant with this widget.
So I guess my next question would be.. What would be the best way to explain this to the user on the screen in question?
For instance… Say you have 4 text fields, the first two use the default keyboard, the next one uses a number keyboard and the last uses an email keyboard.
When the user gets to the number keyboard… What would be the best way to explain to make it intuitive as to what they should do to advance to the next field… Or conversely, to show them how to dismiss the keyboard?
I’m struggling mostly with making this all intuitive and simple for the end user.
I don’t think there is one right answer. I will look at native apps to see if I can find examples to relate. In my opinion (which is often wrong! users tend to start tapping around the second they are done entering info and discover there is no Done button. You could perhaps visually wiggle the next editField once the current one with a number keyboard has valid data in it.
Lets see what others might be doing in this situation.
users tend to start tapping around the second they are done entering info and discover there is no Done button. You could perhaps visually wiggle the next editField once the current one with a number keyboard has valid data in it.