Suggest to add "OnKeyXXX" Annotations

Which examples looks better?

General:

    public boolean onKeyDown(int keyCode, KeyEvent event) {
        if (event.getKeyCode() == KeyEvent.KEYCODE_BACK) {
            return true;
        }

        return super.onKeyDown(keyCode, event);
    }

AA which i want to:

    @KeyDown(KeyEvent.KEYCODE_BACK)
    public boolean onPressedBack() {
        return true;
    }

(Same as Key Up/Long Press/Shortcut etc.)
Support "dispatch" parameters.

Compared with the EventBus I mentioned previously, this looks easier to write, and more practical.
What do you think?

Yeah, i was also thought about adding an annotation like this.

However, we have to carefully design the details. What annotation parameter we provide (action(s) and keycode(s))? Also how we combine these parameters to create the condition?

"Action(s)" can be:
"@KeyDown/@KeyUp/@KeyLongPress/@KeyShortcut"
Each of them can be Annotation(s)

"Keycode" is annotation's value, because it has too many choice, so more suitable as a parameter.

The KeyEvent can be used as the method parameter.

    @KeyDown(KeyEvent.KEYCODE_BACK)
    public boolean onPressedBack(KeyEvent event)

@yDelouis

I am not sure we should add so much annotations. Also we may use one annotation and add the action/flag as annotation parameter for better configurability.

@yDelouis WDYT?

@longclick

Hmm. I don't think so.

Multiple Annotations can be selected users more convenient.
We just need to choose one of the four most common event
("OnKeyDown/OnKeyUp/OnKeyLongPress/OnKeyShortcut")

BTW:

ClickEvents by Cookbook
@Touch/@Click/@longclick
@ItemClick/@ItemLongClick/@ItemSelected

Click events is another situation, they use different listeners.

onKeyXXX is the same.

Look at this one:

    public boolean onKeyDown(int keyCode, KeyEvent event) {
        if (event.getKeyCode() == KeyEvent.KEYCODE_BACK) {
            return true;
        }

        return super.onKeyDown(keyCode, event);
    }

You don't need to care about "KeyEvent.getAction()", because onKeyDown itself shows what is your own Action.

That's to say, each Action corresponding to each kind of method, which is the same as onClick/onLongClick.

In addition, I also hope to contribute some code to AA for everyone. It benefit to my own project too.

I can't just use AA. Because: No pain ,no gain 👍

Excuse me , another question:

What's the "Enhancement" means? Ready to write? or under consideration?

@yDelouis

We defnetly want this feature, but this is not totally ready yet for implementation, because we did not created the exact specification. Let's wait for @yDelouis's answer.
In the meantime, you can initialize the environment and examine the existing codebase, try to add an annotation etc.

@yDelouis

Okay!

Do you have any idea @yDelouis will be back? I haven't seen him lately

He was around three days ago. I do not know when he can get to this issue.

I think :

We should add one annotation for each method (@KeyDown, @KeyLongPress, @KeyMultiple, ...) because the methods have different parameter, so the validation will be different. For example, onKeyMutiple has a parameter int repeatCount and the user may want to use it.
The value of the annotations should be an array of keyCode and we should check if the actual keyCode is in this array, so that we can use the same annotation for different key codes.

Any thoughts ?

@yDelouis

@yDelouis I meeting you at last. :)

That's just what I was thinking.

What would you suggest I do for this issue? If not, I will do as you say :)

@yDelouis

@yDelouis OK, let's go with this way.

@jiongxuan feel free to contribute the feature, but first write down all annotations with all parameters and corresponding method signatures and generated code.

(1) OnKeyDown

    @KeyDown
    public boolean backPressed() {}

    @KeyDown(KeyEvent.KEYCODE_ESCAPE)
    public boolean onEscPressed(KeyEvent event) {}

Generate:

    @Override
    public boolean onKeyDown(int keyCode, KeyEvent event) {
        switch(keyCode) {
            case KeyEvent.KEYCODE_BACK:
                return backPressed();

            case KeyEvent.KEYCODE_ESCAPE:
                return onEscPressed(event);
        }

        return super.onKeyDown(keyCode, event);
    }

(2) OnKeyUp/OnKeyLongPress/OnKeyShortcut are very similar to OnKeyDown

(3) OnKeyMultiple

    @KeyMultiple
    public boolean backMultiplePressed() {}

    @KeyMultiple(KeyEvent.KEYCODE_ESCAPE)
    public void onEscMultiplePressed(KeyEvent event) {}

    @KeyMultiple(KeyEvent.KEYCODE_MENU)
    public boolean onMenuMultiplePressed(KeyEvent event, int repeatCount) {}

Generate:

    @Override
    public boolean onKeyMultiple(int keyCode, int repeatCount, KeyEvent event) {
        switch (keyCode) {
            case KeyEvent.KEYCODE_BACK:
                return backMultiplePressed();

            case KeyEvent.KEYCODE_ESCAPE:
                onEscMultiplePressed(event);
                return true;

            case KeyEvent.KEYCODE_MENU;
                return onMenuMultiplePressed(event, repeatCount);
        }

        return super.onKeyMultiple(keyCode, repeatCount, event);
    }

(4) Multi-Keycodes

    @KeyUp({KeyEvent.KEYCODE_ESCAPE, KeyEvent.KEYCODE_MENU})
    public boolean onKeyPressed(int keyCode, KeyEvent event) {}

