widget.newEditField beta testers needed

Solar2D Widgets
#1

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
     

#2

I’d love to try it out.  I’ve been annoyed with the limitations of newNextField.

-Greg

#3

Thanks Greg,

PM sent with the sample app as well as the sources for the widgets.

Atanas

#4

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. 

#5

I tested here. Nice job.

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.

Apart from that, appears to be great. 

#6

Hi, 

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. 

Cheers

#7

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)

#8

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 )

#9

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. 

#10

We can test it also if you want. We are doing a tourism app with Corona, therefore such a new widget would be more than welcome.

Nick

#11

I’d be excited to try it out too. I’ve got a few arcane Android devices that would be useful to add to your tests.

#12

Hey guys, nice work!

I would love to try this out!

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.

I hope I am not hijacking this thread.
Thanks!

#13

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

#14

Hey Ksan, exactly.

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.

Thanks for your help!

#15

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! :slight_smile: 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. 

#16

Thanks for the suggestions.
I’ll create a thread for this to stop derailing this one.

:slight_smile:

#17

No worries. Certainly a relevant question IMHO. Give the beta a try and see how it works in your use case. Thanks

#18

Thanks guys,

PMs sent with the files. Looking forward to your feedback

Atanas

#19

Would love to give it a go on the business app I am working on and provide some testing rletx

#20

Thanks Rich, PM sent. I am over some attachment limit with PMs, so please send me your email