NME Android menu key event

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

NME Android menu key event

Daniel Uranga
Im trying to catch the Android menu keydown event (Lib.current.stage.addEventListener(KeyboardEvent.KeyDown, func)), but its not working. I can catch center key and it gets mapped to enter (ASCII 13).
Is this currently possible? Did anyone accomplished it?

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Daniel Uranga
I modified MainView.java line 204 method onKeyDown, and it works ok now. Dont know if this solution is the best.
If this is ok, can be added to oficial NME repository?

code:

@Override
    public boolean onKeyDown(final int inKeyCode, KeyEvent event) {
         //Log.e("VIEW","onKeyDown " + inKeyCode);
         final MainView me = this;
         final int keyCode = translateKey(inKeyCode,event);
         //Log.e("VIEW","translatedKey " + keyCode);
         if (keyCode!=0 || inKeyCode!=0) {
             queueEvent(new Runnable() {
                 // This method will be called on the rendering thread:
                 public void run() {
                     me.HandleResult(NME.onKeyChange((keyCode!=0)? keyCode : inKeyCode,true));
                 }});
             return true;
         }
         return super.onKeyDown(inKeyCode, event);
     }


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

singmajesty
Without modification, if you add a keyboard event listener to  
Lib.current.stage, do you get an event when they press the home button?

I know that's the way the back button seems to work. If you find the right  
key code you should be able to watch for it




On Thu, 08 Sep 2011 09:09:30 -0700, Daniel Uranga  
<[hidden email]> wrote:

> I modified MainView.java line 204 method onKeyDown, and it works ok now.
> Dont know if this solution is the best.
> If this is ok, can be added to oficial NME repository?
>
> code:
>
> @Override
>     public boolean onKeyDown(final int inKeyCode, KeyEvent event) {
>          //Log.e("VIEW","onKeyDown " + inKeyCode);
>          final MainView me = this;
>          final int keyCode = translateKey(inKeyCode,event);
>          //Log.e("VIEW","translatedKey " + keyCode);
>          if (keyCode!=0 || inKeyCode!=0) {
>              queueEvent(new Runnable() {
>                  // This method will be called on the rendering thread:
>                  public void run() {
>                      me.HandleResult(NME.onKeyChange((keyCode!=0)?  
> keyCode :
> inKeyCode,true));
>                  }});
>              return true;
>          }
>          return super.onKeyDown(inKeyCode, event);
>      }


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Matt Greene
I can capture it now, the keycode is 27. But the problem is stopping the event from propagating downward. 

Neither of these work:
event.stopImmediatePropagation();
event.stopPropagation();

So right now when you hit back, you can detect it, but your app immediately closes.

-Matt

On Thu, Sep 8, 2011 at 7:36 PM, Joshua Granick <[hidden email]> wrote:
Without modification, if you add a keyboard event listener to Lib.current.stage, do you get an event when they press the home button?

I know that's the way the back button seems to work. If you find the right key code you should be able to watch for it





On Thu, 08 Sep 2011 09:09:30 -0700, Daniel Uranga <[hidden email]> wrote:

I modified MainView.java line 204 method onKeyDown, and it works ok now.
Dont know if this solution is the best.
If this is ok, can be added to oficial NME repository?

code:

@Override
   public boolean onKeyDown(final int inKeyCode, KeyEvent event) {
        //Log.e("VIEW","onKeyDown " + inKeyCode);
        final MainView me = this;
        final int keyCode = translateKey(inKeyCode,event);
        //Log.e("VIEW","translatedKey " + keyCode);
        if (keyCode!=0 || inKeyCode!=0) {
            queueEvent(new Runnable() {
                // This method will be called on the rendering thread:
                public void run() {
                    me.HandleResult(NME.onKeyChange((keyCode!=0)? keyCode :
inKeyCode,true));
                }});
            return true;
        }
        return super.onKeyDown(inKeyCode, event);
    }


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Matt Greene
Actually I take that back. You need to capture BOTH the KEY_UP and KEY_DOWN event, check for keycode 27 and then stop the propagation on BOTH.

-Matt

