Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

No event was triggered when the dismiss the keyboard button was pressed on Nexus 7.
Started by hexor.dev Sep 17 2013 11:57 PM

52 replies to this topic
android tablet keyboard nexus 7 corona event
[TOPIC CONTROLS]
Page 2 of 3 1 2 3
This topic has been archived. This means that you cannot reply to this topic.
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#26

cristianomnsantos

[GLOBAL: userInfoPane.html]
cristianomnsantos
  • Observer

  • 13 posts
  • Corona SDK

Well, yes. Right now I'm doing something similar to that but mannually. So basically, I want an effect on Android like what this line does:

android:windowSoftInputMode="adjustResize"

But I believe that this wouldn't be easy to do for iOS right? And it would go against the way that Corona works?



[TOPIC: post.html]
#27

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

Yeah, that's the Android setting we would have to enable in order for it to slide the text field into view.  We currently have it disabled in code because we ran into other issues with it at the time (that might no longer be an issue anymore), but that's the right approach in my opinion.  The real trick is finding a way to get iOS to do this.  Normally you do it via a UISlideView, but we have to get it to cooperate with the OpenGL view that we're using so that the text fields and OpenGL view move together.  It's been a couple years since we've last looked into this, but that was thing that I remember that was blocking us.

 

Right now we're focusing on finishing graphics 2.0 and getting it into the next release.  I know the team has refactored the iOS view/controller code.  So, it might be worth looking into this again after the release.

 

If you can think of any other ideas, then I'd love to hear it.



[TOPIC: post.html]
#28

cristianomnsantos

[GLOBAL: userInfoPane.html]
cristianomnsantos
  • Observer

  • 13 posts
  • Corona SDK

Well, I don't know to much of iOS yet but yes, what you said seems to be the right approach. Maybe when you get into it again, you can find a way too to control the text fields in order to be able to, for example, show a general loading screen over the text fields and other things like that =).

 

If I remember any other way of doing that, I will post here ^^.



[TOPIC: post.html]
#29

cristianomnsantos

[GLOBAL: userInfoPane.html]
cristianomnsantos
  • Observer

  • 13 posts
  • Corona SDK

Hi again =)

 

I searched a little about iOS and saw that there are many people controlling the opengl view manually when using a uiscrollview. Isn't it possible to make "widget.newScrollView" use that approach and let we use native elements inside of it? That way, I think that's possible to resize the content when keyboard appears on iOS right?

 

And just a last question. As I said, I don't know to much of iOS programming but, isn't it possible to have 2 opengl views? That way, things like overlaying menu or loading could appear above native elements right?



[TOPIC: post.html]
#30

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

The only problem with trying to handle this ourselves is that we have no way to know how tall the virtual keyboard is.  The OS just doesn't provide a reliable means of fetching it.  So, to do this right, we have no choice but to let the OS handle it for us.  The only solution that I can think of is to assume that the top portion of the screen will always be visible when a text field receives the focus, which "should" be the case on all devices.

 

By the way, I've written this up as a task to be re-investigated so that this won't be forgotten.



[TOPIC: post.html]
#31

cristianomnsantos

[GLOBAL: userInfoPane.html]
cristianomnsantos
  • Observer

  • 13 posts
  • Corona SDK

So iOS doesn't have a way to get the height of the keyboard? I thought it could be achieved with something like that: https://developer.appcelerator.com/question/155519/how-to-get-the-height-of-ios-keyboard

 

Thanks for all the help Joshua =)



[TOPIC: post.html]
#32

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

I just talked to one of our iOS developers now.  He said it is actually possible to get the keyboard height on that platform.  So, I stand corrected.  It's just not possible on Android.  However, it looks like making iOS automatically scroll the OpenGL view and its text field together is what's problematic... which happens to be easy on Android.  So, it looks like we're dealing with 2 platforms having totally different ways of handling this.  *sigh*



[TOPIC: post.html]
#33

cristianomnsantos

[GLOBAL: userInfoPane.html]
cristianomnsantos
  • Observer

  • 13 posts
  • Corona SDK

Ah ok, So in order to make it work, one of them must be done manually =S



[TOPIC: post.html]
#34

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

Yeah.  I'm thinking that we would have to slide the iOS view ourselves.  Since the keyboard height is known on iOS, this should be possible.  On Android, we should be able to have the OS do it automatically.  This seems to be the best cross-platform way to handle it.  The only possible issue that I can think of here is that it might not be enough to slide the text field into view.  You might want a label above the text field to be visible as well.  Something that might describe what type of text that field expects.  Or perhaps I'm overthinking it.  Perhaps a "placeholder text" in the text field might serve the same purpose.



[TOPIC: post.html]
#35

primoz.cerar

[GLOBAL: userInfoPane.html]
primoz.cerar
  • Contributor

  • 455 posts
  • Corona SDK

