diff --git a/iris/android-app/app/src/main/AndroidManifest.xml b/iris/android-app/app/src/main/AndroidManifest.xml index 5abb34b..5389aa7 100644 --- a/iris/android-app/app/src/main/AndroidManifest.xml +++ b/iris/android-app/app/src/main/AndroidManifest.xml @@ -1,6 +1,15 @@ + + + ViewPeer for IrisViewPeer { self.render(ctx); } + /// Where `AndroidRedrawHandle::request_redraw` (`android/render.rs`) + /// actually lands: `View.postDelayed`'s Runnable resolves to this, on + /// the UI thread, which is what makes it safe to call from a background + /// task's own thread when `post_frame_callback`'s `Choreographer` + /// requirement (a `Looper` on the *calling* thread) is not. Same body + /// as `do_frame` -- draining tasks and rendering immediately is a + /// perfectly good answer to "a background fetch has new state," and + /// avoids a second frame-scheduling path to keep in sync with the real + /// one. + fn delayed_callback(&mut self, ctx: &mut CallbackCtx) { + self.drain_tasks(); + self.render(ctx); + } + fn as_input_connection(&mut self) -> Option<&mut dyn InputConnection> { Some(self) }