On Thu, Sep 8, 2011 at 7:47 PM, Matt Greene <[hidden email]> wrote:
I can capture it now, the keycode is 27. But the problem is stopping the event from propagating downward. 

Neither of these work:
event.stopImmediatePropagation();
event.stopPropagation();

So right now when you hit back, you can detect it, but your app immediately closes.

-Matt

On Thu, Sep 8, 2011 at 7:36 PM, Joshua Granick <[hidden email]> wrote:
Without modification, if you add a keyboard event listener to Lib.current.stage, do you get an event when they press the home button?

I know that's the way the back button seems to work. If you find the right key code you should be able to watch for it





On Thu, 08 Sep 2011 09:09:30 -0700, Daniel Uranga <[hidden email]> wrote:

I modified MainView.java line 204 method onKeyDown, and it works ok now.
Dont know if this solution is the best.
If this is ok, can be added to oficial NME repository?

code:

@Override
   public boolean onKeyDown(final int inKeyCode, KeyEvent event) {
        //Log.e("VIEW","onKeyDown " + inKeyCode);
        final MainView me = this;
        final int keyCode = translateKey(inKeyCode,event);
        //Log.e("VIEW","translatedKey " + keyCode);
        if (keyCode!=0 || inKeyCode!=0) {
            queueEvent(new Runnable() {
                // This method will be called on the rendering thread:
                public void run() {
                    me.HandleResult(NME.onKeyChange((keyCode!=0)? keyCode :
inKeyCode,true));
                }});
            return true;
        }
        return super.onKeyDown(inKeyCode, event);
    }


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Matt Greene
I should further clarify that this one works for the Back button. The Home, Menu, and Search buttons are not capturable as a KeyboardEvent.

-Matt

On Thu, Sep 8, 2011 at 7:56 PM, Matt Greene <[hidden email]> wrote:
Actually I take that back. You need to capture BOTH the KEY_UP and KEY_DOWN event, check for keycode 27 and then stop the propagation on BOTH.

-Matt


On Thu, Sep 8, 2011 at 7:47 PM, Matt Greene <[hidden email]> wrote:
I can capture it now, the keycode is 27. But the problem is stopping the event from propagating downward. 

Neither of these work:
event.stopImmediatePropagation();
event.stopPropagation();

So right now when you hit back, you can detect it, but your app immediately closes.

-Matt

On Thu, Sep 8, 2011 at 7:36 PM, Joshua Granick <[hidden email]> wrote:
Without modification, if you add a keyboard event listener to Lib.current.stage, do you get an event when they press the home button?

I know that's the way the back button seems to work. If you find the right key code you should be able to watch for it





On Thu, 08 Sep 2011 09:09:30 -0700, Daniel Uranga <[hidden email]> wrote:

I modified MainView.java line 204 method onKeyDown, and it works ok now.
Dont know if this solution is the best.
If this is ok, can be added to oficial NME repository?

code:

@Override
   public boolean onKeyDown(final int inKeyCode, KeyEvent event) {
        //Log.e("VIEW","onKeyDown " + inKeyCode);
        final MainView me = this;
        final int keyCode = translateKey(inKeyCode,event);
        //Log.e("VIEW","translatedKey " + keyCode);
        if (keyCode!=0 || inKeyCode!=0) {
            queueEvent(new Runnable() {
                // This method will be called on the rendering thread:
                public void run() {
                    me.HandleResult(NME.onKeyChange((keyCode!=0)? keyCode :
inKeyCode,true));
                }});
            return true;
        }
        return super.onKeyDown(inKeyCode, event);
    }


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org




--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Mike Wiering
In reply to this post by Matt Greene
Just make the function return false to ignore the backbutton.
The keycode should be 4 (android.view.KeyEvent.KEYCODE_BACK = 4)

On Fri, Sep 9, 2011 at 1:47 AM, Matt Greene <[hidden email]> wrote:

