This was done as a part of #214, so I'll close this PR

@notgull I disagree that this was fixed in #214. While the new winit API forces you to handle suspend() and resume(), your PR is panicking quite violently when handling events outside of a pair of these, where no window/surface is active.

I see, thanks for letting me know.

@notgull I've force-pushed a rework of this patch (based on top of #227), let me know what you think before I convert the remaining examples and make a PR.

Note that there is some confusion currently in the winit APIs that we're cleaning up upstream in rust-windowing/winit#3765 and rust-windowing/winit#3779.

Note that, to actually implement the Android backend, there are ideas to (temporarily?) provide the user a fake Vec without stride and the current fixed pixel format. This buffer will be "transformed/converted" into the Android buffer on "submit".

If we do that, we could also pretend to the user that their Surface "always" exist (and give them a buffer), and handle the lifetime internally.
EDIT: After, all we don't expect winit (:crossed_fingers:) to emit RedrawRequested when there is no surface for the window).

EDIT: Never mind this. The surface can't know without winit loop interaction; I was modifying the example utility code here.

@MarijnS95 rebasing on #228 should fix the remaining CI.

Only nightly seems to fail on #[path = ...] mod winit_app;, perhaps irrelevant to this PR?

Yikes, this relative path error, that we first only saw on nightly, is now only showing on stable:

---- src/../README.md - (line 69) stdout ----
error: couldn't read src/../../examples/utils/winit_app.rs: No such file or directory (os error 2)
Error:   --> src/../README.md:78:1
   |
11 | mod winit_app;
   | ^^^^^^^^^^^^^^

error: aborting due to 1 previous error

Couldn't compile the test.

failures:
    src/../README.md - (line 69)

test result: FAILED. 2 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s

Did the fix (assuming it is a fix to how relative paths from content in include_str!() are resolved) get reverted, removed, or regressed on nightly again?

After all, I'd argue the path should be relative to README.md no matter what, not to wherever this file in #[doc = include_str!()]'d which could be at any arbitrary level in our directory tree...

Pushed a "fix", let's see if nightly would then start to break again...

It breaks both stable and our MSRV... How do you want to fix this, @ids1024 @notgull?