[Chromoting] TouchInputHandler now listens to events in DesktopView

[Chromoting] TouchInputHandler now listens to events in DesktopView

This change is to continually decouple TouchInputHandler and DesktopView.
Instead of calling functions of TouchInputHandler from DesktopView, now
TouchInputHandler listens to a set of DesktopViewInterface events. So we can
have another implementation listens to the same events concurrently without
impacting current logic.
The advantages of this design are,
1. Eventually we do not need to modify mRenderData in DesktopView anymore, it
can also listen to onClientSizeChanged / onHostSizeChanged event.
2. We can have a dummy DesktopViewInterface to test other components.
3. We can forward exactly same events to several implementations, and compare
their outputs. For example, comparing the events generated by TouchInputHandler
and a new implementation.

This is part remoting desktop Android client refactor work, a design doc is @
https://goo.gl/MA6zjx.

BUG=615277
Committed: https://crrev.com/2e1a7b320eec10d8b69937e4540d781c4bc748bb
Cr-Commit-Position: refs/heads/master@{#398956}

[Hzj_jie, 2016-06-08 01:10:41]

Patchset #1 (id:1) has been deleted

[Hzj_jie, 2016-06-08 01:12:03]

Description was changed from

==========
[Chromoting] TouchInputHandler now listens to events in DesktopView

This change is to continually decouple TouchInputHandler and DesktopView.
Instead of calling functions of TouchInputHandler from DesktopView, now
TouchInputHandler listens to a set of DesktopViewInterface events. So we can
have another implementation listens to the same events concurrently without
impacting current logic.
The advantages of this design are,
1. Eventually we do not need to modify mRenderData in DesktopView anymore, it
can also listen to onClientSizeChanged / onHostSizeChanged event.
2. We can have a dummy DesktopViewInterface to test other components.
3. We can forward exactly same events to several implementations, and compare
their outputs. For example, comparing the events generated by TouchInputHandler
and a new implementation.

This is part remoting desktop Android client refactor work, a design doc is @
https://goo.gl/MA6zjx.

BUG=615277
==========

to

==========
[Chromoting] TouchInputHandler now listens to events in DesktopView

This change is to continually decouple TouchInputHandler and DesktopView.
Instead of calling functions of TouchInputHandler from DesktopView, now
TouchInputHandler listens to a set of DesktopViewInterface events. So we can
have another implementation listens to the same events concurrently without
impacting current logic.
The advantages of this design are,
1. Eventually we do not need to modify mRenderData in DesktopView anymore, it
can also listen to onClientSizeChanged / onHostSizeChanged event.
2. We can have a dummy DesktopViewInterface to test other components.
3. We can forward exactly same events to several implementations, and compare
their outputs. For example, comparing the events generated by TouchInputHandler
and a new implementation.

This is part remoting desktop Android client refactor work, a design doc is @
https://goo.gl/MA6zjx.

BUG=615277
==========

[Hzj_jie, 2016-06-08 01:12:03]

zijiehe@chromium.org changed reviewers:
+ lambroslambrou@chromium.org

[Lambros, 2016-06-09 02:36:39]

lgtm

https://codereview.chromium.org/2047903002/diff/20001/remoting/android/java/s...
File
remoting/android/java/src/org/chromium/chromoting/TwoPointsEventParameter.java
(right):

https://codereview.chromium.org/2047903002/diff/20001/remoting/android/java/s...
remoting/android/java/src/org/chromium/chromoting/TwoPointsEventParameter.java:17:
public final MotionEvent e1;
event1 and event2

Not sure about dx and dy. Maybe xDelta or xDistance or distanceX ? Or leave them
as dx, dy - we've probably used those abbreviations elsewhere.

[Jamie, 2016-06-09 16:42:17]

https://codereview.chromium.org/2047903002/diff/20001/remoting/android/java/s...
File
remoting/android/java/src/org/chromium/chromoting/TwoPointsEventParameter.java
(right):

https://codereview.chromium.org/2047903002/diff/20001/remoting/android/java/s...
remoting/android/java/src/org/chromium/chromoting/TwoPointsEventParameter.java:10:
* An {@link Event} parameter to represent two {@link MotionEvent}s with a {@link
dx} and a
Drive-by: What are the semantics of @link when applied to a variable (as opposed
to a class) name? Do we need it here?

https://codereview.chromium.org/2047903002/diff/20001/remoting/android/java/s...
remoting/android/java/src/org/chromium/chromoting/TwoPointsEventParameter.java:17:
public final MotionEvent e1;
On 2016/06/09 02:36:39, Lambros wrote:
> event1 and event2
> 
> Not sure about dx and dy. Maybe xDelta or xDistance or distanceX ? Or leave
them
> as dx, dy - we've probably used those abbreviations elsewhere.

dx and dy are very commonly used throughout the codebase to represent deltas. I
think that naming is fine.

[Hzj_jie, 2016-06-09 18:08:16]

https://codereview.chromium.org/2047903002/diff/20001/remoting/android/java/s...
File
remoting/android/java/src/org/chromium/chromoting/TwoPointsEventParameter.java
(right):

https://codereview.chromium.org/2047903002/diff/20001/remoting/android/java/s...
remoting/android/java/src/org/chromium/chromoting/TwoPointsEventParameter.java:10:
* An {@link Event} parameter to represent two {@link MotionEvent}s with a {@link
dx} and a
On 2016/06/09 16:42:17, Jamie wrote:
> Drive-by: What are the semantics of @link when applied to a variable (as
opposed
> to a class) name? Do we need it here?

Oh, I am using a wrong syntax, which should be {@link #dx}.

https://codereview.chromium.org/2047903002/diff/20001/remoting/android/java/s...
remoting/android/java/src/org/chromium/chromoting/TwoPointsEventParameter.java:17:
public final MotionEvent e1;
On 2016/06/09 02:36:39, Lambros wrote:
> event1 and event2
> 
> Not sure about dx and dy. Maybe xDelta or xDistance or distanceX ? Or leave
them
> as dx, dy - we've probably used those abbreviations elsewhere.

Sure, both updated.

https://codereview.chromium.org/2047903002/diff/20001/remoting/android/java/s...
remoting/android/java/src/org/chromium/chromoting/TwoPointsEventParameter.java:17:
public final MotionEvent e1;
On 2016/06/09 16:42:17, Jamie wrote:
> On 2016/06/09 02:36:39, Lambros wrote:
> > event1 and event2
> > 
> > Not sure about dx and dy. Maybe xDelta or xDistance or distanceX ? Or leave
> them
> > as dx, dy - we've probably used those abbreviations elsewhere.
> 
> dx and dy are very commonly used throughout the codebase to represent deltas.
I
> think that naming is fine.

Done.

[Hzj_jie, 2016-06-09 18:25:45]

The CQ bit was checked by zijiehe@chromium.org

[Hzj_jie, 2016-06-09 18:25:45]

The patchset sent to the CQ was uploaded after l-g-t-m from
lambroslambrou@chromium.org
Link to the patchset: https://codereview.chromium.org/2047903002/#ps60001
(title: "Resolve review comments")

[commit-bot: I haz the power, 2016-06-09 18:26:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2047903002/60001

[commit-bot: I haz the power, 2016-06-09 18:39:30]

Description was changed from

==========
[Chromoting] TouchInputHandler now listens to events in DesktopView

This change is to continually decouple TouchInputHandler and DesktopView.
Instead of calling functions of TouchInputHandler from DesktopView, now
TouchInputHandler listens to a set of DesktopViewInterface events. So we can
have another implementation listens to the same events concurrently without
impacting current logic.
The advantages of this design are,
1. Eventually we do not need to modify mRenderData in DesktopView anymore, it
can also listen to onClientSizeChanged / onHostSizeChanged event.
2. We can have a dummy DesktopViewInterface to test other components.
3. We can forward exactly same events to several implementations, and compare
their outputs. For example, comparing the events generated by TouchInputHandler
and a new implementation.

This is part remoting desktop Android client refactor work, a design doc is @
https://goo.gl/MA6zjx.

BUG=615277
==========

to

==========
[Chromoting] TouchInputHandler now listens to events in DesktopView

This change is to continually decouple TouchInputHandler and DesktopView.
Instead of calling functions of TouchInputHandler from DesktopView, now
TouchInputHandler listens to a set of DesktopViewInterface events. So we can
have another implementation listens to the same events concurrently without
impacting current logic.
The advantages of this design are,
1. Eventually we do not need to modify mRenderData in DesktopView anymore, it
can also listen to onClientSizeChanged / onHostSizeChanged event.
2. We can have a dummy DesktopViewInterface to test other components.
3. We can forward exactly same events to several implementations, and compare
their outputs. For example, comparing the events generated by TouchInputHandler
and a new implementation.

This is part remoting desktop Android client refactor work, a design doc is @
https://goo.gl/MA6zjx.

BUG=615277
==========

[commit-bot: I haz the power, 2016-06-09 18:39:31]

Committed patchset #3 (id:60001)

[commit-bot: I haz the power, 2016-06-09 18:39:36]

CQ bit was unchecked

[commit-bot: I haz the power, 2016-06-09 18:46:10]

Description was changed from

==========
[Chromoting] TouchInputHandler now listens to events in DesktopView

This change is to continually decouple TouchInputHandler and DesktopView.
Instead of calling functions of TouchInputHandler from DesktopView, now
TouchInputHandler listens to a set of DesktopViewInterface events. So we can
have another implementation listens to the same events concurrently without
impacting current logic.
The advantages of this design are,
1. Eventually we do not need to modify mRenderData in DesktopView anymore, it
can also listen to onClientSizeChanged / onHostSizeChanged event.
2. We can have a dummy DesktopViewInterface to test other components.
3. We can forward exactly same events to several implementations, and compare
their outputs. For example, comparing the events generated by TouchInputHandler
and a new implementation.

This is part remoting desktop Android client refactor work, a design doc is @
https://goo.gl/MA6zjx.

BUG=615277
==========

to

==========
[Chromoting] TouchInputHandler now listens to events in DesktopView

This change is to continually decouple TouchInputHandler and DesktopView.
Instead of calling functions of TouchInputHandler from DesktopView, now
TouchInputHandler listens to a set of DesktopViewInterface events. So we can
have another implementation listens to the same events concurrently without
impacting current logic.
The advantages of this design are,
1. Eventually we do not need to modify mRenderData in DesktopView anymore, it
can also listen to onClientSizeChanged / onHostSizeChanged event.
2. We can have a dummy DesktopViewInterface to test other components.
3. We can forward exactly same events to several implementations, and compare
their outputs. For example, comparing the events generated by TouchInputHandler
and a new implementation.

This is part remoting desktop Android client refactor work, a design doc is @
https://goo.gl/MA6zjx.

BUG=615277

Committed: https://crrev.com/2e1a7b320eec10d8b69937e4540d781c4bc748bb
Cr-Commit-Position: refs/heads/master@{#398956}
==========

[commit-bot: I haz the power, 2016-06-09 18:46:11]

Patchset 3 (id:??) landed as
https://crrev.com/2e1a7b320eec10d8b69937e4540d781c4bc748bb
Cr-Commit-Position: refs/heads/master@{#398956}