I definitely second this as it is a great draw back for business apps. The way native apps do this is to reposition the content so the text field sits on top of the keyboard with the added option of placing a button bar between the keyboard and text field. In landscape however the text field is extended to fill the available space with a done button on the right. Either way pressing the back button (or dismiss I imagine) reverts everything to the original state. This is what we need as currently we have only two options both of which are bad.

1. Don't do anything and the user can't see what he is typing if the text field is behind the keyboard

2. Custom handle the positioning and in the event the user cancels the keyboard (with back or dismiss) the user is left with the content repositioned until he presses something else.



[TOPIC: post.html]
#36

primoz.cerar

[GLOBAL: userInfoPane.html]
primoz.cerar
  • Contributor

  • 455 posts
  • Corona SDK

My current fix to this is wrapper for the text field. I have my own newtextfield function that handles everything in the background. By the default it is a custom drawn text field which is just a display group (added bonus you can put it in a scroll view) and when it's clicked it hides the parent which was provided in the newtextfield function (I actualy hide the whole scene except background) creates a real textfield without background and drawn exactly the same as the placeholder display group, but it's placed at the top of the screen with a post button on the right side. Optionaly it takes a label (or any other object) with it if it was provided in the new function and places the textfield below it. If a user then cancels the input with a back or dismiss button they are left with nothing but the text field (optional label above it) and the post button. Pressing the post button (or done on keyboard if it's still active or, if handled in app another back button press) returns everything to it's original state and updates the placeholder display group with the text entered. It also manages width if it's too big to fit next to the button and provides hint functionality when the text is empty, handles secure (password) input (hint possible), keyboard type, ... If there will be interest I will post the code but it is currently tied in to some other util units I use, so I would have to peel it out. It's not ideal but it's definitely better than covering the input with the keyboard or showing displaced content on keyboard dismiss. Still hoping for a native solution.

 

Cheers.



[TOPIC: post.html]
#37

jleigh

[GLOBAL: userInfoPane.html]
jleigh
  • Enthusiast

  • 38 posts
  • Corona SDK

"If your intent is to ensure that the text field is visible when the virtual keyboard is shown"

 

That's exactly what we're trying to do. It's just a bad user experience if they can't see the field they are typing into.

 

"the best solution is to have the OS slide the view to a position where it is visible, because only the OS knows the actual height of the keyboard."

 

So how do we tell the OS to do this from a Corona app?

 

"Unfortunately, Corona apps do not have this ability."

 

So you are suggesting something that we can't actually do?



[TOPIC: post.html]
#38

tiago.rodrigues

[GLOBAL: userInfoPane.html]
tiago.rodrigues
  • Observer

  • 7 posts
  • Corona SDK

I'm having the same problem. This problem has not been solved?



[TOPIC: post.html]
#39

primoz.cerar

[GLOBAL: userInfoPane.html]
primoz.cerar
  • Contributor

  • 455 posts
  • Corona SDK

No. There are only ways to mitigate the problem. You can present an input screen that hides the content behind it and position the text field on the top part off the screen to make sure the keyboard does not cover it and provide a submit button or something for when the user cancels the keyboard but you need a placeholder for the input field in that case or leave the content offset until the user presses something else.



[TOPIC: post.html]
#40

tiago.rodrigues

[GLOBAL: userInfoPane.html]
tiago.rodrigues
  • Observer

  • 7 posts
  • Corona SDK

That I can, but it does not solve the problem. If the User does not "tap" something other, textfield remains out of place. Thanks for help



[TOPIC: post.html]
#41

farmer

[GLOBAL: userInfoPane.html]
farmer
  • Observer

  • 23 posts
  • Corona SDK

Hi

The correct input field position is very basic requirement for a normal non-game app, if Corona SDK cannot provide their owned widget input in Android at this moment, as least SDK can provide as much key response as possible.

The keyboard dismissed or not is very important for programmer to put textfield or textbox in right position. Corona SDK should sent back the key response as much as possible.

There are several ways to dismiss keyboard such as : "Back" key, "V" key or like HTC series' "square key" in HTC soft keyboard. (which can be found in attached image with red circle.)Attached File  HTC 2014-06-08_11-30-05.png   62.7KB   1 downloads

I can get "Back" key response by [[ Runtime:addEventListener( "key", onKeyEvent ) ]], but I failed to get other key response.

According Google Android SDK seem to have solution for this issue, but it still need Coron Lab to implement it in corona sdk.

=============================================================================
public boolean onKeyPreIme (int keyCode, KeyEvent event)
Added in API level 3
 

Handle a key event before it is processed by any input method associated with the view hierarchy. This can be used to intercept key events in special situations before the IME consumes them; a typical example would be handling the BACK key to update the application's UI instead of allowing the IME to see it and close itself.

 
Parameters keyCode The value in event.getKeyCode(). event Description of the key event.
 
Returns

    If you handled the event, return true. If you want to allow the event to be handled by the next receiver, return false.
 



[TOPIC: post.html]
#42

yosu

[GLOBAL: userInfoPane.html]
yosu
  • Contributor

  • 554 posts
  • Corona SDK

Same issue here... Hope Corona can have a fix for this, so I can intercept 'keyboard close' events. 

 

Here is how i virtually solve it. May annoy some users, but this is the best that I can think of....

 

1) Have a runtime listener, and always set keyboard focus on the native text field (native.setKeyboardFocus). I start this listener on event.phase = began.

