Horrible Keyboard Glitch in iOS7

Solar2D iOS
#1

Hello,

We’ve recently ran tests with the Golden Master of iOS7 and are experiencing big problems with the iOS6 keyboard that now appears for iOS6 apps within iOS7.

Basically this keyboad is hugely unresponsive. It seems to cause serious lag, which in turn makes it nearly impossible to enter text–instead keystrokes are registered only 5-20% of the time.

Apple is now using iOS7 for reviews and they ran into this.

I’ve checked an app that we already have on the app store and it seems to exhibit the same issues. Keep in mind that the keyboards performance is extremely varied–at times we were able to type perfectly fine, but almost every time we tested we had big issues.

The issue also applies to the actual iOS7 keyboard (not just the iOS6 keyboard that appears for old apps).

I don’t know if this is just something crazy that we’ve managed to reproduce in multiple cases and under multiple apps, so I was just wondering if anyone was able to reproduce these problems of if anyone has had similar problems.

All the best,

Jacob

#2

The issue appears to have, oddly enough, been how string.sub behaves in iOS 7. I added a check for length of the string before limiting it with string.sub - in previous versions the length check beforehand was unnecessary.

#3

Hi @Shady Guy,

Can you please post the basic code you’re using to do this, for the benefit of others who may encounter similar behavior?

Thanks,

Brent Sorrentino

#4

Well I jumped the gun if my post suggested its completely fixed - previously it just ignored all input, but now it seems to be not registering the first keystroke and then lagging a letter behind. The listener is as follows:

local function finishTyping(event)

        if event.phase==“editing” then

                    if(string.len(nameField.text)>10) then

                        nameField.text = string.sub(nameField.text,1,10)

                    end

            nameDisplay.text = nameField.text

        end

        

        if event.phase==“submitted” and nameField.text:len()>0 then

                    killTyping()

        end

            end

–

killTyping is a function that just transitions some menu elements and sets keyboard focus to nil.

nameField is an invisible textfield object, and nameDisplay is a text display object that shows its content.

#5

Additionally the keyboard remains extremely laggy under these conditions.

#6

We’ve completely remedied the problem by moving everything that sets that text of the name display to a runtime enterframe event. Apparently how the text of a namefield is changed in the editing phase of the userInput event in iOS 7 is not consistant with how it was in previous versions. Any lag was fixed by simply delaying the keyboard’s focus assignment until after any menu transitions were completed.

#7

I’m confused. I have an app about ready to submit that makes heavy use of the keyboard. have not tested in ios7 unfortunately. Can you summarize what steps I need to take to ensure this problem does not occur? Is it only a problem for your particular way of doing things?

#8

Basically, we had to limit the length of the line of text and set the text of a text object to the text of the field. We made the field invisible. We did this by, in the editing phase of the userInput listener, setting the fields text to string.sub of the fields text and setting the text objects text to the field’s text. For whatever reason, the way the text is updated in iOS 7 seems to be different from previous versions and the result was that the text object’s text lagged a letter behind. We moved this update to an enterFrame listener and it worked correctly. If you aren’t limiting the text or setting a value to the text in the editing event, you should be fine. And from our tests the submitted/ended events are still working fine.

#9

Ok cheers, yeah I’m not doing any of those fancy things. Just a regular editable native text box.

If you’re using your own custom textfield but using the native one as a controller… how are people supposed to edit? Or is that not a priority for you. Just curious.

#10

The keyboard automatically focuses on the invisible field when you go to the screen and unfocuses when you either tap a button on the screen or just hit the return button. It’s a name entry screen so it also checks that you don’t have it blank. In another place you’re able to place text objects on screen using a few different selectable fonts and its the same basic idea. It’s an art app.

#11

The issue appears to have, oddly enough, been how string.sub behaves in iOS 7. I added a check for length of the string before limiting it with string.sub - in previous versions the length check beforehand was unnecessary.

#12

Hi @Shady Guy,

Can you please post the basic code you’re using to do this, for the benefit of others who may encounter similar behavior?

Thanks,

Brent Sorrentino

#13

Well I jumped the gun if my post suggested its completely fixed - previously it just ignored all input, but now it seems to be not registering the first keystroke and then lagging a letter behind. The listener is as follows:

local function finishTyping(event)

        if event.phase==“editing” then

                    if(string.len(nameField.text)>10) then

                        nameField.text = string.sub(nameField.text,1,10)

                    end

            nameDisplay.text = nameField.text

        end

        

        if event.phase==“submitted” and nameField.text:len()>0 then

                    killTyping()

        end

            end

–

killTyping is a function that just transitions some menu elements and sets keyboard focus to nil.

nameField is an invisible textfield object, and nameDisplay is a text display object that shows its content.

#14

Additionally the keyboard remains extremely laggy under these conditions.

#15

We’ve completely remedied the problem by moving everything that sets that text of the name display to a runtime enterframe event. Apparently how the text of a namefield is changed in the editing phase of the userInput event in iOS 7 is not consistant with how it was in previous versions. Any lag was fixed by simply delaying the keyboard’s focus assignment until after any menu transitions were completed.

#16

I’m confused. I have an app about ready to submit that makes heavy use of the keyboard. have not tested in ios7 unfortunately. Can you summarize what steps I need to take to ensure this problem does not occur? Is it only a problem for your particular way of doing things?

#17

Basically, we had to limit the length of the line of text and set the text of a text object to the text of the field. We made the field invisible. We did this by, in the editing phase of the userInput listener, setting the fields text to string.sub of the fields text and setting the text objects text to the field’s text. For whatever reason, the way the text is updated in iOS 7 seems to be different from previous versions and the result was that the text object’s text lagged a letter behind. We moved this update to an enterFrame listener and it worked correctly. If you aren’t limiting the text or setting a value to the text in the editing event, you should be fine. And from our tests the submitted/ended events are still working fine.

#18

Ok cheers, yeah I’m not doing any of those fancy things. Just a regular editable native text box.

If you’re using your own custom textfield but using the native one as a controller… how are people supposed to edit? Or is that not a priority for you. Just curious.

#19

The keyboard automatically focuses on the invisible field when you go to the screen and unfocuses when you either tap a button on the screen or just hit the return button. It’s a name entry screen so it also checks that you don’t have it blank. In another place you’re able to place text objects on screen using a few different selectable fonts and its the same basic idea. It’s an art app.

#20

Can you explain this or post your enter frame code? I moved my update code from the editing stage to an enter frame but it is still lagging one character behind like you stated. I am using a hidden textfield as you mentioned… the so called layering hack.