http://gwt-code-reviews.appspot.com/1446812/diff/3002/user/src/com/google/gwt/animation/client/AnimationSchedulerImplMozilla.java
File
user/src/com/google/gwt/animation/client/AnimationSchedulerImplMozilla.java
(right):
http://gwt-code-reviews.appspot.com/1446812/diff/3002/user/src/com/google/gwt/animation/client/AnimationSchedulerImplMozilla.java#newcode75
user/src/com/google/gwt/animation/client/AnimationSchedulerImplMozilla.java:75:
handle.canceled = false;
On 2011/05/27 13:17:02, tbroyer wrote:
On 2011/05/27 13:07:01, jlabanca wrote:
> On 2011/05/27 12:11:44, tbroyer wrote:
> > Hox about constructing an AnimationHandleImpl object in
requestAnimationFrame
> > and passing it as an argument here, given that it's always
constructed? (or
> > construct it here in the JSNI if you prefer)
>
> If we pass AnimationHandleImpl as an argument, then we need another
JSNI block
> to create the JavaScriptObject that it contains. Or, we need a
setter to set
> the JavaScriptObject. Personally, I like the way its implemented
now where
> requestAnimationFrameImpl() returns a JSO handle, and the Java code
wraps it
in
> a logical handle.
I was actually suggesting using something like:
class AnimationHandleImpl implements AnimationHandle {
private boolean canceled;
@Override
public void cancel() { this.canceled = true; }
}
and then in the 'wrapper' function:
if ([email protected]::canceled) { ...
Done. That's makes it cleaner.
http://gwt-code-reviews.appspot.com/1446812/diff/3002/user/test/com/google/gwt/animation/AnimationTest.gwt.xml
File user/test/com/google/gwt/animation/AnimationTest.gwt.xml (right):
http://gwt-code-reviews.appspot.com/1446812/diff/3002/user/test/com/google/gwt/animation/AnimationTest.gwt.xml#newcode25
user/test/com/google/gwt/animation/AnimationTest.gwt.xml:25:
<replace-with
class="com.google.gwt.animation.client.testing.StubAnimationSchedulerImpl">
On 2011/05/27 13:17:02, tbroyer wrote:
On 2011/05/27 13:07:01, jlabanca wrote:
> On 2011/05/27 12:11:44, tbroyer wrote:
> > Would probably be better to somehow "inject" a
StubAnimationScheduler into
> > Animation, rather than "hack" AnimationScheduler.
>
> Agreed if we had an injection framework like gin built in to GWT.
Deferred
> bindings are the closest thing we have for now.
How about my proposal for "protected AnimationScheduler
getAnimationScheduler()
{ return AnimationScheduler.get(); }" in Animation?
(which you'd override in TestAnimation in the AnimationTest)
Or maybe a protected constructor that takes an AnimationScheduler
instead? The getter suggests that the AnimationScheduler can be swapped
out at any time. And maybe that's would work, but I'm not sure we want
to support that use case.
http://gwt-code-reviews.appspot.com/1446812/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