2) Only stop the runtime listener, if the text field event is 'submits/done/ended'



[TOPIC: post.html]
#43

zalacans

[GLOBAL: userInfoPane.html]
zalacans
  • Observer

  • 26 posts
  • Corona SDK

Up!

 

We need an event when keyboard is dismissed!

 

Other android apps can do it properly.



[TOPIC: post.html]
#44

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

As I've mentioned previously in this forum thread, there is no reliable means of knowing when the virtual keyboard is shown/hidden on Android.  It's all handled by the operating system.

 

But that said, we *do* have an experimental API that you can enable in the "build.settings" file that will set up the app to be slid/panned by the operating system when the virtual keyboard is shown/hidden.  Have a look here for more details...

   http://forums.coronalabs.com/topic/50905-detect-keyboard-height/?p=272745



[TOPIC: post.html]
#45

zalacans

[GLOBAL: userInfoPane.html]
zalacans
  • Observer

  • 26 posts
  • Corona SDK

Well Joshua, I've put that on and it seems to work great so far on my device!

You guys gotta document this somewhere! Maybe in the textField API.

 

Are there any known issues about it? Aside from the status bar detail you mentioned there.

 

Thanks



[TOPIC: post.html]
#46

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

On Android, the only other limitation that I'm aware of (other than the status bar) is that it *only* works for TextFields and TextBoxes.  It won't work for text fields inside of WebViews.  Other than that, it seems pretty solid to me.  I just haven't gotten much feedback from other Corona developers yet on it... but perhaps this is a case of no news is good news.  :)

 

We currently have it flagged as experimental because our iOS equivalent of this setting has some limitations/issues that we haven't had time work out yet.  Porting everything to 64-bit kept our iOS developers super busy in the past couple months.



[TOPIC: post.html]
#47

zalacans

[GLOBAL: userInfoPane.html]
zalacans
  • Observer

  • 26 posts
  • Corona SDK

Alright nice  :)

 

Thanks again!



[TOPIC: post.html]
#48

patso

[GLOBAL: userInfoPane.html]
patso
  • Contributor

  • 135 posts
  • Corona SDK

Hi all,
I was trying to apply hidden rect method to dismiss the keyboard on tap. However the textbook seems not to propagate touch to the rect beneath it. What is the matter.
my code:
 

local hidRect
local onHidRect = function(event)
print("touch")
native.setKeyboardFocus( nil )
hidRect:removeSelf( )
hidRect = nil

return true
end


hidRect = display.newRect( x,y,W,H )
   hidRect:setFillColor( 1,1,1,1 )
   hidRect:addEventListener( "tap", onHidRect )

local function onTextBox( event )
    if ( "began" == event.phase ) then
      print("began")
    native.setKeyboardFocus(textBox)
      elseif ("editing" ==event.phase) then

    texttosend = event.target.text

    elseif ( "submitted" == event.phase ) then ---or ("ended" == event.phase) then
        
        native.setKeyboardFocus( nil )
        texttoSend = event.target.text
        
    end

end


[TOPIC: post.html]
#49

Joshua Quick

[GLOBAL: userInfoPane.html]
Joshua Quick
  • Moderator

  • 3,397 posts
  • Corona Staff

You cannot receive "touch" or "tap" events when the user touches native UI.  This is because native UI will steal the event for its own purposes.  This is actually how it works at the native UI level on *all* platforms (Apple, Google, and Microsoft).

 

What you can do instead is detect when a native TextField or TextBox receives/loses the focus.  You can detect this via the "began" and "ended" phases from a TextField/TextBox's "userInput" events.



[TOPIC: post.html]
#50

patso

[GLOBAL: userInfoPane.html]
patso
  • Contributor

  • 135 posts
  • Corona SDK

You cannot receive "touch" or "tap" events when the user touches native UI.  This is because native UI will steal the event for its own purposes.  This is actually how it works at the native UI level on *all* platforms (Apple, Google, and Microsoft).

 

What you can do instead is detect when a native TextField or TextBox receives/loses the focus.  You can detect this via the "began" and "ended" phases from a TextField/TextBox's "userInput" events.

I see. I was playing with began and ended phases but still can't achieve what I want. You see, upper part of the screen is the textbox and the lower is covered by the keyboard, so there is no empty space to move focus from the textbox. (there is the upper panel, but it is not intuitive at all from UX point of view to tap the panel when you want to dismiss the keyboard)




[topic_controls]
Page 2 of 3 1 2 3
 
[/topic_controls]