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
This general Activity glue crate now supersedes the two separate
native-activity and game-activity crates.
The adds the functionality of both crates as modules within this
new crate but provides a single crate + API that downstream can
depend on as an Activity glue layer.
The new crate exposes two (mutually-exclusive) features for
choosing which Activity backend to build:
* "native-activity"
* "game-activity"
This common crate makes it more practical to write code that's
Activity agnostic.
android_main() now takes an `app: AndroidApp` argument and has an
extern "Rust" ABI instead of "C" ABI.
This should help make it possible to run multiple native Activities in a
single process.
This leaves the InputBuffer abstraction as an implementation detail
and just exposes an API like this for processing input:
app.input_events(|event| {
// handle event
});
The main consideration here was to have an API that could also be
supported via NativeActivity to keep open the possibility of a standard
Android 'glue' API.
The functionality found in egui_winit_platform and egui_wgpu_backend is
now available in the upstream egui-winit and egui-wgpu crates
respectively.
This has simplified the example itself and also removed the dependency
on epi.
The example is now based on egui 0.18 (was previously 0.17)
Since the upstream egui-winit/wgpu crates were generally assuming that
the graphics context and surface can be initialized immediately this
currently builds against a branch that aims to upstream changes that
remove these assumptions:
https://github.com/rib/egui/tree/android-deferred-winit-wgpu
Ref: https://github.com/emilk/egui/pull/1634
Robert Bragg