> I can capture it now, the keycode is 27. But the problem is stopping the
> event from propagating downward.
> Neither of these work:
> event.stopImmediatePropagation();
> event.stopPropagation();
> So right now when you hit back, you can detect it, but your app immediately
> closes.
> -Matt
> On Thu, Sep 8, 2011 at 7:36 PM, Joshua Granick <[hidden email]>
> wrote:
>>
>> Without modification, if you add a keyboard event listener to
>> Lib.current.stage, do you get an event when they press the home button?
>>
>> I know that's the way the back button seems to work. If you find the right
>> key code you should be able to watch for it
>>
>>
>>
>>
>> On Thu, 08 Sep 2011 09:09:30 -0700, Daniel Uranga
>> <[hidden email]> wrote:
>>
>>> I modified MainView.java line 204 method onKeyDown, and it works ok now.
>>> Dont know if this solution is the best.
>>> If this is ok, can be added to oficial NME repository?
>>>
>>> code:
>>>
>>> @Override
>>>    public boolean onKeyDown(final int inKeyCode, KeyEvent event) {
>>>         //Log.e("VIEW","onKeyDown " + inKeyCode);
>>>         final MainView me = this;
>>>         final int keyCode = translateKey(inKeyCode,event);
>>>         //Log.e("VIEW","translatedKey " + keyCode);
>>>         if (keyCode!=0 || inKeyCode!=0) {
>>>             queueEvent(new Runnable() {
>>>                 // This method will be called on the rendering thread:
>>>                 public void run() {
>>>                     me.HandleResult(NME.onKeyChange((keyCode!=0)? keyCode
>>> :
>>> inKeyCode,true));
>>>                 }});
>>>             return true;
>>>         }
>>>         return super.onKeyDown(inKeyCode, event);
>>>     }
>>
>>
>> --
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Gamehaxe
In reply to this post by Matt Greene
Hi,
Yes, you are right - you need to stop both.
This code could perhaps use some work, but I wanted the
default case of "back" to "close" (minimise) the app.

Hugh

> Actually I take that back. You need to capture BOTH the KEY_UP and  
> KEY_DOWN
> event, check for keycode 27 and then stop the propagation on BOTH.
>
> -Matt
>
> On Thu, Sep 8, 2011 at 7:47 PM, Matt Greene <[hidden email]> wrote:
>
>> I can capture it now, the keycode is 27. But the problem is stopping the
>> event from propagating downward.
>>
>> Neither of these work:
>> event.stopImmediatePropagation();
>> event.stopPropagation();
>>
>> So right now when you hit back, you can detect it, but your app  
>> immediately
>> closes.
>>
>> -Matt
>>
>> On Thu, Sep 8, 2011 at 7:36 PM, Joshua Granick  
>> <[hidden email]
>> > wrote:
>>
>>> Without modification, if you add a keyboard event listener to
>>> Lib.current.stage, do you get an event when they press the home button?
>>>
>>> I know that's the way the back button seems to work. If you find the  
>>> right
>>> key code you should be able to watch for it
>>>
>>>
>>>
>>>
>>>
>>> On Thu, 08 Sep 2011 09:09:30 -0700, Daniel Uranga <
>>> [hidden email]> wrote:
>>>
>>>  I modified MainView.java line 204 method onKeyDown, and it works ok  
>>> now.
>>>> Dont know if this solution is the best.
>>>> If this is ok, can be added to oficial NME repository?
>>>>
>>>> code:
>>>>
>>>> @Override
>>>>    public boolean onKeyDown(final int inKeyCode, KeyEvent event) {
>>>>         //Log.e("VIEW","onKeyDown " + inKeyCode);
>>>>         final MainView me = this;
>>>>         final int keyCode = translateKey(inKeyCode,event);
>>>>         //Log.e("VIEW","translatedKey " + keyCode);
>>>>         if (keyCode!=0 || inKeyCode!=0) {
>>>>             queueEvent(new Runnable() {
>>>>                 // This method will be called on the rendering thread:
>>>>                 public void run() {
>>>>                     me.HandleResult(NME.**onKeyChange((keyCode!=0)?
>>>> keyCode :
>>>> inKeyCode,true));
>>>>                 }});
>>>>             return true;
>>>>         }
>>>>         return super.onKeyDown(inKeyCode, event);
>>>>     }
>>>>
>>>
>>>
>>> --
>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Daniel Uranga
Without modification I was receiving no event from the haxe side.
"translateKey" method from MainView.java was translating KeyEvent.KEYCODE_MENU into 0.
I added a case so now: "case KeyEvent.KEYCODE_MENU: return 319;" (319 is defined as "MENU" in NME side).
I also modified "translateKey" so it returns the input code it received instead of 0 when it doesnt know how to translate.
I propose to modify translateKey method like this: http://pastebin.com/f9N5CfJ3