Generate:

    @Override
    public boolean onKeyUp(int keyCode, KeyEvent event) {
        switch (keyCode) {
            case KeyEvent.KEYCODE_MENU:
            case KeyEvent.KEYCODE_ESCAPE:
                return onKeyPressed(keyCode, event);
        }

        return super.onKeyMultiple(keyCode, repeatCount, event);
    }

@WonderCsabo

Limitation:

(1) Each KeyCode can have only one correspondence method. Even if there are "Multi-Keycodes"

Wrong:

    @KeyDown
    public boolean backPressed() {}

    // ERROR: Same keycode used in this activity
    @KeyDown(KeyEvent.KEYCODE_BACK)
    public boolean onBackPressed(KeyEvent event) {}

    // ERROR: Also apply for Multi-Keycodes
    @KeyDown({KeyEvent.KEYCODE_BACK, KeyEvent.KEYCODE_MENU})
    public boolean onKeyPressed(int keyCode) {}

You should do it manually:

    // OK
    @KeyDown(KeyEvent.KEYCODE_BACK)
    public boolean onBackPressed(KeyEvent event) {
        ...
        if (!backPressed()) {
            return onKeyPressed(KeyEvent.KEYCODE_BACK);
        }
        ...
        return onBackPressed(event);
    }

(2) OnKeyLongPress can only used on Android 2.0+. OnKeyShortcut on Android 3.0+.
We'll report an error at compile time. Also, we need to specify in the Wiki

(3) At the moment, we don't support Fragment, because it does not support onKeyXX methods which write more complex.
If I have more free time, I will consider write it in future releases (4.0+, maybe).

@WonderCsabo @yDelouis @dodgex
Any great idea? :)

Looks good to me.

My English is not good, in order to avoid such problems such as English grammar, I still want to you to write down the Wiki and Cookbook part. :)

I take charge of to help you write the code, etc.

I have several comments:

you should use an array of key codes as the annotation parameter
why do you have the first limitation
why it is hard to work around the third limitation?
we can validate the second limitation
On Nov 20, 2014 9:39 AM, "Jiongxuan Zhang" notifications@github.com wrote:

My English is not good, in order to avoid such problems such as English
grammar, I still want to you to write down the Wiki and Cookbook part. :)

I take charge of to help you write the code, etc.

Reply to this email directly or view it on GitHub
#1238 (comment)
.

why do you have the first limitation

i think this is because of the posibility to return a boolean if the key has been handled. what to do if a method wants to return true or false here? when there would be an ensured calling order that might be something that the developer could workaround, but due to the current nature of random order i think this limitation is valid.

I Edit it for a while

you should use an array of key codes as the annotation parameter

Okay

why do you have the first limitation

For ex.

    @KeyDown(KeyEvent.KEYCODE_BACK)
    public boolean onBackPressed1(KeyEvent event) {
        Log.d(TAG, "Pressed: 1");
        return false;
    }

    @KeyDown(KeyEvent.KEYCODE_BACK)
    public boolean onBackPressed2(KeyEvent event) {
        Log.d(TAG, "Pressed: 2");
        return true;
    }

If we consider to run onBackPressed1 first, Is there no need to perform onBackPressed2?

There are ruled out the "random call" situation

why it is hard to work around the third limitation?

Fragment does not have onKeyXX methods, we must:

Check if Inheritance class has onKeyXX methods which is own written
Add some code to Activity (you know i mean)
Generate some code cross java classes

There was too mixed up for me, in fact :)

we can validate the second limitation

Sure.

Actually KeyEvent.Callback is implemented in lot of classes, not just in Activity. I think we should allow them in everywhere where they can be called and validate against whether it is implemented in the current class or not.

It is not implemented in Fragments, but it would be definitely useful. You can call getActivity().onKeyXXX there instead of onKeyXXX if (getActvity() != null).

@jiongxuan

@jiongxuan any news on this?

@WonderCsabo

@WonderCsabo
I'm sorry about that. I really do not have time to do it recently. Because there are some unforeseen circumstances I need to deal with.
I do this feature is expected to be completed after the Spring Festival (the end of February) .

If you want this feature anxiously, you can let someone else do it.

Thank you for understanding. :)

Finally implemented.

Navigation Menu

Repository navigation

Suggest to add "OnKeyXXX" Annotations #1238

1 remaining item

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Suggest to add "OnKeyXXX" Annotations #1238

Description

Activity

WonderCsabo commented on Nov 12, 2014

jiongxuan commented on Nov 12, 2014

WonderCsabo commented on Nov 12, 2014

jiongxuan commented on Nov 12, 2014

WonderCsabo commented on Nov 12, 2014

jiongxuan commented on Nov 13, 2014

jiongxuan commented on Nov 13, 2014

jiongxuan commented on Nov 13, 2014

WonderCsabo commented on Nov 13, 2014

jiongxuan commented on Nov 14, 2014

WonderCsabo commented on Nov 14, 2014

yDelouis commented on Nov 17, 2014

jiongxuan commented on Nov 18, 2014

WonderCsabo commented on Nov 19, 2014

1 remaining item

jiongxuan commented on Nov 20, 2014

jiongxuan commented on Nov 20, 2014

yDelouis commented on Nov 20, 2014

jiongxuan commented on Nov 20, 2014

WonderCsabo commented on Nov 20, 2014

dodgex commented on Nov 20, 2014

jiongxuan commented on Nov 20, 2014

WonderCsabo commented on Nov 20, 2014

WonderCsabo commented on Dec 23, 2014

jiongxuan commented on Dec 26, 2014

WonderCsabo commented on Sep 12, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions