I was running version 2012.2.913 and the input was still showing the "flying text box" on an HTC EVO 4G with Android 2.3.5.
My understanding was that this was "fixed" in the Q2 release. I don't think it was 100%. It did work fine on an HTC EVO 4G LTE with Android 4.x, but not an HTC EVO 4G running 2.x.
So I decided to try the latest internal build. I'm now running 2012.2.1002. That seems to have gotten rid of the flying text box, but there is still an issue with not being able to "long press" a key on Android 2.x AND 4.x. I'm running Android 4.0.3 and the long key presses result in double characters just as they do on 2.x.
Is there any hope for a fix in the future? It does not appear that it's going to be addressed in Android, and I know for a fact that even if it was, HTC is not longer making releases for the EVO 4G, so it would not matter. I understand that it appears to be an Android issue, but does that mean that we have no real solution for the HTC Android users?
Also, version 2012.2.1002 broke the styling on Navbar buttons on 2.x and 4.x devices. The buttons are cut off on the bottom and appear too large.
[EDIT] - After playing with this some more, the 2012.2.1002 build prevents the flying/double text box input, however, you can't see the data input on any text boxes that are under the popup keyboard. This makes it unusable.
Sean
My understanding was that this was "fixed" in the Q2 release. I don't think it was 100%. It did work fine on an HTC EVO 4G LTE with Android 4.x, but not an HTC EVO 4G running 2.x.
So I decided to try the latest internal build. I'm now running 2012.2.1002. That seems to have gotten rid of the flying text box, but there is still an issue with not being able to "long press" a key on Android 2.x AND 4.x. I'm running Android 4.0.3 and the long key presses result in double characters just as they do on 2.x.
Is there any hope for a fix in the future? It does not appear that it's going to be addressed in Android, and I know for a fact that even if it was, HTC is not longer making releases for the EVO 4G, so it would not matter. I understand that it appears to be an Android issue, but does that mean that we have no real solution for the HTC Android users?
Also, version 2012.2.1002 broke the styling on Navbar buttons on 2.x and 4.x devices. The buttons are cut off on the bottom and appear too large.
[EDIT] - After playing with this some more, the 2012.2.1002 build prevents the flying/double text box input, however, you can't see the data input on any text boxes that are under the popup keyboard. This makes it unusable.
Sean
5 Answers, 1 is accepted
0
Hi Sean,
Yes, there was an issue with the service pack, where the major version classes were not added as they should have. The next internal builds fixed that. However, the fake input is really important for the text entry in Android and hiding it has some negative effects as the one you describe. Another negative effect is that custom keyboards like Swype will stop working. So, you should carefully weigh the pros and cons of using it and maybe revert to the flying ones if long press is necessary. Google fixed the flying inputs issue in Jelly Bean, but they probably won't do so in older versions, so we're left on our own. Currently there's no better way of fixing this - if I find one, I'll be sure to let everyone affected know.
Can you send a sample page of the cutoff NavBar buttons issue? I can't seem to experience that.
Kind regards,
Kamen Bundev
the Telerik team
Yes, there was an issue with the service pack, where the major version classes were not added as they should have. The next internal builds fixed that. However, the fake input is really important for the text entry in Android and hiding it has some negative effects as the one you describe. Another negative effect is that custom keyboards like Swype will stop working. So, you should carefully weigh the pros and cons of using it and maybe revert to the flying ones if long press is necessary. Google fixed the flying inputs issue in Jelly Bean, but they probably won't do so in older versions, so we're left on our own. Currently there's no better way of fixing this - if I find one, I'll be sure to let everyone affected know.
Can you send a sample page of the cutoff NavBar buttons issue? I can't seem to experience that.
Kind regards,
Kamen Bundev
the Telerik team
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
0
Sean
Top achievements
Rank 1
Rank 1
answered on 09 Oct 2012, 02:44 PM
Kamen,
Thanks for the response.
I could live with the double input boxes if they remained over the target input area. The problem is that if you scroll the screen with one of the input boxes showing, all other input boxes don't display on top of the target input.
This can be seen on http://demos.kendoui.com/mobile/m/index.html in the Forms Overview. If you click on something like "Type Number" and then scroll the screen, any other input area that you click on appears off.
As for version 2012.2.1002, I'm using it without any overrides for the input styling and have the following issues:
1) Long press on HTC not working
2) Input fields on the lower half of the screen are hidden by the popup keyboard.
3) Nav buttons styling is off. I've attached good and bad images of this. Good is from 2012.2.913.
Sean
Thanks for the response.
I could live with the double input boxes if they remained over the target input area. The problem is that if you scroll the screen with one of the input boxes showing, all other input boxes don't display on top of the target input.
This can be seen on http://demos.kendoui.com/mobile/m/index.html in the Forms Overview. If you click on something like "Type Number" and then scroll the screen, any other input area that you click on appears off.
As for version 2012.2.1002, I'm using it without any overrides for the input styling and have the following issues:
1) Long press on HTC not working
2) Input fields on the lower half of the screen are hidden by the popup keyboard.
3) Nav buttons styling is off. I've attached good and bad images of this. Good is from 2012.2.913.
Sean
0
Hi Sean,
That's exactly the problem - if the fake inputs were staying were they are supposed to be, they wouldn't be in need of a workaround. We don't really have issue with the impossible styling of the active state, if the fake inputs translated along with the original ones. We use transforms to handle the custom scrolling and once translated, the form should stay translated in order to remain scrolled. However the fake inputs are not affected by translation and they appear where the input should be if not translated.
In version 1002 the workaround is in effect and it breaks the long press and probably scroll into view (if Android depends on the fake inputs for scroll into view to work, I wouldn't be surprised).
We are still looking for a viable fix for both flying inputs and keyboard issues, but currently only one of them can be fixed - the other one breaks.
The button styling specificity changed a little in 1002 after the NavBar button group styling landed and I will need a test case for the 3rd issue so that I can tell you how to fix it.
Greetings,
Kamen Bundev
the Telerik team
That's exactly the problem - if the fake inputs were staying were they are supposed to be, they wouldn't be in need of a workaround. We don't really have issue with the impossible styling of the active state, if the fake inputs translated along with the original ones. We use transforms to handle the custom scrolling and once translated, the form should stay translated in order to remain scrolled. However the fake inputs are not affected by translation and they appear where the input should be if not translated.
In version 1002 the workaround is in effect and it breaks the long press and probably scroll into view (if Android depends on the fake inputs for scroll into view to work, I wouldn't be surprised).
We are still looking for a viable fix for both flying inputs and keyboard issues, but currently only one of them can be fixed - the other one breaks.
The button styling specificity changed a little in 1002 after the NavBar button group styling landed and I will need a test case for the 3rd issue so that I can tell you how to fix it.
Greetings,
Kamen Bundev
the Telerik team
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
0
Sean
Top achievements
Rank 1
Rank 1
answered on 02 Feb 2013, 01:53 AM
I just tried 2012.3.1315 and the same problems exist on the HTC. Long press on the HTC keyboard doesn't work and you can't get to input boxes that are behind the popup keyboard.
Is there any hope of getting these issues resolved any time soon?
I'm still using 2012.2.913 which at least is functional on all of the platforms that I've tried.
Sean
Is there any hope of getting these issues resolved any time soon?
I'm still using 2012.2.913 which at least is functional on all of the platforms that I've tried.
Sean
0
Hi Sean,
As I already stated in this thread, the reason long press is working in 913 is due to the flying inputs fix regression. We added the fix back in later releases which unfortunately causes the long press to stop working as Android keyboards depend on the flying input. Check the Forms documentation article and use the CSS at the end of the article to switch off the fix and get your long press working in Kendo UI Mobile Q3 and later.
Regards,
Kamen Bundev
the Telerik team
As I already stated in this thread, the reason long press is working in 913 is due to the flying inputs fix regression. We added the fix back in later releases which unfortunately causes the long press to stop working as Android keyboards depend on the flying input. Check the Forms documentation article and use the CSS at the end of the article to switch off the fix and get your long press working in Kendo UI Mobile Q3 and later.
Regards,
Kamen Bundev
the Telerik team
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!