Daniel

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Pimm Hogeling
Guys, I love all of you. But I have to set two things straight.

Capturing interaction through the back button via KeyEvents is uncommon. The normal way of doing this, is by overriding onBackPressed.

Furthermore, the default behaviour of the back button does not "minimise" the app; it finishes it.

2011/9/9 Daniel Uranga <[hidden email]>
Without modification I was receiving no event from the haxe side.
"translateKey" method from MainView.java was translating KeyEvent.KEYCODE_MENU into 0.
I added a case so now: "case KeyEvent.KEYCODE_MENU: return 319;" (319 is defined as "MENU" in NME side).
I also modified "translateKey" so it returns the input code it received instead of 0 when it doesnt know how to translate.
I propose to modify translateKey method like this: http://pastebin.com/f9N5CfJ3

Daniel

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Gamehaxe
Hi,
It sort of "finishes" the activity, but in exactly the same way that  
minimising
a desktop app "finishes" with the window.  The key point is that you can  
"unfinish"
the application by, for example, clicking in the icon again.  You pick up
exactly where you left off, so I'm not sure "finish" means that android  
think is means.
In a game, I think that the "back" key is very very similar to the "escape"
key.  ie, close a dialog, close a window, go back to the menu screen etc.
So I would like to avoid:
#if andoid
onBackPressed() doX();
#end
...
onKey(e)
#if !android
if (code==ESCAPE) doX();
#end

Each OS comes along and thinks that they are so special and that their way
of doing something is THE ONE TRUE WAY, (objectC is the best language ever,
shared objects should be called "dlls", you should separate directories  
with
"/", you should use "DYLD_LIBARARY_PATH" of "LD_LIBRARY_PATH", you only
need to support java - all other languages are redundant, you should get  
your
users to run a configure script to get something working, just stick
a link in /usr/bin (why would you want to do anything else?) ... etc etc)

But ultimately all programming is pretty much the same and every new thing
you make someone learn is just annoying and pretty pointless.

I understand that some OS features may require specific solutions,
but I'm not convinced that the number of situations is anywhere near
the number of cases the OS peddlers would have you believe.

In the specific case of back -> escape, I think the problem lies in having
to cancel both the down-and-up and lack of doco, but I still think they
are pretty much the same action.

Hugh


> Guys, I love all of you. But I have to set two things straight.
>
> Capturing interaction through the back button via KeyEvents is uncommon.  
> The
> normal way of doing this, is by overriding
> onBackPressed<http://developer.android.com/reference/android/app/Activity.html#onBackPressed%28%29>
> .
>
> Furthermore, the default behaviour of the back button does not "minimise"
> the app; it finishes

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Benjamin Dasnois

Hi,

From my understanding Pimm is right since your process may get terminated (at least as far as I can remember).

On the other hand doing uncommon thing is not necessarily bad if it does not hurt the system. It may just make thing harder for other people who are used to the common way.

Regards,

