Skip to content

Commit bb8eeb7

Browse files
committed
native-activity: emit an InputAvailable event for new input
This reinstates support for notifying applications of new input events without requiring them to always check for input as part of their rendering updates. This makes it possible to build UI applications that might only need to redraw in response to new input. For now GameActivity doesn't emit this event but the plan is to also add support for this in GameActivity. Addresses: #4
1 parent 1ca5f13 commit bb8eeb7

File tree

2 files changed

+26
-18
lines changed

2 files changed

+26
-18
lines changed

android-activity/src/lib.rs

Lines changed: 15 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -81,11 +81,21 @@ pub type StateLoader<'a> = activity_impl::StateLoader<'a>;
8181
#[non_exhaustive]
8282
#[derive(Debug)]
8383
pub enum MainEvent<'a> {
84-
/**
85-
* Unused. Reserved for future use when usage of AInputQueue will be
86-
* supported.
87-
*/
88-
//InputChanged,
84+
/// New input events are available via [`AndroidApp::input_events()`]
85+
///
86+
/// _Note: Even if more input is received this event will not be resent
87+
/// until [`AndroidApp::input_events()`] has been called, which enables
88+
/// applications to batch up input processing without there being lots of
89+
/// redundant event loop wake ups._
90+
///
91+
/// [`AndroidApp::input_events()`]: AndroidApp::input_events
92+
///
93+
/// # Portability
94+
///
95+
/// This is currently only supported with `NativeActivity` with the
96+
/// "native-activity" feature. Applications using `GameActivity` should
97+
/// continue to check for input as part of their rendering updates.
98+
InputAvailable,
8999

90100
/// Command from main thread: a new [`NativeWindow`] is ready for use. Upon
91101
/// receiving this command, [`native_window()`] will return the new window

android-activity/src/native_activity/mod.rs

Lines changed: 11 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -268,19 +268,13 @@ impl AndroidAppInner {
268268
}
269269
ffi::LOOPER_ID_INPUT => {
270270
trace!("ALooper_pollAll returned ID_INPUT");
271-
// For now we don't forward notifications of input events specifically, we just
272-
// forward the notifications as a wake up, and assume the application main loop
273-
// will unconditionally check events for each iteration of it's event loop
274-
//
275-
// (Specifically notifying when input events are received would be inconsistent
276-
// with the current design of GameActivity input handling which we want to stay
277-
// compatible with))
278-
//
279-
// XXX: Actually it was a bad idea to emit a Wake for input since applications
280-
// are likely to _not_ consider that on its own a cause to redraw and it could
281-
// end up spamming enough wake ups to interfere with other events that would
282-
// trigger a redraw + input handling
283-
//callback(PollEvent::Wake);
271+
272+
// To avoid spamming the application with event loop iterations notifying them of
273+
// input events then we only send one `InputAvailable` per iteration of input
274+
// handling. We re-attache the looper when the application calls
275+
// `AndroidApp::input_events()`
276+
ffi::android_app_detach_input_queue_looper(app_ptr.as_ptr());
277+
callback(PollEvent::InputAvailable)
284278
}
285279
_ => {
286280
let events = FdEvent::from_bits(events as u32)
@@ -341,6 +335,10 @@ impl AndroidAppInner {
341335
pub fn input_events<'b, F>(&self, mut callback: F)
342336
where F: FnMut(&input::InputEvent)
343337
{
338+
// Reattach the input queue to the looper so future input will again deliver an
339+
// `InputAvailable` event.
340+
ffi::android_app_attach_input_queue_looper(app_ptr.as_ptr());
341+
344342
let queue = unsafe {
345343
let app_ptr = self.ptr.as_ptr();
346344
if (*app_ptr).inputQueue == ptr::null_mut() {

0 commit comments

Comments
 (0)