Multiple Event Listener Tweaks

[juanpedromoreno]

This PR brings the ability to override the different handlers in the Android Listeners with several overrides (for instance: OnSeekBarChangeListener).

If this contribution looks good to you, in a potential next PR, we would propose replace the current On implementation for the equivalent UnitOn proposed here, and FuncOn for UnitFuncOn, even both could be named On and FuncOn. That means the UnitOn is equivalent to the current On, and in the other hand, UnitFuncOn is equivalent to FuncOn.

From 47Deg, we wish this contribution will be useful.

Please, @stanch , Could you review? Thanks!

[stanch]

Hi and thanks for your contribution!

I’ve left some comments in the main commits, so here I’d just like to do a short summary.

1. I would appreciate if you could look at the contribution section of the README and adapt the commit messages accordingly — it makes it much easier to write changelogs. Thanks!

2. Could you provide more context for the BoolOn handler?

3. The usage of parameter groups, such as (onProgressChanged: UnitFuncEvent), to indicate the desired method is very clever. In fact, it got me confused for a second :) I wonder if we can take it even further and make something super generic, like

   w[Button] <~ handle {
     case Event("click", v: View) ⇒
       toast("Clicked") <~ fry
     case Event("seekBarChange.onProgressChanged", view: SeekBar, progress: Int, fromUser: Boolean) ⇒
       toast(s"Progress changed to $progress") <~ fry
   }

   What do you think?

[juanpedromoreno]

Hi @stanch,

I didn't see your last comment over the PR :( , sorry about it. My last commit message, it doesn't fit with the desired structure.

In the last commit, I've removed the BoolEvent handler type because of it adds some confusion and it really doesn't provide anything new.

About your 3rd point, sounds good. I'm going to take a look and I'll let you know my final thoughts about it ;)

I have to push another commit and I promise it will be with the desired format. Thanks!

[juanpedromoreno]

All comments have been addressed. Could you take another look when you have a chance? Thanks!

As I said in the comment above, your proposal to improve the DSL to manage the events it seems very interesting and looks so good but at this time, I think we could go ahead with this PR such it has been implemented and in the future we could improve it ;) . What do you think?

Also, On is equivalent to UnitOn and FuncOn is equivalent to UnitFuncOn. Does it make sense if we unify them in a next PR?

[stanch]

Hey @juanpedromoreno, sorry it’s taking so long — I’ll only be able to have a thorough look at your changes over the weekend.

[stanch]

Can HandlerType, HUnit, HUnitFunc reuse macroid.EventTweakMacros.{ ListenerType, UnitListener, FuncListener }?

[stanch]

Hi, here goes the second bunch of comments :) At the moment I’m mostly concerned about two things:

1. UnitOn and FuncUnitOn provide the same functionality as On and FuncOn. I would prefer a single implementation, otherwise it’s a bit confusing for the end-user. It could be your implementation — we can remove the old On and FuncOn (not ideal, since it would break source compatibility) or just rewire them to your macros.
2. Some parts of code are almost exactly the same as in the old implementation (e.g. EventTweakMacros.getListener vs MultiEventTweakMacros.getOverride). I think we should unify them as much as possible. Ideally the old macros would be reused where applicable; if they are not flexible enough, you can modify them. Alternatively, the old macros can be deleted and references to them can be replaced with your new ones.

By the way, just a small note — before merging I’ll kindly ask you to squash everything into a single commit with the standardized message format and rebase on top of the current master.

[juanpedromoreno]

Hi @stanch,

I've unified all the duplicated code and functionality into a single event implementation, adding the MultiOn feature.

Please, review it again when you have a chance. Then, when it's ready to merge I will squash all these changes into a single commit with the standardised message format and rebase on top of the current master once more ;)

[stanch]

Hi, sorry for the delay — I’ve just returned from a vacation yesterday. I’ll try to review your changes ASAP, unfortunately before leaving I upgraded IDEA and now I can’t import the project properly :(