Le 10 sept. 2011 04:29, "Gamehaxe" <[hidden email]> a écrit :
> Hi,
> It sort of "finishes" the activity, but in exactly the same way that
> minimising
> a desktop app "finishes" with the window. The key point is that you can
> "unfinish"
> the application by, for example, clicking in the icon again. You pick up
> exactly where you left off, so I'm not sure "finish" means that android
> think is means.
> In a game, I think that the "back" key is very very similar to the "escape"
> key. ie, close a dialog, close a window, go back to the menu screen etc.
> So I would like to avoid:
> #if andoid
> onBackPressed() doX();
> #end
> ...
> onKey(e)
> #if !android
> if (code==ESCAPE) doX();
> #end
>
> Each OS comes along and thinks that they are so special and that their way
> of doing something is THE ONE TRUE WAY, (objectC is the best language ever,
> shared objects should be called "dlls", you should separate directories
> with
> "/", you should use "DYLD_LIBARARY_PATH" of "LD_LIBRARY_PATH", you only
> need to support java - all other languages are redundant, you should get
> your
> users to run a configure script to get something working, just stick
> a link in /usr/bin (why would you want to do anything else?) ... etc etc)
>
> But ultimately all programming is pretty much the same and every new thing
> you make someone learn is just annoying and pretty pointless.
>
> I understand that some OS features may require specific solutions,
> but I'm not convinced that the number of situations is anywhere near
> the number of cases the OS peddlers would have you believe.
>
> In the specific case of back -> escape, I think the problem lies in having
> to cancel both the down-and-up and lack of doco, but I still think they
> are pretty much the same action.
>
> Hugh
>
>
>> Guys, I love all of you. But I have to set two things straight.
>>
>> Capturing interaction through the back button via KeyEvents is uncommon.
>> The
>> normal way of doing this, is by overriding
>> onBackPressed<http://developer.android.com/reference/android/app/Activity.html#onBackPressed%28%29>
>> .
>>
>> Furthermore, the default behaviour of the back button does not "minimise"
>> the app; it finishes
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: NME Android menu key event

Pimm Hogeling
In reply to this post by Gamehaxe
Let me start by saying I completely feel Hugh's pain regarding every OS, language and framework to do things in their own special way.

With that said, Android - in my opinion - does have some sexy and revolutionary ideas, such as the way activities work. To summarise it in one sentence: it carries the burden of putting the activities in their appropriate state, the user uses apps instead of thinking about starting and closing them. Other sexy and revolutionary ideas include the intent system.

This is something you guys probably don't care about much, though. And this is getting mighty off-topic. Just keep these things in mind:

One. You must save the state of your activity in your onPause implementation and restore the state in your onResume implementation. Alternatively, you can save the state in onStop and restore it in onStart. This goes for games as well!

Two. When your activity is off the screen of the user ("minimised"), perhaps because the user pressed the home button, it isn't necessarily gone. In fact, it isn't over until the fat lady sings. When Android thinks your activity is no longer needed and is just taking up memory, it asks the fat lady for a chant. You can't predict when this'll happen. (You can detect this by implementing onDestroy.) When your activity is finished, however, it really is gone. This is what happens by default when the user presses the back button.

2011/9/10 Gamehaxe <[hidden email]>
Hi,
It sort of "finishes" the activity, but in exactly the same way that minimising
a desktop app "finishes" with the window.  The key point is that you can "unfinish"
the application by, for example, clicking in the icon again.  You pick up
exactly where you left off, so I'm not sure "finish" means that android think is means.
In a game, I think that the "back" key is very very similar to the "escape"
key.  ie, close a dialog, close a window, go back to the menu screen etc.
So I would like to avoid:
#if andoid
onBackPressed() doX();
#end
...
onKey(e)
#if !android
if (code==ESCAPE) doX();
#end

Each OS comes along and thinks that they are so special and that their way
of doing something is THE ONE TRUE WAY, (objectC is the best language ever,
shared objects should be called "dlls", you should separate directories with
"/", you should use "DYLD_LIBARARY_PATH" of "LD_LIBRARY_PATH", you only
need to support java - all other languages are redundant, you should get your
users to run a configure script to get something working, just stick
a link in /usr/bin (why would you want to do anything else?) ... etc etc)

But ultimately all programming is pretty much the same and every new thing
you make someone learn is just annoying and pretty pointless.

I understand that some OS features may require specific solutions,
but I'm not convinced that the number of situations is anywhere near
the number of cases the OS peddlers would have you believe.

In the specific case of back -> escape, I think the problem lies in having
to cancel both the down-and-up and lack of doco, but I still think they
are pretty much the same action.

Hugh


Guys, I love all of you. But I have to set two things straight.

Capturing interaction through the back button via KeyEvents is uncommon. The
normal way of doing this, is by overriding
onBackPressed<http://developer.android.com/reference/android/app/Activity.html#onBackPressed%28%29>

.

Furthermore, the default behaviour of the back button does not "minimise"
the app; it finishes

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org